Anchore released Syft v1.20.0 in mid-2025 with what they billed as faster scans, smarter license detection, and enhanced Bitnami support. Syft is the SBOM-generator side of the Anchore open source duo (Grype is the matcher), and the 1.20 release is the most consequential since v1.0 dropped the experimental tag in early 2024. By the end of 2025 Anchore had iterated past v1.26 and into 2026 with v1.42, but v1.20 is the one where most of the new ergonomics landed. We ran it against five mixed-language codebases and a small fleet of Bitnami-derived images.
What changed in the license cataloger?
Syft used to emit "unlicensed" in CycloneDX output whenever it found a license file whose contents did not match a valid SPDX expression — even when the file clearly contained a real license. The v1.20 cataloger first attempts SPDX matching, then falls back to fuzzy text matching against a curated set of common license templates, and finally emits the raw text as a License.text field in CycloneDX rather than swallowing it. The practical effect on our test corpus: on a 1,400-component Java/Python monorepo, the number of components labelled "unlicensed" dropped from 187 to 31. The remaining 31 were genuinely missing license metadata; the other 156 were already-licensed components that the old fuzzy matcher had given up on.
This matters for procurement and OSPO workflows because "unlicensed" findings are often treated as blockers in license-compliance gates. Before v1.20, hand-rolling overrides was the only fix. After v1.20, the gate gets accurate input.
How does Bitnami passthrough work?
Bitnami container images ship with an embedded /opt/bitnami/.bitnami-pkg.json SBOM produced by the Bitnami build pipeline. Pre-v1.20 Syft would re-catalog the same image and produce its own (less complete) SBOM, missing the application-level dependencies Bitnami already enumerated. The new Bitnami cataloger detects the embedded SBOM, parses it into Syft's internal package model, and merges it with the OS-layer catalog. We tested on bitnami/postgresql:16.4.0-debian-12-r0: pre-1.20 SBOM had 312 components; post-1.20 had 478, with the additional 166 corresponding to the Bitnami-shipped Postgres extensions and bundled utilities.
What about the performance claims?
Anchore claims "faster scans" without numbers in the release notes. We ran a time syft scan against five targets, ten runs each, median reported, on a fresh AWS c7i.4xlarge.
| Target | v1.18.1 | v1.20.0 | Delta |
| --- | --- | --- | --- |
| python:3.12-slim (250 MB) | 6.2s | 4.9s | -21% |
| golang:1.23-alpine (380 MB) | 7.8s | 6.1s | -22% |
| bitnami/postgresql:16.4 | 11.4s | 7.3s | -36% |
| Filesystem scan: Java monorepo (12 GB) | 142s | 88s | -38% |
| Filesystem scan: Go monorepo (4 GB) | 38s | 27s | -29% |
The biggest gains are filesystem scans and any target that benefits from the parallelised cataloger executor. Image scans see modest gains from improved layer-extraction concurrency.
Did SPDX output stay equivalent?
Yes, with one caveat. The CycloneDX 1.6 output is the cleanly improved one; SPDX 2.3 output gained the same license fidelity but the creationInfo.tools field changed from a string array to a structured object array, which broke our internal SPDX validator. The fix is to update validators to SPDX spec 2.3 strict mode rather than the 2.2 mode many tools still ship by default. Diff your downstream parsers before promoting v1.20 in critical pipelines.
# Generate a clean v1.20 CycloneDX 1.6 SBOM for a container image
syft scan \
registry.internal/myapp:${GIT_SHA} \
--output cyclonedx-json=sbom.cdx.json \
--select-catalogers "+bitnami-cataloger,+java-archive-cataloger" \
--scope all-layers
# Generate a SPDX 2.3 SBOM with full license text included
syft scan \
dir:/src/myapp \
--output spdx-json=sbom.spdx.json \
--license-content-include-types "*"
What about the v1.26 follow-on?
Syft v1.26.1, released in early February 2026, is the small one that mainly fixed regressions introduced when v1.25 added the experimental Rust binary cataloger. If you adopt v1.20 today and skip ahead to v1.26 at upgrade time, the only material additional behaviour is the Rust cataloger (auto-enabled for any binary built with rustc 1.75+) and a handful of Bitnami detection refinements. Nothing in v1.21 through v1.25 changes the CycloneDX or SPDX wire format.
How should teams adopt v1.20?
Three steps. First, run v1.20 in shadow mode for two weeks against the same images your current Syft version covers and diff the SBOMs — expect significantly more components on Bitnami images and significantly fewer "unlicensed" findings. Second, update license-compliance gates to treat the new License.text field as evidence rather than as a missing-license signal. Third, if you use --select-catalogers to allow-list specific catalogers in your pipeline, audit the list — v1.20 renamed three internal catalogers and added two new ones, and an unchanged allow-list will silently exclude them.
How Safeguard Helps
Safeguard ingests Syft v1.20 CycloneDX 1.6 and SPDX 2.3 output directly, parsing the new License.text field as a first-class evidence object so license compliance gates can be set against actual license content rather than against the deprecated "unlicensed" placeholder. Griffin AI cross-checks Syft component inventories against runtime artifact data and flags drift — useful for catching cases where a Bitnami passthrough SBOM is over-inclusive relative to what the running container actually loads. Policy gates can require a Syft v1.20-or-newer SBOM as a publishing prerequisite, and the SBOM normaliser merges Syft output with cdxgen, Trivy, and JFrog Xray output so a single asset has one consolidated component graph regardless of which scanner produced it. For organisations standardising on Syft, Safeguard is the layer that turns the SBOM artifact into a policy decision.