Software Supply Chain Security Glossary

The practice of protecting software from tampering and attack across development, build, distribution and runtime — covering source code, third-party components, build systems, artifact registries and delivery channels. SolarWinds and Log4Shell made it a security priority. SCA vs SBOM explained →

A Software Bill of Materials: a complete inventory of every component, version and dependency in a piece of software — its 'ingredients list'. US EO 14028 accelerated SBOM adoption across federal procurement, and agencies may require SBOMs based on software criticality and solicitation requirements; the EU CRA imposes SBOM and transparency obligations on digital products placed on the EU market — different scopes, same direction. See CleanSource SCA's SBOM capabilities → SBOM requirements in 2026 → Full guide: What is an SBOM? →

Software Composition Analysis: automatically identifying open source components in code and detecting known vulnerabilities and license risks. CleanSource SCA identifies down to snippet level, across direct and transitive dependencies. See how CleanSource SCA works → Read the full guide: What is SCA? →

Direct dependencies are components you explicitly declare; transitive dependencies are what those components pull in themselves. Most vulnerabilities hide in transitive dependencies — transitive dependencies often make up the majority of a modern application's dependency tree, making them a major source of hidden and hard-to-track risk.

The full chain from writing code to running software: source code, third-party components, build systems, artifact registries, distribution channels. Contamination at any link propagates to the final product — supply chain security means bringing every link under trust management.

Four signal groups: activity (commit and release cadence), maintainer structure (solo vs team, organizational backing), community responsiveness (issue turnaround), and security practice (OpenSSF Scorecard, security response process). Health determines how fast a patch appears after a vulnerability. OpenSSF Scorecard →

Broadly permissive (MIT, Apache-2.0, BSD — few obligations, business-friendly) and copyleft (the GPL family — derivatives must be released under the same terms). Check obligation strength before adopting.

Derivative works built on GPL components must be open-sourced under GPL when distributed, with complete source provided — the 'viral' effect. Internal use without distribution generally does not trigger obligations. Exact obligations depend on modification, linking, distribution and deployment models; seek legal advice for specific cases.

LGPL is looser: dynamic linking generally doesn't require your code to be open-sourced. AGPL is stricter: serving over a network counts as distribution, so SaaS triggers the obligations too. Exact obligations depend on modification, linking, distribution and deployment models; seek legal advice for specific cases. GPL vs LGPL vs AGPL: full comparison →

Two components' license terms are mutually incompatible and cannot legally coexist in one work — classically GPLv2 vs Apache-2.0. Detection needs tooling at the dependency-combination level.

Both are permissive; the key difference is patents. Apache-2.0 includes an explicit patent grant and retaliation clause — safer for enterprises. MIT is shorter and simpler but silent on patents. Prefer Apache-2.0 where patent risk matters.

AGPL extends copyleft to network services: users accessing your service over a network also trigger source-provision obligations — the 'no distribution, no disclosure' exemption vanishes for SaaS. This is exactly why many cloud vendors ban AGPL components outright. Exact obligations depend on modification, linking, distribution and deployment models; seek legal advice for specific cases.

Depends on license type and usage: permissive licenses (MIT/Apache) don't require it; copyleft (GPL) requires derivative works to be opened upon distribution — internal use doesn't trigger it; LGPL with dynamic linking is generally exempt. The boundaries are subtle — which is why license analysis needs tooling. Exact obligations depend on modification, linking, distribution and deployment models; seek legal advice for specific cases.

Yes. GPL enforcement has ample precedent: the gpl-violations.org victories in Europe, and SFC v. Vizio in the US establishing that even consumers can assert GPL rights. Consequences: sales injunctions, forced disclosure, damages and reputational cost. 'Nobody enforces open source' is an outdated belief. Exact obligations depend on modification, linking, distribution and deployment models; seek legal advice for specific cases.

Common Vulnerabilities and Exposures: the global numbering system for known security flaws, e.g. CVE-2021-44228 (Log4Shell). Maintained by MITRE, it is the lingua franca of vulnerability intelligence.

The Common Vulnerability Scoring System quantifies severity from 0-10: 9.0-10.0 critical, 7.0-8.9 high, 4.0-6.9 medium. It factors attack vector, complexity, required privileges and user interaction.

Vulnerability Exploitability eXchange: a machine-readable statement from a vendor on whether a product is affected by a given vulnerability. It complements SBOM — SBOM says 'I contain this component', VEX says 'but this CVE is not exploitable in my usage', cutting false-positive triage cost dramatically. See VEX support in CleanSource →

CISA's Known Exploited Vulnerabilities catalog — only flaws with real-world exploitation evidence. The gold standard for prioritization: KEV-listed beats CVSS score — an actively exploited medium beats a paper-only critical. CISA KEV catalog →

CVSS measures theoretical severity, not real-world risk: a 9.8 with no exploit code in an isolated deployment can matter less than an actively mass-exploited 6.5. Prioritization should layer KEV (is it exploited?) and reachability analysis (does your code actually call the vulnerable function?).

The Exploit Prediction Scoring System: machine learning that predicts the probability a vulnerability will be exploited within 30 days, scored 0–1. Complements CVSS — CVSS says how severe, EPSS says how likely to actually be attacked. Combining both is standard in modern vulnerability prioritization. Official EPSS from FIRST →

