The cloud-native supply chain is a long conveyor belt: source code, third-party dependencies, a build system, a container registry, and finally a Kubernetes cluster or serverless runtime. An attacker doesn't need to breach your production account if they can slip malicious code onto that belt earlier and let your own pipeline deliver it. The last few years made the threat concrete — the SolarWinds build-system compromise (2020), the Codecov bash-uploader incident (2021), the dependency-confusion technique that pushed look-alike internal packages to public registries (2021), and the XZ Utils backdoor (CVE-2024-3094) planted in a widely used compression library (2024). Securing this belt means putting a control at each stage. This guide walks them in order, source to runtime.
Stage 1: Source Integrity
The supply chain starts at the repository. Protect the default branch with required reviews and status checks, require signed commits so authorship can't be forged, and enforce phishing-resistant MFA on every account with write access. Dependency confusion begins here too: configure your package manager to resolve internal names only from your private registry, never falling back to the public one, so an attacker can't publish a higher-versioned public package with your internal name and win resolution.
Stage 2: Dependency Provenance and the SBOM
Most of your code isn't yours — it's transitive dependencies you've never read. A software bill of materials (SBOM) is the inventory that makes this tractable. Generate one in a standard format (CycloneDX or SPDX) for every build, and scan it against vulnerability data before the artifact ships.
# CI: generate and scan an SBOM as a build gate
- name: Generate SBOM and scan dependencies
run: |
safeguard sbom generate --format cyclonedx --output sbom.json
safeguard scan --sbom sbom.json --fail-on high
The value of an SBOM is retrospective as much as preventive: when the next XZ- or Log4Shell-class disclosure lands, the question "which of our artifacts contain this component?" becomes a query instead of a multi-day audit. Software composition analysis both generates the SBOM and adds reachability analysis, so you patch the dependencies your code actually calls first.
Stage 3: Build Integrity and SLSA
The build system is a high-value target because its output is trusted implicitly. The SLSA framework (Supply-chain Levels for Software Artifacts) defines increasing levels of build integrity; the core idea is generating signed provenance — a verifiable record of what source and dependencies produced an artifact, on which builder. Run builds in isolated, ephemeral environments, keep them hermetic where you can, and emit provenance so a consumer can verify an artifact wasn't tampered with after the fact.
Stage 4: Sign and Verify Artifacts
An unsigned container image is one an attacker can swap. Sign images and their provenance at build with a tool like Sigstore's cosign, and store the signatures alongside the artifacts in your registry.
# Sign an image, then verify its provenance before it can run
cosign sign $REGISTRY/orders-api@sha256:...
cosign verify-attestation --type slsaprovenance $REGISTRY/orders-api@sha256:...
Pin images by digest (@sha256:...), not by mutable tags like latest, so what you verified is exactly what runs.
Stage 5: Admission Control at Deploy
The final gate is the cluster itself. A Kubernetes admission controller (Kyverno, OPA Gatekeeper, or Sigstore's policy-controller) can reject any image that isn't signed by your key, lacks valid SLSA provenance, or carries an unresolved critical vulnerability — so an unverified artifact never becomes a running pod, even if something upstream failed.
Protect the Pipeline's Own Credentials
The belt itself runs on credentials, and those are a target in their own right. A CI/CD system typically holds registry-push tokens, cloud-deploy roles, and signing keys — compromise the pipeline and an attacker doesn't need to touch your source at all; they can inject into the build or publish a malicious artifact directly. Several real incidents turned on exactly this kind of build-system or CI-secret exposure. Scope pipeline credentials to the minimum each job needs, prefer short-lived federated tokens (OIDC from your CI to the cloud) over stored long-lived keys, isolate signing keys in a KMS or hardware-backed store rather than a CI variable, and log every deploy and publish action for review. The provenance you generate in Stage 3 is only as trustworthy as the builder that signed it.
Supply Chain Control Map
| Stage | Control | Artifact |
|---|---|---|
| Source | Branch protection, signed commits, MFA, scoped registries | Repository |
| Dependencies | SBOM + reachability scan, dependency-confusion guard | SBOM |
| Build | Isolated/hermetic builds, SLSA provenance | Provenance |
| Artifacts | Sign with cosign, pin by digest | Signature |
| Deploy | Admission policy verifies signature + provenance + CVEs | Running workload |
How Safeguard Helps
Safeguard instruments the belt end to end. It generates a CycloneDX or SPDX SBOM for every build through software composition analysis and adds reachability analysis, turning the next big disclosure into a query rather than a fire drill — and it can ingest SBOMs you already produce to unify the view. Its container image scanning verifies image contents and flags vulnerable layers before they're pushed, and its infrastructure-as-code scanning checks the manifests and admission policies that gate deployment so the verification step can't be quietly disabled. All of it runs inside your pipeline, so SBOM generation, dependency scanning, and policy gates live inside the build rather than bolted on after. Griffin, Safeguard's AI triage engine, ranks findings by real exploitability across the whole chain so teams fix what attackers can actually reach. If you're comparing supply-chain approaches, the Safeguard vs Snyk comparison lays out the differences.
Secure your supply chain from source to runtime — get started free or read the documentation.