8. Software Supply Chain and Artifact Security

Introduction and Context

Modern software is rarely created entirely within one organisation. Applications depend on open-source libraries, commercial components, container base images, build tools, cloud services, package registries, and automated delivery platforms. A change introduced in any of these elements may affect the security, reliability, legality, and operational behaviour of the final product. The software supply chain is therefore the complete network of people, processes, tools, code, dependencies, and infrastructure involved in producing and delivering software.

Traditional application security concentrated primarily on the source code written by developers. DevSecOps extends that concern to the entire production pathway. A secure source repository is insufficient if an attacker can replace a dependency, compromise a build runner, alter an artifact in a registry, or provide a misleading security report. Software supply chain security seeks to establish confidence that an artifact is composed of approved inputs, produced by an authorised process, and delivered without unauthorised modification.

This chapter examines the technical and organisational controls used to protect that chain. It focuses on dependency management, package registries, build systems, software bills of materials (SBOMs), provenance, digital signatures, attestations, SLSA, reproducible builds, and vulnerability disclosure. It also considers third-party risk, governance, practical implementation, and the trade-offs between security assurance, delivery speed, cost, and usability.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain the structure and security significance of a modern software supply chain.

2. Distinguish dependencies, packages, artifacts, provenance, attestations, signatures, and SBOMs.

3. Analyse threats affecting source repositories, build systems, registries, and deployment artifacts.

4. Design a layered approach to dependency, artifact, and build security.

5. Apply SLSA principles, reproducible-build techniques, and policy-based verification.

6. Evaluate third-party and open-source risk using technical and governance criteria.

7. Develop an appropriate vulnerability disclosure and response process.

8. Assess practical and ethical trade-offs in supply chain security programmes.

The Software Supply Chain as a System

A software supply chain begins with requirements and source code, but it does not end when code is committed. A typical chain includes source repositories, developer workstations, dependency-resolution tools, package managers, build servers, test systems, artifact repositories, signing services, deployment pipelines, and production environments. Each stage can introduce, transform, or transmit software components.

An artifact is a produced software object, such as a binary, container image, library archive, installation package, or infrastructure module. Artifacts are normally immutable releases of a build process. A dependency is an external component required to compile, test, package, or run a system. Direct dependencies are explicitly selected by a project; transitive dependencies are introduced by those direct dependencies. A small application can consequently inherit a large and difficult-to-observe dependency graph.

Supply chain security has three central objectives. First, an organisation must know what is present in an artifact. Second, it must know how and from which inputs the artifact was produced. Third, it must be able to detect whether the artifact or its production process was altered. These objectives correspond broadly to composition visibility, provenance, and integrity.

The distinction between integrity and authenticity is important. A cryptographic hash can show that an object has not changed since the hash was calculated, but it does not identify who produced it. A digital signature links an object to a signing identity, while provenance explains the process and inputs associated with that object. Effective assurance normally requires all three: an integrity mechanism, a trusted identity, and meaningful production evidence.

Threats Across the Chain

Supply chain attacks exploit trust relationships. An attacker may compromise a widely used dependency, publish a malicious package under a confusing name, steal developer credentials, alter a build script, compromise a continuous integration runner, or replace an artifact in a repository. Some attacks target availability or intellectual property rather than direct code execution.

Dependency confusion occurs when a package manager retrieves an attacker-controlled public package instead of an internally intended package with the same name. Typosquatting uses names that resemble legitimate packages. Maintainer-account compromise allows attackers to publish malicious versions under an otherwise trusted project identity. A vulnerable dependency may be introduced deliberately or simply remain unpatched for years.

Build systems are particularly attractive targets because they often possess source-code access, signing credentials, deployment permissions, and secrets. Risks include untrusted pull-request code executing with excessive privileges, poisoned build caches, mutable build images, exposed tokens, and undocumented manual interventions. A compromised build process can produce a legitimate-looking artifact that passes ordinary functional tests.

