TL;DR: Software Supply Chain Security helps us protect the software components, dependencies, and processes involved in building and delivering software. A Software Bill of Materials (SBOM) gives us an inventory of those components, helping us identify vulnerabilities and respond when problems are discovered.

I believe in checklists. Before completing a task, I want to know what needs to be done, what has already been done, and what might have been missed. In infrastructure, overlooking one small dependency can sometimes create a much bigger problem.

Now, remember Order 66 in Star Wars? Imagine discovering that something you trusted had a hidden weakness or an instruction you never knew existed. By the time you discover it, the damage may already be done.

Software can have similar problems. We build applications by combining libraries, packages, frameworks, tools, and other components. If we don’t know what’s inside our software, how can we identify a vulnerable component before it becomes a serious problem?

What does this have to do with Software Supply Chain Security and a Software Bill of Materials?

Both concepts help us understand what’s behind the software we build and deliver. Software Supply Chain Security focuses on protecting the components and processes involved throughout the software lifecycle. A Software Bill of Materials (SBOM) provides an inventory of the software components included in a product.

With that inventory, we have a starting point for checking dependencies, identifying known vulnerabilities, and determining which products may be affected when a security issue is discovered. The earlier we identify the problem, the sooner we can assess the risk and take appropriate action.

What is Software Supply Chain Security?

Software Supply Chain Security encompasses the practices, tools, and processes used to protect software throughout its development, build, distribution, and deployment lifecycle.

Traditional application security often focuses on vulnerabilities within application code. Software supply chain security extends that protection to the broader ecosystem, including source code repositories, third-party dependencies, build systems, CI/CD pipelines, container images, and deployment processes.

Even when application code is secure, a compromised dependency, an unauthorized modification, or an untrusted build process can introduce risks before the software reaches production.

The goal is to establish confidence in both the software components we use and the processes through which our software is produced and delivered.

What is a Software Bill of Materials (SBOM)?

A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of the software components included in an application or software artifact.

Depending on the format and the information collected, an SBOM can include component names, versions, package identifiers, licenses, cryptographic hashes, and dependency relationships. It can describe both direct dependencies and transitive dependencies—the additional components required by the dependencies we explicitly use.

An SBOM is similar to an ingredient list for software. It helps us understand what is included in a product and provides a starting point for investigating vulnerabilities, licensing concerns, and affected applications.

However, an SBOM is an inventory, not a security guarantee. It does not automatically establish that a component is safe or that the software has not been tampered with. We need additional security controls to verify integrity, establish provenance, and detect known vulnerabilities.

Example 1: Implementing Software Supply Chain Security

Consider a team building a containerized application and deploying it to a Kubernetes cluster. We want to establish confidence in the source code, the build process, and the container image before allowing the application to run in production.

A typical implementation can combine GitHub Actions, Sigstore Cosign, build provenance, and Kubernetes admission policies.

Step 1: Protect the source code

The code repository should enforce appropriate branch protection rules, require code reviews, and restrict who can approve or merge changes.

Commit signing can provide additional evidence of the identity associated with a commit. However, signing alone does not prove that the code is safe, so it should complement repository access controls and review procedures.

Step 2: Build in a controlled environment

The CI/CD pipeline should use isolated build environments with least-privilege permissions. Build credentials should be restricted to the resources and operations required by the pipeline.

The objective is to reduce the impact of compromised build steps, unauthorized access, or malicious changes to the build process.

Step 3: Generate build provenance

The build pipeline can generate a provenance attestation describing how an artifact was produced.

Depending on the provenance format and implementation, this may record the source repository, commit identifier, build system, build parameters, and other relevant details.

Provenance helps answer an important question: Where did this artifact come from, and how was it built?

The pipeline must explicitly generate and retain the attestation; it is not automatically provided by every CI/CD configuration.

Step 4: Sign the container image

Sigstore Cosign can sign a container image to help verify its integrity and the identity associated with the signature.

For example:

cosign sign --yes \
  registry.example.com/my-app:v1.0.0

