Software supply chain security glossary: 62 terms engineers use

Software supply chain security is the practice of knowing what goes into your software, where it came from, and whether it was tampered with on the way. This cheat sheet defines 62 terms in plain language. Where a standards body defines a term, the source is linked below. Definitions are short on purpose.

What are the building blocks?

• Software supply chain: every step that produces an artifact, including sources, builds, dependencies and packages. SLSA models it as a graph.
• Artifact: an immutable blob of data, such as a file, commit, container image or firmware image.
• Source: code authored or reviewed by people, before any build.
• Build: a process that turns input artifacts into output artifacts.
• Package: an artifact published for others to use.
• Dependency: a package that is an input to your build.
• Direct dependency: one you declare yourself.
• Transitive dependency: one pulled in by another dependency.
• Lockfile: a file that records exact resolved versions.
• Registry: a service that hosts packages, such as npm or PyPI.
• Producer, consumer, verifier: SLSA's roles for who makes software, who uses it, and who checks claims about it.

Which inventory and data formats matter?

• SBOM: a software bill of materials, a nested inventory of the components in software, per CISA.
• SPDX: an SBOM format that also covers licenses.
• CycloneDX: an SBOM format with a modular object model.
• VEX: a vulnerability exploitability exchange, an attestation that says whether a product is affected by a known vulnerability.
• Purl: package URL, a standard way to name a package across ecosystems.
• Minimum elements: the baseline data fields an SBOM should hold, set by NTIA in 2021 and being updated by CISA.
• CBOM: a bill of materials for cryptographic assets.
• AI-BOM: an inventory of models, datasets and related parts of an AI system.
• Hash (digest): a fingerprint of file contents used to check integrity.

How are vulnerabilities named and scored?

• CVE: an identifier for a publicly known vulnerability.
• NVD: the US National Vulnerability Database, which enriches CVE records.
• GHSA: an advisory ID from the GitHub Advisory Database.
• OSV: an open schema and aggregator for open source vulnerability data.
• CWE: a catalog of weakness types.
• CVSS: a severity score for a vulnerability.
• EPSS: a model estimating the likelihood a vulnerability will be exploited.
• KEV: CISA's catalog of known exploited vulnerabilities.
• Zero-day: a flaw exploited before a fix exists.
• Advisory: a published note about a vulnerability, with affected versions.
• Fix version: the release that removes a vulnerability.
• Malicious package: code published to do harm on purpose. It needs removal, not an upgrade.

Which attacks target the chain?

• Typosquatting: publishing a package with a name close to a popular one.
• Dependency confusion: tricking a build into pulling a public package in place of an internal one.
• Account takeover: stealing a maintainer's credentials to publish bad versions.
• Install script: code that runs during package installation, a common worm path.
• Worm: malware that spreads by publishing infected packages itself.
• Build compromise: tampering with the build system or its inputs.
• Poisoned pipeline: abusing CI configuration to run attacker code.
• Secrets leak: credentials committed to code, logs or images.
• Protestware: code changed by a maintainer to make a political point.
• Abandoned package: unmaintained code that no one patches.

What do defenders use?

• SCA: software composition analysis, which finds known issues in dependencies.
• SAST: static analysis of source code.
• DAST: testing a running application from outside.
• Secrets scanning: finding credentials in code and history.
• Reachability analysis: checking whether your code calls a vulnerable function.
• Triage: deciding which findings matter and who acts.
• Policy gate: an automated check that blocks a build or merge.
• Package firewall: a control that checks packages before install.
• Allowlist: an approved list of packages, licenses or tools.
• Pinning: fixing a dependency to an exact version or digest.
• Reproducible build: a build that gives identical output from identical inputs.
• Trusted publishing: publishing from CI with short-lived identity in place of stored tokens.
• Attestation: an authenticated statement about an artifact, for example signed provenance.
• Provenance: metadata about how and where an artifact was built.
• Signing: attaching a cryptographic signature to prove origin and integrity.
• SLSA: a framework of levels for build and source integrity.
• SSDF: NIST's Secure Software Development Framework, SP 800-218.
• License compliance: meeting the terms of the licenses in your dependencies.
• Copyleft: a license type that asks you to share source under conditions.
• Remediation: fixing or mitigating a finding.

What to do

1. Pick the ten terms your team argues about most and agree one definition each.
2. Link this list from your security onboarding page.
3. Use standard names in tickets, such as CVE and purl, so tools can match them.
4. Generate an SBOM and a VEX statement for one product to see both formats.
5. Check the primary definition before you use a term in a contract.

Quick check

Sources

• SLSA v1.0 terminology (retired page; v1.2 is current)
• CISA: Software Bill of Materials
• CISA: Minimum Requirements for VEX
• NTIA: Minimum Elements for an SBOM
• CycloneDX specification overview
• SPDX overview
• OSV documentation
• NIST SP 800-218 SSDF
• CISA Known Exploited Vulnerabilities catalog

Last reviewed: 18 October 2026.