Supply Chain Security: Automating SBOMs & Signed Attestations

In 2026, the 'trust but verify' model of software distribution has been rendered obsolete by the sophistication of supply chain attacks. As organizations move toward SLSA (Supply-chain Levels for Software Artifacts) compliance, the manual verification of dependencies is being replaced by automated, cryptographically signed metadata. This guide demonstrates how to build a resilient 'Chain of Trust' by automating Software Bill of Materials (SBOM) generation and signed attestations directly within your deployment pipeline.

Prerequisites & Tools

Before we begin, ensure your environment meets these specifications. We will be using the Sigstore ecosystem for signing and Anchore's tooling for discovery.

Step 1: Automated SBOM Generation with Syft

The first step is identifying every dependency, library, and OS package inside your container. Syft excels at this by performing a deep scan of the filesystem layers.

1. Choose your format: While SPDX is common, CycloneDX has become the preferred choice for security automation due to its lightweight JSON structure.

   Dimension	SPDX	CycloneDX	Edge
   Compliance	Legal/License focus	Security focus	CycloneDX
   Parsing	Heavy (Tag-Value)	Native JSON/XML	CycloneDX
   VEX Support	Developing	First-class	CycloneDX

2. Generate the SBOM: Run the following command to output a JSON-formatted bill of materials for your image:

   syft my-app:latest -o cyclonedx-json > sbom.json

Step 2: Keyless Image Signing with Cosign

In 2026, managing private GPG keys is a liability. Sigstore's Cosign allows for 'keyless' signing using OpenID Connect (OIDC). In a CI/CD environment like GitHub Actions, the runner receives a short-lived certificate tied to the repository's identity.

To sign an image locally using a key (if not using OIDC), you would first generate a pair:

cosign generate-key-pair
cosign sign --key cosign.key user/repo:tag

However, for automation, the --oidc-issuer flag is your best friend, as it leverages the platform's identity without requiring secrets stored in your environment.

Step 3: CI/CD Pipeline Integration

Integrating these steps into GitHub Actions ensures that every build is accompanied by proof of its contents. Before publishing these artifacts, ensure any sensitive environment data is handled correctly—refer to our Data Masking Tool if you need to sanitize configuration outputs during the build process.

jobs:
  build-and-sign:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      id-token: write # Required for keyless signing

    steps:
      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          image: ghcr.io/${{ github.repository }}:latest
          format: cyclonedx-json
          output-file: ./sbom.json

      - name: Install Cosign
        uses: sigstore/cosign-installer@v3.5.0

      - name: Sign Image and Attest SBOM
        run: |
          cosign sign --yes ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}
          cosign attest --yes --type cyclonedx --predicate ./sbom.json ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}

Verification & Expected Output

Once signed, anyone can verify the provenance of the image. This is what you should expect to see when running cosign verify:

cosign verify ghcr.io/my-org/my-app:latest \
  --certificate-identity https://github.com/my-org/my-app/.github/workflows/deploy.yml@refs/heads/main \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Expected Output:

[
  {
    "critical": [
      {
        "Identity": "https://github.com/my-org/my-app/.github/workflows/deploy.yml@refs/heads/main",
        "Issuer": "https://token.actions.githubusercontent.com"
      }
    ],
    "optional": null,
    "verified": true
  }
]

Troubleshooting Top-3

What's Next: Admission Control

Generating and signing data is only half the battle. The final step in a mature security posture is Policy Enforcement. By using Kyverno or Gatekeeper in your Kubernetes cluster, you can create a rule that rejects any pod whose container image does not have a valid signature from your CI/CD pipeline. This ensures that even if a registry is compromised, unauthorized images can never be executed in your production environment.