Wiki · Concept · Last reviewed June 25, 2026

Syft

Syft is Anchore's open source command-line tool and library for generating software bills of materials from container images, filesystems, archives, and related software artifacts.

Definition

Syft is an open source SBOM generator maintained by Anchore. The public anchore/syft repository describes it as a command-line tool and library for generating software bills of materials from container images and filesystems, with support for many packaging ecosystems and image formats.

Syft's job is inventory. It does not decide whether a package is exploitable, compliant, reachable, or approved. It creates a structured description of what software components appear to be present in a scanned source so that other systems, reviewers, and governance workflows can reason about them.

How It Works

Syft takes a source and catalogs packages. Its supported-sources documentation says it can generate SBOMs from images, files, directories, and archives, and can infer source type from the input. The CLI reference describes syft scan as generating a package-based software bill of materials from container images and filesystems.

Output format matters because an SBOM is usually consumed by another tool. Syft's output-format documentation covers SPDX, CycloneDX, Syft JSON, table output, template output, and other formats. The repository also notes that Syft works with Grype for vulnerability scanning, which separates the inventory step from the vulnerability-matching step.

In CI, Syft can run directly or through Anchore's SBOM GitHub Action. The action repository states that it executes a Syft scan in the workspace and uploads a workflow artifact SBOM in SPDX format by default.

Agent Context

AI coding agents can add dependencies, rewrite Dockerfiles, vendor code, update lockfiles, or copy examples into a repository. A generated patch may look small while changing the deployable inventory. Syft gives reviewers a concrete object to compare: what packages were present before the agent change, what packages are present after it, and which artifact was scanned.

The useful workflow is to generate SBOMs from resolved artifacts, not from the model's explanation. For an agent-produced container change, scan the built image. For a repository change, scan the tree and relevant lockfiles. For a release, preserve the SBOM beside the commit, image digest, build provenance, and human approval record.

Governance Use

A governance-grade Syft record should preserve the target source, source digest or commit, Syft version, command, configuration, output format, generated SBOM, excluded paths, and build context. If the SBOM is converted, uploaded, signed, or used for vulnerability scanning, that downstream step should be recorded separately.

Syft belongs beside AI Bill of Materials, SPDX, CycloneDX, Package URL, Trivy, and OSV. It helps establish software inventory, while those neighboring systems describe formats, identifiers, scanners, vulnerability records, and decision workflows.

Limits

An SBOM is evidence, not assurance. Syft may produce different inventories from a source tree, built image, archive, or release artifact because each exposes different files and package metadata. A clean or complete-looking SBOM does not prove the software is vulnerability-free, licensed correctly, reachable in production, or safe to deploy.

Agentic workflows add another limit: a model can modify build scripts so that the scanned source and shipped artifact diverge. For important releases, the SBOM should be tied to the actual artifact shipped, not only to a repository snapshot described in a pull request.

Source Discipline

Claims about Syft should cite the anchore/syft repository, Anchore's CLI reference, and Syft's own documentation for supported sources, output formats, and configuration. Audit notes should state the date checked, source target, output format, Syft version, and whether the SBOM came from source, an image, an archive, or another artifact.

Spiralist Reading

Spiralism reads Syft as inventory discipline. The machine-written patch says what it intends. The SBOM says what the artifact appears to contain. Governance begins when those two records are allowed to disagree.

For AI supply chains, that disagreement is valuable. It keeps attention on the components that entered quietly: transitive packages, base-image libraries, vendored files, and build-time residue that no prompt summary will reliably remember.

Sources


Return to Wiki