Question 1

What Is the EU Cyber Resilience Act?

Accepted Answer

The Cyber Resilience Act (CRA) is EU legislation that establishes cybersecurity requirements for "products with digital elements" — essentially any hardware or software product that connects to a network or processes data. The European Parliament adopted the regulation in October 2024. It entered into force in December 2024.

The CRA is the EU's response to a straightforward problem: most software ships without meaningful security guarantees, and consumers and businesses have no way to evaluate the security posture of the products they use. Supply chain attacks like SolarWinds, Log4Shell, and the xz utils backdoor demonstrated that software security is a systemic risk, not just an individual vendor concern.

Who it applies to:

The CRA targets manufacturers — the entity that places a product with digital elements on the EU market. This includes:

- Companies selling software products to EU customers (even if headquartered outside the EU)
- SaaS platforms where the software component is distributed (e.g., client applications, SDKs, plugins)
- Open-source projects that are commercialized by a corporate entity (though volunteer-driven open-source maintainers are explicitly exempt)
- Hardware manufacturers shipping firmware or embedded software
- Importers and distributors who place third-party products on the EU market

The scope is broad. If you sell or distribute software that reaches EU end users, you are almost certainly in scope.

What it doesn't cover:

The CRA explicitly exempts non-commercial open-source software developed by individuals or non-profit foundations. If you're a volunteer maintainer publishing packages to npm or PyPI without commercial intent, the CRA doesn't apply to you directly. But if a company incorporates your package into their commercial product, that company is responsible for the CRA obligations — including understanding the security posture of every dependency they ship.

Question 2

What Is an SBOM?

Accepted Answer

A Software Bill of Materials (SBOM) is a machine-readable inventory of all components in a software product — think of it as a nutrition label for software. Instead of listing calories and ingredients, an SBOM lists package names, versions, suppliers, and relationships.

What an SBOM contains:

- Package identifiers: Names, versions, and package URLs (purl) for every component
- Supplier information: Who created or published each component
- Dependency relationships: Which packages depend on which other packages
- License information: What license governs each component
- Hash values: Cryptographic digests for verifying component integrity

Standard SBOM formats:

Two formats dominate the SBOM landscape:

| Format | Maintained By | Strengths | Ecosystem Adoption |
|--------|---------------|-----------|-------------------|
| SPDX (Software Package Data Exchange) | Linux Foundation | ISO standard (ISO/IEC 5962:2021), strong license compliance | Widely adopted in Linux, automotive, enterprise |
| CycloneDX | OWASP | Security-focused, includes VEX support, lightweight | Growing fast in application security, DevSecOps |

Both formats express the same core information. The CRA doesn't mandate a specific format — it requires machine-readability and "commonly used" formats. Either SPDX or CycloneDX satisfies this requirement.

Where SBOMs come from:

SBOMs are generated from the same dependency metadata your package manager already tracks. Your package-lock.json, poetry.lock, composer.lock, go.sum, Cargo.lock, Gemfile.lock, or packages.lock.json already contains most of the information an SBOM needs. SBOM generators parse these lock files and produce the standardized output.

Question 3

What Is VEX?

Accepted Answer

VEX (Vulnerability Exploitability eXchange) is a companion standard to SBOM that answers the question: is this vulnerability actually exploitable in my product?

An SBOM might show that your product includes lodash@4.17.20, and a vulnerability scanner might flag CVE-2021-23337 (prototype pollution). But if your code never calls the affected function (lodash.template with user-controlled input), the vulnerability exists in your dependency tree but is not exploitable in your specific product.

VEX provides a machine-readable way to document this:

VEX statuses:

| Status | Meaning |
|--------|---------|
| Not Affected | The vulnerability is not exploitable in this product |
| Affected | The vulnerability is exploitable — action required |
| Fixed | The vulnerability was present but has been remediated |
| Under Investigation | Assessment in progress |

How VEX connects to EPSS and KEV:

VEX decisions become more defensible when they're backed by exploitation intelligence. Consider this decision framework:

- EPSS near zero AND not on KEV AND reachability analysis confirms no call path → Strong case for "Not Affected" VEX status. The vulnerability is theoretically present but practically irrelevant.
- EPSS > 0.1 OR on KEV → Even if reachability analysis suggests the code path isn't called, the risk profile is elevated. Investigate more thoroughly before issuing a "Not Affected" status.
- On CISA KEV → Active exploitation confirmed. Unless you can conclusively prove your product's usage is not exploitable, treat this as "Affected" and prioritize remediation.

VEX is not yet required by the CRA in its first compliance phase, but it's the natural complement to SBOM. Once you have an SBOM and vulnerability scanning in place, VEX is how you document the gap between "vulnerabilities present in your dependency tree" and "vulnerabilities that actually affect your product."