What is software supply chain security?

Software supply chain security is the practice of protecting everything that goes into your software and the path it takes to production: open source dependencies, build systems, CI pipelines, artifacts, and the people and tools that change the code. It answers two questions: what is in this software, and can I trust how it got here? Its main tools are software bills of materials (SBOMs), build provenance, dependency and license policy, and signed records of how each change was made.

What the software supply chain includes

Most applications are largely made of code their team did not write. Each direct dependency can pull in many transitive ones, which nobody on the team chose by name. Each of them is a supplier, whether or not there is a contract.

The supply chain covers:

• Source code and who can change it, including bots and AI agents.
• Dependencies, direct and transitive, and the registries they come from.
• Build tools and CI pipelines, including their plugins, runners and credentials.
• Artifacts: packages, container images and binaries, and where they are stored.
• Deployment: what promotes an artifact to production and with which credentials.

AI coding tools are now part of this chain. An agent that writes code also picks libraries, edits build files and pipeline definitions, and can be steered by text it reads. It should be governed like any other actor that can change what you ship.

Common supply chain attacks

Supply chain attacks target the trust between you and your suppliers. The well-known categories:

• Malicious package versions. An attacker takes over a maintainer account or a release process and publishes a version with harmful code. The 2024 backdoor found in the xz utils compression library was inserted through a long campaign to gain maintainer trust.
• Typosquatting. A malicious package with a name close to a popular one, waiting for a typo.
• Dependency confusion. A public package with the same name as an internal one, which a misconfigured build fetches instead.
• Build system compromise. Changing the build rather than the source, so the shipped artifact differs from the reviewed code. The 2020 SolarWinds attack worked this way.
• Vulnerable dependencies. Not an attack in itself, but the most common exposure. The Log4Shell vulnerability in Log4j, disclosed in December 2021, showed how hard it is to answer "where do we use this?" without an inventory.
• Hallucinated packages. AI assistants sometimes suggest package names that do not exist. If an attacker registers that name, the next person who installs the suggestion gets their code.

SBOMs: knowing what you ship

A software bill of materials is a machine-readable inventory of the components in a piece of software. The US NTIA's 2021 minimum elements for an SBOM list the data fields as supplier name, component name, component version, other unique identifiers, dependency relationships, the author of the SBOM data and a timestamp.

An SBOM is useful when you can act on it:

• Vulnerability response. When a new vulnerability is announced, search your SBOMs instead of every repository.
• License compliance. Sum the licenses of every component and compare them with your policy.
• Procurement and audit. Customers and regulators increasingly ask for SBOMs from software suppliers.

SBOMs are generated by tools that read lockfiles, package manifests, container images or build outputs. An SBOM generated from the build is more accurate than one assembled by hand, and one per release or per commit lets you answer questions about what was running at a point in time.

CycloneDX vs SPDX

Two open SBOM standards dominate. Most generators can produce both, and many teams pick whichever their customers or tooling ask for.

The SPDX License List matters to both formats: identifiers such as MIT, Apache-2.0 and GPL-3.0-only, and expressions such as MIT OR Apache-2.0, give licenses consistent names that tools can compare.

License compliance for AI-written code

Licenses decide what you may do with a component. Permissive licenses such as MIT, BSD and Apache 2.0 allow use in closed-source products with attribution. Copyleft licenses such as the GPL require that derived works be released under the same terms when distributed, and the AGPL extends that to software offered over a network. Whether a license is a problem depends on how you distribute your product, which is a question for your legal team, not a tool.

AI agents make license compliance more pressing in two ways. They add dependencies quickly, often without anyone reading the package's license. And a dependency added in one change may only surface at release, when it is expensive to remove.

The practical answer is to check license policy automatically, on every change:

• Generate an SBOM in CI.
• Keep a list of licenses you do not accept.
• Fail the pipeline when the SBOM contains one of them.
• Treat a missing SBOM as a failure, not as nothing to report.