Both are mainstream SBOM standards. SPDX (Linux Foundation, an ISO standard) models license compliance in finer detail; CycloneDX (OWASP) grew from security use cases and iterates fast. Most tools support both — choose per downstream requirements. SPDX → CycloneDX → SPDX vs CycloneDX in depth →

An OpenSSF-stewarded framework for software supply chain integrity. Version 1.2 is no longer a single 1-to-3 ladder: it defines separate tracks — a Build Track for build-process tamper resistance and provenance, and a Source Track for source-repository change control — each with its own assurance levels. Practical path: start by emitting build provenance (Build L1), then climb. SLSA levels are becoming the shared language large customers and foundations use to assess artifact integrity. Official SLSA 1.2 specification →

Cryptographically signing build outputs so downstream consumers verify integrity and provenance before use. Sigstore/Cosign made signing infrastructure free and easy — it's becoming a standard CI/CD stage.

Five dimensions: detection capability (snippet-level scanning vs manifest-only), data quality (vulnerability DB coverage and freshness), false-positive governance (reachability analysis, policy customization), engineering fit (CI/IDE integration, scan speed), compliance output (SBOM formats, audit reports). A POC on your own real codebase beats any spec sheet. Try CleanSource Community Edition → Full evaluation guide + checklist →

Three pieces: an internal registry mirror (periodically synced from outside under control), offline vulnerability-database updates (your SCA must support offline deployment and intel import), and an intake allowlist process (new components reviewed in a DMZ before entering). Standard in finance, defense and energy — 'full offline support' is a hard requirement in tool selection. Air-gapped SCA deployment guide →

Models and datasets become components themselves (and can be poisoned), fast-moving AI frameworks ship dense vulnerabilities, and agent plugin/tool mechanisms open code-execution surfaces. Per Sectrend CSSA monthly statistics for 2026, AI components rank among the most frequent sources of critical vulnerabilities. Explore CleanCode →

Contested and evolving: AI can reproduce copyrighted snippets from training data, importing unknown license obligations. The safe practice: run snippet-level SCA on AI-generated code to detect similarity to known open source and surface its license. See snippet-level detection →

An AI Bill of Materials extends the SBOM to record models, datasets, training frameworks and their provenance and versions. AI component transparency is moving toward more structured, standardized disclosure — CISA published AI-focused SBOM minimum elements guidance in 2026, and the EU AI Act adds transparency obligations. Organizations that inventory their AI assets now will be ahead when disclosure expectations solidify. CISA SBOM / AI SBOM guidance →

A poisoning variant targeting AI hallucinations: LLMs recommend nonexistent package names; attackers pre-register those hallucinated names in public registries and wait for developers to install per the AI's advice. Defense is the same as anti-poisoning: verify package authenticity and history before intake.

Model Context Protocol — an open protocol letting AI agents call external tools and data sources. The risks: MCP servers are a new supply-chain component (poisonable), tool descriptions can carry injected instructions (prompt injection), and agent permissions can be abused. Audit MCP servers before adoption exactly as you audit open source components. Explore SkillSec → MCP security guide + adoption checklist →

Agents convert text they read into actions they take: hidden instructions in web pages, documents or emails can be executed as tasks (indirect prompt injection) — while agents hold real credentials and system permissions. Defenses: least-privilege tools, human confirmation for sensitive actions, injection screening on agent-readable content. See SkillSec capability auditing →

The US baseline for what a useful SBOM must contain — updated by CISA in 2025. It covers data fields (supplier, component, version, identifiers, dependency relationships, author, timestamp), automation support, and practices. Most procurement requirements and tooling checklists trace back to this baseline: if your SBOM covers the minimum elements in SPDX or CycloneDX, you can answer most requests. CISA SBOM resources →

The CRA applies to products with digital elements placed on the EU market. Manufacturers must maintain component transparency (SBOM covering at least top-level dependencies), manage vulnerabilities across the product lifecycle, and report actively exploited vulnerabilities — reporting obligations begin phasing in ahead of the full application of the regulation through 2027. Obligations differ by role (manufacturer, importer, distributor) and product class, so map your exposure early. EU CRA official page →

Two international standards from the OpenChain Project: ISO/IEC 5230 specifies a quality open source license compliance program; ISO/IEC 18974 does the same for open source security assurance — a defined process for identifying and remediating known vulnerabilities in open source you consume. Adopting both signals to customers that your open source intake is governed, not ad hoc. Sectrend participates in the OpenChain community and aligns its tooling with both standards. OpenChain Project →

SLSA 1.2 organizes supply chain integrity into tracks — Build Track (tamper-resistant builds with provenance) and Source Track (source change control) — each with assurance levels. It matters commercially because large buyers increasingly reference SLSA levels in vendor security questionnaires: being able to state your build provenance level shortens security review cycles. SLSA 1.2 specification →

Toward structured disclosure, on two fronts: CISA published AI-focused SBOM minimum elements guidance in 2026, extending the SBOM discipline to models, datasets and frameworks; the EU AI Act adds transparency obligations for covered AI systems. Neither amounts to a universal AI BOM mandate today — but the direction is consistent, and organizations that inventory AI components now will meet requirements from a position of strength. CISA guidance →