Risk Scoring
The score exists, but it is secondary to the findings list. Read it as a trend indicator between milestones, not as an absolute measure or an SLA metric.
The formula
Why density, not counts
The first formula was a weighted sum of finding counts multiplied by a constant, and it saturated at 100 on the very first realistic SBOM. A score that cannot move is worse than no score, because it looks informative. That was BUG-08.
Dividing by component count makes the score comparable across ECUs of different sizes and across milestones of the same ECU. A 200-component BOM with 10 critical components is a smaller problem than a 40-component BOM with the same 10, and density expresses that.
Why these weights
The three weights encode a deliberate priority order:
| Weight | Term | Rationale |
|---|---|---|
| 0.5 | density — what is in the BOM | Composition matters most |
| 0.3 | blockerDensity — how many findings it produced | Findings matter next |
| 0.2 | qualityPenalty — how well documented it is | Documentation quality is the smallest term, because a beautifully documented GPL violation is still a GPL violation |
An SBOM that cannot be trusted should not score well — but it should not score terribly either, which is why the penalty is capped at 20 % of the total.
Two honest caveats
:::warning The weights are judgement, not calibration They have not been fitted against historical outcomes, and the test suite only asserts that the score is in range — there is no golden-value test. If you change the formula, pin expected scores for both fixtures first so the change is visible. :::
The score is normalised by component count, which means it is comparable — but it also means a single-component BOM with one GPL component scores very high. Sanity-check against the findings list before quoting a number to anyone.
Worked example
For the bundled 4.2.0 demo SBOM:
| Input | Value |
|---|---|
| Components | 42 |
| Findings | CRITICAL 13, HIGH 30, MEDIUM 8 |
| SBOM quality | 50 % (6 / 12 checks) |
| Score | 61 — band HIGH |
The 4.1.0 → 4.2.0 diff reports a risk delta of +3, driven by 2 new critical findings.
Reading the band
| Band | Score | Interpretation |
|---|---|---|
| CRITICAL | 70 – 100 | Do not sign off without legal involvement |
| HIGH | 45 – 69 | Substantial obligation load; triage before the milestone |
| MEDIUM | 20 – 44 | Review the findings; usually manageable |
| LOW | 0 – 19 | Routine |
These bands are a convention, not a policy. Your programme's gate criteria belong in the
gate command thresholds, where they are
visible in version control.