Registries also require protection. An attacker may upload a malicious package, delete a required version, replace mutable tags, compromise repository credentials, or exploit weak access controls. In container environments, relying on a tag such as `latest` creates ambiguity because the tag may point to different content over time. Digest pinning identifies content more precisely.

Dependency Governance and Open-Source Risk

Dependency management is not merely the act of running a package-manager command. It is a governance discipline involving selection, evaluation, versioning, monitoring, and retirement. Organisations should maintain an inventory of direct and transitive dependencies and record their source, licence, maintainer information, version, integrity data, and business criticality.

Version ranges provide convenience but reduce determinism. A declaration permitting any compatible future version may silently introduce a new vulnerability or behavioural change. Lockfiles record resolved versions and integrity values, helping teams reproduce installations. They must themselves be reviewed and protected because an altered lockfile can redirect the build to malicious content.

Useful controls include private mirrors, approved package lists, dependency pinning, automated update tools, vulnerability scanning, licence review, and review of maintainer activity. No single vulnerability score should determine a decision. Severity, exploitability, reachability, exposure, compensating controls, support status, and business context all matter. A high-severity issue in unreachable test code may deserve a different response from a moderate vulnerability in an internet-facing authentication service.

Open-source risk also has a human dimension. Projects may be maintained by small communities, depend on unpaid labour, or have limited security processes. Organisations benefiting from such software have a professional responsibility to report vulnerabilities responsibly, contribute fixes where feasible, and avoid treating maintainers as an invisible free service. Procurement and architecture teams should consider sustainability and support alternatives for critical components.

SBOMs: Making Composition Visible

A software bill of materials is a structured inventory of the components contained in or required by a software product. It can include package names, versions, suppliers, identifiers such as Common Platform Enumeration or package URLs, licences, hashes, and dependency relationships. Common exchange formats include SPDX and CycloneDX.

An SBOM is not itself a guarantee that software is secure. It is an evidence and analysis instrument. It enables an organisation to ask whether a newly disclosed vulnerability affects a product, identify where a component is used, support licence compliance, and accelerate incident response. Its value depends on accuracy, completeness, freshness, and the ability to connect component records to deployed assets.

SBOM production should occur as part of the build rather than as an occasional manual exercise. Organisations should establish whether the SBOM describes source dependencies, runtime dependencies, generated components, operating-system packages, or all of these. They should also preserve the relationship between an SBOM and the exact artifact it describes. An SBOM detached from a versioned artifact can create false confidence.

SBOM limitations include incomplete metadata, duplicated component identities, difficulty representing dynamically downloaded code, and uncertainty about vulnerabilities in unused functions. SBOMs also create information-protection concerns: publishing a detailed inventory may assist attackers. Access, distribution, and retention policies should therefore reflect the sensitivity of the product.

Provenance, Attestations, and Signatures

Provenance is information describing where, when, and how an artifact was produced. It may identify the source revision, build definition, builder, dependencies, parameters, environment, and resulting digest. Provenance enables verification of claims such as “this image was built from the reviewed source at revision X using the approved workflow.”

An attestation is a signed statement about an object or process. Examples include an SBOM attestation, a vulnerability-scan result, a test attestation, or a statement that a build was produced by a particular trusted service. Attestations are useful because different security questions require different evidence. A signature on an image may prove who signed it, but not whether it passed tests or contains approved dependencies.

Digital signatures require careful identity and key management. Signing keys should be protected by hardware-backed or managed key services where appropriate, with limited permissions, rotation procedures, revocation processes, and auditable use. The signing identity should represent a controlled workload or release authority rather than an individual’s long-lived workstation key. Verification must occur before deployment, not merely after publication.

A practical policy might require that production accepts only artifacts whose digest is signed by the release service, whose provenance identifies an approved repository and protected branch, whose SBOM contains no prohibited component, and whose vulnerability scan satisfies the organisation’s risk threshold. Such policies convert evidence into an enforceable control.

SLSA and Build Assurance

