When security teams talk about "shifting left," Anchore is usually one of the first names that comes up. Shift left security — or, in Anchore's own framing, a shift left security approach that moves vulnerability detection into the build pipeline instead of waiting for production — is the philosophy its entire product line is built around. Founded in 2013 and now built around the open-source Syft (SBOM generation) and Grype (vulnerability scanning) projects, Anchore has spent the past decade arguing that container security has to start at the Dockerfile, not the production cluster. Its devsecops security model centers on generating a software bill of materials at build time, scanning it against vulnerability databases before an image ever reaches a registry, and enforcing policy gates in CI/CD so non-compliant artifacts never ship. That model has made Anchore a fixture in federal environments, including Platform One and Iron Bank, where SBOM-backed attestations are now a procurement requirement. But shift-left scanning answers only part of the question: what happens to that image after it's deployed, patched, or forked six months later? This post breaks down how Anchore's approach actually works, where it came from, and what it still leaves on the table.
What Is Anchore's DevSecOps Approach?
Anchore's devsecops approach is to treat the SBOM as the control point: generate it at build time with Syft, scan it with Grype, and gate the pipeline with policy-as-code before an artifact can be promoted. This is a deliberate architectural choice — rather than bolting a scanner onto a running cluster, Anchore instruments the CI/CD pipeline itself, typically at the docker build or image-push step. A GitHub Actions or Jenkins job calls Syft to produce a CycloneDX or SPDX document, Grype cross-references that document against the NVD and vendor feeds, and Anchore Enterprise's policy engine evaluates the results against rules like "no critical CVEs older than 30 days" or "no GPL-licensed dependencies in this repo." If a build fails a rule, it stops before merge or deploy. The company markets this as "shift-left security," and it's a genuinely useful discipline: catching a vulnerable OpenSSL version during a pull request is cheaper than catching it after a customer incident.
Why Does Anchore Emphasize Shift-Left Over Runtime?
Anchore's instinct is to shift security left because its origin and core IP — Syft and Grype — are static analysis tools, not runtime agents. Both projects were open-sourced in 2020-2021 and remain among the most widely adopted SBOM and vulnerability tools in the CNCF ecosystem, with Grype alone accumulating tens of thousands of GitHub stars. That heritage shapes the product roadmap: Anchore Enterprise, Anchore Federal, and the associated policy bundles are all built around scanning artifacts before deployment, not observing what those artifacts actually do once they're running. The pitch to engineering teams is straightforward — a 2023 Anchore-commissioned survey of software supply chain practitioners found that most organizations were still scanning fewer than half of their production images, and Anchore's answer was to push scanning earlier and make it mandatory in the pipeline rather than optional in production. The tradeoff is that a clean scan at build time says nothing about a zero-day disclosed the next week, or about a container that behaves unexpectedly at runtime despite a passing SBOM.
How Does Anchore Generate and Manage SBOMs?
Anchore generates SBOMs through Syft, which parses container layers, language package managers (npm, pip, Maven, Go modules, and others), and OS package databases to produce a component inventory in SPDX or CycloneDX format. This matters because SBOM format standardization has been a genuine industry pain point — NTIA published its "minimum elements" guidance for SBOMs in July 2021, and Anchore was one of the earlier vendors to support both major schemas natively rather than picking one. Once generated, SBOMs are stored in Anchore's own catalog and re-scanned against updated vulnerability feeds, so a component that was clean in January can surface a new CVE in March without a rebuild. That re-scan capability is a real strength of the model. Where it gets harder is scale: large enterprises with thousands of microservices and daily deploys generate an enormous volume of SBOM documents, and correlating "which of my 4,000 running containers actually contain this vulnerable library" requires tying the SBOM catalog back to a live deployment inventory — a step that sits outside Syft and Grype's native scope.
What Role Do Policy Gates Play in the Pipeline?
Policy gates are the enforcement mechanism that turns Anchore's scanning output into an actual go/no-go decision, blocking builds that violate rules like severity thresholds, license restrictions, or the presence of unapproved base images. This is arguably where the security in DevSecOps actually gets enforced rather than just reported — a scanner that only surfaces findings without blocking anything tends to get ignored after the first few sprints. Anchore's policy bundles are written in a JSON-based rule format and can be scoped per-repository or per-environment, so a team can require zero criticals for a production-bound image while allowing more leniency in a sandbox branch. Federal customers in particular rely on this for continuous authorization to operate (cATO) workflows, where a failed policy gate is documented evidence in an audit trail. The limitation is that policy gates evaluate a point-in-time snapshot: an image that passes the gate on Tuesday can become non-compliant on Thursday when a new CVE drops, and without a runtime or registry re-evaluation loop, that drift goes unnoticed until the next scheduled scan.
How Did the 2021 Executive Order Shape Anchore's Strategy?
Executive Order 14028, signed May 12, 2021, mandated SBOMs for software sold to the federal government and directly accelerated Anchore's push into public-sector DevSecOps. The order, combined with the NTIA's minimum-elements guidance two months later, gave federal integrators a compliance deadline to build toward, and Anchore's existing partnership with the U.S. Air Force's Platform One (and its Iron Bank hardened-container repository) positioned it as a default answer for agencies needing SBOM attestation baked into their pipelines. This is a legitimate and well-earned advantage — Anchore Federal exists specifically to meet FedRAMP and DoD hardening requirements, and its shift-left model maps cleanly onto the "authorize once, reuse everywhere" logic of container hardening programs. The downside for commercial buyers is that a product roadmap shaped heavily by federal compliance checklists can lag on developer experience and on integrating supply-chain signals — like provenance attestation or SLSA levels — that matter more to fast-moving commercial engineering teams than to a cATO audit binder.
Does Shift-Left Scanning Catch Everything It Needs To?
No — there's a real limit to how far you can shift left on security (sometimes typed "start left security" by searchers, same concept), and shift-left scanning shows it clearly: it catches known vulnerabilities present at build time, but it structurally misses issues that only appear after deployment — newly disclosed CVEs in already-running images, runtime behavior anomalies, misconfigured permissions discovered post-deploy, and supply-chain tampering that occurs between build and registry push. This isn't a knock unique to Anchore; it's a structural limit of any shift left security tool whose core competency is static SBOM analysis. Industry incident data backs this up — the median time between a CVE's public disclosure and its exploitation in the wild has been trending under 30 days in several recent analyses, which means a monthly or even weekly rescan cadence can leave a meaningful exposure window. Teams that rely solely on a shift-left gate often discover, during an actual incident, that the vulnerable component was flagged as clean six weeks earlier — the SBOM was accurate at build time, but nobody was watching what happened to that artifact afterward.
How Safeguard Helps
Safeguard is built around the idea that a shift left devsecops program is necessary but not sufficient — the pipeline gate is one control point, not the whole security program. Where Anchore's model largely stops at "block the build if the SBOM fails policy," Safeguard extends coverage across the full artifact lifecycle: continuous re-evaluation of deployed images against newly disclosed CVEs, provenance and attestation checks that verify what actually shipped matches what was built, and policy enforcement that follows artifacts from registry through runtime rather than expiring at the merge gate. For teams already using Syft- or Grype-style scanning in CI, Safeguard doesn't ask you to rip that out — it closes the gap those tools leave open, correlating SBOM data against live deployment inventory so a new CVE disclosed on a Tuesday afternoon surfaces against every running workload that contains it, not just the next scheduled build. Combined with tenant-aware policy controls and audit-ready reporting, Safeguard gives security and platform teams the shift-left discipline Anchore popularized, plus the continuous, post-deploy visibility that a point-in-time build gate can't provide on its own.