SBOM & Sigstore: Securing Your Software Supply Chain

In today’s interconnected world, software is the bedrock of nearly every industry. From critical infrastructure to your smartphone apps, code powers everything. But with great power comes great responsibility, and unfortunately, also great risk. The software supply chain, once a niche concern, has rapidly become a prime target for sophisticated attackers. We’ve seen devastating incidents like SolarWinds and Log4j ripple across the globe, demonstrating that a single compromised component or build step can have catastrophic consequences.

As senior engineers, it’s no longer enough to just build robust applications; we must also ensure the integrity and trustworthiness of the software we produce and consume. This isn’t just about patching known vulnerabilities; it’s about establishing verifiable trust from the very first line of code to the final deployment.

This article dives deep into two pivotal technologies at the forefront of this battle: Software Bill of Materials (SBOM) and Sigstore. Individually powerful, together they form a formidable defense, providing both transparency into software components and cryptographic assurances of their origin and integrity. We’ll explore what they are, why they matter, how they work, and how you can integrate them into your development lifecycle to build more secure software.

The Software Supply Chain: A Landscape of Interconnected Risks

Before we dissect the solutions, let’s clearly define the problem. The “software supply chain” refers to everything that goes into delivering a piece of software. This includes:

• Source Code: Your own code, third-party libraries, open-source packages.
• Development Tools: Compilers, build systems, IDEs.
• Dependencies: Direct and transitive dependencies, their versions, and origins.
• Build Process: CI/CD pipelines, build servers, scripts, and configurations.
• Artifacts: Executables, container images, packages, configuration files.
• Distribution: Registries, repositories, update mechanisms.
• People: Developers, operators, maintainers, and their access credentials.

Each of these links represents a potential attack vector. A malicious actor could:

• Inject Malicious Code: Compromise an open-source library (e.g., through a rogue maintainer or typo-squatting) that then gets pulled into thousands of projects.
• Tamper with Build Systems: Gain access to a CI/CD pipeline and inject malware into compiled artifacts without touching the source code.
• Hijack Update Mechanisms: Distribute malicious updates through legitimate channels, as seen in the SolarWinds attack.
• Compromise Developer Accounts: Steal credentials to push malicious changes or sign harmful software.
• Exploit Vulnerabilities in Dependencies: Leverage a critical vulnerability in a widely used library (like Log4j) to gain control over systems.

The sheer complexity and interconnectedness of modern software development mean that an organization’s security posture is only as strong as its weakest link, which often lies outside its direct control, deep within its transitive dependencies. The goal of software supply chain security is to provide visibility, integrity, and trust throughout this intricate process.

<

>

Demystifying the Software Bill of Materials (SBOM)

Imagine you’re building a complex electronic device. You wouldn’t just slap components together; you’d have a detailed list of every resistor, capacitor, chip, and wire, along with their specifications and suppliers. This is essentially what a Software Bill of Materials (SBOM) does for software.

What is an SBOM?

An SBOM is a formal, machine-readable inventory of the components that make up a piece of software. It details all direct and transitive dependencies, including open-source and commercial software, their versions, licenses, and other crucial metadata. Think of it as a nutritional label for your software, providing transparency into its ingredients.

Why is an SBOM Crucial?

The primary driver behind the widespread adoption of SBOMs is the need for transparency and risk management. With an SBOM, organizations can:

1. Identify Vulnerabilities Faster: When a new critical vulnerability (like Log4j’s CVE-2021-44228) is announced, an SBOM allows you to quickly identify every application in your portfolio that uses the affected component, dramatically reducing response time.
2. Manage License Compliance: SBOMs list the licenses associated with each component, helping you ensure compliance with open-source licensing agreements and avoid legal issues.
3. Improve Incident Response: In the event of a breach, an SBOM provides an immediate snapshot of potentially compromised components, aiding in forensic analysis and containment.
4. Enhance Supply Chain Trust: By requiring and providing SBOMs, organizations can foster greater trust and accountability with their software suppliers and consumers.
5. Meet Regulatory Requirements: Governments and industry bodies (e.g., the U.S. Executive Order 14028) are increasingly mandating SBOM usage to enhance national cybersecurity.

