Question 1

Does EU CRA apply to my open-source project?

Accepted Answer

The CRA applies primarily to software placed on the EU market for commercial purposes. Open-source software developed without a commercial relationship is largely exempt, but contributors who offer open-source software commercially lose that exemption. If your open-source project is the basis for a commercial product, consult legal counsel. For the full scope breakdown, see SBOM and Vulnerability Scanning: What the EU CRA Means for Your Dependencies.

Question 2

What format does the EU CRA require for SBOMs?

Accepted Answer

The CRA regulation references machine-readable SBOMs but doesn't mandate a specific format as of current guidance. SPDX and CycloneDX are both widely accepted and supported by all major SBOM tools. ENISA guidance (expected before the December 2027 deadline) will likely clarify format requirements. Generating both formats from your SBOM tool covers the likely options.

Question 3

Is EPSS required for EU CRA compliance?

Accepted Answer

Not explicitly — the regulation doesn't mention EPSS by name. But the 24-hour reporting requirement for "actively exploited vulnerabilities" requires you to know when a vulnerability becomes actively exploited. EPSS provides early warning before a CVE reaches KEV status. KEV is the definitive signal — a CVE appearing in the CISA KEV catalog is actively exploited by definition, and that's when the 24-hour clock starts. Tools with native KEV monitoring (Grype, GeekWala) are better positioned for this requirement than tools that require manual KEV correlation.

Question 4

Can I generate an SBOM with Trivy and then scan it with Grype?

Accepted Answer

Yes. Trivy generates SBOMs in CycloneDX and SPDX formats. Grype can scan those SBOMs directly: grype sbom:sbom.json. This is a legitimate workflow if you want Trivy's broad container scanning for SBOM generation and Grype's EPSS + KEV enrichment for vulnerability scanning. The formats are compatible.

Question 5

What's the difference between an SBOM and a VEX document?

Accepted Answer

An SBOM lists what components are in your software. A VEX (Vulnerability Exploitability eXchange) document asserts whether a known vulnerability in one of those components actually affects your product in its deployed configuration. For example, if CVE-2024-1234 affects a library you use, but you never call the vulnerable function, a VEX document records that assertion with justification. VEX helps narrow which CVEs actually require CRA reporting. For a full explanation, see What is VEX and Why it Matters for Vulnerability Management.

Question 6

Do I need an SBOM tool and a separate vulnerability scanner?

Accepted Answer

Not necessarily. Grype and Trivy both generate SBOMs and scan them in the same tool. The Syft + Grype split (generate SBOM separately, then scan) is an architectural choice that gives you more control over the SBOM artifact. If you want a single command that outputs "here are the vulnerabilities in my container image with KEV flags," Trivy handles that. If you want explicit SBOM artifacts for compliance documentation, Syft + Grype gives you more control.