example-monorepo

grade C · last checked 5 days ago · 1 recent history entry

What you can evidence for Annex I, Part II

What the CRA asks for	What this scan shows
Components identified and documented	20 components, from CycloneDX JSON
An SBOM in a commonly used, machine-readable format	CycloneDX JSON, and 100% carry a package identifier and version
Vulnerabilities identified	181 found, 0 in CISA KEV A KEV listing is an early signal that Article 14 reporting may apply. Whether a flaw is exploited in your product is a separate assessment.
Remediated without delay	19 upgrades recommended 1 have no available fix and need a different answer
Security updates and secure design (rest of Annex I)	Outside what a dependency scan can see

Assessed 2026-09-30.

Wording you can adapt

for your own technical documentation

Component inventory

For the part of your technical documentation that describes what is in the product.

The software bill of materials for example-monorepo is maintained in CycloneDX JSON, a commonly used machine-readable format. It records 20 components. 20 of these (100%) carry a package identifier and version sufficient for automated vulnerability matching; the remainder are listed and were not treated as free of vulnerabilities. The inventory was last assessed on 2026-09-30.

{{Describe how the SBOM is produced and at what point in your build it is regenerated.}}

Anything in {{ }} is a fact only you can supply. The copied text includes a line saying it’s drafting help, not legal advice. Leave that line in until you’ve reviewed the paragraph.

Vulnerability handling

For describing your process rather than the result, since the process is what regulators ask about.

Components are checked against public vulnerability data (OSV.dev), CISA’s Known Exploited Vulnerabilities catalogue and FIRST EPSS exploitation probability. The most recent assessment of example-monorepo on 2026-09-30 identified 181 vulnerabilities, of which 0 are listed in the CISA KEV catalogue, and produced 19 recommended component upgrades. Remediation is prioritised by whether a fix exists and by evidence of exploitation, rather than by severity score alone.

{{State who reviews these findings, how often, and your target time to remediate each priority level.}}

Anything in {{ }} is a fact only you can supply. The copied text includes a line saying it’s drafting help, not legal advice. Leave that line in until you’ve reviewed the paragraph.

A vulnerability you haven’t fixed

Write one for each finding you’re carrying. Customers and auditors ask for this paragraph, so it’s worth having it written before they do.

{{CVE or advisory identifier}} affects {{component and version}} in example-monorepo. Assessment date: 2026-09-30.

{{State the outcome and the grounds: not exploitable in this product because …, or mitigated by …, or scheduled for remediation in release … . If you are claiming it is not exploitable, say what in your product makes that true. An unsupported claim is worse than an open finding.}}

Anything in {{ }} is a fact only you can supply. The copied text includes a line saying it’s drafting help, not legal advice. Leave that line in until you’ve reviewed the paragraph.

Words that cause trouble

Avoid	Why	Say instead
CRA compliant / CRA certified	Compliance is a legal conclusion and, for some product classes, a notified body’s decision. No scan establishes it, and claiming it in your own documentation invites exactly the scrutiny you don’t want.	Describe what you did: "components identified and documented", "vulnerabilities assessed on <date>".
Not affected	Stated flatly, it asserts a technical fact about your product that a component list can’t support. It’s also the claim your customers most often push back on.	Give the grounds: "not exploitable in this product because the affected function is not reachable from any entry point".
Secure / no known vulnerabilities	It’s true only of what was checked, and the coverage figure usually shows that wasn’t everything. An absolute claim ages badly within days.	Bound it: "no known vulnerabilities in the <n> components that could be matched, as of <date>".
Fully remediated	Ticking off a recommended upgrade records a decision. It doesn’t prove the software shipped with it.	"Upgraded to <version> in release <x>", which is checkable.
Real-time monitoring	Scheduled re-checks against a public database aren’t real-time, and an incident can land in the gap between them.	"Re-assessed <daily/weekly> against updated vulnerability data".