Key Data Points in an SBOM

While specific formats vary, a comprehensive SBOM typically includes:

• Component Name: The name of the software component (e.g., “Apache Log4j”).
• Version: The specific version of the component (e.g., “2.14.1”).
• Supplier: The entity that supplied the component (e.g., “Apache Software Foundation”).
• Unique Identifier: A reliable identifier like Package URL (PURL), Common Platform Enumeration (CPE), or Software Heritage Identifier (SWHID).
• Cryptographic Hash: A hash (e.g., SHA256) of the component’s files, verifying its integrity.
• License Information: The licensing terms under which the component is distributed (e.g., “Apache-2.0”).
• Relationships: How components relate to each other (e.g., “A depends on B”).
• Authorship/Maintainer: Information about the component’s creators.

Common SBOM Formats

To ensure interoperability and machine readability, several standardized SBOM formats have emerged:

1. SPDX (Software Package Data Exchange)

• Overview: Developed by the Linux Foundation, SPDX is a mature and widely adopted standard. It aims to provide a complete and unambiguous way to share information about software components, licenses, copyrights, and security references.
• Focus: Strong emphasis on license compliance and provenance.
• Structure: Can represent information in various sections: package information, file information, snippet information, license information, and relationship information.
• Output Formats: Supports Tag-Value, JSON, YAML, XML, and RDF.
• Use Case: Ideal for organizations with complex license compliance requirements and those needing detailed provenance tracking.

An SPDX JSON snippet might look something like this:

{
  "SPDXID": "SPDXRef-DOCUMENT",
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "name": "myapp-1.0.0-spdx.json",
  "documentNamespace": "http://spdx.org/spdxdocs/myapp-1.0.0-spdx-json-12345",
  "creationInfo": {
    "created": "2023-10-27T10:00:00Z",
    "creators": ["Tool:Syft-v0.90.0", "Organization:Khadervali.com"]
  },
  "packages": [
    {
      "name": "myapp",
      "SPDXID": "SPDXRef-Package-myapp",
      "versionInfo": "1.0.0",
      "filesAnalyzed": false,
      "licenseDeclared": "NOASSERTION",
      "checksums": [
        {
          "algorithm": "SHA256",
          "checksumValue": "a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890"
        }
      ],
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE_MANAGER",
          "referenceLocator": "pkg:docker/myapp@sha256:...",
          "referenceType": "purl"
        }
      ]
    },
    {
      "name": "underscore",
      "SPDXID": "SPDXRef-Package-underscore",
      "versionInfo": "1.13.6",
      "licenseDeclared": "MIT",
      "checksums": [
        {
          "algorithm": "SHA256",
          "checksumValue": "f1e2d3c4b5a69870f1e2d3c4b5a69870f1e2d3c4b5a69870f1e2d3c4b5a69870"
        }
      ],
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE_MANAGER",
          "referenceLocator": "pkg:npm/underscore@1.13.6",
          "referenceType": "purl"
        }
      ]
    }
  ],
  "relationships": [
    {
      "spdxElementId": "SPDXRef-Package-myapp",
      "relationshipType": "CONTAINS",
      "relatedSpdxElement": "SPDXRef-Package-underscore"
    }
  ]
}

2. CycloneDX

• Overview: Maintained by the OWASP Foundation, CycloneDX is a lightweight and opinionated standard specifically designed for use in application security and supply chain risk management.
• Focus: Strong emphasis on security, vulnerability analysis, and operational risk.
• Structure: Organized around BOMs (Bill of Materials) of software components, services, and external references. It also supports vulnerability exploitability exchange (VEX) data.
• Output Formats: Primarily JSON and XML.
• Use Case: Well-suited for CI/CD pipeline integration, security tooling, and organizations prioritizing rapid vulnerability assessment.

