What we still need to verify : 2 points in this profile are not yet confirmed against vendor documentation.
- Current Enterprise feature set and edition boundaries: confirm with vendor
- Full integration list beyond the major CI systems: verify against vendor documentation
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
Anchore's model separates two jobs that many scanners fuse together. First it catalogs: it walks a container image layer by layer, or a filesystem or archive, and identifies operating system packages, language ecosystem packages, binaries and file metadata, producing a CycloneDX or SPDX software bill of materials. That cataloging step is the open source Syft project. Second it matches: the resulting SBOM is compared against vulnerability data assembled from the National Vulnerability Database, distribution security trackers for Alpine, Debian, Ubuntu, Red Hat and Amazon, GitHub Advisories and language ecosystem sources. That matching step is the open source Grype project.
The commercial Enterprise product wraps those engines for scale: an SBOM repository that stores every build's inventory so you can answer retroactive questions when a new vulnerability lands, a policy engine that evaluates rules beyond severity thresholds including base images, exposed ports, Dockerfile directives and licenses, plus reporting, remediation workflow and scheduled registry scanning.
Where it fits
This is build pipeline and registry tooling, operated by a platform or security engineering team rather than by individual developers. Syft and Grype run as single binaries in a CI job or on a laptop. Enterprise runs as a self-hosted service that watches registries and receives SBOMs from build jobs. You need a consistent build process producing images through a pipeline you control, and an agreed policy on what fails a build versus what merely gets recorded.
Strengths
- Storing SBOMs rather than just scan results means you can answer "which of our images ever contained this package" without rebuilding anything.
- The policy engine evaluates image construction, not only CVEs, so you can enforce approved base images and Dockerfile hygiene in the same gate.
- Distribution-specific feeds reduce the false positives you get from matching versions against NVD alone.
Limitations
- Matching is version-based. Anchore cannot tell you whether vulnerable code is reachable or even loaded, so triage volume stays high on large images.
- Enterprise is self-hosted infrastructure with a database and workers to run, patch and size. That is real operational cost.
- Language ecosystem coverage inside images is good but not exhaustive, and statically linked or vendored binaries often land in the SBOM without usable version data.
Who it suits
A good fit for teams that build containers at volume and want SBOM generation, vulnerability matching and policy enforcement from one toolchain, especially where regulatory or customer requirements make SBOM retention non-optional. Less compelling if your risk is mostly in first-party application dependencies rather than image contents, or if you want reachability-based prioritization to cut triage effort.
Used Anchore? Recommend it under your own name and title.
Recommend this tool