cosign

1.0 Why Supply Chain Security is Your Shared Strategic Advantage

Software supply chain security is not merely a technical challenge; it is a critical business and strategic imperative we must jointly address. In today’s ecosystem, defined by complex dependencies, blind trust is your greatest liability.

This strategy provides you with a clear path to transform your security posture from a reactive, incident-driven model to a proactive, evidence-based framework. We will move from simply hoping your software is secure to proving its integrity with cryptographic, verifiable evidence.

1.1 The Evolving Threat Landscape

We recognize that the modern software supply chain is, increasingly, a primary target for sophisticated attacks. What was once the domain of niche, nation-state actors has become a mainstream threat vector affecting organizations of all sizes. The attack surface is vast, spanning every stage of the Software Development Lifecycle (SDLC). Recent high-profile incidents starkly illustrate the varied nature of these threats:

• Compromised Build System
  The SolarWinds attack demonstrated the devastating impact of malicious code injected into legitimate software updates.
• Compromised Package Distribution
  The XcodeGhost incident revealed the danger of developers unknowingly downloading a backdoored version of a development environment.
• Compromised Version Control
  The Juniper backdoor highlighted risk within the repository, where attackers allegedly compromised the system to insert malicious code.

These are not isolated events. Attacks on the software supply chain have been growing at an exponential rate, making this an issue that we (together) must now address with the highest priority. We’ve seen the XZ backdoor incident (Feb 2024) and, most recently, the npm incident (Sept 15th 2025), underscoring the urgency.

1.2 The Business and Financial Impact

We know the consequences of a supply chain compromise are tangible and severe, extending far beyond the immediate technical fallout. The business impact manifests in several critical areas:

• Direct Financial Costs: The financial repercussions are staggering. The global average cost of a data breach in 2023 reached $4.45 million. Cleanup costs for a single incident, like the Equifax breach, exceeded $1.4 billion (source).
• Organizational Disruption: A single vulnerability in a common dependency can trigger massive, organization-wide disruption. The Log4Shell vulnerability, for instance, forced security teams into week-long fire drills. After one year, only 70% of the affected projects had been patched, leaving 30% still vulnerable (source).
• Erosion of Customer Trust: In a competitive market, provable integrity is the ultimate differentiator. Your ability to provide customers with verifiable proof of software integrity is no longer a luxury but a foundational component of customer confidence.

1.3 The Compliance Mandate

Regulatory and compliance frameworks are no longer optional hurdles but have become powerful enablers for better security hygiene. We are seeing a growing number of government and industry mandates that are compelling the adoption of more secure software development practices. Key drivers include:

• The U.S. Executive Order 14028
  • This order explicitly mandates that suppliers to the federal government provide a Software Bill of Materials (SBOM) for their products.
• The European Cyber Resilience Act (NIS2)
  • This legislation mandates specific security controls and protections for products with digital elements sold within the EU. Locally, the Cyberbeveiligingswet (Cbw) formulates this for Dutch companies.
• Industry Frameworks
  • The NIST Secure Software Development Framework (SSDF) provides a set of best practices that we are adopting as a baseline.

These mandates are leveraging purchasing power and regulation to catalyze the industry, compelling the adoption of better operational hygiene by making artifacts like SBOMs a non-negotiable requirement for doing business.

This strategy directly addresses these evolving threats, business impacts, and compliance mandates by building a new foundation of verifiable trust throughout your software supply chain.

2.0 Target Architecture: The Four Pillars of Verifiable Trust

This shared strategy is architected upon four fundamental pillars that work in concert to create a transparent, verifiable audit trail for every software artifact you produce. This architecture systematically moves us from a position of blind trust to one of cryptographic proof, ensuring every component is traceable, attested, signed, and continuously verifiable.

2.1 Pillar 1: SBOMs – The Foundation of Transparency

A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of every component in a piece of software; it is an “ingredients list” for an application. Its critical role is to provide complete, unambiguous visibility into your software’s DNA.