A CycloneDX JSON snippet would highlight components and their security attributes:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2023-10-27T10:05:00Z",
    "tools": [
      {
        "vendor": "Anchore",
        "name": "Syft",
        "version": "0.90.0"
      }
    ],
    "component": {
      "bom-ref": "pkg:docker/myapp@sha256:...",
      "type": "application",
      "name": "myapp",
      "version": "1.0.0",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890"
        }
      ]
    }
  },
  "components": [
    {
      "bom-ref": "pkg:npm/underscore@1.13.6",
      "type": "library",
      "name": "underscore",
      "version": "1.13.6",
      "purl": "pkg:npm/underscore@1.13.6",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "f1e2d3c4b5a69870f1e2d3c4b5a69870f1e2d3c4b5a69870f1e2d3c4b5a69870"
        }
      ],
      "licenses": [
        {
          "license": {
            "id": "MIT"
          }
        }
      ]
    }
  ]
}

3. SWID (Software Identification) Tags

• Overview: An ISO standard (ISO/IEC 19770-2:2015) designed to identify and categorize software. SWID tags are embedded within software to provide metadata about the software itself.
• Focus: Asset management, software inventory, and patch management.
• Structure: XML-based, containing information like software name, version, unique ID, entity information, and payload information.
• Use Case: Often used by enterprises for IT asset management and ensuring that installed software matches authorized versions. Less common for deep dependency analysis compared to SPDX/CycloneDX.

Generating and Consuming SBOMs

Generating SBOMs

The best practice is to generate SBOMs at various stages of your SDLC, especially during the build process. Tools can analyze source code, package managers, and even compiled binaries or container images to extract component information.

Popular open-source tools for SBOM generation include:

• Syft: Created by Anchore, Syft is excellent for generating SBOMs from container images, file systems, and various package managers. It supports SPDX and CycloneDX formats.
• Trivy: From Aqua Security, Trivy is primarily known as a vulnerability scanner, but it also has robust SBOM generation capabilities for container images, file systems, and Git repositories.
• OpenSSF Scorecard: While not a pure SBOM generator, Scorecard assesses the security posture of open-source projects, which can indirectly contribute to understanding component risk.
• Gradle/Maven Plugins: Many build systems have plugins that can generate SBOMs directly from your project’s dependency tree.

Let’s see a quick example using Syft to generate a CycloneDX SBOM for a Docker image:

# First, ensure Syft is installed. You can find installation instructions on its GitHub.
# For example, on Linux:
# curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# Pull a simple Docker image (e.g., Nginx)
docker pull nginx:latest

# Generate a CycloneDX JSON SBOM for the Nginx image
syft nginx:latest -o cyclonedx-json > nginx-sbom.json

# You can also generate an SPDX JSON SBOM
# syft nginx:latest -o spdx-json > nginx-sbom.spdx.json

# View the generated SBOM (first 50 lines)
head -n 50 nginx-sbom.json

This command will produce a detailed JSON file listing all identified software components within the nginx:latest image, their versions, licenses, and hashes. This file can then be stored alongside your image or published to an SBOM management system.

Consuming and Utilizing SBOMs

Generating an SBOM is only half the battle; the real value comes from consuming and acting upon the information it provides. SBOMs can be fed into various security tools and processes:

• Vulnerability Scanners: Tools like Trivy, Snyk, and Mend can ingest an SBOM and quickly cross-reference its components against known vulnerability databases (e.g., NVD, OSV) to identify potential risks.
• License Compliance Tools: Automatically check if any included licenses are incompatible with your project’s licensing or corporate policies.
• Dependency Graph Analysis: Visualize your software’s dependency tree, identify deep dependencies, and detect potential supply chain risks.
• Vulnerability Exploitability eXchange (VEX): A companion to SBOM, VEX documents provide additional context on whether a known vulnerability in a component is actually exploitable in a specific product. This helps reduce alert fatigue.
• SBOM Management Platforms: Centralized platforms (e.g., OWASP Dependency-Track) can store, manage, and analyze SBOMs from across your entire software portfolio.

Challenges and Best Practices for SBOM Adoption

