Software Supply Chain Security in 2026: SBOMs, Sigstore, and Defending Against the Next SolarWinds

The SolarWinds attack in 2020 demonstrated that compromising a single software vendor could give attackers access to 18,000 organizations, including multiple US government agencies. Since then, supply chain attacks have only accelerated: the 2024 XZ Utils backdoor (CVE-2024-3094) showed that even open-source projects maintained by a single burned-out developer can be subverted through years of patient social engineering. In 2025, over 245,000 malicious packages were detected across npm, PyPI, and RubyGems — a 400% increase from 2023.

Software supply chain security is no longer optional. US Executive Order 14028 mandates SBOMs for government contractors. The EU Cyber Resilience Act requires software manufacturers to maintain and share vulnerability information. NIST SP 800-218 (SSDF) provides a comprehensive framework. This guide covers the practical implementation of supply chain security controls that satisfy these requirements and actually protect your software.

Understanding Your Attack Surface

Your software supply chain includes everything between a developer's keyboard and production deployment: source code, dependencies (direct and transitive), build tools, CI/CD platforms, container base images, package registries, artifact repositories, and deployment infrastructure. An attacker who compromises any link in this chain can inject malicious code that ships to production with your next deployment.

The most common attack vectors in 2026 are:

Dependency confusion: An attacker publishes a malicious package with the same name as an internal package to a public registry. Build systems that check public registries before private ones will pull the malicious version.

Typosquatting: Publishing packages with names similar to popular packages (e.g., reqeusts instead of requests). Automated tools now generate thousands of typosquatting variants.

Maintainer account compromise: Hijacking a legitimate maintainer's npm/PyPI account and publishing malicious updates to widely-used packages.

Build system compromise: Injecting malicious code during the build process rather than in source code, making it invisible to source code reviews.

Software Bill of Materials (SBOM): Your Ingredient List

An SBOM is a machine-readable inventory of every component in your software — every dependency, every transitive dependency, their versions, licenses, and known vulnerabilities. Think of it as a nutritional label for software. Without an SBOM, you cannot answer the basic question: "Are we affected by CVE-2026-XXXX?"

The two standard SBOM formats are CycloneDX (OWASP, JSON/XML) and SPDX (Linux Foundation, JSON/RDF/tag-value). We recommend CycloneDX for most teams because it's simpler, has better tooling, and supports VEX (Vulnerability Exploitability eXchange) for annotating which vulnerabilities actually affect your deployment.

# Generate SBOM for a Node.js project using Syft
syft dir:. -o cyclonedx-json > sbom.json

# Generate SBOM for a Docker image
syft docker:myapp:latest -o cyclonedx-json > sbom.json

# Generate SBOM for a Go binary
syft file:./myapp -o cyclonedx-json > sbom.json

# Scan SBOM for known vulnerabilities using Grype
grype sbom:sbom.json --output json > vulnerabilities.json

# In CI/CD (GitHub Actions example):
# - name: Generate SBOM
#   uses: anchore/sbom-action@v0
#   with:
#     format: cyclonedx-json
#     output-file: sbom.json
# - name: Scan for vulnerabilities
#   uses: anchore/scan-action@v4
#   with:
#     sbom: sbom.json
#     fail-build: true
#     severity-cutoff: high

Artifact Signing with Sigstore and Cosign

SBOMs tell you what's in your software; signing tells you who built it and that it hasn't been tampered with. Sigstore is the industry-standard toolchain for keyless code signing — it uses OpenID Connect (your existing Google/GitHub/Microsoft identity) to sign artifacts, and the signatures are recorded in a public transparency log (Rekor) that provides non-repudiation.

Sign your container images in CI/CD:

# Install cosign
brew install sigstore/tap/cosign  # macOS
# or: go install github.com/sigstore/cosign/v2/cmd/cosign@latest

# Sign a container image (keyless, using OIDC identity)
cosign sign --yes registry.example.com/myapp:v1.2.3

# Verify the signature
cosign verify registry.example.com/myapp:v1.2.3   --certificate-identity=ci@your-org.com   --certificate-oidc-issuer=https://token.actions.githubusercontent.com

# Attach SBOM to a signed container image
cosign attach sbom --sbom sbom.json registry.example.com/myapp:v1.2.3

# Sign the attached SBOM
cosign sign --yes --attachment sbom registry.example.com/myapp:v1.2.3

# Enforce signature verification in Kubernetes using Kyverno:
# apiVersion: kyverno.io/v1
# kind: ClusterPolicy
# metadata:
#   name: verify-image-signatures
# spec:
#   validationFailureAction: Enforce
#   rules:
#     - name: verify-cosign-signature
#       match:
#         any:
#           - resources:
#               kinds: ["Pod"]
#       verifyImages:
#         - imageReferences: ["registry.example.com/*"]
#           attestors:
#             - entries:
#                 - keyless:
#                     subject: "ci@your-org.com"
#                     issuer: "https://token.actions.githubusercontent.com"

SLSA Framework: Levels of Supply Chain Assurance

SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is a framework by Google that defines four levels of supply chain security maturity. Each level adds requirements that make it progressively harder for attackers to tamper with your build process:

SLSA Level 1: Build process is documented and produces provenance metadata (who built what, when, from which source). This is the minimum viable supply chain security.

SLSA Level 2: Build process runs on a hosted build service (not developer laptops) and provenance is signed. Most CI/CD-using organizations can achieve Level 2 with minimal effort.

SLSA Level 3: Build process runs on a hardened, isolated build environment. The build service is the only entity that can produce provenance. Source is version-controlled with code review requirements. This is where most enterprise organizations should aim.

SLSA Level 4: Hermetic builds (no network access during build), two-person review of all changes, and the highest assurance of artifact integrity. Required for critical infrastructure and high-security environments.

Dependency Management: The Practical Essentials

Generating SBOMs and signing artifacts is important, but the most impactful thing you can do today is improve how you manage dependencies:

Pin all dependencies to exact versions. Never use ^ or ~ ranges in production. Use lockfiles (package-lock.json, go.sum, poetry.lock) and commit them to version control.

Use a private registry proxy. Tools like Nexus, Artifactory, or even a simple npm/PyPI proxy cache packages locally. This protects against dependency confusion attacks (the proxy can be configured to only serve from your private namespace), registry outages, and package deletions (left-pad incident).

Automate dependency updates with review. Renovate Bot or Dependabot can automatically create pull requests for dependency updates. Configure them to run tests and require manual approval for major version bumps. The goal is to stay current without breaking things.

Audit transitive dependencies. Your package.json might list 20 direct dependencies, but node_modules contains 800+ transitive dependencies. Run npm audit, pip audit, or govulncheck in CI/CD and fail builds on high/critical vulnerabilities.

Building a Supply Chain Security Program

Start with these three actions this week: (1) Add SBOM generation to your CI/CD pipeline — it takes 10 minutes and gives you visibility into every component in your software. (2) Enable Dependabot or Renovate on all repositories. (3) Set up npm audit / pip audit / govulncheck to run on every pull request.

Next month: implement artifact signing with Cosign and enforce signature verification in your deployment pipeline. This ensures that only artifacts built by your CI/CD system can be deployed to production.

Next quarter: achieve SLSA Level 2 by documenting your build process, generating provenance attestations, and ensuring all builds run on hosted CI/CD (not developer machines).

ZeonEdge provides supply chain security assessments and implementation services. We help teams achieve SLSA Level 3 compliance and integrate SBOMs, signing, and vulnerability scanning into existing CI/CD pipelines. Learn more about our security services.