Having a comprehensive SBOM transforms incident response. When a vulnerability like Log4Shell emerges, the response is no longer a reactive scramble of guesswork. Instead, you can simply query your SBOMs to get an immediate, precise list of every affected application.

• Implementation Tools: You can automate SBOM generation within your CI/CD pipelines using tools like Trivy, Grype or Syft, producing standardized formats such as CycloneDX or SPDX. (Ideally, you should create both, if possible.)

2.2 Pillar 2: Attestations – The Notarized Proof of Process

If an SBOM answers what’s in your software, an attestation answers how it was made.

An attestation is a cryptographically signed piece of metadata that makes verifiable claims about the software’s build process, providing provenance.

This provenance proves that:

1. An artifact was built on a specific, identifiable, trusted platform.
2. It was built from a specific source code commit.
3. It passed all required quality gates (lints, tests, security scans).

This makes it incredibly difficult for an attacker to inject a malicious artifact into the supply chain, as it would lack the correct, verifiable attestation linking it back to your secure build process.

• Implementation Standards & Tools: You will standardize on the in-toto attestation framework to generate this evidence. Tools like Tekton Chains can automate the generation of these attestations within Kubernetes-native CI/CD pipelines.

2.3 Pillar 3: Digital Signatures – The Unbroken Seal of Integrity

The final step in securing the artifact is applying a digital signature. This acts as a cryptographic seal, providing a guarantee of two critical properties: authenticity (it came from us) and integrity (it has not been altered since we signed it).

The modern approach of “keyless signing,” pioneered by Sigstore’s Cosign, has revolutionized this process. This method leverages OIDC identity tokens from CI/CD platforms to generate short-lived signing certificates. The resulting signature is then published to a public, tamper-evident transparency log, such as Rekor, creating a verifiable and auditable record that anyone can inspect.

2.4 Pillar 4: Verification – Empowering Consumers with Proof

Together, these first three pillars enable a simple yet powerful verification workflow for any consumer of your software. We are no longer asking them to trust us; we are giving them the tools to prove it for themselves. The workflow is as follows (actions for the consumer):

1. Download: They fetch the software artifact along with its associated signature, attestation, and SBOM.
2. Verify Signature: Using a simple command like cosign verify, they confirm the artifact’s signature against the public transparency log.
3. Inspect Provenance: They examine the attestation metadata to see precisely how, where, and from which source code commit the artifact was built.
4. Analyze Components: Finally, they use the SBOM to check the artifact’s dependencies against their own internal security policies.

3.0 The Technology Ecosystem: Tools and Frameworks for Implementation

While the four pillars define our strategic goals, a mature ecosystem of open-source tools and standards provides the practical means to achieve them at scale. This section details the core components of your technical strategy.

3.1 The Blueprint: SLSA (Supply-chain Levels for Software Artifacts)

SLSA (pronounced “salsa”) should be thought of as the blueprint or the building code for your secure pipeline. It is a security framework that provides a checklist of standards and controls.

SLSAs purpose is to define increasing levels of security assurance, giving us a clear, standardized way to measure and communicate the maturity of your supply chain security.

Implementing the four pillars of verifiable trust is the practical method by which we will achieve and demonstrate SLSA compliance.

3.2 The Signing and Attestation Standard: in-toto and Sigstore

The in-toto framework and the Sigstore project have a symbiotic relationship that provides the cryptographic foundation for your strategy.

• in-toto
  • This framework is designed to secure the supply chain by creating verifiable metadata about the process (attestations). The SLSA provenance format is a specific implementation of an in-toto attestation.
• sigstore
  • This is the complete, free-to-use toolkit for signing and verifying software. Its core components – Cosign (for signing), Fulcio (a root certificate authority), and Rekor (a transparency log) – provide the “keyless” infrastructure needed to cryptographically secure the attestations.

In essence, in-toto and SLSA generate the verifiable claims about what happened in the supply chain, while Sigstore provides the public, keyless infrastructure to cryptographically prove those claims are authentic and untampered.

