“Supply chain security” used to mean physical logistics. In software, it now means a specific, practical question: can you prove what’s actually inside the artifact you’re about to deploy, whether any of it is known to be vulnerable, and whether the process that built it was tampered with along the way? Four pieces of free, open-source tooling answer those questions in combination: Syft generates a Software Bill of Materials (SBOM), Grype scans that SBOM for known vulnerabilities, in-toto attests to and verifies the build process itself, and SLSA provides the framework for judging how strong those build-time guarantees actually are. This is an explainer on how they fit together, written and checked directly against each project’s own documentation.
At a Glance
| Tool / standard | What it is | Maintainer / governance | License / cost |
|---|---|---|---|
| SBOM (SPDX, CycloneDX) | A structured inventory of a software artifact’s components | SPDX: the Linux Foundation (ISO/IEC 5962:2021). CycloneDX: OWASP Foundation (also ECMA-424) | Free, open standards |
| Syft | CLI tool/library that generates SBOMs from container images and filesystems | Anchore (open-source project, commercial support optional) | Free, Apache-2.0 |
| Grype | CLI vulnerability scanner that consumes SBOMs (including Syft’s) or scans images/filesystems directly | Anchore (open-source project, commercial support optional) | Free, Apache-2.0 |
| in-toto | Framework/attestation format for recording and verifying each step of a supply chain so tampering is detectable | Cloud Native Computing Foundation (CNCF, graduated project) | Free, open-source |
| SLSA | A leveled framework (L0–L3) for how trustworthy a build’s provenance is | OpenSSF, under a vendor-neutral cross-organization steering group (Linux Foundation specification) | Free, open specification |
Short Verdict
None of these tools compete with each other — they stack. SBOMs (via Syft) tell you what’s in an artifact. Grype tells you whether any of that is a known vulnerability. in-toto tells you whether the process that produced the artifact can be trusted. SLSA tells you how strong that trust actually is, on a scale anyone can audit against. A team adopting software supply chain security in 2026 should expect to run all four pieces together, not pick one.
What an SBOM Is
A Software Bill of Materials is a structured, machine-readable list of every component — open-source library, OS package, language dependency — that makes up a piece of software, roughly analogous to an ingredients list. Two open standards dominate:
- SPDX is maintained by the Linux Foundation and is also published as the international standard ISO/IEC 5962:2021. Per spdx.dev, it’s designed to represent systems of software components as SBOMs, and its scope has grown to include AI, data, and security references as well.
- CycloneDX is maintained by the OWASP Foundation (with Ecma International’s TC54 committee) and is also published as ECMA-424. Per cyclonedx.org, it’s framed as a “full-stack” BOM standard covering not just software but hardware (HBOM), cryptographic assets (CBOM), AI/ML models, and vulnerability data formats like VEX (Vulnerability Exploitability eXchange).
Neither format is “better” in the abstract — they’re both free, open, and widely supported; which one you use is usually dictated by what your regulator, customer, or downstream scanning tool expects. This is also the natural next step after the risk covered in our earlier piece on AI package hallucinations and slopsquatting: an accurate SBOM is one of the few reliable ways to catch a dependency that shouldn’t be there before it ships.
How Syft Generates SBOMs
Syft is an open-source CLI tool and Go library, maintained by Anchore, that generates an SBOM from a container image, a directory, or an archive. According to the project’s own GitHub page, it supports a wide range of package ecosystems out of the box — Alpine (apk), Debian (dpkg), RPM, Go, Python, Java, JavaScript, Ruby, Rust, PHP, .NET, and more — and can output SPDX, CycloneDX, or its own Syft JSON format, including writing more than one format at once.
# Install Syft
curl -sSfL https://get.anchore.io/syft | sudo sh -s -- -b /usr/local/bin
# Generate an SBOM for a container image, printed as a table
syft alpine:latest
# Generate a CycloneDX-format SBOM for a local project directory
syft ./my-project -o cyclonedx-json
# Write both SPDX and CycloneDX SBOMs to files in one run
syft alpine:latest -o spdx-json=./sbom.spdx.json -o cyclonedx-json=./sbom.cdx.jsonSyft is licensed Apache-2.0 and is entirely free to run yourself; Anchore separately sells commercial support and a hosted platform built on top of it, but the open-source tool has no paywall.
How Grype Scans SBOMs for Vulnerabilities
Grype, also maintained by Anchore and also Apache-2.0 licensed, is the matching vulnerability scanner. It can scan a container image or filesystem directly, but it’s designed to work especially well against an SBOM Syft already produced — Grype’s own GitHub page highlights that feeding it a Syft SBOM (rather than re-scanning the raw image) enables faster vulnerability detection, since the inventory step is already done.
# Scan a container image directly
grype alpine:latest
# Scan an existing Syft SBOM instead of re-inventorying the image
grype sbom:./sbom.cdx.json
# Pipe a Syft SBOM straight into Grype
syft alpine:latest -o cyclonedx-json | grypePer Grype’s documentation, it supports the same broad set of OS and language package ecosystems as Syft (Alpine, Debian, Ubuntu, RHEL, Oracle Linux, Amazon Linux, plus Ruby, Java, JavaScript, Python, .NET, Go, PHP, Rust), and it layers prioritization signals on top of raw CVE matches — EPSS (Exploit Prediction Scoring System) and CISA’s KEV (Known Exploited Vulnerabilities) list — plus support for OpenVEX, so teams can suppress matches they’ve already determined aren’t actually exploitable in their context. In short: Syft answers “what’s in here,” Grype answers “is any of that dangerous, and how urgently.”
What in-toto Adds: Verifying the Build Process Itself
Syft and Grype both operate on the finished artifact. Neither one can tell you whether the build pipeline that produced that artifact was itself compromised — whether an attacker slipped in a malicious step, substituted a dependency mid-build, or tampered with the output before it was signed. That’s the gap in-toto closes.
in-toto is a CNCF graduated project, created and led by Prof. Santiago Torres-Arias at Purdue University under Linux Foundation governance. Per in-toto.io, the framework’s goal is to protect a software product’s integrity “from initiation to end-user installation” — not just the final release step, because, as the project’s own site puts it, a package can already be compromised long before it reaches a repository. It does this by making every step in a supply chain (who ran it, what it did, in what order) transparent and checkable: a supply chain owner can define which steps are expected and by whom, and consumers can verify, after the fact, that the steps that actually happened match that expectation.
A key technical detail, confirmed directly against SLSA’s own blog on the relationship between the two projects: in-toto isn’t only an attestation file format. It defines a lightweight “Statement” envelope that names the artifact in question and a “predicate type” describing the specific claim being made about it — this could be a build-step link, a test result, an SBOM (in SPDX or CycloneDX form), or a SLSA provenance record. On top of that, in-toto also defines a verification model: the supply chain owner signs a layout naming authorized actors and expected steps, and that layout is checked against the attestations actually produced. SLSA’s own framing is explicit: “in-toto isn’t just a format of attestations.”
Where SLSA Fits
SLSA (Supply-chain Levels for Software Artifacts) is not a tool you run — it’s a framework for grading how trustworthy a build’s provenance actually is. It’s developed under OpenSSF by a vendor-neutral, cross-organization steering group (with Google, IBM, Intel, and Red Hat among the listed participants), and published as an open specification under the Community Specification License.
Per slsa.dev’s own level descriptions, the build track has four levels:
- L0 — No guarantees. No requirements at all; the implicit baseline for ad hoc or local builds.
- L1 — Provenance exists. The build process is consistent and generates provenance describing how the artifact was built, but that provenance may be unsigned and is easy to forge or bypass.
- L2 — Hosted build platform. The build runs on dedicated hosted infrastructure, and the platform itself signs the provenance, protecting against post-build tampering.
- L3 — Hardened builds. The build platform isolates runs from each other and keeps signing secrets inaccessible even to user-defined build steps, protecting against tampering during the build itself.
Provenance — “what entity built the artifact, what process they used, and what the inputs were” in SLSA’s own words — is the central artifact at every level; higher levels simply make that provenance harder to forge or bypass. And per SLSA’s own blog post explaining the relationship, SLSA Provenance (the predicate at https://slsa.dev/provenance/v1) is itself carried inside an in-toto Statement — SLSA defines what the build claim should contain, and in-toto supplies the signed, verifiable envelope and verification process that claim travels in. This pairs naturally with the CI/CD hardening practices in our earlier pieces on Sigstore, SLSA, and provenance attestation and the broader CI/CD supply-chain security checklist, both of which cover the pipeline-hardening side that complements the artifact-level tooling discussed here.
Comparison Table
| Question it answers | Tool/standard | Output |
|---|---|---|
| What components are in this artifact? | Syft | SBOM (SPDX, CycloneDX, or Syft JSON) |
| Are any of those components known-vulnerable? | Grype | Vulnerability match list, prioritized with EPSS/KEV, filterable with VEX |
| Was the build process itself tampered with? | in-toto | Signed layout + link/attestation metadata, independently verifiable |
| How strong is the build’s provenance, on a comparable scale? | SLSA | A level (L0–L3) describing build-platform trust, carried as an in-toto-wrapped provenance attestation |
Trade-offs
- SBOM format choice has real downstream friction. SPDX and CycloneDX are both free and widely accepted, but regulators, customers, and scanning tools don’t always agree on which they expect — generating both (as Syft lets you do in a single command) sidesteps the argument.
- An SBOM is a snapshot, not a guarantee. Syft tells you what’s declared in the artifact; it can’t tell you whether the build that produced it was itself compromised — that’s what in-toto and SLSA are for, not a gap in Syft.
- Grype’s accuracy depends on database freshness and ecosystem coverage, and no vulnerability scanner eliminates false positives/negatives entirely — EPSS and KEV scoring help triage, but they don’t replace judgment.
- in-toto’s guarantees require actually running verification, not just generating attestations. Signing a layout and producing link metadata does nothing if nobody checks the finished chain against it before deploying.
- SLSA levels describe build-platform trust, not application security. A SLSA L3 artifact can still contain a vulnerable dependency — that’s precisely why SLSA, Syft, and Grype are complementary rather than substitutes for one another.
Who Should Care
- Platform/DevOps teams building CI/CD pipelines who need a repeatable way to produce and scan SBOMs on every build, not just at release time.
- Security and compliance teams responding to customer or regulatory SBOM requirements (increasingly common in US federal and critical-infrastructure procurement) who need a free, standards-compliant way to generate them.
- Open-source maintainers who want to give downstream users verifiable proof of how a release was built, not just a changelog.
- Anyone evaluating AI-generated code or AI coding assistants, where an accurate, automatically generated SBOM is one of the few practical checks against a hallucinated or substituted dependency making it into a shipped artifact.
Bottom Line
None of this tooling costs money, and none of it is optional in any meaningful sense anymore for teams shipping software that others depend on. Syft and Grype are a five-minute CLI install that immediately answers “what’s in this artifact and is any of it dangerous.” in-toto and SLSA are the layer above that, answering the harder question of whether the artifact’s own creation can be trusted — and increasingly, that’s the question customers and regulators are starting to ask for proof of, not just an assurance.
FAQ
Do I have to choose between SPDX and CycloneDX?
Not with Syft — it can output both formats from the same scan in one command, so many teams generate both and let downstream consumers pick.
Are Syft and Grype really free?
Yes. Both are Apache-2.0 licensed open-source projects maintained by Anchore, installable and runnable with no license key. Anchore sells separate commercial support and a hosted platform, but the CLI tools themselves are not gated.
Can Grype scan something other than a Syft SBOM?
Yes — it can scan a container image or filesystem directly without a pre-generated SBOM, though per Anchore’s own documentation, feeding it an existing Syft SBOM is faster since the inventory step is already done.
Is in-toto the same thing as SLSA?
No. SLSA defines the specific claim (“provenance”) and a maturity scale (L0–L3) for how trustworthy that claim is; in-toto defines the signed envelope/attestation format that provenance (and other claims, like SBOMs or test results) travels in, plus the layout-based verification model used to check it. SLSA’s own blog is explicit that SLSA provenance is carried inside an in-toto attestation, not a competing format.
What SLSA level should a typical team target first?
SLSA’s own materials describe L1 (provenance exists, even if unsigned) as the first on-ramp, moving to L2 (hosted, platform-signed builds) as a realistic target for most CI/CD setups; L3’s isolation and secret-handling requirements are aimed at build platforms themselves, not typical application teams.