Know what you built, where it came from, and what evidence survives delivery.

Inventory the supply chain as a graph, not a list of tools

Start with the path from source to production. Identify source repositories, source-control organizations, build definitions, reusable workflows, runners, package registries, dependency sources, signing or attestation systems, artifact stores, deployment controllers, cloud accounts, and the teams or suppliers that administer them.

For each link, record who can change it, what credentials it uses, what is logged, how changes are reviewed, what evidence is produced, and which downstream products depend on it. A highly trusted build service can become a concentration risk if hundreds of products depend on one administrative boundary.

Include external suppliers. A commercial package, hosted build service, base image, compiler, package registry, SaaS dependency, and managed deployment platform can all influence the software ultimately delivered.

Treat source integrity as a first-class assurance problem

SLSA 1.2's Source Track makes source-control assurance explicit. Organizations should decide what source properties they need to rely on: attributable changes, protected history, enforced review, controlled administrative access, durable repository identity, and evidence about the source-control system itself.

Do not stop at branch protection. Review who can change branch rules, bypass approvals, modify CI definitions, rewrite history, administer organization-wide apps, or inject credentials. Source governance should cover the privileged paths around the repository as well as the pull-request path inside it.

For critical products, record the source revision used for each release and retain enough information to reconstruct which repository state produced a deployed artifact.

Make build provenance useful to a verifier

Build provenance should connect an artifact digest to the build process and inputs that produced it. The consumer must then have a policy that decides whether the provenance is acceptable. Generating an attestation without verifying it later creates storage, not assurance.

Define which build platforms are approved, how their identities are established, how build definitions are protected, what network or credential access builders receive, whether builds are isolated, how secrets are injected, and what administrators can bypass.

At release or deployment, verify the artifact rather than trusting a mutable filename or tag. Where signatures or attestations are part of the design, verification failure should have an explicit operational result: block, quarantine, escalate, or require a documented exception.

Govern dependencies before vulnerability scanning begins

Dependency risk starts at selection. Define allowed sources, package managers, namespace protections, versioning policy, integrity checks, update ownership, unsupported-component rules, and what evidence is required for critical third-party software.

Lockfiles and checksums improve repeatability, but pinned software can still be vulnerable or abandoned. Maintain a process for identifying when a dependency is no longer acceptable because of vulnerability, provenance, maintainer, licence, support, or supplier changes.

For high-consequence dependencies, combine technical evidence with supplier due diligence. Use the NIST SP 1326 supplier due-diligence analysis and vendor security questionnaire when the dependency is delivered by a material vendor rather than an anonymous package alone.

Define the SBOM consumer before optimizing SBOM generation

An SBOM is valuable when someone uses it to answer a question: Which deployed products contain this component? Which versions are affected? Which supplier introduced it? Which product owner must act? Is the component reachable or actually used? What customer or regulator evidence must be produced?

Generate SBOMs at a point where component identity can be tied to a product and release. Preserve the artifact digest and product/version context. Decide whether generated data covers source dependencies, built packages, operating-system packages, containers, bundled libraries, and other relevant components.

Then test the response path. Choose a real or simulated component advisory and measure whether the organization can find affected releases, identify owners, determine production exposure, make a risk decision, and preserve the evidence used.

Create a release evidence bundle that can be queried later

Ask suppliers for evidence you can actually consume

Do not require an SBOM, provenance statement, attestation, penetration test, or certification merely because it sounds mature. Define how your team will receive it, what scope it must cover, which format or access path is useful, who reviews it, what finding changes the decision, and how often the evidence must be refreshed.

For hosted platforms, ask how the provider protects its own source and build systems, how material dependency or architecture changes are communicated, how vulnerability information is shared, and what happens to evidence access when the contract ends.

Exercise the supply-chain response path

Run at least three scenarios: a critical vulnerable dependency, a compromised or untrusted build path, and a supplier or registry disruption. For each scenario, determine how the organization identifies affected products, blocks new releases, validates existing artifacts, communicates with owners, rolls back or replaces components, and records the decision.

The exercise should expose missing identifiers and ownership. If teams cannot connect a component or build platform to deployed services, the supply-chain inventory is not operational yet.

Measure assurance coverage and response capability

• Production services linked to an identifiable source revision and artifact digest.
• Releases produced by approved build paths with verifiable provenance.
• Critical products with usable SBOMs tied to a release, not generic repository snapshots.
• Critical dependencies with named owners and support/update policy.
• Time to identify production exposure after a component or supplier alert.
• Exceptions that are expired, repeatedly renewed, or lack a compensating control.
• Supplier evidence that is stale or inaccessible to the teams expected to use it.

Current sources

• SLSA Specification v1.2 — current approved version
• NIST SP 800-204D — Strategies for Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines
• NIST SP 800-161 Revision 1 — Cybersecurity Supply Chain Risk Management Practices
• NIST SP 1326 — Supplier Due Diligence Assessment Quick-Start Guide
• CISA Software Bill of Materials resources