The Supply Chain Security Crisis
The software supply chain has become one of the most critical attack vectors in modern cybersecurity. High-profile incidents like SolarWinds (2020), Codecov (2021), and Log4Shell (2021) demonstrated how a single compromised component can cascade through thousands of organisations.

According to Sonatype's 2024 State of the Software Supply Chain report, supply chain attacks increased by 742% over the past three years. The average application contains 148 open-source dependencies, each representing potential risk.
Regulatory Requirements
The US Executive Order 14028 and EU Cyber Resilience Act now mandate SBOM generation for software sold to government entities. Non-compliance can result in significant penalties and loss of contracts.
Common Attack Vectors
Dependency Confusion
Attackers publish malicious packages with the same name as internal packages to public registries, exploiting misconfigured package managers.
Typosquatting
Publishing malicious packages with names similar to popular packages (e.g., "lod4sh" instead of "lodash").
Compromised Maintainer Accounts
Attackers gain access to legitimate maintainer accounts through phishing or credential theft, then push malicious updates.
Build System Compromise
Injecting malicious code during the build process (as in SolarWinds), bypassing source code review.
Software Bill of Materials (SBOM)
An SBOM is a comprehensive inventory of all components, libraries, and dependencies in your software. Think of it as a "nutrition label" for software: it tells you exactly what's inside.
SBOM Formats
Two primary standards have emerged for SBOM generation:
SPDX (ISO/IEC 5962:2021)
Developed by the Linux Foundation, SPDX is now an ISO standard. It provides comprehensive license information alongside component data.
- Strong licensing focus
- ISO standardised
- Supported by NTIA guidelines
CycloneDX
Developed by OWASP, CycloneDX is designed specifically for security use cases and integrates well with vulnerability databases.
- Security-first design
- VEX (Vulnerability Exploitability Exchange) support
- Lightweight JSON/XML formats
Generating SBOMs
Several tools can generate SBOMs from your projects:
# Using Syft (Anchore) - supports multiple ecosystems# For container images# For container images# For container images# For container images# For container images# For container images# Using Trivy (Aqua Security)# Using Trivy (Aqua Security)# Using Trivy (Aqua Security)# Using cdxgen (CycloneDX generator)# Using cdxgen (CycloneDX generator)# Using cdxgen (CycloneDX generator)# GitHub Actions - automatic SBOM generation# Add to your workflow:# Add to your workflow:o your workflow:
- name: Generate SBOM
uses: anchore/sbom-action@v0
with:
path: ./
format: cyclonedx-json
output-file: sbom.cdx.jsonSBOM Content Requirements
According to NTIA minimum elements, an SBOM should include:
- Supplier Name: The entity that created the component
- Component Name: The name of the software component
- Component Version: The specific version identifier
- Unique Identifier: A unique ID (e.g., PURL, CPE)
- Dependency Relationship: How components relate to each other
- Author of SBOM: Who generated the SBOM
- Timestamp: When the SBOM was generated
SLSA Framework
SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is a security framework developed by Google. It provides a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure.
SLSA Levels
Level 0: No Guarantees
Starting point with no SLSA compliance. Builds may be manual, without any provenance or verification.
Level 1: Provenance Exists
Build process generates provenance metadata showing how the artifact was built. Prevents accidental tampering.
Level 2: Hosted Build Platform
Builds run on a hosted platform (e.g., GitHub Actions, GitLab CI). Provenance is signed by the build service. Prevents some tampering.
Level 3: Hardened Builds
The build platform provides strong isolation between builds, and provenance is non-falsifiable. Prevents most tampering by insiders.
Generating SLSA Provenance
# GitHub Actions workflow for SLSA Level 3 provenance
name: SLSA Provenance
on:
push:
tags:
- 'v*'
jobs:
build:
runs-on: ubuntu-latest
outputs:
digest: ${{ steps.build.outputs.digest }}
steps:
- uses: actions/checkout@v4
- name: Build artifact
id: build
run: |
# Your build commands here
make build
echo "digest=$(sha256sum ./dist/app | cut -d' ' -f1)" >> $GITHUB_OUTPUT
- uses: actions/upload-artifact@v4
with:
name: my-artifact
path: ./dist/app
provenance:
needs: build
permissions:
actions: read
id-token: write
contents: write
uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v1.9.0
with:
base64-subjects: "${{ needs.build.outputs.digest }}"
upload-assets: trueSLSA Verification
Use slsa-verifier to verify provenance attestations:slsa-verifier verify-artifact my-artifact --provenance-path provenance.intoto.jsonl --source-uri github.com/org/repo
Sigstore and Artifact Signing
Sigstore is an open-source project that makes signing, verifying, and protecting software easy and accessible. It provides keyless signing using OpenID Connect (OIDC) identities, eliminating the complexity of key management.
Sigstore Components
- Cosign: Signs and verifies container images and other artifacts
- Fulcio: A certificate authority that issues short-lived certificates bound to OIDC identities
- Rekor: A transparency log that records signing events, providing an immutable audit trail
- Gitsign: Signs Git commits using Sigstore
Signing Container Images with Cosign
# Install Cosign# or download from https://github.com/sigstore/cosign/releases# Keyless signing (uses OIDC identity)# This will:# This will:# This will:# This will:# This will:# This will:# This will:# 1. Open a browser for OIDC authentication# 2. Generate a short-lived certificate from Fulcio# 3. Sign the image and push signature to the registry# 4. Record the signing event in Rekor transparency log# Sign with SBOM attestation# Verify a signed image# Verify a signed image# Verify a signed image# Verify a signed image# Verify a signed image# Verify with policy# Verify with policy# Verify with policy# Verify with policy# Verify with policy# Verify with policy# Verify with policy# Verify with policy# Verify with policypolicy
cosign verify ghcr.io/myorg/myimage:v1.0.0 \
--certificate-identity-regexp ".*@myorg\.com" \
--certificate-oidc-issuer https://accounts.google.comCI/CD Integration
# GitHub Actions workflow for signing
name: Build and Sign
on:
push:
branches: [main]
jobs:
build-and-sign:
runs-on: ubuntu-latest
permissions:
contents: read
packages: write
id-token: write # Required for OIDC
steps:
- uses: actions/checkout@v4
- name: Install Cosign
uses: sigstore/cosign-installer@v3
- name: Login to GHCR
uses: docker/login-action@v3
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- name: Build and push
id: build
uses: docker/build-push-action@v5
with:
push: true
tags: ghcr.io/${{ github.repository }}:latest
- name: Sign the image
run: |
cosign sign --yes \
ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}
- name: Generate and attach SBOM
run: |
syft packages ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }} \
-o cyclonedx-json > sbom.cdx.json
cosign attest --yes --predicate sbom.cdx.json \
--type cyclonedx \
ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}Enforcing Signatures in Kubernetes
# Kyverno policy to require signed images
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: verify-image-signature
spec:
validationFailureAction: Enforce
background: false
rules:
- name: verify-signature
match:
any:
- resources:
kinds:
- Pod
verifyImages:
- imageReferences:
- "ghcr.io/myorg/*"
attestors:
- entries:
- keyless:
subject: "*@myorg.com"
issuer: "https://accounts.google.com"
rekor:
url: https://rekor.sigstore.devDependency Management
Proactive dependency management is essential for supply chain security. This includes vulnerability scanning, update automation, and access controls.
Vulnerability Scanning
# Scan dependencies with Trivy# Scan container images# Scan container images# Scan with Grype (Anchore)# Scan with Grype (Anchore)# GitHub Dependabot configuration (.github/dependabot.yml)# GitHub Dependabot configuration (.github/dependabot.yml)ml)
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
open-pull-requests-limit: 10
groups:
production-dependencies:
patterns:
- "*"
exclude-patterns:
- "@types/*"
- "*eslint*"
- "*jest*"
ignore:
- dependency-name: "*"
update-types: ["version-update:semver-major"]
- package-ecosystem: "docker"
directory: "/"
schedule:
interval: "weekly"
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "weekly"Lock Files and Pinning
- Always commit lock files: package-lock.json, yarn.lock, Pipfile.lock, go.sum ensure reproducible builds
- Pin CI/CD action versions: Use SHA hashes instead of tags (e.g.,
actions/checkout@abcdef123) - Use private registries: Mirror dependencies from public registries to internal ones with security scanning
Dependency Confusion Prevention
Configure your package manager to use scoped packages and set registry priorities. For npm, use .npmrc with @myorg:registry=https://internal.registry.
Practical Implementation
Supply Chain Security Maturity Model
Phase 1: Foundation (Weeks 1-4)
- Inventory all software components and dependencies
- Enable Dependabot or Renovate for automated updates
- Implement vulnerability scanning in CI/CD
- Commit and enforce lock files
Phase 2: Visibility (Weeks 5-8)
- Generate SBOMs for all builds
- Store SBOMs in a central repository
- Implement SBOM-based vulnerability tracking
- Create dashboards for dependency health
Phase 3: Integrity (Weeks 9-12)
- Implement artifact signing with Sigstore/Cosign
- Generate SLSA provenance for builds
- Enforce signature verification in Kubernetes
- Pin GitHub Actions to SHA hashes
Phase 4: Automation (Ongoing)
- Automate SBOM generation and distribution
- Implement policy-as-code for supply chain requirements
- Continuous compliance monitoring and alerting
- Regular supply chain security assessments
Troubleshooting
Common issues and solutions when implementing supply chain security.
SBOM Generation Failing
Symptom: SBOM tools producing incomplete or empty output.
Common causes:
- Lock files not committed or outdated
- Build environment missing dependencies
- Tool doesn't support your package manager
- Container image layers not accessible
Solution:
# Ensure lock files are present and current npm install --package-lock-only pip freeze > requirements.txt # Use syft for comprehensive SBOM generation syft packages dir:. -o spdx-json > sbom.spdx.json # For containers, scan the image directly syft packages registry:myrepo/myimage:tag # Verify SBOM completeness jq '.packages | length' sbom.spdx.json
Signature Verification Failures
Error: “Error: no matching signatures found” or “signature verification failed”
Common causes:
- Image digest changed after signing
- Wrong public key or certificate
- Rekor transparency log unreachable
- Keyless signature identity mismatch
Solution:
# Verify with correct identity for keyless signing cosign verify \ --certificate-identity "user@example.com" \ --certificate-oidc-issuer "https://accounts.google.com" \ myrepo/myimage@sha256:abc123 # For key-based verification cosign verify --key cosign.pub myrepo/myimage:tag # Check if signature exists cosign triangulate myrepo/myimage:tag # Debug Rekor log entry rekor-cli get --uuid <entry-uuid>
SLSA Provenance Attestation Failures
Symptom: CI/CD provenance generation failing or attestation rejected.
Common causes:
- GitHub Actions OIDC token permissions missing
- Builder not running in trusted environment
- Attestation format mismatch
Solution:
# Ensure workflow has required permissions
permissions:
id-token: write
contents: read
attestations: write
# Use official SLSA generators
- uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v1.9.0
with:
image: myrepo/myimage
digest: sha256:abc123
# Verify attestation
cosign verify-attestation \
--type slsaprovenance \
--certificate-identity-regexp ".*" \
--certificate-oidc-issuer-regexp ".*" \
myrepo/myimage@sha256:abc123Dependency Confusion Vulnerabilities
Symptom: Package manager pulling wrong version of internal package from public registry.
Common causes:
- Internal package name exists on public registry
- Registry priority misconfigured
- No namespace/scope for internal packages
Solution:
# Use scoped packages for npm
@mycompany/internal-package
# Configure .npmrc for private registry priority
@mycompany:registry=https://npm.mycompany.com/
//npm.mycompany.com/:_authToken=${NPM_TOKEN}
# For Python, use --index-url and --extra-index-url carefully
pip install --index-url https://pypi.mycompany.com/simple/ \
--extra-index-url https://pypi.org/simple/ \
my-package
# Reserve your internal package names on public registriesPolicy Enforcement Blocking Legitimate Deployments
Symptom: Kubernetes admission controller rejecting valid images.
Common causes:
- Signature verification policy too strict
- SBOM not attached to image
- Attestation type not matching policy
- Cache stale or webhook timeout
Solution:
# Check Kyverno policy reports kubectl get policyreport -A kubectl describe policyreport <name> # Temporarily use warn mode for debugging apiVersion: kyverno.io/v1 kind: ClusterPolicy spec: validationFailureAction: Audit # Change from Enforce # Verify image meets policy requirements locally cosign verify-attestation --type vuln myrepo/myimage@sha256:abc cosign verify-attestation --type sbom myrepo/myimage@sha256:abc
Conclusion
Software supply chain security is no longer optional; it's a regulatory requirement and a business imperative. The tools and frameworks discussed in this article: SBOMs, SLSA, and Sigstore, provide a practical path to securing your software supply chain.
Start with visibility by generating SBOMs for all your software. Progress to integrity by implementing artifact signing and build provenance. Finally, automate and enforce these controls throughout your CI/CD pipelines.
The investment in supply chain security pays dividends not just in risk reduction but also in regulatory compliance, customer trust, and operational efficiency. As attacks continue to grow in sophistication, organisations that have implemented these controls will be significantly better protected.
Frequently Asked Questions
References & Further Reading
- SLSA (Supply-chain Levels for Software Artifacts)- Framework for supply chain integrity
- Sigstore- Keyless signing for software artifacts
- CISA SBOM Resources- Software Bill of Materials guidance
- CycloneDX- OWASP lightweight SBOM standard
- SPDX (Software Package Data Exchange)- ISO standard for SBOM format
- Syft- CLI tool for generating SBOMs

