Skip to content
Learni
View all tutorials
Sécurité logicielle

How to Secure the Software Supply Chain in 2026

Lire en français

Introduction

In 2026, software supply chain security is critical amid surging attacks like SolarWinds (2020, affecting 18,000 organizations) or Log4Shell (2021, a zero-day Java dependency vuln). These incidents reveal that 80% of breaches stem from third parties, per the Verizon DBIR 2025 report. An insecure supply chain leaves your artifacts (npm packages, Docker containers) vulnerable to upstream malware injections.

This intermediate tutorial guides you step by step: from threats to frameworks like SLSA (Supply-chain Levels for Software Artifacts), plus actionable strategies. Think of your CI/CD as a physical logistics chain: one weak link (compromised dependency) poisons everything. Securing it cuts risks by 70% (Gartner). By the end, you'll implement a robust policy that's bookmark-worthy for any DevSecOps lead.

Prerequisites

  • Basic knowledge of DevOps and CI/CD (GitHub Actions, Jenkins).
  • Familiarity with containers (Docker) and registries (Docker Hub, ECR).
  • Understanding of SBOMs (Software Bill of Materials) and supply chain attacks (e.g., XZ Utils 2024).
  • Tools like Sigstore or Trivy for hands-on practice.

Understanding Key Threats

Supply chain attacks target four phases: source, build, stage, and deploy.

PhaseThreat ExampleImpact
-------------------------------
SourceInjection in third-party repo (npm typosquatting)Malicious code in your dependencies
BuildCI/CD compromise (stolen GitHub token)Forged artifacts
StageRegistry poisoning (Hugging Face 2024)Infected container images
DeployRuntime injection (via K8s manifests)Post-deployment execution
Analogy: Like a wine supplier faking labels, an attacker tampers with a PyPI package without your scans noticing. Case study: The Codecov (2021) attack injected a malicious bash uploader into 42,000 CIs, exfiltrating credentials. Prioritize threats by likelihood: open-source dependencies (94% of apps, OWASP).

Adopting the SLSA Framework

SLSA (pronounced 'salsa'), developed by Google, defines 4 maturity levels for securing software artifacts. It's an open standard adopted by GitHub and the Cloud Native Computing Foundation.

LevelKey RequirementsConcrete Example
--------------------------------------
0Basic (no protections)Public repo without signatures
1Tamper-evident (immutable logs)GitHub Actions with provenance
2Tamper-resistant (no new scripts)Locked pipelines, no dynamic bash
3Trusted (all inputs signed)SLSA v1.0 for containers
4Full (hosted publishers)Cosign + Rekor for attestations
Why SLSA? It proves integrity via provenance (cryptographically signed metadata). Real-world case: After XZ Utils, Red Hat upgraded to SLSA level 2, blocking 99% of build-time injections. Aim for level 2 in 6 months.

Securing Phase by Phase

Apply defense-in-depth across each phase.

1. Source:

  • Generate SBOMs (via Syft or CycloneDX) to list all dependencies.
  • Policy: Audit vendors (GitHub Security score > 80/100).

2. Build:
  • Use ephemeral runners (GitHub-hosted).
  • Checklist: Secrets scanning (TruffleHog), SLSA provenance.

3. Stage:
  • Sign images (cosign) and scan (Trivy, Grype).
  • Private mirrors for public registries.

4. Deploy:
  • K8s admission controllers (Kyverno) to validate signatures.
  • Runtime monitoring (Falco).

Real example: At Uber, SLSA + SBOM implementation detected a transient vuln in 2 hours vs. 48 hours manually.

Implementing a Global Policy

Create a supply chain policy as a charter:

  1. Governance: DRI (Directly Responsible Individual) team per project.
  2. Audits: Quarterly with tools like OpenSSF Scorecard (github.com/ossf/scorecard).
  3. Response: Incident playbook (e.g., build freeze).
  4. Metrics: SBOM coverage >95%, detection time <24h.
Actionable framework:
  • Day 1: Dependency inventory (dependabot).
  • Week 1: SLSA level 1.
  • Month 1: Full signatures.
Case study: Post-SolarWinds, Microsoft mandated SBOMs for all suppliers, cutting risks by 60%.

Essential Best Practices

  • Always generate SBOMs: Integrate natively (npm ci --sbom).
  • Sign everything: Cosign for containers, npm sigstore for packages.
  • Minimize attack surface: Pinned versions (strict package-lock.json), zero-trust CI.
  • Automate scans: Gatekeeper in CI/CD (fail on high vulns).
  • Diversify suppliers: No more than 20% from one registry.

Common Mistakes to Avoid

  • Ignoring transitive deps: 70% of vulns come from them; use npm ls --depth=0.
  • Persistent runners: Easy to compromise; prefer ephemeral.
  • No secret rotation: A Codecov leak costs millions.
  • Static SBOMs only: Generate runtime SBOMs for dynamic containers.

Next Steps

Dive into official resources:


Check out our Learni DevSecOps training for hands-on SLSA workshops and real-world cases.