Open Source Compliance vs Security: What Teams Need

The short answer

Compliance asks whether you have a process and can prove you followed it. Security asks whether an attacker can still get in. For open-source components the two share most of their inputs, an inventory, a patch policy, scan results, so teams often treat a clean audit as a proxy for low risk. That works until a component reaches end of life, a scanner stops seeing a vulnerability, or an exception stays open for a year because the paperwork was accepted.

The fix is not to choose one over the other. Run a single inventory and a single remediation process, and measure it two ways: against the framework's floor, and against what is actually exposed. This article is general information, not legal or audit advice.

What each one measures

Where they agree

Most control text is written to reduce risk, so the overlap is large. NIST SP 800-53 CM-8 asks for an accurate component inventory, RA-5 for scanning and remediation of legitimate vulnerabilities within defined response times, and SI-2 for installing security-relevant updates within a defined period. PCI DSS v4 sets internal scans at least every three months under 11.3.1 and a one-month window for critical patches under 6.3.3. SOC 2 CC7.1 asks for detection and monitoring procedures that identify "susceptibilities to newly discovered vulnerabilities". A team that does these things well is both more compliant and harder to attack.

The overlap also explains why the same artefacts serve both purposes. Our audit evidence checklist lists the nine that auditors sample, and every one of them is also useful to an incident responder.

Where they pull apart

1. A scanner-clean report is not the same as no exploitable vulnerabilities

Software composition scanners mostly match component names and versions against vulnerability databases. A clean report means no known advisory matched what the scanner could identify. It says nothing about vulnerabilities nobody has reported, components the scanner could not fingerprint, or copies of a library shaded inside another jar. End-of-life lines make this worse in a specific way: once upstream stops reviewing an old branch, a new CVE may list only the supported versions it was tested on, and an older line can drop out of the affected range without being any safer. Our ZooKeeper, Spring Boot and PostgreSQL vulnerability-by-version guides show which lines each advisory actually names.

The reverse also happens. A build with a backported fix can keep the old version string, so the scanner flags a vulnerability that is no longer there. The audit sees a finding; the attacker sees nothing to exploit. A VEX statement with the status fixed or not_affected closes that gap in a form scanners such as Trivy and Grype can read.

2. Severity is not reachability

Patch policies are usually written by CVSS severity because that is easy to audit. Risk depends on whether the vulnerable code runs, whether an attacker can reach it, and whether anyone is exploiting it. A critical CVE in a code path your deployment never loads is a compliance item and a low security priority. A medium CVE on an internet-facing service that appears in CISA's Known Exploited Vulnerabilities catalog is the opposite.

US federal policy has moved toward the second view. CISA's Binding Operational Directive 26-04, issued on 10 June 2026, revoked BOD 22-01 and now sets federal remediation timelines from four inputs: whether the asset is publicly exposed, whether the CVE is in the KEV catalog, whether exploitation can be automated, and whether the attacker gains partial or total control. The most urgent combinations require remediation within three days plus a forensic triage; the least urgent can wait until the asset's next scheduled major upgrade or rebuild. The directive binds federal civilian agencies only, but it is a useful model for ranking work anywhere.

3. An accepted exception closes the finding, not the risk

Every framework allows some route for a vulnerability you cannot fix yet: a compensating control, a risk acceptance, a plan of action and milestones under NIST CA-5. From the audit's point of view the finding is handled once the paperwork is complete. From the attacker's point of view nothing has changed until the control works. The PCI DSS compensating controls worksheet is honest about this: it asks you to "identify any additional risk posed by the lack of the original control" and to define how the control is validated and maintained.

Exceptions for end-of-life components are the ones most likely to stay open, because there is no upstream release that will eventually close them. Give each one an expiry date and a test of the compensating control, and treat an expired exception as an open vulnerability.

4. Point-in-time evidence against continuous exposure

Audits sample a period after it ends. A quarterly scan cadence satisfies PCI DSS 11.3.1, and a SOC 2 Type 2 report describes how controls operated over a past window. Exploitation runs on a different clock. A vulnerability disclosed the day after a clean quarterly scan can be exploited long before the next one, and the audit evidence for that quarter will still look fine. Continuous scanning in the build pipeline and alerts on new advisories for components in your SBOM close most of that gap at little extra cost.

5. Licence compliance is a different question from vulnerability management

"Open source compliance" often means licence compliance: meeting the obligations of the GPL, AGPL, Apache and other licences on the components you ship or run. That work answers whether you are allowed to use and distribute the software on your terms. It does not answer whether the software is safe. A component can be fully licence-compliant, end of life and exploitable all at once.

NIST treats the two separately. CM-10 covers using software in accordance with licence agreements, and its enhancement for open-source software notes that "remediating vulnerabilities in open-source software may be problematic" and that "there may also be licensing issues". The same SBOM feeds both programmes, but the owners, the reviews and the evidence differ. Our guide to GPL compliance in enterprise SaaS covers the licence side. A patched build of an open-source component keeps the licence of the original, so switching where fixes come from does not change your licence obligations.

A practical model for running both

1. One inventory, two views. Generate the SBOM in the pipeline and add two fields the minimum elements do not carry: upstream support status and internet exposure. The compliance view reads the inventory; the security view reads it with exposure and exploitation data joined on.
2. Timelines that meet the floor and rank above it. Set severity-based patch timelines at or below the strictest framework in scope, then shorten them for anything exposed and known to be exploited. You stay compliant and the urgent work goes first.
3. An exceptions register with expiry dates. Each exception names its compensating control, the last test of that control, and the date it lapses. Review expired items with the same urgency as new critical findings.
4. Evidence as a by-product. Scan reports, change records, signatures and VEX documents should come out of the pipeline automatically. If evidence is assembled by hand before each audit, it describes what people remember, not what ran.
5. A named source of fixes for every component. For supported lines that is upstream. For end-of-life lines it is an upgrade date, an in-house team or an external provider, which is also what NIST SA-22 and PCI DSS 12.3.4 ask for.

Measure it both ways

If the two columns disagree, the security column tells you where the next incident is likely to start, and the compliance column tells you where the next finding will be. End-of-life components are usually where they disagree most, because the documentation can be perfect while no fixes are arriving. Our post on managing CVE risk for end-of-life open source in regulated industries covers prioritisation for that case.

Where OSSeva fits

For end-of-life open source, the gap between the two columns usually comes down to whether fixes are arriving. OSSeva Patch ships drop-in builds of community end-of-life runtimes with backported security fixes, quarterly and out of cycle for CVSS 9.0 and above, signed with GPG and attested with Sigstore Cosign. OSSeva Assure adds architecture review and the compliance documentation auditors ask for. The compliance library lists the frameworks covered.

Frequently asked questions

If we pass our audit, are our open-source components secure?

Not necessarily. An audit confirms that your process exists and was followed during the period. It does not test whether every exploitable vulnerability was found or whether accepted exceptions are still safe.

Does a clean scan mean an end-of-life component is safe?

No. It means no known advisory matched the version the scanner identified. Advisories for new vulnerabilities often name only supported lines, so an old branch can be vulnerable without being flagged.

Is licence compliance part of security compliance?

They are separate programmes that share an inventory. Licence compliance covers your right to use and distribute the code; vulnerability management covers whether it can be exploited.

Should patch timelines follow CVSS or exploitation data?

Both. Keep a CVSS-based policy that meets your frameworks, and move anything exposed and known to be exploited to the front of the queue.