13. Software Supply-Chain and Dependency Security

Introduction and Context

Modern software is rarely built entirely by one organization. Applications incorporate open-source libraries, commercial components, container images, operating-system packages, build tools, cloud services, development platforms, and code generated or transformed by automated systems. This network of relationships is the software supply chain: the sequence through which software and its constituent artifacts are selected, developed, built, distributed, deployed, and maintained.

The supply chain creates substantial engineering value, but it also creates security exposure. A vulnerability in a widely used library may affect thousands of organizations. A malicious package may imitate a legitimate dependency. A compromised maintainer account, build server, package registry, or software update mechanism may allow attackers to insert code without directly attacking the final user. Consequently, secure software development must govern not only source code but also the identity, integrity, provenance, and lifecycle of every component used to produce software.

Dependency security is therefore broader than vulnerability scanning. It involves informed procurement, inventory, trust decisions, version control, verification of origin, protection of build pipelines, rapid response, and evidence that released artifacts correspond to reviewed source and approved processes. This chapter examines these activities through software composition analysis, software bills of materials, provenance, signing, reproducible builds, dependency policies, SLSA, Sigstore, and related governance practices.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain the structure and risks of modern software supply chains.

2. Distinguish direct, transitive, optional, development, and runtime dependencies.

3. Evaluate software composition analysis and SBOM practices.

4. Analyze typosquatting, dependency confusion, malicious packages, and compromised pipelines.

5. Explain provenance, artifact signing, verification, reproducible builds, SLSA, and Sigstore.

6. Design dependency-management and secure-procurement policies.

7. Interpret supply-chain risk in technical, organizational, legal, and managerial terms.

8. Recommend controls for realistic software supply-chain scenarios.

The Software Supply Chain as a System of Trust

A software supply chain contains several interacting layers. Developers select dependencies and obtain them from registries or vendors. Source repositories store application and build code. Continuous integration systems compile, test, package, and sign artifacts. Registries distribute packages, containers, and installers. Deployment systems consume those artifacts in production. Each layer has identities, permissions, metadata, and attack paths.

A useful distinction is between source integrity, build integrity, and artifact integrity. Source integrity concerns whether the code repository contains the intended, reviewed content. Build integrity concerns whether the build process used the expected source, tools, configuration, and dependencies. Artifact integrity concerns whether the binary, package, or container delivered to users is the artifact produced by that authorized process and has not been altered.

A secure supply chain must also establish authenticity. Integrity answers the question, “Has this object changed?” Authenticity asks, “Who produced or authorized it?” A cryptographic hash can identify content, but it does not by itself identify its creator. Digital signatures bind an identity or key to a digest and can support authorization decisions, provided that keys, identities, and verification rules are managed properly.

Important Dependency Concepts

A direct dependency is explicitly declared by an application. A transitive dependency is required by another dependency. Transitive dependencies are especially important because developers may not know they exist, yet they execute within the application or build environment.

A runtime dependency is needed when the application operates. A development dependency supports testing, linting, compilation, or packaging and may not be deployed, but it can still compromise source code or the build pipeline. An optional dependency is activated only under particular features or platforms. A vendored dependency is copied into the project rather than retrieved during the build. Vendoring may improve availability and reviewability, but it can also make updates and provenance more difficult.

A package manager resolves, downloads, installs, and records dependencies. A lockfile records exact versions, and often integrity hashes, selected for a particular dependency graph. Version ranges provide flexibility but can introduce non-determinism if not constrained. A private registry or proxy can provide controlled access, caching, policy enforcement, and protection against external registry outages; it must itself be secured against unauthorized publication and tampering.

Principal Supply-Chain Threats

Vulnerable and Abandoned Components

A legitimate component may contain a known vulnerability, use an insecure algorithm, expose unsafe defaults, or become unmaintained. Vulnerability presence is not identical to exploitability: the affected function may not be reachable, the vulnerable feature may be disabled, or compensating controls may exist. Nevertheless, organizations need a repeatable process for identifying, prioritizing, mitigating, and documenting such issues.

A component may also become operationally risky when its maintainers disappear, its release practices deteriorate, or its license changes. Dependency selection should therefore consider maintenance activity, responsiveness, release transparency, security advisories, and organizational support—not merely popularity or download count.

