Software supply chain security glossary: 150 terms defined

Software supply chain security is the practice of knowing what goes into your software, how it was built and who can change it, then acting on risk at each step. This glossary defines 150 terms in plain English, grouped by topic, with links to the primary sources used at the end. Link to any heading.

Inventory and formats

• SBOM (software bill of materials). A nested inventory of the components that make up a piece of software.
• SPDX. An SBOM format, also used for licences.
• CycloneDX. An SBOM format designed for security use cases.
• SWID tag. A software identification tag, a third SBOM-related format.
• Software component. A unit of software, such as a library or package.
• Direct dependency. A component your code names itself.
• Transitive dependency. A component pulled in by another dependency.
• Dependency graph. The map of which components depend on which.
• Manifest. A file that declares a project's dependencies.
• Lockfile. A file that fixes exact dependency versions.
• Package manager. A tool that installs and tracks components.
• Package URL (purl). A standard string that names a package across ecosystems.
• CPE. An identifier scheme that names products for vulnerability matching.
• Component hash. A fingerprint of a file used to verify identity.
• Supplier. The party that provides a component.
• Minimum elements. The baseline data fields an SBOM should contain.
• VEX. A statement saying whether a product is affected by a known vulnerability.
• CSAF. A machine readable format for security advisories.
• AI-BOM. An inventory of the models, data and tools inside an AI system.
• Asset inventory. A list of the systems and software an organisation owns.
• Software composition analysis (SCA). Tooling that finds components and matches them to known vulnerabilities.
• Binary analysis. Identifying components by examining compiled files.

Vulnerabilities and risk

• Vulnerability. A weakness that can be used to harm a system.
• CVE. A public identifier for a specific known vulnerability.
• CWE. A category of weakness type, such as injection.
• CVSS. A scoring system for the severity of a vulnerability.
• EPSS. A score estimating the likelihood a vulnerability will be exploited.
• KEV. A catalogue of vulnerabilities known to be exploited in the wild.
• NVD. The US national database of CVE records and metadata.
• OSV. An open database format and service for vulnerabilities in open source.
• Security advisory. A notice describing a vulnerability and its fix.
• Zero-day. A flaw with no fix available when it is first exploited.
• N-day. A flaw that has been public for some time.
• Exploit. Code or technique that takes advantage of a vulnerability.
• Proof of concept. A demonstration that a flaw can be triggered.
• Patch. A change that fixes a vulnerability.
• Backport. Applying a fix to an older supported version.
• Fixed version. The first release that removes a vulnerability.
• Workaround. A temporary step that avoids a flaw without fixing it.
• Mitigation. A control that reduces risk from a flaw.
• Reachability. Whether your code can actually call the vulnerable code.
• Exploitability. How practical it is to use a flaw in your setting.
• False positive. A finding that is not real.
• False negative. A real issue that a tool misses.
• Severity. The potential impact of a flaw in general terms.
• Risk. Severity combined with likelihood and your exposure.
• Triage. Sorting findings to decide what to act on first.
• Remediation. Fixing or neutralising a finding.
• Remediation window. The time you allow to fix a class of finding.
• Coordinated disclosure. Reporting a flaw privately so a fix can ship first.
• Embargo. An agreed delay before publishing details.
• Vulnerability scanner. A tool that checks systems or code for known flaws.

Build and provenance

• CI/CD. Automated pipelines that build, test and deploy software.
• Build system. The tooling that turns source into artefacts.
• Artefact. A built output such as a package or container image.
• Provenance. A record of where and how an artefact was built.
• Attestation. A signed statement about an artefact or process.
• SLSA. A framework of levels for build integrity and provenance.
• Reproducible build. A build that gives identical output from identical input.
• Hermetic build. A build with no network access beyond declared inputs.
• Build runner. The machine that executes pipeline jobs.
• Ephemeral runner. A runner discarded after one job.
• Pipeline as code. Pipeline definitions stored in version control.
• Branch protection. Rules that restrict changes to key branches.
• Code review. Another person checking a change before merge.
• Separation of duties. No single person can write and release alone.
• Signed commit. A commit with a cryptographic signature of its author.
• Artefact signing. Signing built outputs so users can verify them.
• Sigstore. An open project for signing and verifying software.
• in-toto. A framework for recording supply chain steps.
• Transparency log. A public append-only record of signatures.
• Digest pinning. Referencing an artefact by its content hash.
• Version pinning. Fixing a dependency to a specific version.
• Secure development framework. A set of practices for building software safely.
• SSDF. The NIST framework of secure software development practices.
• Release gate. A check that must pass before release.
• Policy as code. Rules written so tools can enforce them.

