Trackr.Live The landing site for Trackr Services
§ Trackr.Live

Anchore

The first thing to get straight about Anchore is that “Anchore” names two different things, and which one you mean changes the whole conversation. There is the open-source engine: Syft, which builds a software bill of materials from a container image or filesystem, and Grype, which takes that SBOM and matches it against vulnerability data. Both Apache-2.0, both free, both genuinely good, and between them and Grant (the license checker) they crossed 50 million downloads earlier this year. Then there is Anchore Enterprise, the commercial platform built on the same engine, driven through the AnchoreCTL CLI, sold to people who need policy enforcement, a central SBOM inventory, and an audit trail they can hand to an assessor. The OSS tools are what your developers already run. Enterprise is what a program office signs a PO for. Conflating the two is how budget conversations go sideways.

Schematic of a container image being decomposed into a software bill of materials, the component list flowing through a policy gate that passes most layers and flags a few, feeding a provenance ledger.
The vendor is Anchore, Inc., out of Santa Barbara, founded 2015, still independent and privately held as of this writing. Worth confirming at your own publish date, because ownership in this space moves fast and ownership drift is the single thing most likely to make a tool page wrong six months out. But there is no acquisition, no rebrand, no source-available relicense of the OSS tools. The older names you may remember (Anchore Engine, the standalone OSS scanner, and a separately marketed “Anchore Federal”) have folded into the current shape: Syft/Grype/Grant on the OSS side, one Anchore Enterprise on the commercial side with federal capabilities built in rather than sold as a distinct SKU.

Version reality, and one date that matters

Grype is shipping in the v0.112 range as of May 2026; Syft is on v1.x. These move constantly, which is fine, you pin a version in CI and bump it on your own cadence. Anchore Enterprise’s current shipping release is 5.27.0 (documentation last touched mid-April 2026). And then there is v6, which has been announced with a launch webinar on June 4 (2026) — five days after this page’s date. So: treat v6 as imminent, not shipped. If you are reading this and it is past early June, v6 is real and the headline changes are a Unified Asset Model that pulls container images, VMs, and remote filesystems into one view, multi-factor risk scoring with VEX to knock down false positives, and POA&M-as-code. One practical gotcha buried in the 5.27 notes: v6 will require Postgres 17 and the pg_cron extension, so if you are running Enterprise on an older RDS instance, the upgrade is a database project, not a helm upgrade.

Where it sits in the DoD flow

This is the part that separates Anchore from a generic container scanner. Anchore Enterprise underpins Iron Bank, the DoD’s hardened-container registry (the DCAR, DoD Centralized Artifacts Repository) on Platform One, and has since 2020. A jointly developed custom policy pack enforces the DoD Container Hardening Guide across every image in the registry. Anchore also built features like SBOM Hints and SBOM Corrections specifically to improve SBOM accuracy and vuln mapping for that workload, because cataloging 1,800-odd base images accurately is a different problem than scanning one. The current Iron Bank policy pack ships as Anchore DoD Iron Bank v20250101, with a companion DISA Image Creation and Hardening Guide pack.

What that does and doesn’t mean for you is the part people get wrong, so:

Deeper: “Anchore powers Iron Bank” does not mean pulling an Iron Bank image inherits you an ATO, and it does not mean your own Anchore deployment is automatically configured the way Iron Bank’s is. Iron Bank images carry DoD-wide reciprocity because the registry’s hardening pipeline ran the custom policy pack and a human signed off, not because Anchore touched the bytes. If you stand up Anchore Enterprise in your own boundary, you get the engine and the ability to load that policy pack, but the cATO story is yours to build. The reciprocity rides with the image and the authorization behind it, not with the scanner brand.

The 2026 reason this page exists at all is the DoD Software Fast Track. SWFT moved from pilot to a standing requirement as of January 2026, and the load-bearing piece for tooling like Anchore is the mandate for machine-readable SBOMs that regenerate on every code change. Static PDF SBOMs are dead on arrival. If you are shipping containerized software (Kubernetes workloads, mostly) into Platform One, Cloud One, or any of the software factories, a per-commit SBOM is now table stakes, and DoD can condition awards on assessment requirements later in 2026. That is the regulatory pull. The compliance authority underneath the SBOM story is still EO 14028 Section 4 and the NTIA minimum-elements framing, which remain operative.