Typosquatting and Dependency Confusion

Typosquatting uses a package name that resembles a legitimate name, such as a spelling variation, misplaced character, or altered punctuation. It exploits human error during installation or dependency declaration. Dependency confusion occurs when a package manager selects a malicious public package over an identically named internal package, often because of repository precedence or version-resolution behavior.

Controls include explicit registry configuration, namespace ownership, reserved internal names, dependency allowlists, lockfiles, package signature verification, review of new dependencies, and private-registry policies that prevent untrusted fallback to public sources. Developers should not install packages merely because a command or forum post recommends them.

Malicious Packages and Maintainer Compromise

A malicious package may be intentionally created, or a legitimate package may be modified after an attacker compromises a maintainer account. Malicious behavior can include credential theft, cryptocurrency mining, data exfiltration, destructive actions, or manipulation of downstream builds. Obfuscated install scripts are a particular concern because some package managers execute code during installation.

Package review should examine provenance, ownership, release history, permissions, install scripts, network access, and unusual changes. However, manual review cannot scale alone. Organizations need layered controls: restricted build environments, network egress controls, malware analysis, dependency pinning, automated scanning, and rapid revocation or quarantine procedures.

Compromised Build and Distribution Pipelines

Attackers may target source-control accounts, CI runners, build plugins, secrets, artifact repositories, signing keys, or release automation. A compromised pipeline can produce a clean-looking artifact from untrusted inputs. Distribution compromise may replace a package after publication or redirect users to a malicious location.

The relevant question is not only whether a dependency is vulnerable but also whether the organization can prove what was built, from which source, with which tools, under which identity, and whether the released object is unchanged. This requirement motivates provenance attestations, isolated builds, protected branches, short-lived credentials, separation of duties, and artifact verification.

Software Composition Analysis and SBOMs

Software composition analysis (SCA) identifies components in an application and compares them with vulnerability, license, and policy information. SCA may analyze manifest files, lockfiles, source code, binaries, container layers, or a combination of these. Strong implementations detect transitive dependencies and distinguish development components from production components.

SCA results require interpretation. A scanner may produce false positives because of inaccurate version detection, duplicated components, unreachable code, or a vulnerability that does not affect the configured feature. It may produce false negatives when dependencies are dynamically loaded, bundled, renamed, embedded, or unavailable to the analyzer. A vulnerability score is a prioritization input, not a complete risk decision.

A software bill of materials (SBOM) is a structured inventory of software components and their relationships. Common exchange formats include SPDX and CycloneDX. An SBOM may contain component names, versions, supplier information, identifiers such as package URLs or Common Platform Enumeration references, licenses, hashes, dependency relationships, and tool metadata.

An SBOM is not a security certificate. It describes what is believed to be present; it does not prove that the inventory is complete, accurate, current, or trustworthy. Its value increases when it is generated from authoritative build data, linked to a specific artifact, signed or attested, stored with release records, and updated when the artifact changes.

Organizations should establish an SBOM operating process: generate inventories during builds, validate them, retain them with artifacts, monitor vulnerability intelligence, identify affected products, notify owners, and record remediation or risk acceptance. Customer-provided SBOM requirements should be treated as procurement and operational requirements rather than as a documentation exercise.

Provenance, Signing, and Reproducible Builds

Provenance is evidence describing where and how an artifact was produced. It may identify the source revision, build definition, builder, parameters, dependencies, timestamps, and output digest. Provenance supports investigation and policy decisions, but it is meaningful only when the producing system is trustworthy and the attestation is protected from alteration.

Artifact signing uses a private key to sign an artifact or its digest. Consumers verify the signature with a trusted public key or identity. Signing should be integrated with authorization policies: an application should accept artifacts signed by approved builders or publishers, not simply any valid signature. Key protection may involve hardware-backed storage, keyless signing, short-lived certificates, workload identities, rotation, revocation procedures, and separation between development and production signing.

Sigstore is an ecosystem for signing and transparency practices that can reduce dependence on long-lived private keys. Its components include identity-based signing mechanisms, a certificate authority, and a public transparency log. In a typical keyless workflow, a workload or developer authenticates through an external identity provider, obtains a short-lived certificate, signs an artifact, and records the event in a transparency log. Verification can then consider the artifact digest, signer identity, build context, certificate, and log entry. Sigstore improves auditability, but organizations must still define trusted identities and verification policies.

