Open source, SBOM and vulnerabilities, clearly explained.
Short, factual explanations for software, product and compliance teams: what the terms mean, what matters in practice and where the primary sources are.
What is an SBOM and what must it contain?
An SBOM (Software Bill of Materials) is a machine-readable inventory of all components in a piece of software, with version, origin and dependencies. It is the basis for knowing quickly whether a product is affected when a new vulnerability appears. The Cyber Resilience Act requires manufacturers to maintain an SBOM covering at least the top-level dependencies.
Read article TRIAGEVulnerability triage: from CVE report to decision.
Triage means assessing a vulnerability finding in a structured way: is our product actually affected, how urgent is it, and what do we decide? Severity (CVSS) alone is not enough; likelihood of exploitation (EPSS), evidence of exploitation (KEV) and how the component is actually used in the product all matter. The outcome is documented traceably, for example as a VEX statement.
Read article GOVERNANCEOpen-source governance: rules, licences, ownership.
Open-source governance defines how an organisation selects, uses, documents and maintains open source. It combines licence compliance, security processes and clear ownership. The aim is not to slow open source down but to make its use traceable and accountable.
Read article CRACyber Resilience Act: what manufacturers should know about open source.
The Cyber Resilience Act (Regulation (EU) 2024/2847) sets cybersecurity requirements for products with digital elements made available in the EU. For manufacturers this means, among other things: document components (SBOM), handle vulnerabilities, provide security updates and report actively exploited vulnerabilities on time. The reporting duties have applied since 11 September 2026, the remaining requirements apply from 11 December 2027.
Read articleFrom backport to VEX: the key terms, each explained in one sentence.