Registries and dependencies

• Registry. A service that hosts packages for download.
• Public registry. A registry open to anyone, such as for open source.
• Private registry. A registry restricted to an organisation.
• Mirror. A copy of a registry kept under your control.
• Proxy repository. A cache between you and a public registry.
• Maintainer. A person who publishes and looks after a package.
• Abandoned package. A package no longer maintained.
• Deprecated package. A package its authors discourage using.
• Unmaintained dependency. A dependency with no recent fixes.
• Semantic versioning. A version scheme signalling the type of change.
• Version range. A permitted span of versions in a manifest.
• Dependency update bot. A tool that proposes version bumps.
• Vendoring. Copying a dependency's source into your repository.
• Fork. A copy of a project that can diverge.
• Licence compliance. Meeting the terms of open source licences.
• Copyleft. A licence type that requires sharing derived code.
• Permissive licence. A licence with few conditions on reuse.
• Attribution. Crediting authors as a licence requires.
• End of life. The date after which a product gets no fixes.
• Software supply chain. Everything and everyone involved in making and delivering software.

Attacks and threats

• Supply chain attack. Compromising software through a supplier or build step.
• Dependency confusion. Tricking a build into pulling a public package instead of an internal one.
• Typosquatting. Publishing a package with a name close to a popular one.
• Malicious package. A package designed to harm those who install it.
• Install script. Code that runs automatically when a package installs.
• Account takeover. Taking control of a maintainer's account.
• Protestware. Software altered by its author to make a political point.
• Backdoor. Hidden access built into software.
• Trojanised update. A legitimate-looking update that contains malware.
• Compromised build. A build process altered to inject code.
• Poisoned pipeline. A pipeline manipulated to run attacker steps.
• Secret leakage. Credentials exposed in code, logs or chat.
• Hardcoded credential. A password or key written into source.
• Package hallucination. An AI assistant suggesting a package that does not exist.
• Slopsquatting. Registering names that assistants tend to hallucinate.
• Lateral movement. An attacker moving between systems after entry.
• Exfiltration. Moving stolen data out of a network.
• Indicator of compromise. Evidence that a system was attacked.
• Malware. Software built to cause harm.
• Ransomware. Malware that locks data and demands payment.
• Threat actor. A person or group behind an attack.

Governance, compliance and risk management

• Software supply chain risk management. Managing risk from suppliers and components.
• C-SCRM. NIST's term for cybersecurity supply chain risk management.
• Third-party risk management. Assessing and monitoring vendors.
• Vendor questionnaire. A form a buyer sends to assess a supplier.
• Security attestation. A supplier's signed statement about its practices.
• Audit evidence. Records that show a control operated.
• Control. A safeguard that reduces a risk.
• Control mapping. Linking one control to requirements in several frameworks.
• Framework. A structured set of security or compliance requirements.
• Continuous monitoring. Checking controls regularly instead of yearly.
• Policy exception. Approved deviation from a policy.
• Shared responsibility. The split of security duties between provider and customer.
• Least privilege. Granting only the access needed for a task.
• Multi-factor authentication. Requiring more than one proof of identity.
• Non-human identity. An account for a service, bot or agent.
• Short-lived credential. A token that expires quickly.
• Secrets manager. A service that stores and rotates credentials.
• Secrets scanning. Searching code and history for exposed credentials.
• Incident response. Steps to handle a security incident.
• Tabletop exercise. A discussion-based rehearsal of an incident.
• Blast radius. How far damage spreads from one failure.
• Defence in depth. Layering controls so one failure is not enough.
• Zero Trust. A model that verifies every request instead of trusting a network.

AI and agent supply chain

• Model supply chain. The data, code and weights behind an AI model.
• Model card. A document describing a model's use, limits and evaluation.
• Model weights. The learned parameters that make a model work.
• Serialisation risk. Harm from loading untrusted model files.
• Retrieval augmented generation. Giving a model outside documents at question time.
• Vector database. A store of embeddings used for similarity search.
• Prompt injection. Input that tries to change what a model does.
• Excessive agency. An AI system with more power than its task needs.
• MCP. A protocol for connecting AI assistants to tools and data.

Quick check

Sources

• CISA SBOM
• NTIA Software Bill of Materials
• NIST Secure Software Development Framework
• NIST SP 800-161 Rev. 1
• SLSA
• OWASP Top 10 2025, A03 Software Supply Chain Failures
• OSV
• OWASP Dependency-Check
• OWASP LLM06 Excessive Agency
• OWASP LLM09 Misinformation
• MITRE ATLAS

Last reviewed: 18 October 2026.