Sovereign Software Supply Chain Attestation for Regulated Organisations

Sovereign software supply chain attestation is the practice of producing cryptographically verifiable, jurisdictionally controlled evidence that every software artefact running in an organisation’s environment was built exactly as claimed, using known inputs, by an authorised pipeline, without tampering at any stage. For European regulated organisations, that definition has moved from a security best practice to a legal requirement, shaped by NIS-2 Article 21(2)(d), the Cyber Resilience Act, and the sovereign imperative to keep infrastructure evidence out of reach of US jurisdiction.

Software supply chain attacks increased by 742% between 2019 and 2022, according to Sonatype’s State of the Software Supply Chain Report (2022). The average cost of a data breach reached USD 4.45 million in 2023, the highest figure IBM has recorded in its annual Cost of a Data Breach Report. ENISA’s Threat Landscape 2023 placed supply chain compromises among the top threats affecting government and critical infrastructure sectors across the European Union. Against that backdrop, the question for compliance officers and CISOs is no longer whether to implement attestation, but how to implement it in a way that survives regulatory scrutiny and removes dependency on infrastructure that falls under the US CLOUD Act or FISA 702.

SLSA v1.0 Maturity Levels and the Defensible Threshold for Regulated Deployments

SLSA v1.0 (Supply-chain Levels for Software Artifacts), maintained under the OpenSSF umbrella, defines four levels of build integrity assurance, each adding verifiable constraints on the build process.

For most regulated organisations in finance, healthcare and the public sector, SLSA Level 2 is the defensible minimum: it produces signed provenance that can be presented to an auditor as proof that a specific build system produced a specific artefact. Level 3 is the appropriate target for components that process special-category personal data under GDPR, or for software classified as an important or critical product under the Cyber Resilience Act’s Annex I categories.

Sigstore, Cosign, Rekor and Fulcio: Verifiable Provenance Without US Infrastructure Dependency

The Sigstore project, hosted under the OpenSSF, provides the tooling that makes SLSA Level 2 and above operationally achievable at scale. Understanding each component matters because the sovereign question turns on where each component runs.

Cosign is the signing tool. It attaches cryptographic signatures to container images and other artefacts, binding the signature to a short-lived certificate rather than a long-lived private key. That certificate is issued by Fulcio, Sigstore’s certificate authority, which ties the certificate to a verified identity, typically an OpenID Connect identity from a CI/CD provider. Rekor is the transparency log: an append-only, Merkle-tree-based ledger that records every signing event. Once an entry is written to Rekor, its inclusion can be verified independently without trusting the signer. The combination means that a consumer of a signed artefact can verify: who signed it, when, under what identity, and that the signing event is permanently recorded in a tamper-evident log.

The problem for European regulated organisations is that the public Sigstore instance writes to a Rekor log operated on Google infrastructure. Transparency log entries may themselves contain metadata about the organisation’s internal build processes, and the infrastructure falls within US jurisdiction under the CLOUD Act. The solution is to self-host the entire Sigstore stack within European infrastructure, described in the section below.

In-toto Attestations and DSSE Envelopes: Chain of Custody from Source to Deployment

Signing an artefact with Cosign proves that a specific identity signed a specific digest at a specific time. It does not, by itself, describe the series of steps that produced the artefact. That is the role of the in-toto attestation framework, which defines a structured format for recording each step in a software supply chain, from source checkout through compilation, testing, packaging and deployment.

An in-toto statement describes a predicate (what happened) and a subject (which artefact was produced). The SLSA Provenance predicate is one specialised form of in-toto statement, recording the builder identity, build configuration reference, and the digest of every input material. These statements are wrapped in Dead Simple Signing Envelope (DSSE) format, which provides a simple, canonical serialisation that Cosign can sign and Rekor can log.

For a regulated organisation, the practical result is an auditable chain of custody: each stage of the build pipeline produces a signed in-toto attestation that references the outputs of the previous stage. An auditor or incident investigator can reconstruct exactly which source commit, which build configuration, which dependency versions, and which signing identity produced a deployed container image. That chain of custody is the evidence that NIS-2 Article 21(2)(d) supply-chain security obligations require organisations to be able to demonstrate.

Attestation and SBOM Under the Cyber Resilience Act

The Cyber Resilience Act, specifically its Article 14 vulnerability reporting obligations and Annex I security requirements, treats SBOM and supply chain attestation as complementary rather than interchangeable. An SBOM in SPDX or CycloneDX format answers the question of which components are present in a product. A supply chain attestation answers how the product was assembled and whether the build process was controlled.

As ENISA has stated in its supply chain security guidance: “Supply chain security is not just about knowing your vendors. It is about being able to prove, with cryptographic evidence, that every artefact running in your environment is exactly what your vendor claims it to be.”

The CRA’s single reporting platform, which will receive vulnerability disclosures under Article 14, will expect manufacturers of products with digital elements to maintain records that connect a specific product version to its SBOM and to the provenance evidence for that build. For NIS-2 Article 21 supply-chain risk management, the evidence that must be retained includes: the signed SLSA provenance statement for each release, the full in-toto attestation chain for each build pipeline stage, the SBOM linked to the specific artefact digest, and the Rekor log entry reference that proves the signing event was recorded in a transparency log before the artefact was deployed.