SLSA, commonly expanded as Supply-chain Levels for Software Artifacts, is a framework for improving the integrity of software production. It emphasises increasing confidence in the source and build process through controls such as authenticated provenance, protected build infrastructure, isolation, and resistance to tampering. SLSA should be understood as a maturity-oriented framework rather than a product or a single scanner.

At lower maturity, an organisation may document how artifacts are built and generate provenance. At stronger levels, the build is performed by a service that prevents untrusted inputs from modifying the build process, produces non-forgeable provenance, isolates steps, and protects the relationship between source and output. The exact level appropriate to an organisation depends on threat model, product criticality, regulatory expectations, and available resources.

SLSA does not eliminate all vulnerabilities. A build can be faithfully produced from source that contains a security defect. Provenance can establish that an artifact came from a particular source, but it cannot prove that the source is correct. SLSA therefore complements code review, testing, dependency analysis, secure design, and operational monitoring.

Reproducible Builds and Determinism

A reproducible build produces the same result when built from the same source and declared inputs, ideally producing an identical binary or verifiable equivalent. Reproducibility allows an independent party to rebuild software and compare outputs. If the outputs differ, investigators can examine whether the difference arises from timestamps, host paths, compiler versions, network access, generated randomness, or malicious interference.

Achieving reproducibility requires controlling build inputs and environment. Teams may need pinned compiler versions, fixed dependency versions, deterministic archive ordering, normalised timestamps, isolated network access, and explicit build parameters. Reproducibility can be difficult for projects that embed timestamps, use nondeterministic parallel operations, or download content during compilation.

Reproducibility is distinct from provenance. Provenance records how a specific build occurred; reproducibility enables another party to test whether the claimed process can produce the same result. Together they provide stronger assurance. Where byte-for-byte identity is impractical, organisations may use reproducible metadata, binary transparency, or independent comparison techniques, while documenting residual uncertainty.

Securing the Build and Registry Infrastructure

Build security begins with separation of trust domains. Code from an untrusted pull request should not execute in an environment containing production credentials or release-signing keys. Build workers should be ephemeral where practical, minimally privileged, patched, monitored, and isolated from unrelated workloads. Secrets should be injected only when necessary and should not be exposed to logs or untrusted build steps.

Build definitions must be treated as security-sensitive code. Changes to workflow files, dependency configuration, container definitions, and release scripts should receive review and be subject to branch protection. Builds should avoid unaudited scripts fetched from the internet at execution time. Network egress should be restricted, and external inputs should be authenticated and pinned.

Registries should enforce authenticated publishing, immutable release versions, role-based access control, malware and vulnerability scanning, retention policies, audit logging, and backup. Consumers should verify signatures and digests and should distinguish development, staging, and production repositories. Promotion between repositories is generally safer than rebuilding the same source separately for each environment because it preserves artifact identity.

A Practical Assurance Workflow

A mature workflow integrates controls rather than placing them in a separate security queue. During design and dependency selection, teams classify components and identify unacceptable licences or unsupported technologies. During development, package managers use lockfiles and approved sources. During pull-request validation, automated checks examine dependency changes, secrets, licence constraints, and build configuration.

During the build, the pipeline generates the artifact, SBOM, provenance, and relevant attestations. The artifact is signed by an authorised service and stored immutably. A policy engine then evaluates whether deployment requirements have been satisfied. At deployment, the platform verifies the artifact digest, signature, provenance, and policy results. In production, inventory systems map running workloads to artifact versions so that vulnerability response can identify affected services.

When a vulnerability is disclosed, the organisation queries its SBOM and deployment inventory, assesses exploitability and exposure, applies mitigations or upgrades, rebuilds and signs the corrected artifact, and records the decision. The process should include communication with customers, suppliers, and regulators when required.

Illustrative Case Study: The Compromised Build Runner

Background

A fictional financial-services company, Northstar Payments, operates a containerised transaction platform. Its release pipeline builds images from a protected source repository and publishes them to a private registry. The company performs dependency scanning but does not generate provenance or enforce signature verification at deployment.