This is an illustrative command. It assumes that the container registry and the appropriate signing identity are configured.

In production, referencing the image by digest provides a more precise identifier than relying on a mutable tag alone.

A signature and provenance serve different purposes: the signature helps establish artifact integrity and signing identity, while provenance provides information about the build process.

Step 5: Verify before deployment

Before a container image is deployed, a Kubernetes admission policy can enforce the required verification checks.

Tools such as Kyverno can be configured to verify image signatures and enforce provenance-related policies. Gatekeeper can enforce admission policies, although signature and attestation verification may require additional integrations or components.

A production policy should validate the expected signing identity, artifact digest, and any required provenance claims. Images that fail the required checks can be rejected before deployment.

The resulting workflow connects source control, controlled builds, provenance, signing, and deployment policy enforcement. Each control addresses a different part of the software supply chain.

Example 2: Creating a Software Bill of Materials

Now consider the same containerized application. Even if we trust the build process, we still need to know which software components are included in the final artifact.

We can use Syft, an SBOM generation tool, to inspect a container image and generate an inventory of its software components.

For example:

syft registry.example.com/my-app:v1.0.0 \
  -o cyclonedx-json=sbom.json

This command generates an SBOM in CycloneDX JSON format. The example assumes that the image is accessible to Syft and that the tool is installed.

The generated inventory can include the components detected in the image, their versions, and other available metadata. The exact contents depend on the image and what the tool can identify.

A simplified SBOM example

The following JSON illustrates the general structure of a CycloneDX SBOM. It is an educational example rather than the output of an actual image scan.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "metadata": {
    "component": {
      "type": "application",
      "name": "my-payment-service",
      "version": "2.1.0",
      "purl": "pkg:generic/my-payment-service@2.1.0"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "github.com/google/uuid",
      "version": "v1.6.0",
      "purl": "pkg:golang/github.com/google/uuid@v1.6.0"
    }
  ],
  "dependencies": [
    {
      "ref": "pkg:generic/my-payment-service@2.1.0",
      "dependsOn": [
        "pkg:golang/github.com/google/uuid@v1.6.0"
      ]
    },
    {
      "ref": "pkg:golang/github.com/google/uuid@v1.6.0",
      "dependsOn": []
    }
  ]
}

In this example, the application depends on the github.com/google/uuid library. The components section identifies the library, while the dependencies section records the relationship between the application and that library.

A real generated SBOM may contain many more components, dependency relationships, and metadata fields. Its contents depend on the application, build artifact, generator, and selected SBOM format.

Automating SBOM Management

SBOM generation should be integrated into the software build or release pipeline rather than treated as a one-time manual task.

A practical workflow should:

  • Generate an SBOM for the relevant software artifact or release.
  • Associate the SBOM with the exact artifact version or digest it describes.
  • Store and retain the SBOM alongside the corresponding release artifacts.
  • Scan the inventory against vulnerability information and investigate affected components.
  • Regenerate the SBOM when the software components change.

For example, when a newly disclosed vulnerability affects a widely used library, teams can search their SBOM inventories to identify potentially affected applications. They can then assess the exposure, prioritize remediation, and rebuild or redeploy affected software where necessary.

Automation makes this process repeatable and reduces the effort required to understand the impact of new security findings.

Bringing the Both Together

Software Supply Chain Security and SBOMs complement each other.

An SBOM helps us understand what is inside our software. Supply chain security helps us establish confidence in where the software came from, how it was produced, and whether it meets our security requirements.

Neither replaces vulnerability scanning, secure development practices, access controls, or runtime protection. Together, however, they provide useful building blocks for a more traceable and maintainable software delivery process.

For platform engineering, the opportunity is to make these controls part of the platform’s standard delivery workflow. Developers should be able to build, inventory, verify, and deploy software through repeatable pipelines with security checks integrated into the process.

The objective is to make secure delivery a consistent platform capability rather than a collection of manual tasks that every development team must implement independently.

Back to Certified Cloud Native Platform Engineering Associate Preparation