Open source SBOM and VEX evidence for end-of-life software
What PCI DSS, the Cyber Resilience Act, DORA and CMMC ask for.

Counts from the OSSeva CVE directory as of 20 October 2026: for each ended line, the CVEs published after its end date whose affected range names that line. A scanner that reads only the version number reports all of them as open. On a patched build, each one needs a statement: fixed in this build, or not affected and why.

Requirement 6.3.3 asks for critical and high-security patches, ranked under 6.3.1, to be installed within one month of release; the PCI SSC's FAQ 1597 (May 2025) adds that you set the risk ranking for your own environment. On a line the community has stopped patching, no upstream patch is released, so the clock has nothing to start from unless someone ships the fix. A backported build has its own release date, and the CVE record ties that date to the advisory.

Requirement 12.3.4 is the annual review. It asks for four things, and each has a document you can keep. 6.3.2 and 12.3.4 were best practice until 31 March 2025 and are required now.

Regulation (EU) 2024/2847 applies in full from 11 December 2027, but Article 14 has applied since 11 September 2026, and Article 69(3) extends it to every in-scope product placed on the market before December 2027. A manufacturer must send an early warning of an actively exploited vulnerability within 24 hours of becoming aware, a notification within 72 hours and a final report within 14 days after a corrective measure is available. When the vulnerable code is an open source component inside your product, you need to know quickly whether your build is affected and which build fixes it. A VEX statement and a CVE record give you that answer.

The SBOM duty sits in Annex I, Part II, point 1: identify and document vulnerabilities and components, including an SBOM in a commonly used, machine-readable format covering at the very least the top-level dependencies. Article 13(5) and 13(6) add due diligence on third-party components, including open source, and a duty to report a vulnerability found in a component to whoever maintains it and to remediate it. Article 13(8) sets a support period of at least five years unless the product is expected to be in use for less time. Whether the Act applies to you turns on whether you make a product with digital elements available in the course of a commercial activity; that is a question for your counsel and your assessor, and OSSeva makes no CRA conformity claim.

DORA has applied since 17 January 2025. Article 8 asks you to identify and document ICT assets and the processes that depend on ICT third-party providers, and Article 9(4)(f) asks for documented policies for patches and updates. Article 28(3) requires a register of information on every contractual arrangement with an ICT third-party provider, and Article 28(8) requires exit strategies for services that support critical or important functions, with alternative solutions and transition plans, tested and reviewed periodically.

For an extended-support provider, that means a register entry, a documented patch window and an exit plan. OSSeva's patches apply to upstream source with no fork, so the exit is to a supported upstream release or another provider, not off a proprietary build. The scope of that move depends on how far the line sits from the supported release (schema size, code volume, downtime window), which is why the plan names the target version.

CMMC Level 2 requirements are identical to NIST SP 800-171 Rev. 2 (32 CFR 170.14). Control 3.14.1 reads "Identify, report, and correct system flaws in a timely manner," and its discussion says organizations identify the systems affected by announced flaws, report that to designated personnel, and set their own time periods based on the severity of the flaw. Rev. 2 does not mention a software bill of materials, so for CMMC the SBOM is a practical way to identify affected systems, not a stated requirement.

The OSSeva evidence maps to the three verbs. CVE records and VEX statements identify and report which flaws affect which build, and the patched build corrects them inside the patch window. Under the DFARS rule, phase 1 began on 10 November 2025 and phase 2 begins one calendar year later; the contract tells you which level applies.

The SBOM minimum elements that auditors and customers now cite are CISA's 2026 list (29 July 2026), which replaces the NTIA 2021 list. It adds component hash, licence, generation context and an SBOM author signature to the 2021 fields. Ask for a sample pack and check it against that list. A sample pack is available on request through the form on this page, and OSSeva's own SOC 2 Type II report is available under NDA for vendor risk review.

Steps from the security page; replace the placeholders with the artifact or image you received.

OSSeva does not certify that you comply with PCI DSS, the Cyber Resilience Act, DORA or CMMC, does not act as an assessor or notified body, does not file reports for you, and does not rank your vulnerabilities or write your remediation plan. The evidence is OSSeva's record of what it patched, when, and in which build; your assessor decides what it proves. It covers the versions on the supported versions list.

Each rule above comes from the primary text, not a summary. Where a document was not available, the section says so.