Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.

How is an engineering risk score calculated and what can you trust?

Updated

An engineering risk score combines delivery, security, debt, lifecycle, and AI-adoption signals into one coverage-weighted view. ShipReady Metrics publishes its methodology; the score is an SRM measurement, not an industry standard or audit opinion.

Engineering risk score guide, last verified 10 September 2026 against ShipReady Metrics /methodology and /what-we-measure (vendor documentation), DORA and SPACE frameworks for delivery context, and CISA KEV, FIRST EPSS, and CVSS v3.1 issuing-body definitions for vulnerability prioritization. Not legal advice.

What an engineering risk score is — and what it is not

Audience: a CTO, investor, or engineering leader who needs to understand how a composite engineering risk score is built so they can read it honestly and act on gaps rather than a letter grade alone. This page describes ShipReady Metrics' engineering risk score — a vendor composite measurement. It is not legal advice.

It is not an industry standard. No ISO, NIST, or regulator publishes an authoritative engineering risk score for software organizations. It is not an audit opinion, not a certification, not a due-diligence pass/fail, and not a prediction that nothing will break. It is a coverage-weighted rollup of measurable engineering signals from connected systems, labeled as an SRM recommendation.

Inputs and issuing-body definitions versus SRM weighting

Underlying signals use public definitions where they exist. How those signals are combined into domain scores and a composite is ShipReady Metrics' vendor methodology — inspectable on /methodology and /what-we-measure, not prescribed by DORA, SPACE, or CVSS.

Signal sources versus SRM composite (not a ranking; not legal advice; last verified 10 September 2026)
Signal familyIssuing body or frameworkWhat SRM measuresKind of text
Delivery throughput and stabilityDORA research programDeployment frequency, lead time, change failure rate from production deploy events; MTTR when an ops source is connectedFramework guidance → SRM Delivery Health score
Vulnerability prioritizationCISA KEV catalog, FIRST EPSS, CVSS v3.1Open findings ordered by exploitation evidence; KEV cap on Security Readiness when applicableIssuing-body definitions → SRM Security Readiness score
Maintainability and debt proxiesISO/IEC 25010 maintainability characteristic (context)Code churn, complexity, and defect-density proxies over eligible repositoriesStandard context → SRM Technical Debt score (inverted: lower debt raises score)
End-of-life exposureVendor EOL catalogs (context)Supported versus past-EOL runtimes and dependencies with criticality weightingVendor EOL data → SRM Lifecycle Risk score
AI-assisted delivery contextGit commit metadata, Copilot Metrics API (when granted)AI-authored-code floor from attributed commits; adoption context for AI ROI — not a classifierTelemetry → SRM AI ROI and AI Readiness context
Composite engineering risk scoreShipReady Metrics methodologyCoverage-weighted rollup across measured domains; unmeasured domains excluded, not guessedSRM recommendation — not an industry standard

Denominators and coverage — confidence follows coverage

Every rate-based signal needs an explicit denominator. Change failure rate is failed deploys divided by total successful production deploys in the window — not total commits. AI-authored share is attributed AI commits divided by total commits in the eligible repository set — not lines of code unless you define lines. Security finding density is open findings divided by repositories in scope — and the scope must be stated.

Coverage-as-confidence means a domain with thin or single-source data carries less weight in the composite than a domain with multiple feeding connectors. A domain with no connected source is excluded entirely and reads Not measured. The engineering risk score does not fill gaps with defaults that look like measurements.

Repository scope (signed-in Integrations → repository scope) sets which repositories feed engineering scores. Excluding a repo removes its signal from denominators; it does not silently average the rest as if the excluded repo never existed without disclosure.

  • Numerator and denominator are recorded per signal — ask for them before trusting a trend.
  • Partial estate coverage is labeled; org-wide claims require org-wide connectors.
  • Not measured is an honest state, not a failure to be hidden.
  • Composite letters withhold when coverage is below SRM's confidence gate.

How to read a rating without overclaiming

Read the score as a map of measured risk posture, not a guarantee. A high Delivery Health score with Security Readiness Not measured is a partial picture — the composite should not be quoted without naming what was absent.

Trends matter more than absolutes when definitions are held constant. A one-point move driven by newly connected coverage is a coverage event, not necessarily an improvement.

Compare domain scores alongside the composite. Technical Debt, Security Readiness, Delivery Health, Lifecycle Risk, Cloud Health, and IT Modernization each tell a different story; collapsing to one number for diligence slides loses the actionable detail.

