Open Source Compliance: 9 Audit-Ready Evidence Checks

The short answer

When an auditor turns to the open-source parts of your stack, they are checking nine things: a software bill of materials, a list of components past upstream end of life, written patch timelines, scan results with a register of exceptions, VEX statements for findings you dispute, contracts with whoever supplies fixes, change records for the fixes, compensating controls where a fix is not possible, and signed approvals or attestation letters that tie it together. Each framework phrases the requirement differently. The artefacts barely change.

This checklist is organised by artefact rather than by framework, so one set of evidence can serve several audits. The framework-by-framework detail lives in our guides to PCI DSS, SOC 2, HIPAA and NIST SA-22. This article is general information, not legal or audit advice. Your auditor's reading of a clause is the one that counts.

Which clause asks for which artefact

The table cites only clauses we checked against the published text. PCI DSS references are to v4.0 as reproduced in the PCI SSC's own self-assessment questionnaire; v4.0.1, the only active version since 31 December 2024, added and deleted no requirements. ISO/IEC 27001:2022 Annex A numbers follow ENISA's published mapping, and SOC 2 references are to the 2017 Trust Services Criteria. "Not named" means we found no criterion that asks for the activity directly, although a service auditor may still test it under CC7.1.

HIPAA is not in the table because the Security Rule does not name these artefacts. It asks for an accurate and thorough assessment of risks and vulnerabilities to electronic protected health information under 45 CFR 164.308(a)(1)(ii)(A), and for security measures that reduce them "to a reasonable and appropriate level" under (B). The nine artefacts are how most covered entities show that work for their open-source components. FedRAMP baselines are drawn from SP 800-53, so the NIST column applies there.

1. A software bill of materials that matches what runs

What it is. A machine-readable list of the components inside each product, image or service you deploy. NTIA's 2021 minimum elements set seven data fields: supplier name, component name, version, other unique identifiers, dependency relationship, author of the SBOM data, and timestamp.

Who asks. PCI DSS 6.3.2 requires an inventory of bespoke and custom software, and of the third-party software components incorporated into it, "to facilitate vulnerability and patch management". It was a best practice until 31 March 2025 and is now assessed. NIST CM-8 asks for an inventory that accurately reflects the system, and its discussion names software version numbers among the information needed for accountability. ENISA maps inventory to ISO/IEC 27001:2022 control A.5.9.

What good looks like. Generated in the build pipeline, not by hand. One SBOM per release, because NTIA's guidance says a new build or release needs a new SBOM. Package URLs or similar identifiers for every component, and a sample the auditor can trace from the SBOM to the artefact in production. Our post on continuous SBOM compliance covers keeping it current.

2. An inventory of end-of-life components

What it is. The subset of the SBOM whose upstream project no longer publishes security fixes for the version you run, with the date support ended and where that date came from.

Who asks. PCI DSS 12.3.4 is the most explicit. At least once every 12 months, the entity reviews the hardware and software technologies in use, analyses whether they "continue to receive security fixes from vendors promptly", documents announcements such as "end of life" plans, and keeps a plan approved by senior management to remediate outdated technologies. NIST SA-22 requires replacement or an alternative source of support once the developer stops supporting a component.

What good looks like. A separate column or report, because none of NTIA's seven fields records support status and most SBOMs will not show it. Each row names an owner and one of three outcomes: replace by a date, support in-house, or support from a named provider. Our end-of-life tracker lists upstream dates for runtimes such as ZooKeeper, Spring Framework and PostgreSQL, and our post on SBOMs and end-of-life components explains why the inventory finds the problem without fixing it.

3. Written patch timelines, measured

What it is. A policy that says how quickly security updates are installed, by severity, and data showing how quickly they actually were.

Who asks. PCI DSS 6.3.3 sets a one-month window for the most serious patches. In v4.0 the window covered critical or high-security patches. The PCI SSC says v4.0.1 reverted to the v3.2.1 wording, so the 30-day window now applies only to critical vulnerabilities, and other patches follow a time frame the entity determines. NIST SI-2(c) leaves the period to the organisation, and SI-2(3) asks you to measure the time between identifying a flaw and fixing it and to set benchmarks. RA-5(d) requires legitimate vulnerabilities to be remediated within organisation-defined response times.

What good looks like. Timelines per severity that meet the strictest framework you are audited against, a report of actual time to remediate for the audit period, and a list of every breach of the timeline with its reason. For an end-of-life component the policy needs a sentence on where the update comes from, since the clock in SI-2(c) starts at "the release of the updates" and upstream will not release one.

4. Scan results and an exceptions register

What it is. Vulnerability scan output for every in-scope asset, the tickets raised from it, and a register of findings you have decided not to fix yet.

Who asks. PCI DSS 11.3.1 requires internal scans at least once every three months, resolution of high-risk and critical findings, and rescans that confirm they are resolved. 11.3.1.1 handles lower-risk findings through a targeted risk analysis. NIST RA-5 requires scanning, analysis of the results and remediation. SOC 2 CC7.1 asks the entity to use "detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities". ENISA maps vulnerability handling to ISO/IEC 27001:2022 control A.8.8.

What good looks like. Scan coverage that reconciles with the inventory in check 1, so the auditor can see nothing was left out. Every high and critical finding links to a ticket, a fix, or an exception. Each exception names an owner, a reason, the compensating control from check 8, and an expiry date, after which it comes back for review.

5. VEX statements for findings that do not apply

