Software Supply Chain Security English: SBOM, Provenance, and Attestation Vocabulary

Software supply chain security has moved from a niche concern to a mainstream engineering responsibility following high-profile attacks like SolarWinds and log4shell. If you work in DevSecOps, platform engineering, or security, the vocabulary in this area is increasingly required for both technical discussions and compliance conversations. This guide covers the key terms and the phrases that surround them.

Core Vocabulary

SBOM (Software Bill of Materials) A machine-readable inventory listing all software components, libraries, and dependencies in an artifact or application — including their versions, licenses, and origin. An SBOM is the foundation of supply chain visibility.

“After the log4j vulnerability, we generated an SBOM for every production service and ran it against the CVE database — we found three affected services within an hour.”

Provenance Verifiable metadata that describes where and how a software artifact was built — including the source repository, the build environment, the build inputs, and the tools used. Provenance answers: “where did this come from and how was it made?”

“We attach provenance to every container image — it records the exact Git commit, the runner environment, and the build timestamp so we can reconstruct exactly what produced the image.”

Attestation A cryptographically signed statement about an artifact or its build process, made by a party that can be verified. An attestation is a machine-verifiable claim: “I, this build system, assert that this artifact was built from this source.”

“We generate an attestation for each release artifact and store it in our OCI registry alongside the image — consumers can verify the attestation before pulling the image.”

in-toto A supply chain security framework that allows you to define the steps in a software build pipeline and verify that each step was performed correctly and in order. In-toto uses signed link metadata for each step.

“We implemented in-toto to prove that our build artifacts went through code review, automated testing, and a vulnerability scan before release — each step is recorded and signed.”

SLSA framework (Supply-chain Levels for Software Artifacts) A graduated maturity model for software supply chain integrity, developed by Google and maintained by OpenSSF. SLSA defines four levels, with each level adding stronger guarantees about build integrity and provenance.

“We’re targeting SLSA Level 2 this quarter — it requires us to generate signed provenance for every build artifact, which our CI platform now supports natively.”

Artifact signing The process of cryptographically signing build outputs — binaries, container images, or packages — using a private key, so that consumers can verify authenticity and detect tampering.

“We use Cosign for artifact signing — every container image we push to the registry is signed with a key stored in our KMS, and our admission controller rejects unsigned images.”

Dependency confusion A supply chain attack where a malicious actor publishes a package to a public registry with the same name as an internal private package, hoping that build tools will pull the public (malicious) version instead of the private one.

“We were almost hit by a dependency confusion attack — someone had registered our internal package names on PyPI. We mitigated it by pinning all internal packages to our private registry URL explicitly.”

Transitive dependency A dependency that your code does not directly import, but which is required by one of your direct dependencies. Transitive dependencies are often the source of unexpected vulnerabilities.

“The vulnerability wasn’t in any library we directly use — it was in a transitive dependency three levels deep. Without an SBOM, we wouldn’t have known it was there.”

Vulnerability disclosure The responsible process of reporting a discovered security flaw to the affected software maintainer, giving them time to develop and release a fix before the vulnerability is made public. Also called responsible disclosure or coordinated disclosure.

“When we found the authentication bypass, we followed vulnerability disclosure best practices — we reported it to the maintainer privately, waited 90 days, and only published after the patch was available.”

Key Collocations

• generate an SBOM — “Our CI pipeline generates an SBOM for every release artifact using Syft and attaches it to the GitHub release.”
• verify provenance — “Consumers can verify provenance using the Sigstore toolchain — it checks the signature against the public key in the Rekor transparency log.”
• sign an artifact — “We sign an artifact at the end of the build pipeline, after all tests pass and before it’s pushed to the registry.”
• achieve SLSA Level 2 — “To achieve SLSA Level 2, we need to produce signed provenance automatically from a hosted build platform — manual builds no longer qualify.”
• audit transitive dependencies — “We audit transitive dependencies every Monday using Renovate’s dependency graph — any new transitive dep triggers a license and CVE check.”
• disclose a vulnerability — “When we discovered the issue, we chose to disclose the vulnerability privately rather than post it publicly — the maintainer released a fix within two weeks.”

Using This Vocabulary in Security Discussions

Supply chain security discussions often happen across teams — security, DevOps, engineering, and compliance. Knowing how to frame the same concept for different audiences is valuable.

For a technical audience: “We generate a CycloneDX SBOM for each image and store it in the OCI registry as an attestation. Our admission controller verifies the attestation signature before any image is deployed to production.”

For a compliance audience: “We have a complete inventory of every software component in our product, including which version and license. We can tell you within minutes whether any component is affected by a newly published vulnerability.”

Both descriptions convey supply chain security maturity — in very different registers of English. Practising both is important for engineers who need to communicate across technical and business contexts.

Practice Tip

Look up your team’s or company’s CI/CD pipeline and ask yourself: “Where is the SBOM generated? Is provenance attached to artifacts? Are artifacts signed before deployment? Where are transitive dependencies audited?” Then write a short paragraph describing the current state of your pipeline’s supply chain security in English, using at least four terms from this article. Describing your real pipeline is more useful practice than hypothetical exercises, because it forces you to connect the vocabulary to concrete systems you already understand.