No absolute claims: this score does not mean your software is safe, compliant, or investment-ready without reviewing the underlying evidence and your counsel's judgment.

Legal requirement versus guidance versus SRM recommendation

CVSS, EPSS, and KEV are public scoring and catalog schemes from their issuing bodies — useful for prioritization, not mandates that you achieve a particular composite score. DORA and SPACE are research frameworks for delivery and productivity measurement. ShipReady Metrics' engineering risk score is a vendor composite that applies SRM weights and coverage rules to connected data. Label it accordingly in board packs and diligence: SRM measurement, not industry standard, not legal advice.

What you need to do now

As of last verification on 10 September 2026. Not legal advice.

  • Ask which domains fed the composite and which read Not measured.
  • Request numerators and denominators for any rate-based sub-score before citing it externally.
  • Connect missing sources rather than interpreting absence as low risk.
  • Read /methodology and /what-we-measure for the current weight table — it can change as the product evolves.
  • The measure-ai-generated-code-risk guide on this site is the AI-code risk signals page. The measure-engineering-excellence guide on this site is the balanced framework page. The how-shipreadymetrics-measures-ai-roi-engineering-health guide on this site is the product capstone.

Checklist

Question list for buyers and leaders — not a certification and not legal advice.

  • Is the score labeled as ShipReady Metrics' methodology, not an industry standard?
  • Are unmeasured domains visible in the same view as measured ones?
  • Can each domain score be traced to connectors and repositories in scope?
  • Are vulnerability priorities using KEV, EPSS, and CVSS definitions from issuing bodies?
  • Is the composite quoted with coverage context, not as a standalone pass/fail?
  • Have we avoided absolute safety or compliance claims from a numeric score?

Where this shows up in ShipReady Metrics

The ShipReady Score (/dashboard, /methodology) is a 0–100 composite of up to nine domain scores, each computed only from connected data. Unmeasured domains are excluded from the composite rather than given placeholder grades.

Engineering Excellence family domains — Technical Debt, Security Readiness, IT Modernization, Lifecycle Risk, Delivery Health, Cloud Health — feed the engineering slice of that composite. AI ROI and AI Readiness are separate domains with their own methodologies.

Signed-in Security → Findings ingests SAST, DAST, Dependabot, and secret-scanning alerts with KEV/EPSS/CVSS prioritization. Findings inform Security Readiness; they are not a penetration test or audit opinion.

ShipReady Passport (/passports, public trust-center marketing at /solutions/trust-center) shares a point-in-time snapshot of measured domains. It is evidence sharing, not certification.

This product does not issue engineering risk certifications and does not replace counsel, auditors, or technical due diligence.

Primary sources (last verified 10 September 2026)

Vendor methodology authority: ShipReady Metrics /methodology and /what-we-measure — SRM documentation for weights, coverage gates, and domain definitions. SRM recommendation.

DORA research program (dora.dev, Accelerate, State of DevOps reports) — delivery metric context; industry guidance.

SPACE framework (ACM Queue, 2021) — multidimensional productivity context; industry guidance.

CVSS v3.1 specification (FIRST) — vulnerability severity scores.

EPSS specification (FIRST) — exploitation probability scores.

CISA Known Exploited Vulnerabilities catalog — confirmed exploitation list.

ISO/IEC 25010:2011 — product quality model context for maintainability signals.

Not legal advice. Not an exhaustive source list.

Frequently asked questions

Is the ShipReady engineering risk score an industry standard?

No. It is ShipReady Metrics' vendor composite built from domain scores and documented on /methodology. DORA, SPACE, CVSS, EPSS, and KEV are public frameworks and definitions SRM draws on for signals — not endorsements of the composite.

Can we cite this score in due diligence as proof of low risk?

You can cite it as a measurement from connected systems with stated coverage, alongside the underlying domain scores and evidence. It is not an audit opinion, not a certification, and not a substitute for technical due diligence or counsel.

Why did the composite change when we only connected a new repository?

Because denominators and coverage changed. New repositories add signal and can shift rates. A coverage change is not the same as a posture improvement — read the coverage headline alongside the score.

What happens when a domain is Not measured?

It is excluded from the composite weight sum. The platform does not invent a neutral middle score. The dashboard shows how many domains are measured so readers know what is missing.

Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.