example-monorepo

1Scope and approach

An SBOM describes the software at the moment it was generated. This assessment matched every declared component against published advisories and ranked each finding by fixed, published rules. It did not run or inspect the software.

Components declared

20

Components checked

20 (100%, high confidence)

Package identifiers present

20 of 20

Dependency graph

Absent, so direct and transitive dependencies cannot be told apart

VEX statements

None supplied

The inventory collection time was not recorded separately, so the assessment date does not prove the inventory is current.

2Remediation plan

One action per package, ordered by exploitation first and then severity. Each target is the lowest version that clears the most findings, checked against current advisories. It was not tested for compatibility with your application, so verify the deployed result with a fresh scan. Appendix A lists every finding each upgrade clears.

Act now 2

Upgrades that clear a Fix now finding: a fix exists and the vulnerability is known exploited or likely to be.

Next 16

Upgrades whose most urgent finding is Fix soon: a moderate exploitation signal or high severity.

Later 1

Upgrades with no sign of urgency. Worth doing with routine dependency updates.

3Changes and decisions

Baseline assessment. A second saved scan is needed to show what changed.

Recorded decisions

0 upgrades were marked done, and 0 findings were ruled out by the account or by VEX. Marking an upgrade done is a declaration, not verified remediation.

4Findings without a fix

No published version resolves these. Each needs a mitigation, a compensating control, a replacement component, or a recorded risk decision.

5Regulatory context: the EU Cyber Resilience Act

Annex I, Part II of Regulation (EU) 2024/2847 asks manufacturers to document the components in their products and handle vulnerabilities without delay. This table maps what this assessment evidences. It is a readiness view, not a conformity assessment, and nothing here makes a product compliant or certified.

Appendix B

Component inventory (20)

The full inventory, including components that could not be analysed. A component with no usable package URL is a blind spot, not a clean result.

Appendix C

Declared licenses

Declarations supplied by the inventory, not independently verified license conclusions. No license policy was applied to this review. Missing declarations and compound expressions need review, and no legal compliance is implied.

Appendix D

Method and data sources

Tiers

• Fix now: a fix exists AND (the vulnerability is in CISA KEV OR EPSS >= 0.50)
• Fix soon: a fix exists AND (EPSS >= 0.10 OR CVSS >= 7.0 OR published severity is high/critical)
• Monitor: a fix exists but no exploitation signal and no high severity
• No fix available: reported separately so it cannot dilute the action list; flagged urgent when in CISA KEV

Order of upgrades

1. Highest tier contained in the action
2. Number of KEV-listed vulnerabilities resolved
3. Highest EPSS score resolved
4. Number of vulnerabilities resolved
5. Smaller upgrade distance (patch before minor before major)
6. Direct dependencies before transitive ones

Recommended version

The recommended version is the lowest version at or above the highest version present that resolves the most known vulnerabilities for that package, not the latest release. This keeps upgrades applicable.

Grade

• Start at 100.
• Subtract 25 for any vulnerability in CISA KEV that has a fix, and 15 for any in KEV without one.
• Subtract 8 per fix-now action, up to 40.
• Subtract 3 per fix-soon action, up to 20.
• A finding published with no severity score counts as high: an upgrade that clears one, otherwise rated monitor, is counted as fix soon.
• Subtract 50 if the SBOM declares no components at all, because nothing can be concluded from it.
• Subtract up to 20 in proportion to how much of the SBOM could not be matched.
• The grade is flagged as possibly optimistic, with no score change, if any vulnerability data source failed during the scan.
• A: 90+, B: 75+, C: 60+, D: 40+, F: below 40.

For this assessment: Fix-now actions (-16), Fix-soon actions (-20), No published severity.

Data sources

Appendix E

Glossary

SBOM

Software bill of materials: the list of components, and their versions, inside a piece of software.

Package URL (purl)

A standard identifier for a package, such as pkg:npm/lodash@4.17.21. Without one a component cannot be matched reliably.

Finding

One published advisory affecting one component. The same CVE in two components is two findings.

CVE

Common Vulnerabilities and Exposures: the public identifier for a known vulnerability.

CVSS

Common Vulnerability Scoring System: a 0 to 10 rating of how severe a vulnerability is, not how likely it is to be used.

EPSS

FIRST's Exploit Prediction Scoring System: the estimated probability that a vulnerability is exploited in the next 30 days.

CISA KEV

The US Cybersecurity and Infrastructure Security Agency's catalogue of vulnerabilities known to be exploited.

VEX

Vulnerability Exploitability eXchange: a supplier statement that a vulnerability does or does not affect a product, and why.

Fix now

A fix exists, and the vulnerability is known exploited or likely to be (EPSS 50% or more).

Fix soon

A fix exists, and there is a moderate exploitation signal or high severity.

Monitor

A fix exists, and nothing points to urgency.

No fix

No published version resolves it. It needs a mitigation or a risk decision.

Appendix F

Limitations

• sbomtriage analyses the inventory declared in your SBOM. It does not read your source code, so it cannot tell whether a vulnerable function is ever reached or executed.
• A "Fix now" rating reflects known exploitation or a high predicted exploitation probability. It is not evidence that you have been compromised.
• Results are only as complete as the SBOM. Components your SBOM generator missed (vendored code, statically linked libraries, bundled assets) are invisible here.
• Compensating controls, network position, and runtime configuration are not considered. A finding that is unreachable in your deployment will still be listed.
• Advisory data comes from OSV.dev. Vulnerabilities published very recently, or not covered by OSV for your ecosystem, will not appear.
• The input contains no dependency graph, so direct and transitive dependencies cannot be distinguished. Lockfiles rarely carry one.
• No VEX statements were found in this SBOM, so no findings have been ruled out by the vendor. Some listed vulnerabilities may not apply to how the component is used.
• Severity for advisories published only with a CVSS v4.0 vector is shown qualitatively; no v4 base score is computed rather than presenting an approximation as fact.