What it does well, and what people gripe about

The OSS engine is fast, scriptable, and free, and the SBOM format support (SPDX and CycloneDX, both directions) is first-class. Running the same Syft/Grype in a developer’s CI job that runs inside the Enterprise gate buys you dev/prod parity, which matters more than it sounds: the finding a dev sees locally is the finding the gate sees. On the Enterprise side, the policy engine (gates and triggers) is the real product, and the STIG-for-containers automation is a genuine federal differentiator. anchorectl image stig runs Cinc/Chef InSpec profiles against an image and gives you STIG evaluation output you can actually attach to a package.

The complaints are honest ones. Grype’s false-positive rate on language ecosystems is the real operational tax, not its detection coverage. You can see it in the changelogs themselves: the v0.109-to-0.110 fixes are literally about GHSA duplicate matches on language packages and missed CVEs on JARs. The detection is fine; the noise on Java, npm, and Go dependency trees is what eats triage time, and you will spend more effort tuning matches out than you expect. There is a long-running accuracy debate against Trivy that comes down to which vuln database and matching logic you trust on a given ecosystem; neither side wins it cleanly, and the honest answer is to test both against your own images. And Enterprise is heavyweight. It is not a binary. It is a multi-service platform with a Postgres backend, a feeds service, a policy engine, and AnchoreCTL orchestration, and standing it up is a real deployment.

Here is the contestable opinion, planted clearly: most teams should run OSS Grype and Syft and only pay for Anchore Enterprise when they need the SBOM inventory and the policy audit trail — not for the scanning itself. The scanning is the free part. What Enterprise sells you that an ad-hoc grype run never will is the ability to answer “where is log4j across the entire fleet” from a central inventory, and a defensible record of which policy gated which build when. If you do not have that question or that audit need yet, buying Enterprise for better scanning is buying the wrong thing.

Capability Grype / Syft (OSS) Anchore Enterprise
Vulnerability scanning Yes, the same engine Yes, same engine plus VEX/risk scoring
SBOM generation (SPDX, CycloneDX) Yes Yes
Policy gates and triggers No Yes, this is the product
STIG-for-containers automation No Yes (anchorectl image stig)
Central SBOM inventory / fleet query No Yes, the real reason to buy
License checking Grant, separately Built in
Vendor support, air-gap install Community only Yes, IL2 through air-gapped IL6

Operational notes

Deployment shape is the fork in the road. OSS is a single binary you drop into a CI job. Enterprise is Postgres-backed and Kubernetes/Helm-deployable (EKS, AKS, GKE, OpenShift), with an air-gap install path that matters for anything past IL5. Integration points worth wiring early: the CI/CD gate (the actual use case), registry scanning, the SBOM repository as a fleet inventory, and STIG evaluation output into your package.

The pitfalls are predictable. Teams treat Grype’s default output as a pass/fail gate without writing any policy, which means the build breaks on a CVE nobody was ever going to fix and somebody disables the gate by Friday. Write the policy. Teams also skip feeding SBOMs into a central inventory, then cannot answer the fleet-wide “where is this component” question when the next log4j lands, which was the whole point of generating SBOMs. And in air-gapped installs, the vulnerability feed does not sync itself. A stale feed produces a clean scan that means nothing, and that failure is silent. Check the feed timestamp before you trust a green result on a disconnected install.

On authorizations: Anchore Enterprise is deployed in your boundary, self-hosted or air-gapped, not consumed as an Anchore-run SaaS, so there is no Anchore FedRAMP-authorized cloud offering to point at on the marketplace — the authorization is the one around your deployment. Don’t write “FedRAMP authorized” against the tool itself; that is not how this one ships.

Control ties

RA-5 is the direct one: Grype and Enterprise are a straight vulnerability-monitoring implementer for container images. The SBOM story is where Anchore is strongest outside RA-5, mapping to the SR family for supply-chain risk, and SR-11 (component authenticity / provenance) in particular is its best non-RA-5 fit. SA-11 covers the developer security testing you get by putting the scan in the build pipeline, with SA-15 for the development tooling itself. The STIG automation and SBOM inventory land on CM-6 (config settings) and CM-8 (component inventory), and CM-8 maps about as cleanly to an SBOM repository as any control maps to any tool. Don’t reach further than that; a scanner is not your whole SR program.

Sources

Adjacent material on this site