06 - Supply Chain Security - SBOM and Sigstore for Artifact Integrity

Supply Chain Security: Protecting the Software Chain

Supply chain security in software refers to protecting the entire process of creating, distributing, and consuming software. Supply chain attacks are growing exponentially: compromising a single component in the chain allows attacking thousands of downstream organizations.

The SolarWinds attack of 2020 and the XZ Utils incident of 2024 demonstrated how vulnerable the supply chain is. In this article, we will explore the standards and tools for protecting the software chain: SBOM for component inventory, Sigstore for artifact signing, and the SLSA framework for provenance verification.

SBOM: Software Bill of Materials

An SBOM (Software Bill of Materials) is a complete inventory of all components that make up a software product: libraries, frameworks, tools, and their exact versions. Like an ingredient list for food, the SBOM lets you know exactly what's inside the software.

SBOM has become a legal requirement in many contexts: US Executive Order 14028 requires it for federal government suppliers, and European regulations (NIS2, Cyber Resilience Act) are making it mandatory for digital products sold in the EU.

SBOM Standards: CycloneDX vs SPDX

Generate SBOM with Syft

# Install Syft
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh

# Generate SBOM from a Docker image (CycloneDX)
syft myapp:latest -o cyclonedx-json > sbom-cyclonedx.json

# Generate SBOM in SPDX format
syft myapp:latest -o spdx-json > sbom-spdx.json

# Generate SBOM from local filesystem
syft dir:. -o cyclonedx-json > sbom-project.json

# Generate SBOM from a lock file
syft file:package-lock.json -o cyclonedx-json > sbom-deps.json
      

SBOM in the CI/CD Pipeline

# .github/workflows/sbom.yml
name: SBOM Generation
on:
  push:
    branches: [main]
    tags: ["v*"]

jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build Docker image
        run: docker build -t myapp:${{ github.sha }} .

      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          image: myapp:${{ github.sha }}
          format: cyclonedx-json
          output-file: sbom.json

      - name: Upload SBOM as artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.json

      - name: Attach SBOM to release
        if: startsWith(github.ref, 'refs/tags/')
        uses: softprops/action-gh-release@v1
        with:
          files: sbom.json
      

Sigstore: Artifact Signing

Sigstore is a Linux Foundation project that provides tools for cryptographic signing and verification of software artifacts. The goal is to make software signing as easy as code commit, eliminating key management complexity.

Sigstore consists of three main components:

• Cosign: signing and verification of container images and OCI artifacts
• Fulcio: Certificate Authority that issues ephemeral certificates based on OIDC identity
• Rekor: immutable transparency log that records all signatures

# .github/workflows/sign-and-verify.yml
name: Sign and Publish
on:
  push:
    tags: ["v*"]

jobs:
  build-sign-publish:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      id-token: write  # Required for Sigstore keyless
    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/myorg/myapp:${{ github.ref_name }}

      - name: Sign image (keyless)
        run: cosign sign --yes ghcr.io/myorg/myapp@${{ steps.build.outputs.digest }}

      - name: Attach SBOM
        run: |
          syft ghcr.io/myorg/myapp@${{ steps.build.outputs.digest }} -o cyclonedx-json > sbom.json
          cosign attach sbom --sbom sbom.json ghcr.io/myorg/myapp@${{ steps.build.outputs.digest }}
      

SLSA Framework

SLSA (Supply-chain Levels for Software Artifacts), pronounced "salsa", is a security framework that defines increasing levels of assurance about the provenance and integrity of software artifacts. Developed by Google, SLSA defines 4 levels:

VEX: Vulnerability Exploitability eXchange

VEX is a format that allows software producers to communicate whether a known vulnerability in a component is actually exploitable in their product. This reduces noise for consumers who would otherwise need to triage every CVE manually.

Supply Chain Security Best Practices

1. Generate SBOM for every release: automate generation and attachment of SBOM to every release
2. Sign all artifacts: use Cosign/Sigstore to sign container images, binaries, and SBOMs
3. Verify signatures at deploy: configure admission controllers that reject unsigned images
4. Monitor dependencies: use the SBOM to receive immediate alerts when a new CVE is discovered
5. Reach SLSA 3+: implement isolated builds with verifiable provenance
6. Publish VEX: communicate vulnerability status to software consumers

Conclusions

Supply chain security has become an imperative for every software-developing organization. SBOM, Sigstore, and SLSA provide the tools and frameworks to build a transparent, verifiable, and attack-resistant software chain.

In the next article, we'll explore Secret Management, analyzing how to manage credentials, API keys, and certificates securely with HashiCorp Vault and automatic rotation strategies.

Related deep dive: 04 - SCA - Software Composition Analysis e Dependency Vulnerabilities.

Related deep dive: 05 - Container Security - Image Scanning e Runtime Protection.