Situation and Problem

An attacker gains access to a self-hosted build runner through an outdated administrative component. The runner has a persistent workspace and stores a cloud credential used to publish images. The attacker modifies a build script so that a credential-stealing utility is copied into the production image. Tests pass because the utility does not affect application behaviour. The attacker then replaces the image associated with a mutable production tag.

Analysis

The incident is not only a vulnerability in the runner. It is a chain-of-trust failure. The build environment was persistent, the publishing credential was overprivileged, tags were trusted instead of immutable digests, and deployment did not verify provenance or signatures. Dependency scanning could not detect a malicious file inserted during the build because the file was not a declared dependency.

Approach and Solution

Northstar first revoked credentials, isolated the runner, and redeployed a previously verified image from a known digest. It then introduced ephemeral runners, separated build and release permissions, and moved signing keys to a managed signing service. Build workflows were protected by mandatory review. The pipeline began producing SBOMs and provenance statements, while the registry enforced immutable versions.

The deployment platform was configured to accept only images signed by the release identity and accompanied by provenance identifying the approved repository and workflow. Network access from build jobs was restricted, and production images were promoted by digest rather than rebuilt. The company also created a continuously updated inventory connecting deployed workloads to artifact digests.

Outcome

These measures did not guarantee that source code would always be secure, but they substantially reduced the attacker’s ability to publish an undetectable artifact. A later test involving an unauthorised build failed at the deployment policy gate because its provenance and signature did not satisfy policy.

Learning Points

The case demonstrates that artifact security depends on the build environment as much as on the artifact itself. Scanning alone cannot establish trustworthy origin. Least privilege, ephemeral infrastructure, immutable references, provenance, signing, and deployment verification must operate together.

Challenges, Limitations, and Common Errors

Supply chain security programmes often fail through misplaced confidence. An organisation may generate an SBOM but never connect it to deployed assets, sign artifacts but leave signing keys accessible to arbitrary build steps, or adopt a framework without defining which threats it addresses. Another common error is treating every scanner finding as equally urgent, creating alert fatigue and encouraging teams to ignore security results.

Legacy builds may depend on undocumented network access or unmaintained tools, making reproducibility expensive. Small teams may lack the resources to operate private registries, independent rebuild infrastructure, or 24-hour vulnerability response. Strict policies can also impede emergency releases if exception processes are absent. Controls should therefore be risk-based and implemented progressively.

False positives, incomplete component detection, and stale vulnerability databases limit automated analysis. Signatures prove control of a key, not the trustworthiness of the person or process behind it. Provenance can be accurate yet describe insecure source code. Security leaders should communicate these limitations clearly rather than presenting assurance controls as absolute guarantees.

Governance, Ethics, and Vulnerability Disclosure

Governance should define ownership for dependency approval, artifact signing, exception decisions, incident response, and supplier management. Contracts with third parties may require timely vulnerability notification, evidence of secure development practices, SBOM delivery, incident cooperation, and preservation of relevant logs. Regulatory obligations vary by jurisdiction and sector, so legal and compliance teams should participate in policy design.

Responsible vulnerability disclosure balances public safety, vendor remediation, researcher recognition, and transparency. Organisations should publish a security contact or vulnerability-reporting policy, acknowledge reports, assess severity, protect reporters from retaliation where legally appropriate, and coordinate disclosure timelines. Researchers should avoid unnecessary access to personal data or disruption of services. Organisations receiving a report should not conceal material risk merely to protect reputation.

SBOMs and provenance can contain sensitive information about internal systems, suppliers, and build practices. Their collection and distribution should follow data-minimisation and access-control principles. Ethical supply chain security also requires avoiding discriminatory or arbitrary treatment of open-source maintainers and recognising the social costs of imposing unreasonable security demands on under-resourced projects.

Automation, Policy, and Emerging Practice