A reproducible build produces the same output, or an equivalently verifiable output, when given the same source, dependencies, tools, and declared environment. Reproducibility reduces uncertainty and makes unauthorized build changes easier to detect. It can be difficult because of timestamps, file ordering, nondeterministic compilation, embedded paths, network retrieval, generated identifiers, and toolchain differences. Reproducible builds are not identical to secure builds: a malicious source tree can be reproducibly compiled. They are best combined with code review, provenance, isolated builders, and independent verification.

SLSA and a Layered Assurance Model

SLSA, commonly pronounced “salsa,” provides a framework for improving software supply-chain security through increasing levels of assurance. Its model emphasizes source and build requirements, provenance, protected build services, and verification. The exact level terminology and requirements evolve, so organizations should consult the applicable SLSA specification rather than treat levels as permanent labels.

The progression is conceptually important. Basic practices document the build process. Stronger practices prevent tampering with build inputs and outputs, use hosted or isolated build services, generate authenticated provenance, and make it difficult for a single compromised developer environment to forge a release. Higher assurance requires stronger protection of source, builders, dependencies, and release processes.

SLSA does not certify that software is free of vulnerabilities, nor does it replace secure coding, testing, or threat modeling. It answers a different class of questions: whether a release can be traced to authorized source and a controlled build process, and whether tampering would be detectable or difficult. A mature program maps SLSA expectations to practical controls such as protected branches, ephemeral runners, hermetic builds, two-person release approval, provenance verification, and restricted signing authority.

Dependency Governance and Secure Procurement

A dependency policy translates security principles into operational decisions. It should define approved sources, permitted licenses, versioning rules, vulnerability thresholds, exception authorities, update responsibilities, support expectations, and retirement procedures. Policies should distinguish blocking conditions from conditions requiring review. For example, a critical vulnerability in reachable production code may block release, while a low-severity issue in an unused development tool may require tracking rather than immediate rejection.

A sound workflow commonly includes:

• proposal and business justification for a new dependency;
• review of maintenance, reputation, license, provenance, and security history;
• automated retrieval through an approved registry or proxy;
• exact version and integrity recording;
• SCA, license, malware, and secret scanning;
• testing and review of transitive dependencies;
• approval according to risk and data-access requirements;
• continuous monitoring and scheduled updating; and
• documented removal, replacement, or risk acceptance when support ends.

Secure procurement extends this analysis to commercial suppliers. Contracts may require vulnerability disclosure, security contacts, incident notification, SBOM delivery, secure development evidence, patch timelines, provenance information, independent assurance, data-handling restrictions, and rights to audit or receive remediation information. Procurement teams should avoid treating a security certification or questionnaire as conclusive proof. Evidence must be matched to the product, deployment model, and threat profile.

Ownership must be explicit. Developers own appropriate dependency selection and integration; platform teams own registry and build controls; security teams provide standards, intelligence, and assessment; procurement manages supplier obligations; legal teams review licensing and contractual exposure; product leadership accepts residual risk. A committee may coordinate decisions, but it should not obscure accountable owners.

Practical Implementation Architecture

A mature implementation establishes a controlled path from declaration to deployment. Developers use approved package sources and lockfiles. Pull requests trigger dependency-diff analysis, SCA, license checks, secret detection, and tests. CI builds in an isolated environment with minimal credentials and controlled network access. The build emits an SBOM and provenance attestation, then signs the artifact using an approved identity. The artifact is stored in a registry that enforces immutability and access control. Deployment systems verify digest, signature, provenance, policy, and environment compatibility before release.

Monitoring continues after deployment. Vulnerability intelligence is correlated with SBOMs to identify affected artifacts and services. Runtime telemetry helps establish whether vulnerable functionality is reachable. Emergency procedures can quarantine an artifact, block a package version, revoke trust, rotate credentials, rebuild from a clean source, and notify stakeholders. The organization should test these procedures rather than assume that a database or scanner automatically produces a response.