What it is. A machine-readable statement that a product is not_affected, affected, fixed or under_investigation for one vulnerability, with a justification where the product is not affected.

Who asks. None of these frameworks names VEX. They ask you to analyse scan results (RA-5(c)) and to rank vulnerabilities by risk (PCI DSS 6.3.1), and a VEX statement is the most portable record of that analysis. Scanners such as Trivy and Grype can read VEX and suppress findings marked not affected, which keeps the next scan report consistent with the last decision.

What good looks like. Signed by an identifiable author, product IDs that match the SBOM, a justification backed by evidence the auditor can examine, and a process for updating the status when the deployment changes. Our guide to VEX statements covers the five justification codes and what auditors check before accepting one.

6. Contracts with whoever supplies the fixes

What it is. For each component whose fixes come from outside your team, the agreement that says what is covered and how fixes are delivered.

Who asks. SA-22(b) lists "support from external providers" as one of the two alternative sources of continued support, and its discussion says those providers can include open-source software value-added vendors. SOC 2 CC9.2 requires the entity to assess and manage "risks associated with vendors and business partners". ENISA maps supply chain security to ISO/IEC 27001:2022 controls A.5.19 to A.5.21. NIST SR-4 asks for documented provenance of components.

What good looks like. The contract names the components and version lines covered, not just a product family. Delivery records show which patched builds arrived and when. Each build carries a signature or provenance attestation your pipeline verifies before deployment, so the auditor can match the build in production to the build the provider shipped.

7. Change records for every fix

What it is. The trail from a vulnerability to the change that fixed it in production.

Who asks. PCI DSS 6.5.1 requires production changes to follow procedures that include the reason for the change, its security impact, approval by authorised parties and testing. NIST CM-3 requires configuration-controlled changes to be reviewed, approved, documented and retained, and SI-2(d) folds flaw remediation into configuration management. SOC 2 CC8.1 covers changes that are authorised, tested, approved and implemented. ENISA maps change management to ISO/IEC 27001:2022 control A.8.32.

What good looks like. An auditor picks a CVE from the scan history and follows it to a ticket, an approved change, a test result and the hash of the build now running, without anyone reconstructing the story from chat logs. Patching an end-of-life component should look exactly like patching anything else.

8. Compensating controls, tested

What it is. Controls that reduce the risk of a vulnerability you cannot fix yet: network isolation, removing a vulnerable feature from the configuration, tighter access, extra monitoring.

Who asks. PCI DSS sets out the exact structure in its compensating controls worksheet: the legitimate technical or business constraint, the definition of the control, the objective of the original requirement, the additional risk created by not meeting it, how the control was validated and tested, and how it is maintained. The SA-22 discussion suggests reducing the risk of unsupported components by keeping them off public or uncontrolled networks or isolating them in other ways. HIPAA's risk management standard asks for measures that bring risk to a reasonable and appropriate level.

What good looks like. Each control names the finding it compensates for, shows a test result from the audit period, and has a review date. Isolation that nobody has tested since the network was redesigned does not count.

9. Signed approvals and attestation letters

What it is. A dated decision, signed by someone accountable, to keep running a component or to accept a risk, plus any attestation letter from the provider supporting it.

Who asks. SP 800-53A lists "documented approvals, including justification, for the continued use of unsupported system components" among the evidence an assessor examines for SA-22. CA-5 requires a plan of action and milestones for weaknesses not yet corrected. PCI DSS 12.3.4 asks for a remediation plan approved by senior management.

What good looks like. One approval per end-of-life component or risk, with scope, justification, the source of fixes and an expiry, signed at the level your policy requires. An attestation letter from a support provider should say which versions it covers and what was delivered in the period. A letter that only says the vendor takes security seriously will not help you.

How to hand it over

Auditors sample, so build the package around a component rather than around a framework. For each end-of-life component in scope, one folder can hold the SBOM entry, the end-of-life record, the source-of-fixes contract, the approval, the change records for fixes in the period, any VEX statements, and the compensating controls with test evidence. The same folder answers a QSA, an ISO 27001 auditor and a SOC 2 service auditor, and the next audit only needs the period updated.

Where OSSeva fits

OSSeva Patch provides the source of fixes for community end-of-life runtimes: drop-in builds with backported security patches, delivered quarterly and out of cycle for CVSS 9.0 and above, signed with GPG and attested with Sigstore Cosign, through the repository manager you already use. OSSeva Assure adds an annual architecture review and the compliance packages for SOC 2, PCI DSS, HIPAA, ISO 27001 and FedRAMP-aligned audits. The compliance library describes what each package contains.

Frequently asked questions

Is an SBOM enough to show an auditor we manage open-source risk?

No. An SBOM covers the inventory, which is check 1. It does not say whether a component is still supported or whether its vulnerabilities were fixed, which is why checks 2 to 9 exist.

Does PCI DSS 6.3.3 still cover high-severity patches?

Under v4.0 it covered critical and high. The PCI SSC says v4.0.1 limited the one-month window to critical vulnerabilities, so other patches follow a time frame you set and justify. Check the wording against the version your assessor uses.

Do we need VEX for SOC 2 or ISO 27001?

Neither requires it by name. Both expect you to analyse vulnerabilities and act on the results, and VEX is a convenient way to record that analysis so the next scan does not raise the same finding.

Can one evidence package serve several frameworks?

Mostly. Timelines differ, so set yours to the strictest framework in scope, and keep the framework-specific items, such as the PCI DSS compensating controls worksheet, alongside the shared evidence.