Automation is valuable because inventories, dependency graphs, vulnerability records, signatures, and deployment states change continuously. Policy-as-code can express requirements such as approved registries, signed images, non-expired attestations, restricted licences, and maximum vulnerability thresholds. Automated remediation tools can create upgrade proposals, but human review remains necessary when upgrades affect compatibility, licences, or business risk.

Emerging practice includes stronger workload identity, transparency logs for signed artifacts, independent build verification, in-toto-style link metadata, secure software development attestations, and increased use of hardware-backed keys. Organisations are also improving the mapping between SBOMs and live assets, enabling faster exposure analysis during a vulnerability event.

Artificial intelligence introduces additional supply chain questions. AI-generated code may import unfamiliar libraries, reproduce insecure patterns, or obscure authorship and licensing. Models, training data, prompt-processing services, and model packages themselves form supply chains requiring provenance and integrity controls. AI tools should therefore be integrated into existing review, dependency, signing, and disclosure processes rather than treated as inherently trustworthy.

Best-Practice Design Principles

A defensible programme generally follows these principles:

• Maintain an accurate inventory of source, dependencies, artifacts, and deployed instances.
• Prefer immutable, digest-addressed artifacts and protected package sources.
• Generate SBOMs and provenance as build outputs and associate them with exact artifact identities.
• Sign artifacts and attestations using narrowly scoped, auditable identities.
• Isolate untrusted code from release credentials and production environments.
• Use reproducible or independently verifiable builds for high-value software.
• Verify policy at deployment rather than relying solely on build-time checks.
• Prioritise vulnerabilities using exploitability, reachability, exposure, and business impact.
• Establish a tested vulnerability disclosure and incident-response process.
• Treat supply chain security as shared responsibility among developers, security teams, procurement, platform engineers, suppliers, and leaders.

Chapter Summary

Software supply chain security protects the relationships and processes through which software is selected, built, stored, and delivered. Dependencies and package registries require controlled sourcing, version pinning, integrity verification, and continuous assessment. SBOMs provide composition visibility; provenance explains production; attestations record verifiable claims; signatures establish authenticity; and reproducible builds support independent verification. SLSA offers a maturity-based approach to improving build integrity, while secure runners, least privilege, immutable registries, and deployment policy enforcement reduce opportunities for tampering.

These technologies are most effective when integrated with governance, third-party management, responsible vulnerability disclosure, and risk-based decision-making. No individual control proves that software is safe. Assurance arises from layered evidence connecting source, build process, artifact, and deployment environment.

Key Terms

SBOM: A structured inventory of software components and their relationships.

Artifact: A produced software object such as a binary, package, or container image.

Dependency: An external component required to build, test, or run software.

Transitive dependency: A dependency introduced indirectly through another dependency.

Provenance: Information describing an artifact’s source, inputs, builder, and production process.

Attestation: A signed statement asserting a property about an artifact or process.

Digital signature: A cryptographic mechanism linking data to a signing identity and detecting modification.

Digest: A cryptographic hash used to identify specific content.

Package registry: A repository that stores and distributes software packages or artifacts.

Dependency confusion: An attack that substitutes a malicious public package for an intended internal package.

Lockfile: A file recording resolved dependency versions and often their integrity values.

SLSA: A framework for increasing confidence in software source and build integrity.

Reproducible build: A build that produces the same or verifiably equivalent result from the same inputs.

Immutable artifact: An artifact whose content cannot be changed without creating a new identity.

Vulnerability disclosure: The process of reporting, assessing, remediating, and communicating security defects.

Policy as code: Machine-readable rules that automatically evaluate security or compliance conditions.

Artifact promotion: Moving a verified artifact between environments without rebuilding it.

Third-party risk: Security, operational, legal, and continuity risk arising from external suppliers or components.

Review Questions

Short Answer Questions

1. Why is an SBOM useful during vulnerability response?

2. Distinguish provenance from a digital signature.

3. What is dependency confusion?

4. Why should production deployments prefer artifact digests over mutable tags?

5. State two benefits of reproducible builds.

Long Answer Questions

1. Explain the major attack surfaces across a modern software supply chain.