A separate question is whether AI-generated code reproduces licensed code from a model's training data. That is a legal and policy question, and an SBOM does not answer it, because SBOMs list packages, not snippets.

Frameworks: SLSA and the NIST SSDF

SLSA (Supply-chain Levels for Software Artifacts) is an OpenSSF framework for build integrity. Its build track defines levels that range from having provenance at all to producing it from a hardened, isolated build platform. Provenance is a signed statement of how an artifact was built: from which source, by which builder, with which parameters.

The NIST Secure Software Development Framework (SSDF, SP 800-218) groups secure development practices into preparing the organisation, protecting the software, producing well-secured software and responding to vulnerabilities. US federal software suppliers are asked to attest to it.

Neither is a product you install. They are checklists for what your process should guarantee.

How to build a supply chain security programme

1. Inventory. Generate an SBOM for every release, from the build, and store it with the release.
2. Pin and lock. Use lockfiles and pinned versions so builds are reproducible and changes to dependencies show up in a diff.
3. Scan dependencies. Run software composition analysis against vulnerability data on every change and on a schedule.
4. Set license policy. Agree which licenses are banned, and check every change against the SBOM in CI.
5. Protect the build. Least-privilege CI credentials, isolated runners and build provenance where your platform supports it.
6. Review dependency changes. A new dependency is a new supplier. Review it like code, especially when an AI agent added it.
7. Gate on the results. Make these checks part of a quality gate, so a failure stops the change.
8. Keep records. Store SBOMs, scan results and approvals with each change, so you can show what shipped and why.

How AI CodeOps does it

AI CodeOps keeps a history of the SBOMs you produce for each project, in CycloneDX or SPDX format, and uses the latest one for a license check. It does not generate SBOMs and does not scan dependencies against a vulnerability database: generate the SBOM with the tool you already use, then record it. In the open beta, a record is created with a request to /api/sbom from a signed-in session:

{
  "projectID": "checkout",
  "commitSHA": "4f2a9c1e7b3d",
  "format": "cyclonedx",
  "formatVersion": "1.5",
  "downloadURL": "https://artifacts.example.com/checkout/4f2a9c1e7b3d/bom.json",
  "sha256": "9d1c5e0b7a2f4c6e8d0b1a3c5e7f9a2b4d6c8e0f1a3b5c7d9e2f4a6b8c0d1e3f",
  "componentCount": 412,
  "vulnerableCount": 3,
  "licenseSummary": { "MIT": 301, "Apache-2.0": 74, "ISC": 29, "BSD-3-Clause": 8 },
  "generationSource": "ci"
}

When your CI calls the release check with disallowedLicenses, the check fails if the project's latest SBOM lists one of them, and it fails if the project has no SBOM at all. The relevant part of a denied answer:

{
  "allowed": false,
  "summary": "Disallowed license \"GPL-3.0\" in checkout (2 components)",
  "reasons": ["Disallowed license \"GPL-3.0\" in checkout (2 components)"],
  "licenseViolations": [{ "projectID": "checkout", "license": "GPL-3.0", "count": 2 }],
  "licenseEvidenceMissing": []
}

The match is against the license names in the SBOM's summary. The check uses the project's current SBOM, not one per commit. The Dependency Auditor agent reviews manifests for vulnerable, conflicting or unmaintained packages in the Dependency Refresh and Release Readiness workflows, using the model's knowledge rather than a live advisory database. Each change can also be downloaded as a signed evidence pack.

See Security and SBOM tracking, the Security and SBOM and Dependency audit guides, and the free SBOM viewer, which opens a CycloneDX JSON file in your browser without uploading it.

Go deeper

• What is an SBOM?: what goes in one, component identifiers, SBOM types from design to runtime, generation and VEX.
• What is SLSA?: the build track levels, what a provenance attestation records, and how to verify it before you deploy.