Resources
Does an SBOM satisfy CRA Article 14?
No. A software bill of materials is an inventory of components and versions. EU CRA Article 14 is a manufacturer reporting duty for actively exploited vulnerabilities and severe incidents — plus user notification and a corrective measure.
Security teams often generate SBOMs because customers and CRA-style questionnaires ask for them. That work is real. It does not close Article 14. When a clock starts, auditors and CSIRTs ask what you knew, what you told users, and what you shipped — not whether a CycloneDX file exists in a bucket.
What to keep besides an SBOM
- 1
Use the SBOM to name versions, not to close the incident
Map CVEs and agent-tool dependencies to a versioned SBOM so the reporting packet can identify the product. Stop there. The SBOM is an input to the packet, not a substitute for it.
- 2
Record how you became aware
Write the intake path: customer report, runtime deny, MCP tool abuse, CVE feed, or CSIRT notice. Store the timestamp. Article 14 clocks run from becoming aware, which an SBOM cannot timestamp.
- 3
Export what the product or agent actually did
Keep logs that show the agent, tool, policy decision, and whether the action was blocked. For connected products, retain the equivalent incident telemetry. This is the difference between inventory and evidence.
- 4
Attach user notices and the reporting-platform copy
Save what you submitted through the CRA single reporting platform and what you told affected users. An SBOM does not notify anyone.
- 5
Cite the pull request as the corrective measure
A library bump listed in the next SBOM is not enough unless the change is reviewable and constrained. Finding → Fix Spec → PR is how you show a fix that preserves product intent. That path is a scoped remediation POC; Gateway is how you keep the runtime log.
Frequently asked questions
- Does an SBOM satisfy CRA Article 14?
- No. An SBOM lists components and versions. Article 14 of Regulation (EU) 2024/2847 requires manufacturers to notify actively exploited vulnerabilities and severe incidents, inform users, and keep a path to a corrective measure. Inventory is necessary; it is not the report, the notice, or the fix.
- What is an SBOM useful for under CRA-style duties?
- An SBOM helps you name the product version, affected packages, and where a CVE might sit. Use it to fill identity fields in a reporting packet and to scope a patch. Do not treat SBOM generation as proof you handled an exploited vulnerability.
- If we publish SBOMs, what else do security teams still need?
- Awareness timestamps, runtime or intake evidence of exploitation or a severe incident, copies of CSIRT/ENISA submissions, user advisories, mitigations already applied, and a reviewable change that implements the corrective measure. For agents, that includes which tool or MCP server was involved.
- Can a scanner plus SBOM replace Gateway logs?
- No. Scanners and SBOMs describe known components and static findings. Article 14-style questions are about what happened, when you knew, what you blocked, and what you shipped. UnitOne Gateway inspects agent traffic in your network and exports that operational trail.
- Is this legal advice on CRA scope?
- No. Whether your product is in scope, and what conformity assessment you need, is a legal classification. This page is practical AppSec evidence for teams that already expect Article 14-style reporting.
Export Article 14-style logs from Gateway
Start free to keep runtime evidence in your network. An SBOM still belongs in your release process — Gateway covers the part an inventory file cannot: what the agent did, what you blocked, and what you can export.