3.3 The Aggregation Engine: GUAC (Graph for Understanding Artifact Composition)

If SLSA is the blueprint, GUAC is the central building management system – an observability platform for the software supply chain. GUAC’s role is to ingest and aggregate all of your security metadata (SBOMs, SLSA attestations, vulnerability scans, and more) and connect it all within a single, queryable graph database.

The strategic value of GUAC is its ability to answer complex, cross-domain security questions that are impossible to address with siloed data.

For example, you will be able to ask: “Show me all production assets vulnerable to Log4Shell (from the SBOM) that were built from your main branch (from the attestation), show the containers it is built into and the regions where these are deployed (and possibly the pipeline that did that).”

This moves us beyond package-level vulnerability management to portfolio-wide risk analysis, allowing you to identify and remediate systemic weaknesses before they can be exploited.

4.0 Phased Implementation Roadmap

You will execute this transformation through a deliberate, four-phased roadmap. This approach prioritizes foundational capabilities to deliver value at each stage while building towards a comprehensive, automated end state.

4.1 Phase 1: Foundational Transparency and Visibility

• Goal: Achieve complete visibility into the software components of your critical applications, establishing a baseline for vulnerability management.
• Actions:
  • You must integrate automated SBOM generation tools, such as Syft or Trivy, into the CI/CD pipelines for all products defined as critical software according to your standards.
  • You need to establish a central repository (e.g., a dedicated metadata repository such as an artifact store) to store and index all generated SBOMs for easy querying.
  • You will begin initial analysis of SBOMs to identify, prioritize, and remediate known critical vulnerabilities present in bundled runtime dependencies.

4.2 Phase 2: Establishing Provenance and Integrity

• Goal: Ensure every artifact can be traced back to its exact source and build process, with its integrity cryptographically guaranteed.
• Actions:
  • You will integrate Sigstore/Cosign into your primary CI/CD platforms (GitHub Actions, Tekton, GitLab CI) to implement keyless signing for all container images and critical build artifacts.
  • You must implement SLSA-compliant provenance generation using automated tools like the SLSA GitHub Generator or Tekton Chains to create verifiable attestations for each build.
  • You need to ensure all signatures and attestations are published to the public Rekor transparency log and are stored alongside their corresponding artifacts in your OCI registries.

4.3 Phase 3: Active Enforcement at Runtime

• Goal: Transition from generating security evidence to actively enforcing security policies based on that evidence before software is deployed into production.
• Actions:
  • You will deploy a Kubernetes admission controller, such as Kyverno, to your production clusters to act as a policy enforcement point.
  • You need to develop and implement admission policies that automatically verify artifact signatures and inspect key attestation claims (e.g., must be built from the main branch, must have passed all required tests) before a deployment is permitted.
  • You should begin with an “audit-mode-first” approach to gather data on non-compliant deployments and refine policies before shifting to full enforcement mode to block them.

4.4 Phase 4: Comprehensive Insight and Proactive Risk Management

• Goal: Create a unified, queryable view of your entire software supply chain to enable proactive security analysis, dependency management, and continuous improvement.
• Actions:
  • You will deploy GUAC and configure its data collectors to ingest all SBOMs, SLSA attestations, and vulnerability scan results from across the organization into a central graph.
  • You need to develop dashboards and automated queries in GUAC to identify systemic risks, such as the most frequently used vulnerable dependencies or projects with low OpenSSF Scorecard ratings.
  • You must use the insights generated from GUAC to inform and prioritize strategic security investments, driving continuous improvement in your development tools and practices.

5.0 End State: A Proactive and Resilient Security Posture

By executing this strategy, we will have fundamentally transformed the security posture. This initiative elevates security from a reactive, compliance-driven cost center into a core, differentiating feature of your products.

By making transparency the default and trust verifiable, we are not just hardening your defenses; we are building a powerful sales and marketing asset that directly addresses customer and regulator demands.

This investment in a provably secure software supply chain will pay dividends in resilience, customer confidence, and market leadership for years to come.