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.

Use Sigstore verification as an enforcement component, not as a Kubernetes-native guarantee

Current SLSA level model: the approved SLSA v1.2 Build Track defines Build L0 through Build L3. Build L1 requires provenance, Build L2 adds signed provenance from a hosted build platform, and Build L3 adds hardened-build requirements. References to a current “SLSA Build Level 4” are legacy framing from older SLSA versions and should not be used as the current implementation target.

Sigstore provides a separate set of software-signing and verification components. Cosign signs and verifies containers and other artifacts; Fulcio issues short-lived signing certificates tied to identity; Rekor provides transparency-log services; and Sigstore's policy-controller provides an admission controller for Kubernetes that can validate image signatures and attestations.

Kubernetes admission control is the mechanism that allows admission-time policy to accept, warn on, or reject workload changes before persistence. Signature enforcement is not a generic property automatically supplied by every Kubernetes cluster or by Kubernetes 1.30 itself. A team must deliberately deploy and configure an admission policy implementation—such as Sigstore policy-controller—and then define which namespaces, image patterns, authorities, signatures, attestations, and failure modes are trusted.

For a safe rollout, begin in audit or warning mode where appropriate, inventory unsigned or unverifiable workloads, establish trusted identities and registries, pin image references to digests, validate the provenance/attestation policy against real release artifacts, and then move bounded namespaces or workloads to enforcement. Treat policy changes, trusted-root changes, bypass permissions, and controller administration as privileged supply-chain controls.

Do not claim a generic percentage reduction in “unverified deployments” unless it comes from your own measured environment or a traceable study. The objective is verifiable release evidence and explicit deployment policy, not an unsupported industry-average improvement statistic.

• SLSA v1.2 — Build Track Basics
• Sigstore — Tooling overview
• Sigstore — Kubernetes policy-controller
• Kubernetes — Admission control

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

Current baseline: CISA's 2025 minimum-elements update expands the historical 2021 NTIA baseline to eleven minimum data fields and revises the surrounding automation and process expectations. Use the CISA SBOM Minimum Elements 2025 guide for the current field-by-field implementation baseline.

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

• CISA — Minimum Elements for a Software Bill of Materials (2025)
• 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