Every CI/CD pipeline now produces two things: software, and evidence. In 2026, shipping code without generating an auditable trail of what was scanned, signed, and approved is no longer a minor gap — it's a finding waiting to happen. Auditors ask for SBOMs by commit. Customers ask for SLSA provenance before they'll sign a contract. Regulators under the EU Cyber Resilience Act and the US Executive Order 14028 lineage ask for continuous evidence, not a PDF from last year's audit.
Teams building on GitHub Actions, GitLab CI, or Jenkins are discovering that "we run a scanner" and "we can prove compliance" are different claims. Anchore built a strong reputation automating the first one — SBOM generation and vulnerability gating inside pipelines. But compliance integration is a broader problem: policy-as-code, attestation, drift detection, and audit-ready reporting across every stage, not just the scan step.
This post walks through what's actually breaking in CI/CD pipelines today, how the market — including Anchore — is addressing it, and where the gaps still sit.
Why is CI/CD now the primary attack surface for software supply chains?
Because CI/CD systems hold the credentials, the build logic, and the artifact signing keys all in one place, and attackers have noticed. The March 2025 compromise of tj-actions/changed-files, a GitHub Action used in an estimated 23,000+ repositories, injected code that dumped CI secrets into publicly readable workflow logs. It followed the same pattern as the December 2023 attack on reviewdog/action-setup, which had been used to compromise tj-actions in the first place — a supply chain attack seeding another supply chain attack. Neither incident required a vulnerable dependency in the traditional sense; both abused trust in third-party pipeline steps.
This is the shift compliance frameworks are catching up to. SLSA (Supply-chain Levels for Software Artifacts), now referenced directly in NIST SP 800-218 (the Secure Software Development Framework), treats the build pipeline itself as an asset requiring provenance, isolation, and non-falsifiable records — not just the code that runs through it.
What actually happened with SolarWinds and Log4Shell, and why do they still shape CI/CD policy?
Because both incidents proved that a single unverified build step or unpatched component can cascade to thousands of downstream organizations within days. SolarWinds (discovered December 2020) showed a compromised build server injecting malicious code into signed updates for roughly 18,000 customers. Log4Shell (disclosed December 9, 2021) showed a single transitive dependency — Log4j 2, often three or four levels deep in a dependency tree — creating remote code execution risk across an estimated 35,000+ Java packages, with Maven Central download data showing vulnerable versions still being pulled more than two years later.
These two events are why CI/CD compliance mandates now explicitly require: (1) build provenance attestation, (2) SBOMs generated at build time rather than reconstructed after the fact, and (3) continuous re-scanning of previously "clean" artifacts as new CVEs are disclosed. A scan that ran once at merge time and was never revisited is functionally useless against a CVE disclosed six months later against a dependency that shipped unchanged.
How does Anchore approach CI/CD security and compliance integration?
Anchore's approach centers on Syft and Grype as SBOM generation and vulnerability scanning tools, wrapped into Anchore Enterprise for policy enforcement inside pipelines. Syft, first released in 2019, generates SBOMs in SPDX or CycloneDX format at build time, and Grype cross-references those SBOMs against vulnerability databases to produce pass/fail gates in CI jobs. Anchore also publishes FedRAMP-oriented tooling (Anchore Federal) aimed at agencies needing container compliance against DoD Iron Bank hardening requirements.
This is a solid, narrow foundation: SBOM plus CVE gate, plumbed into a GitHub Action or GitLab job. Where teams tend to hit friction is everything adjacent to the scan — mapping a CVE gate to a specific SOC 2 or ISO 27001 control, producing a single evidence artifact that satisfies both a security engineer and an auditor, and extending policy enforcement to secrets, IaC misconfigurations, and license risk in the same gate rather than a second and third tool. Anchore's SBOM output is a good input to a compliance program; it isn't, by itself, the compliance program.
What does "compliance integration" mean beyond running a scanner in a pipeline?
It means the pipeline produces a defensible, timestamped record that maps technical findings to specific control language auditors and regulators actually cite. A vulnerability gate that blocks a build on a CVSS 9.8 finding is a security control. Turning that same event into evidence for SOC 2 CC7.1 (system monitoring to identify anomalies) or ISO 27001 Annex A 8.28 (secure coding) requires structured logging, retention, and reporting that most scan-only tools were never built to produce.
This gap shows up concretely during audits. A 2024 analysis of SOC 2 Type II reports across SaaS companies found that vulnerability management and change management were the two most frequently cited exception categories — not because teams weren't scanning, but because they couldn't produce consistent, pipeline-linked evidence that every flagged issue had been triaged, remediated, or formally risk-accepted within a defined SLA (commonly 15 days for critical, 30 for high, under frameworks like FedRAMP's).
What compliance frameworks are actually forcing CI/CD changes in 2026?
Four are driving the most concrete engineering work right now: NIST SSDF (SP 800-218), mandatory for federal software suppliers via the 2022 OMB self-attestation requirement; SLSA Level 3, increasingly requested contractually by enterprise buyers of open-source-adjacent tooling; the EU Cyber Resilience Act, whose vulnerability-handling and SBOM obligations begin phasing in from September 2026 with full enforcement in December 2027; and SOC 2, which remains the default trust signal demanded in B2B security questionnaires regardless of industry.
Each of these pushes the same requirement down into CI/CD: don't just find issues, prove when they were found, prove what happened next, and retain that proof in a form a third-party auditor can sample without a week of manual log archaeology. A GitHub Actions workflow that runs Grype and posts a red or green check satisfies none of that on its own — it needs a system behind it retaining the finding, the remediation timeline, and the sign-off.
Where do policy-as-code gates break down in real pipelines?
They break down at the boundary between "the tool said no" and "someone needs to explain why, in writing, within an audit sample." Teams commonly run vulnerability gates, secret scanners, and IaC checks as three separate tools with three separate exception processes, which means a single build can fail three different ways with three different remediation trails — and during an audit, reconciling those trails by hand is where most of the engineering time actually goes, not the scanning itself. Policy-as-code frameworks like OPA/Rego or Kyverno solve the enforcement half of this well; they rarely solve the evidence-retention half, which is a reporting and workflow problem more than a policy-engine problem.
How Safeguard Helps
Safeguard is built around the assumption that a CI/CD security finding and a compliance artifact should be the same object, generated once, not reconciled after the fact. Instead of bolting SBOM output onto a separate GRC tool, Safeguard generates SBOMs, runs vulnerability and secret scanning, and evaluates policy-as-code gates inside the same pipeline execution — GitHub Actions, GitLab CI, or Jenkins — and writes every result directly into a control-mapped evidence trail aligned to SOC 2, ISO 27001, and NIST SSDF language from the start.
Concretely, that means: every blocked or approved build produces a timestamped record an auditor can sample without a manual export; exceptions and risk-acceptance decisions are captured in-line rather than in a separate ticketing system that drifts out of sync; and SBOMs are generated at build time, in SPDX and CycloneDX, and continuously re-checked against new CVE disclosures rather than left static after merge — closing the exact gap that let Log4Shell-era dependencies keep shipping unnoticed for years.
For teams evaluating Anchore or similar scan-first tools, the practical question is whether the output of that scan is something your security team can act on, or something your compliance team can also hand to an auditor without a week of extra work translating findings into control evidence. Safeguard is built to make that translation automatic, so CI/CD security and compliance integration stop being two separate projects run by two separate teams on two separate timelines.