Vocabulary for SBOM and Software Supply Chain Security
Learn the essential English vocabulary for discussing software bills of materials, provenance, and dependency vulnerabilities in supply chain security work.
Software supply chain security has become a mainstream engineering concern, and it comes with a vocabulary that spans compliance, security, and build-system engineering. Terms like “SBOM” and “provenance” now appear routinely in vendor questionnaires, security reviews, and regulatory conversations, and using them precisely helps you communicate risk clearly to both security teams and less technical stakeholders like procurement or legal.
Key Vocabulary
SBOM (Software Bill of Materials) A structured, machine-readable inventory of every component — direct and transitive dependencies, libraries, and their versions — that makes up a piece of software. Example: “We generate an SBOM as part of every release build, so we can quickly check which shipped versions include a newly disclosed vulnerable library.”
Provenance Verifiable metadata describing how a software artifact was built — including the source repository, commit, build system, and the steps taken — used to establish trust in the artifact’s origin and integrity. Example: “Without provenance attestation, we can’t cryptographically verify that this binary was actually built from the source code we reviewed, rather than tampered with afterward.”
Transitive dependency A dependency that is not directly declared by your project, but is pulled in indirectly because one of your direct dependencies depends on it. Example: “The vulnerable library isn’t something we imported directly — it’s a transitive dependency three levels deep, pulled in by a logging library we do use directly.”
Vulnerability disclosure (CVE) A publicly documented security vulnerability, typically assigned a standardized identifier (a CVE number), describing the affected software and the nature of the flaw. Example: “This CVE affects versions before 4.2.1 of the library, and our SBOM shows we’re currently on 4.1.0, so we need to patch.”
Dependency confusion An attack technique where a malicious package is published under the same name as an internal, private package, tricking a build system into pulling the malicious public version instead. Example: “We mitigated dependency confusion risk by reserving our internal package names on the public registry, even though we never intend to publish real code under them.”
Typosquatting Publishing a malicious package under a name deliberately similar to a popular legitimate package, hoping developers will mistype the name and install the malicious one instead. Example: “The compromised package was a typosquat of a widely used utility library, differing by a single transposed letter in its name.”
Signing / artifact signing Cryptographically signing a software artifact (a package, container image, or binary) so that consumers can verify it hasn’t been tampered with and genuinely came from the claimed source. Example: “We now require every published container image to be signed, and our deployment pipeline refuses to deploy anything with an invalid or missing signature.”
Attestation A signed statement, often machine-verifiable, that a specific claim about a software artifact is true — for example, that it was built by a specific CI pipeline from a specific source commit. Example: “The attestation confirms this artifact was built by our official CI pipeline, not manually uploaded by someone with registry write access.”
Common Phrases
In code reviews:
- “This build pipeline doesn’t generate an SBOM as part of the release — we should add that before this goes to any customer requiring supply chain compliance.”
- “We’re pulling this dependency from a general-purpose registry without pinning an exact version or verifying a checksum — that leaves us exposed to a compromised update.”
- “This new package has almost no download history and was published last week — let’s hold off until we’ve reviewed it more carefully before adding it as a dependency.”
In standups:
- “Yesterday I set up automated SBOM generation in the release pipeline; today I’m wiring up a scanner to flag any newly disclosed CVEs against our current dependency tree.”
- “I’m blocked on a transitive dependency vulnerability — the direct dependency we use hasn’t released a patched version yet, so we can’t simply bump a version number.”
- “I finished adding artifact signing to our container build; the deployment pipeline now verifies the signature before allowing a rollout.”
In vendor security review or compliance conversations:
- “We can provide an SBOM for this release on request, along with provenance attestations showing it was built through our official CI pipeline.”
- “This transitive dependency does have an open CVE, but our usage doesn’t invoke the vulnerable code path — here’s our documented risk assessment.”
- “We require signed artifacts throughout our deployment pipeline, so an attacker with registry access alone couldn’t get an unsigned image deployed.”
Phrases to Avoid
Saying “we checked our dependencies” without specifying how. Say instead: “we scan our SBOM against a CVE database on every build” or “we manually reviewed the top-level dependencies but haven’t yet automated transitive dependency scanning.” Vague assurances don’t hold up in a security review.
Saying “it’s just a small utility library” to dismiss supply chain risk. Size doesn’t correlate with risk — some of the most impactful supply chain compromises have involved small, widely used utility packages. Assess based on usage and maintenance signals, not perceived importance.
Saying “the vulnerability doesn’t affect us” without justification. This claim needs a documented reason — such as “we don’t call the vulnerable function” or “the vulnerable code path is unreachable in our configuration.” An unsubstantiated dismissal is a red flag in any security review.
Quick Reference
| Term | How to use it |
|---|---|
| SBOM | ”We generate an SBOM for every release to track our full dependency tree.” |
| provenance | ”Provenance attestation confirms the artifact came from our official build.” |
| transitive dependency | ”The vulnerable library is a transitive dependency, three levels deep.” |
| dependency confusion | ”We reserved our internal package names to prevent dependency confusion.” |
| typosquatting | ”The compromised package was a typosquat of a popular library.” |
| artifact signing | ”Our pipeline rejects any artifact without a valid signature.” |
Key Takeaways
- An SBOM is the foundation for supply chain security conversations — know how to describe what it captures and how often it’s regenerated.
- Distinguish clearly between direct and transitive dependencies when discussing vulnerability exposure and remediation timelines.
- Provenance and artifact signing establish trust in where an artifact came from — describe them as verifiable, not just as a policy statement.
- Never dismiss a vulnerability as “not affecting us” without a specific, documented technical justification.
- Dependency confusion and typosquatting are named, well-understood attack patterns — use the precise term rather than a vague description of “a malicious package.”