Automation is valuable but requires governance. Dependency-update bots can create pull requests, run tests, and propose upgrades. Policy engines can reject unsigned artifacts or packages from unapproved registries. Analytics can identify unusually large dependency changes, new maintainers, anomalous release timing, or unexpected network activity. Machine-learning systems may help prioritize alerts, but they can miss novel attacks and produce misleading confidence. Human review remains necessary for high-impact decisions.

Illustrative Case Study: The Northstar Payments Release

Background

Northstar Payments, a fictional mid-sized financial-technology company, operates a customer transaction service built from internally developed code and several hundred open-source components. It uses a public package registry, a cloud CI platform, and container images deployed through a managed orchestration system. The company scans source manifests but does not generate SBOMs for released containers.

Situation and Problem

A developer adds a small utility package whose name closely resembles an established internal package. The public package contains an installation script that collects environment variables and sends them to an external server. Because the public registry has a higher version number and the build does not enforce the internal namespace, the package manager selects it during a clean build. The CI runner has access to cloud credentials used for publishing images.

The malicious package is detected two days later when network monitoring identifies an unusual outbound connection. By then, one production image and several test artifacts have been built. The organization must determine exposure, identify affected releases, preserve evidence, and restore trust.

Analysis

The immediate technical failure is dependency confusion, but the deeper failure is governance. Northstar lacks namespace reservation, registry precedence controls, dependency review, installation-script restrictions, artifact provenance, and an SBOM that would quickly identify the affected package. Excessive CI permissions increase the possible impact. The company also cannot readily prove which source, dependency graph, and builder produced each image.

Strategy and Solution

Northstar first disables the affected package and rotates exposed credentials. It quarantines images built during the relevant period, compares artifact digests, examines runner logs, and reviews cloud activity. It rebuilds from a known-good revision in an isolated environment and verifies that the replacement image is signed by the approved builder.

For prevention, the company reserves internal package namespaces, configures the package manager to use a controlled proxy, blocks direct public fallback, and requires approval for new dependencies. CI credentials are replaced with short-lived, narrowly scoped identities. Every release now produces a CycloneDX SBOM and provenance attestation. Deployment admission policies require an approved signature, trusted builder identity, vulnerability-policy compliance, and an exact image digest. Northstar also establishes a rehearsed incident procedure for malicious dependencies.

Outcome

The immediate release is restored with a verifiable build record, and the organization can identify affected consumers through SBOM-based inventory. The new controls do not eliminate all supply-chain risk, but they reduce the probability of accidental selection, limit blast radius, and improve detection and response.

Learning Points

The case demonstrates that a scanner operating only on source manifests is insufficient. Registry configuration, namespace governance, least privilege, build isolation, SBOMs, signatures, provenance, and incident response must operate as a system. It also shows why supply-chain security is a management responsibility: technical controls require policy, ownership, funding, and tested procedures.

Challenges, Limitations, and Common Mistakes

One common mistake is treating dependency count as the primary risk measure. A small but privileged package may be more dangerous than many isolated libraries. Another is relying on vulnerability severity without considering reachability, exploit availability, exposure, compensating controls, and business impact.

Organizations often generate SBOMs only at release time, omit transitive or build dependencies, fail to link inventories to immutable digests, or assume that an SBOM proves integrity. They may sign artifacts but fail to verify signatures at deployment, or use one broadly shared signing key whose compromise invalidates trust. Lockfiles can become stale, and pinning versions can delay security updates if update automation is absent.

Reproducible builds may require significant engineering effort, especially for native toolchains and complex container environments. Private registries create valuable control points but become high-value targets. SCA tools have incomplete vulnerability data and may disagree on package identity. Finally, strict policies can encourage unsafe workarounds if they are slow or inaccessible. Governance must be rigorous while providing developers with a practical approved path.

Ethical, Legal, and Regulatory Considerations

Dependency governance involves responsibilities to customers, maintainers, employees, and the wider digital ecosystem. Organizations should avoid concealing known supply-chain incidents, should notify affected parties according to applicable obligations, and should provide maintainers with responsible vulnerability reports. Open-source licenses impose conditions that may include attribution, notice, source-code availability, or patent terms. Automated copying or modification without license review can create legal exposure.

SBOMs may reveal proprietary architecture, vulnerable components, or supplier relationships. Their distribution should therefore be controlled according to audience and purpose. Procurement decisions should not unfairly exclude open-source projects solely because they lack commercial documentation; risk should be evaluated proportionately, with support and funding considered where the organization depends heavily on a critical project.