2. Discuss how SBOMs, provenance, signatures, and attestations complement one another.

3. Describe a secure build and registry architecture for a high-value application.

4. Explain the purpose of SLSA and evaluate its limitations.

5. Discuss the governance and ethical responsibilities involved in open-source vulnerability disclosure.

Analytical / Application Questions

1. A company signs container images, but any developer can modify the build workflow and access the signing key. Analyse the weaknesses and propose corrective controls.

2. A newly disclosed vulnerability affects a transitive dependency used by several applications. Design a response process using SBOMs, deployment inventory, exploitability analysis, and artifact promotion.

3. An organisation wants to require byte-for-byte reproducible builds for every project but has many legacy systems. Develop a risk-based adoption strategy and identify reasonable exceptions.

22. Multiple Choice Questions with Answers

Question 1

Which combination provides the strongest evidence that an artifact was produced from an approved source by an authorised process?

A. A vulnerability scan and a mutable version tag

B. A hash stored in a developer’s workstation

C. A verified signature together with provenance identifying the approved source and builder

D. A package name and a successful unit test

Correct Answer: C. A verified signature together with provenance identifying the approved source and builder

Question 2

What is the primary purpose of an SBOM during incident response?

A. To prove that the software contains no vulnerabilities

B. To identify products and deployments containing an affected component

C. To replace all security testing

D. To encrypt the software artifact

Correct Answer: B. To identify products and deployments containing an affected component

Question 3

Which practice most directly reduces dependency confusion risk?

A. Allowing unrestricted access to public registries

B. Using private package sources and explicitly controlling package resolution

C. Using mutable package tags

D. Disabling lockfiles

Correct Answer: B. Using private package sources and explicitly controlling package resolution

Question 4

Why are ephemeral build runners valuable?

A. They guarantee that source code is vulnerability-free

B. They prevent all failures in compilation

C. They reduce persistence of attacker changes and residual secrets between builds

D. They eliminate the need for access control

Correct Answer: C. They reduce persistence of attacker changes and residual secrets between builds

Question 5

What does a reproducible build enable an independent party to do?

A. Change the source without review

B. Rebuild the software from declared inputs and compare the result

C. Publish packages without authentication

D. Avoid recording build provenance

Correct Answer: B. Rebuild the software from declared inputs and compare the result

Question 6

A deployment system accepts any image labelled latest. What is the principal security weakness?

A. The image cannot contain dependencies

B. The label may refer to different content over time and does not uniquely identify the artifact

C. The image will always fail vulnerability scanning

D. The registry cannot store metadata

Correct Answer: B. The label may refer to different content over time and does not uniquely identify the artifact

Question 7

Which statement best describes SLSA?

A. A replacement for all application testing

B. A framework for improving confidence in software source and build integrity

C. A package manager used only for containers

D. A vulnerability severity scoring system

Correct Answer: B. A framework for improving confidence in software source and build integrity

Question 8

Why is signing alone insufficient for supply chain assurance?

A. Signatures cannot detect modification

B. A signature does not by itself prove that the source, dependencies, or build process were secure

C. Signatures cannot identify an artifact

D. Signed artifacts cannot be stored in registries

Correct Answer: B. A signature does not by itself prove that the source, dependencies, or build process were secure

Question 9

A vulnerability scanner reports a severe flaw in a library used only in unreachable test code. What is the most appropriate initial response?

A. Ignore every future scan result

B. Immediately shut down all production systems without analysis

C. Assess reachability, exposure, exploitability, and business impact before prioritising remediation

D. Delete the SBOM

Correct Answer: C. Assess reachability, exposure, exploitability, and business impact before prioritising remediation

Question 10

Which control best prevents untrusted pull-request code from using production release credentials?

A. Running all builds on one persistent server

B. Storing credentials in the source repository

C. Separating trust domains and limiting secrets to authorised release workflows

D. Using a longer package name

Correct Answer: C. Separating trust domains and limiting secrets to authorised release workflows