Software supply chain security is the work of knowing what is inside the software you build or buy, and making sure none of it has been tampered with or carries known flaws. This glossary covers the terms you will hear most, in plain words, grouped by topic.
Inventory and formats
Software supply chain. Everything that goes into software: code you write, libraries, build tools, the systems that package it and the people with access.
Dependency. A piece of other people's code your software uses.
Direct dependency. One your team chose on purpose.
Transitive dependency. One pulled in by another dependency. Most of what you ship is transitive.
SBOM. Software bill of materials. CISA calls it a nested inventory, a list of ingredients that make up software components (CISA).
SPDX. An SBOM format.
CycloneDX. Another SBOM format, published as ECMA-424, that also covers hardware, services and cryptographic assets (CycloneDX).
HBOM. A bill of materials for hardware.
Component. One item listed in an SBOM.
Lockfile. A file that records exact dependency versions so builds repeat.
Package manager. A tool that downloads and installs dependencies, such as npm or pip.
Registry. A public or private store of packages.
Vulnerabilities
Vulnerability. A flaw that can be misused to harm a system.
CVE. A public identifier for a specific vulnerability.
CWE. A category of weakness, such as SQL injection. MITRE ranks the most common each year (MITRE).
NVD. The US National Vulnerability Database, which adds severity and affected product data to CVE records.
CVSS. A scoring standard for severity, maintained by FIRST. The current version is 4.0 (FIRST).
Advisory. A notice describing a flaw and its fix.
Patch. A software update that fixes a flaw.
Zero-day. A flaw exploited before a fix exists.
Exploit. Code or a method that takes advantage of a flaw.
Known exploited. A flaw with evidence of real attacks.
VEX. A statement of whether a product is affected by a known vulnerability. CISA calls it an attestation, a form of security advisory.
Reachability. Whether your code actually calls the vulnerable part of a library. If not, the finding is lower priority.
False positive. A report of a problem that is not real.
Remediation. Fixing or reducing the risk.
Attacks on the chain
Malicious package. A package built to do harm.
Typosquatting. Publishing a package with a name close to a popular one, hoping for a typing mistake.
Dependency confusion. Tricking a build into fetching a public package instead of an internal one of the same name.
Account takeover. An attacker gains control of a maintainer's account and publishes a bad version.
Install script. A command a package runs when installed, sometimes abused.
Build compromise. An attacker alters the build system so shipped software differs from its source.
Backdoor. A hidden way to access a system.
Obfuscation. Making code hard to read to hide what it does.
Controls and practices
Pinning. Fixing a dependency to a specific version.
Provenance. A record of where and how software was built.
Attestation. A signed statement about software or a process.
Code signing. Using a cryptographic signature to show who published software and that it was not altered.
Hash. A short fingerprint of a file used to check it is unchanged.
Reproducible build. A build that produces identical output from the same source.
SAST. Static application security testing, which reads source code for flaws.
SCA. Software composition analysis, which finds known issues in dependencies.
DAST. Dynamic testing of a running application.
Secrets scanning. Looking for passwords and keys left in code.
Least privilege. Giving each person and system only the access needed.
SSDF. NIST's Secure Software Development Framework, SP 800-218, with four practice groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software and Respond to Vulnerabilities (NIST).
Shift left. Finding issues earlier in development.
Gate. A check that blocks a build or merge when a rule fails.
Open source license. The terms that allow you to use a library, which can carry obligations.
Vendor risk. The risk from suppliers whose software or services you rely on.
What to do
- Share this list with finance, legal and procurement before your next supply chain review.
- Add your own team's terms and tools to it.
- Pick five terms your team misuses and agree on one meaning.
Quick check
What is the difference between an SBOM and a VEX?
An SBOM lists what is in software. A VEX says whether a listed component's known vulnerability actually affects the product.
Is a transitive dependency less risky than a direct one?
No. It runs in your product all the same. You just chose it less deliberately, so it is easier to overlook.
Sources
Last reviewed: 18 October 2026.