Self-Hosting a Sovereign Sigstore Stack

Removing dependency on Google-operated infrastructure requires deploying three components in European-controlled infrastructure: a Rekor instance as the transparency log, a Fulcio instance as the certificate authority, and a certificate transparency log for Fulcio’s own certificates.

The Sigstore project provides each component as an open-source service. Rekor can be deployed against any PostgreSQL-compatible backend, with the Merkle tree state stored locally. Fulcio requires an upstream OIDC provider: for sovereign deployments, this is typically an internal identity provider such as Keycloak or a national eIDAS-compliant identity service rather than a dependency on Google Accounts or GitHub. The Fulcio CA itself should be backed by a hardware security module (HSM) or a CloudHSM equivalent hosted in the same European jurisdiction.

Organisations should also configure Cosign to point to their internal Rekor and Fulcio endpoints via the SIGSTORE_REKOR_URL and SIGSTORE_FULCIO_URL environment variables, and distribute the root certificate of the internal Fulcio CA through their internal PKI so that verification does not fall back to the public trust roots. The OpenSSF maintains documentation on operating a private Sigstore deployment, and several European cloud providers with sovereign hosting commitments now offer managed Sigstore components as part of their platform offerings.

Procurement Language and Contractual Controls for Sovereign Software Vendors

As the OpenSSF Technical Advisory Council has observed, “A software bill of materials without attestation of how that software was built is like a food label without any inspection record. It tells you what is in the package, but not whether the factory was clean.” That analogy translates directly into procurement requirements.

CISOs and compliance officers should require the following in contracts with sovereign software vendors: an explicit statement of the SLSA level achieved (Level 2 as a minimum, Level 3 for high-assurance components); delivery of signed SLSA provenance as a release artefact alongside every build, not as an optional attachment; identification of the build platform by name, with a commitment that it meets the SLSA v1.0 definition of a hosted build service; retention of full in-toto attestation chains for a period aligned with the organisation’s NIS-2 audit retention obligations (typically five years for critical infrastructure); the right to audit the build pipeline or to receive a third-party audit report against SLSA Level 3 criteria annually; and a change notification obligation requiring the vendor to notify the customer and re-attest if the build platform, signing identity infrastructure, or dependency management process changes materially. Contracts should also specify that provenance must be verifiable against a transparency log accessible to the customer, and that for sovereign deployments, that log must not be the Google-operated public Rekor instance.

FAQ

Is SLSA Level 1 sufficient for NIS-2 compliance in regulated sectors?

SLSA Level 1 requires only that build provenance exists and is documented, but it does not mandate that the build process is tamper-resistant or that provenance is cryptographically signed. For regulated sectors subject to NIS-2 Article 21(2)(d), Level 1 is generally considered insufficient because it cannot demonstrate that the artefact was produced by a specific, unmodified pipeline. Level 2, which requires a hosted build service and signed provenance, is the defensible minimum for audit purposes.

Can a European organisation use the public Sigstore instance, or must it self-host?

Using the public Sigstore instance means that transparency log entries are written to a Rekor instance on Google infrastructure, creating a dependency on a US-controlled service. For organisations subject to GDPR data localisation concerns or sector-specific sovereignty requirements, self-hosting the full Sigstore stack, including Rekor as the transparency log and Fulcio as the certificate authority, removes that dependency and keeps attestation metadata under European jurisdiction.

What is the difference between an SBOM and a supply chain attestation?

A Software Bill of Materials lists the components included in a software artefact, typically in SPDX or CycloneDX format. A supply chain attestation, such as an in-toto statement wrapped in a DSSE envelope, describes the process by which that artefact was produced: which build system ran, which inputs were used, which identity signed the result, and whether the pipeline was hermetic. Both are required under the Cyber Resilience Act, and they complement each other: the SBOM answers “what”, while the attestation answers “how and by whom”.

What contractual clauses should a CISO include when procuring sovereign software to ensure SLSA compliance?

Procurement contracts should specify the required SLSA level (Level 2 as a minimum, Level 3 for high-assurance deployments), require that signed provenance is delivered with every release artefact, name the build platform and require that it meets the criteria for a hosted build service under SLSA v1.0, require retention of attestation records aligned with NIS-2 audit obligations, and include the right to audit the build pipeline or receive third-party audit reports. Contracts should also prohibit substitution of the build platform without prior notification and re-attestation.

How does post-quantum cryptography affect software supply chain attestation?

Current Sigstore tooling and in-toto attestations rely on conventional elliptic-curve signatures (ECDSA). As quantum computers capable of breaking these algorithms become a credible near-term threat, organisations storing attestation records for long-lived artefacts should plan migration to post-quantum signature schemes. The NIST PQC standardisation process has produced FIPS 204 (ML-DSA) as the primary post-quantum signature standard, and sovereign deployments should evaluate when Cosign and in-toto implementations will support these algorithms to protect the long-term integrity of their attestation archives.