Tekton SBOM Generation: Software Bill of Materials in CI (2026)

Tekton’s Software Bill of Materials (SBOM) generation feature doesn’t just list what’s in your software; it fundamentally changes how you reason about your supply chain by making the invisible visible.

Let’s see it in action. Imagine we have a simple Go application and we want to generate an SBOM for it as part of our CI pipeline using Tekton.

First, we need a Task that can generate an SBOM. Tekton offers a built-in Task for this, often found in the Tekton Hub. We’ll adapt a common pattern.

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: generate-sbom
spec:
  params:
    - name: image-url
      type: string
      description: The container image to generate SBOM for.
    - name: output-dir
      type: string
      description: The directory to store the SBOM files.
      default: /sbom
  steps:
    - name: generate
      image: ghcr.io/tektoncd/chains/actions/sbom-generator:v0.6.0 # Using a specific version for reproducibility
      workingDir: $(params.output-dir)
      script: |
        #!/usr/bin/env sh
        echo "Generating SBOM for $(params.image-url)"
        # The sbom-generator tool, when run with `generate`,
        # inspects the image and outputs SBOMs in multiple formats.
        # We're directing output to the volume mount.
        sbom-generator generate \
          --image $(params.image-url) \
          --output-dir $(params.output-dir)

        echo "SBOMs generated in $(params.output-dir)"
        ls -l $(params.output-dir) # List generated files for verification

Now, let’s create a Pipeline that uses this Task. We’ll assume we’ve already built and pushed a container image named my-awesome-app:latest to a registry.

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: sbom-pipeline
spec:
  tasks:
    - name: build-and-push-app # Assuming this task exists and pushes an image
      taskRef:
        name: build-push-docker-image # Replace with your actual build task
      params:
        - name: IMAGE
          value: "my-registry.com/my-awesome-app:latest" # Your image URL

    - name: generate-app-sbom
      taskRef:
        name: generate-sbom
      runAfter:
        - build-and-push-app
      params:
        - name: image-url
          value: "my-registry.com/my-awesome-app:latest" # Same image URL
        - name: output-dir
          value: "/var/tekton/sbom-output" # A specific path for the workspace

  workspaces:
    - name: shared-workspace
      volumeClaimTemplate:
        spec:
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 1Gi # Sufficient space for SBOMs

When this PipelineRun executes, the generate-sbom task will spin up a pod. The sbom-generator image contains tools capable of inspecting container images and extracting dependency information. It’s not just reading a package.json or pom.xml; it’s often analyzing the layers of the container image itself, identifying installed packages, libraries, and their versions. The output typically includes formats like CycloneDX and SPDX, which are standardized ways to represent SBOM data. These files will be written into the shared-workspace under the specified output-dir.

The core problem this solves is the "unknown unknowns" in your software supply chain. Without an SBOM, you might know what your application code is, but you likely have little visibility into the third-party libraries, operating system packages, or even the base image’s components. This makes it incredibly difficult to assess the impact of a vulnerability disclosed in a common library like OpenSSL or Log4j. An SBOM allows you to quickly query, "Does my application use this vulnerable component?"

Internally, tools like sbom-generator leverage various techniques. For Linux-based images, they might run package managers (dpkg, rpm) within the image’s filesystem to list installed packages. For language-specific dependencies, they might use language-aware tools (like go list -m all for Go, or dependency analysis tools for Python and Java) to extract more granular information. The key is that it aims to be comprehensive, covering as many software components as possible.

The exact levers you control are primarily the image-url parameter, ensuring it points to the image you want to analyze, and the output-dir to manage where the generated SBOM files are stored within your Tekton workspace. The sbom-generator tool itself has various flags for specifying output formats or filtering, which could be exposed as further params in your Task.

The most surprising thing about SBOM generation in CI is how it forces a shift from reactive vulnerability patching to proactive supply chain management. Instead of waiting for a CVE to be announced and then scrambling to find where it exists, you have a continuously updated inventory. This means you can subscribe to vulnerability feeds for components listed in your SBOMs and get notified before a public announcement, or at least much faster. It’s like having a manifest for every piece of software you ship, allowing for precise and rapid incident response.

Once you have your SBOMs generated and stored, the next logical step is to integrate them with vulnerability scanning tools.