• Accuracy: Ensuring the generated SBOM accurately reflects all components can be challenging, especially for legacy systems or proprietary binaries.
• Automation: Manual SBOM generation is impractical. Integrate SBOM generation into your CI/CD pipelines to ensure it’s always up-to-date.
• Storage and Management: You’ll generate many SBOMs. Plan for how to store, version, and manage them effectively.
• Consumption: Don’t just generate them; integrate SBOM consumption into your security tooling and processes.
• Education: Educate your development and security teams on the importance and utility of SBOMs.

Ensuring Software Integrity with Sigstore

While an SBOM tells you what’s in your software, it doesn’t inherently tell you who built it or if it has been tampered with since it was created. This is where digital signatures come into play. Historically, code signing has been complex, expensive, and often poorly implemented, leading to a lack of widespread adoption, especially in the open-source community. Sigstore aims to change that.

What is Sigstore?

Sigstore is a non-profit, open-source project that provides a free and easy-to-use service for signing software artifacts, such as container images, binaries, and even SBOMs. Its primary goal is to make software signing ubiquitous, enhancing the security of the open-source software supply chain and beyond. It eliminates the need for developers to manage long-lived private keys by using short-lived certificates tied to developer identities.

The Problem Sigstore Solves: The Trust Gap

Consider these challenges that Sigstore addresses:

• Complex Key Management: Traditional code signing requires developers to securely generate, store, and manage private keys, which is a significant operational burden and security risk.
• Lack of Widespread Adoption: Due to complexity and cost (for commercial CAs), many open-source projects don’t sign their releases, leaving users to trust artifacts based on reputation alone.
• Verifiability: Even when software is signed, verifying the signature and the signer’s identity can be challenging for consumers.
• Auditability: There’s often no public record of what was signed by whom, making it difficult to audit the integrity of the software supply chain.

Sigstore tackles these issues head-on by simplifying the signing process, making it free, publicly verifiable, and auditable.

Core Components of Sigstore

Sigstore is not a single tool but an ecosystem built around three core components:

1. Fulcio: The Root Certificate Authority (CA)

Fulcio acts as a public root CA that issues short-lived X.509 certificates. Unlike traditional CAs that verify organizations, Fulcio verifies developer identities. Here’s how it works:

• OIDC Integration: Fulcio integrates with OpenID Connect (OIDC) providers like Google, GitHub, Microsoft, or even enterprise identity providers.
• Identity Verification: When a developer wants to sign an artifact, they authenticate with their chosen OIDC provider. Fulcio then verifies this identity.
• Short-Lived Certificates: Upon successful verification, Fulcio issues a cryptographic certificate that is valid for a very short period (e.g., 5-10 minutes). This certificate contains the developer’s verified identity (e.g., their GitHub email address).
• No Key Management: Because the certificates are short-lived, developers don’t need to generate or manage their own private keys. A new ephemeral key pair is generated for each signing operation.

This approach dramatically reduces the risk associated with compromised long-lived keys and simplifies the entire signing workflow.

2. Rekor: The Transparency Log

Rekor is a cryptographically verifiable, immutable transparency log for signed software artifacts. It’s built on a Merkle tree, similar to Certificate Transparency logs, meaning that once an entry is added, it cannot be removed or altered without detection. Here’s its role:

• Public Record: Rekor publicly records every signing event. When an artifact is signed using Fulcio, the resulting signature and the public key (or the certificate) used for signing, along with the artifact’s cryptographic hash, are uploaded to Rekor.
• Immutability: The Merkle tree structure ensures that any attempt to tamper with or remove an entry will be immediately detectable.
• Auditability: Anyone can query Rekor to verify the existence and integrity of a signature, providing a public audit trail for software releases. This helps detect if a supply chain has been compromised, as unauthorized signatures would either not appear in Rekor or appear with unexpected identities.
• Offline Verification: Rekor also allows for “offline” verification of artifacts by proving that a specific signature existed in the log at a certain point in time, even if the original public key is no longer available.

3. Cosign: The CLI Tool