Current Developments and Emerging Directions

Supply-chain programs are moving from periodic scanning toward continuous, identity-aware verification. In-toto-style attestations, SLSA-aligned provenance, Sigstore workflows, and policy-as-code are increasingly used to connect build evidence with deployment decisions. Standards for SBOM exchange and vulnerability exploitation context continue to mature.

Another important direction is the security of build and development assistants. Code-generating systems may introduce unreviewed dependencies, insecure patterns, or contaminated training outputs. Their use should be covered by the same review, testing, provenance, and licensing controls as other development inputs. Organizations are also examining software bills of materials for machine-learning models, datasets, and plugins, extending supply-chain reasoning beyond conventional packages.

Best-Practice Checklist

A postgraduate practitioner should be able to recommend the following baseline:

1. Maintain an authoritative inventory of direct, transitive, runtime, build, and container dependencies.

2. Use approved registries, reserved namespaces, lockfiles, integrity hashes, and controlled network access.

3. Review new dependencies for security history, maintenance, license, permissions, and business necessity.

4. Generate, validate, store, and monitor SBOMs for release artifacts.

5. Protect source repositories, CI systems, registries, and signing identities with least privilege and strong authentication.

6. Produce authenticated provenance and verify signatures and policy at deployment.

7. Make builds as deterministic and isolated as practical, and independently verify important releases.

8. Automate updates, vulnerability triage, license checks, and emergency blocking without eliminating human judgment.

9. Contractually govern commercial suppliers and require meaningful security evidence.

10. Exercise incident-response procedures for malicious packages, compromised maintainers, and forged or altered artifacts.

Chapter Summary

Software supply-chain security governs the trust relationships through which software components become production artifacts. Risks arise from vulnerable or abandoned dependencies, typosquatting, dependency confusion, malicious packages, compromised maintainers, insecure build systems, and distribution tampering. Effective control combines dependency policy, SCA, SBOMs, controlled registries, provenance, signatures, reproducible builds, least privilege, and continuous monitoring.

SCA identifies component and vulnerability information, while SBOMs provide structured inventories; neither automatically proves safety or integrity. Provenance records how an artifact was produced, signatures support authenticity and integrity, and reproducible builds improve independent verification. SLSA provides a model for increasing build and provenance assurance, while Sigstore supports identity-based signing and transparency. Secure procurement extends these controls to commercial suppliers and contractual obligations. The central lesson is that supply-chain security is a socio-technical discipline requiring engineering controls, governance, ethical responsibility, and tested response processes.

Key Terms

Software supply chain: The people, processes, systems, components, and artifacts involved in producing and delivering software.

Direct dependency: A component explicitly declared by an application.

Transitive dependency: A component introduced because another dependency requires it.

Software composition analysis (SCA): Automated analysis that identifies software components and evaluates vulnerabilities, licenses, and policies.

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

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

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

Digital signature: Cryptographic evidence linking an artifact or digest to an authorized signing identity.

Reproducible build: A build that produces the same or equivalently verifiable output from the same declared inputs.

Lockfile: A file recording exact dependency selections and often integrity information.

Typosquatting: Impersonation of a legitimate package through a similar name.

Dependency confusion: Selection of an untrusted package instead of an identically named internal package.

Package registry: A service that stores and distributes software packages.

SLSA: A framework for increasing software supply-chain build and provenance assurance.

Sigstore: An ecosystem supporting identity-based signing and public transparency for software artifacts.

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

Hermetic build: A build designed to use only explicitly declared and controlled inputs.

Vulnerability reachability: The extent to which vulnerable functionality can actually be invoked in a deployment.

Namespace reservation: Preventing untrusted parties from registering names intended for internal packages.

Dependency policy: Organizational rules governing selection, use, monitoring, updating, and retirement of components.

Review Questions

Short Answer Questions

1. Distinguish source integrity, build integrity, and artifact integrity.

2. Why can a transitive dependency create security risk even when developers did not select it directly?

3. What information can an SBOM contain, and why is an SBOM not a security certificate?

4. Explain the relationship between a digital signature and artifact authenticity.

5. State two reasons why reproducible builds may be difficult to achieve.

Long Answer Questions

1. Explain how SCA, SBOMs, provenance, and signing complement one another in a secure release process.

2. Discuss the principal differences among vulnerable components, malicious packages, dependency confusion, and compromised build pipelines.

3. Describe how SLSA concepts can be translated into practical controls for a CI/CD environment.

4. Design a dependency governance policy for an organization using both open-source and commercial components.

5. Evaluate the technical, managerial, ethical, and legal considerations involved in secure software procurement.

Analytical / Application Questions

1. An organization signs all container images but permits any developer workstation to publish to the registry. Analyze the assurance weaknesses and recommend controls.

2. A vulnerability scanner reports a critical issue in a transitive library, but the affected function is not reachable in production. Explain how the organization should investigate, prioritize, document, and communicate the decision.

3. Design an incident-response plan for a suspected malicious package discovered in a CI build, including evidence preservation, credential actions, artifact decisions, notification, and long-term remediation.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes provenance from a digital signature?

A. Provenance identifies vulnerabilities, while a signature lists licenses.

B. Provenance describes how an artifact was produced, while a signature provides cryptographic evidence connected to an identity.

C. Provenance is an exact dependency version, while a signature is a lockfile.

D. Provenance replaces the need for protected build systems, while a signature replaces testing.

Correct Answer: B. Provenance describes how an artifact was produced, while a signature provides cryptographic evidence connected to an identity.

Question 2

A private package named internal-parser is unintentionally replaced by a higher-version public package. Which threat is most directly involved?

A. Buffer overflow

B. Typosquatting only

C. Dependency confusion

D. Reproducible-build failure

Correct Answer: C. Dependency confusion

Question 3

What is the strongest use of an SBOM in incident response?

A. It guarantees that every listed component is secure.

B. It identifies which released artifacts may contain an affected component.

C. It automatically patches vulnerable components.

D. It proves that the build system was uncompromised.

Correct Answer: B. It identifies which released artifacts may contain an affected component.

Question 4

Which control most directly limits the impact of stolen CI credentials?

A. Longer package names

B. Broad, permanent publishing permissions

C. Short-lived, narrowly scoped identities

D. Disabling dependency updates

Correct Answer: C. Short-lived, narrowly scoped identities

Question 5

Why should deployment systems verify both a signature and the signer’s identity or authorization?

A. A valid signature alone does not prove that the signer is approved for the deployment context.

B. Signatures cannot identify changed content.

C. Identity verification makes hashing unnecessary.

D. Only unsigned artifacts can contain vulnerabilities.

Correct Answer: A. A valid signature alone does not prove that the signer is approved for the deployment context.

Question 6

Which statement about reproducible builds is accurate?

A. They prove that source code is non-malicious.

B. They ensure that every dependency is vulnerability-free.

C. They make equivalent inputs produce the same or verifiably equivalent output.

D. They eliminate the need for provenance.

Correct Answer: C. They make equivalent inputs produce the same or verifiably equivalent output.

Question 7

A package contains an installation script that accesses environment variables and contacts an external server. What is the most appropriate initial response?

A. Approve it because installation scripts are always harmless.

B. Quarantine the package and investigate its behavior and affected build credentials.

C. Increase the package version range.

D. Remove all SBOM generation from the pipeline.

Correct Answer: B. Quarantine the package and investigate its behavior and affected build credentials.

Question 8

Which practice best addresses typosquatting?

A. Allowing developers to install packages from any registry

B. Using namespace controls, approved registries, and review of new dependencies

C. Relying exclusively on package download counts

D. Disabling lockfiles

Correct Answer: B. Using namespace controls, approved registries, and review of new dependencies

Question 9

What is a limitation of vulnerability severity scores in dependency decisions?

A. They never contain technical information.

B. They cannot be used with open-source software.

C. They do not alone establish reachability, exploitability, or business impact.

D. They are relevant only after deployment.

Correct Answer: C. They do not alone establish reachability, exploitability, or business impact.

Question 10

Which statement most accurately describes SLSA?

A. A framework for increasing assurance in software build and provenance processes

B. A replacement for all secure coding practices

C. A package manager used to resolve transitive dependencies

D. A vulnerability database containing only container flaws

Correct Answer: A. A framework for increasing assurance in software build and provenance processes