Cosign is the command-line utility that developers and CI/CD systems use to interact with Fulcio and Rekor. It handles the entire signing and verification process end-to-end:

• Signing: Cosign orchestrates the process of generating an ephemeral key, authenticating with Fulcio to get a short-lived certificate, signing the artifact, and then uploading the signature and certificate to Rekor.
• Verification: Cosign can verify signatures by checking them against the artifact, validating the certificate chain with Fulcio, and ensuring the signing event is recorded in Rekor.
• Support for Artifacts: While initially focused on container images (OCI artifacts), Cosign now supports signing any arbitrary file or blob.
• Simplicity: It abstracts away the underlying cryptographic complexities, making software signing accessible to everyone.

How Sigstore Works End-to-End (Architecture in Words)

Let’s walk through the process of a developer signing a container image and a consumer verifying it:

Signing Process:

1. Developer Initiates Sign: A developer runs cosign sign my-registry/my-image:latest.
2. Ephemeral Key Generation: Cosign generates a new, ephemeral cryptographic key pair locally on the developer’s machine.
3. OIDC Authentication: Cosign redirects the developer to their chosen OIDC provider (e.g., GitHub) for authentication.
4. Fulcio Certificate Request: After successful OIDC authentication, Cosign sends the public key of the ephemeral pair, along with the OIDC identity token, to Fulcio.
5. Fulcio Issues Certificate: Fulcio verifies the OIDC identity and, if valid, issues a short-lived X.509 certificate back to Cosign. This certificate binds the ephemeral public key to the developer’s OIDC identity.
6. Artifact Signing: Cosign uses the ephemeral private key and the Fulcio-issued certificate to cryptographically sign the container image (specifically, its digest).
7. Upload to Rekor: Cosign then uploads the signature, the Fulcio certificate, and the image digest to Rekor, the transparency log. Rekor records this event, producing a log entry ID.
8. Store Signature: The generated signature is typically stored alongside the container image in the OCI registry (as an OCI artifact itself, often referred to as a “signature manifest”).

Verification Process:

1. Consumer Initiates Verify: A consumer runs cosign verify my-registry/my-image:latest.
2. Retrieve Signature: Cosign retrieves the signature and the associated certificate from the OCI registry.
3. Rekor Lookup: Cosign queries Rekor using the image digest and certificate to ensure the signing event was logged and hasn’t been tampered with. It retrieves the Rekor entry for cryptographic verification.
4. Certificate Validation: Cosign validates the Fulcio certificate by checking its chain of trust up to the Sigstore root of trust and verifying its validity period.
5. Signature Verification: Cosign uses the public key from the validated Fulcio certificate to verify the signature against the image digest.
6. Identity Check: If all checks pass, Cosign confirms that the image was signed by the identity specified in the Fulcio certificate (e.g., a specific GitHub account) and that the signing event is recorded in Rekor.

<

>

Code Examples with Cosign

1. Signing a Container Image

Let’s sign a simple Nginx image. You’ll need Docker installed and Cosign. For demonstration, we’ll use an ephemeral key, which is the most common Sigstore workflow.

# 1. Install Cosign (if you haven't already)

# Go to https://github.com/sigstore/cosign/releases and download the latest binary

# For example:

# wget https://github.com/sigstore/cosign/releases/download/v2.2.3/cosign-linux-amd64

# sudo mv cosign-linux-amd64 /usr/local/bin/cosign

# sudo chmod +x /usr/local/bin/cosign

# 2. Set an environment variable for the Sigstore OIDC client (optional for basic use)

# export SIGSTORE_FULCIO_ISSUER=https://oauth2.sigstore.dev/auth

# export SIGSTORE_OIDC_PROVIDER=github
# 3. Pull a container image to sign

docker pull busybox:latest
# 4. Sign the image using Cosign.

# This will open your browser for GitHub (or Google) authentication.

# Ensure you are logged into your GitHub account in your default browser.

cosign sign busybox:latest
# You will see output like:

# >  Signing for <your_github_email>

# >  You must authenticate with your OIDC provider to continue.

#