A sovereign DevSecOps CI/CD pipeline is a software delivery system in which every stage, from source code commit through build, test, signing, and deployment, runs on infrastructure that is legally and technically outside the reach of foreign jurisdiction, backed by cryptographic provenance records and structured to produce audit evidence that satisfies regulatory frameworks such as NIS-2 and DORA. For European organisations in regulated sectors, this distinction is not an abstraction: the pipeline is where source code, deployment secrets, signing keys and build artefacts converge, and that convergence creates a high-value target both for adversaries and for compelled legal disclosure.
The Legal Exposure of SaaS CI/CD Platforms
GitHub Actions, GitLab SaaS and CircleCI are operated by US-incorporated entities and are therefore subject to the Clarifying Lawful Overseas Use of Data Act (CLOUD Act, 18 U.S.C. § 2713), which obliges them to produce customer data stored or processed anywhere in the world in response to US government orders, without requiring notice to the data subject or the customer organisation.
For a government body or a financial institution, the implications are concrete. Source code that embeds proprietary business logic, security-relevant configuration or authentication flows is processed by the build platform on every commit. Build secrets, including signing keys, container registry credentials and deployment tokens, are injected into pipeline runners. FISA Section 702 additionally authorises collection from US-controlled electronic communication service providers, a category that covers major SaaS platforms, without individual warrants. The combination means that routing regulated workloads through GitHub Actions is not a neutral technical choice: it is a legal risk decision.
Software supply-chain attacks increased by 742% between 2019 and 2022, according to the Sonatype State of the Software Supply Chain Report 2022. A compromised build platform is among the most efficient vectors because a single injection point can distribute malicious code to every downstream consumer of the affected pipeline.
Building a Self-Hosted Sovereign Pipeline
The practical alternative is a fully self-hosted stack in which no component is operated by a US-controlled entity, running on sovereign hardware in a qualifying jurisdiction such as Switzerland or an EU member state.
Source code management
Forgejo and Gitea are lightweight, open-source Git hosting platforms that can be deployed on a single virtual machine or in a container cluster. Forgejo is a community-governed hard fork of Gitea maintained under the Codeberg e.V. umbrella, which makes its governance structure attractive for public-sector operators who require vendor-independence guarantees. Both support fine-grained access control, branch protection rules, signed commit verification and webhook integration with CI systems. For larger organisations that need built-in container registry, DAST integration or a mature issue tracker, GitLab Community Edition provides a self-hosted alternative with no dependency on GitLab Inc. infrastructure.
Pipeline orchestration
Woodpecker CI is a lightweight, open-source pipeline engine descended from the Drone CI codebase. It uses a YAML-based pipeline definition, executes steps as OCI containers and connects to Forgejo or Gitea via webhook. Because Woodpecker agents pull work from a central server and execute in isolated containers, the attack surface is limited and the execution environment can be confined to a sovereign network segment without outbound internet access. Pipelines that require internet-accessible dependencies resolve them from internal mirrors rather than upstream registries.
Supply-Chain Security Controls Required by NIS-2
NIS-2 Article 21(2)(d) explicitly names supply-chain security, covering relationships with direct suppliers and service providers, as a mandatory security measure for essential and important entities. The ENISA has stated: “Secure software development practices are not optional for critical infrastructure operators. The supply chain is an attack surface that must be explicitly governed, not assumed to be safe because it is managed by a trusted vendor.”
62% of network intrusions in 2021 entered through an organisation’s partner or supplier ecosystem, according to the Verizon Data Breach Investigations Report 2022. A sovereign pipeline addresses this statistic only if it enforces provenance at every layer.
SBOM generation and dependency scanning
Every build should produce a Software Bill of Materials in CycloneDX or SPDX format, generated by tools such as Syft or cdxgen, and attached to the artefact as a signed attestation. The SBOM is not a compliance checkbox: it is the input to vulnerability matching tools such as Grype or OSV-Scanner, which compare the component inventory against known CVE databases. In a sovereign pipeline, the vulnerability database is mirrored internally so that scanning does not require outbound calls to NVD or OSV APIs.
NIST SP 800-218 (Secure Software Development Framework) provides the authoritative control catalogue for this layer. NIST has noted that “organisations should treat every build system, every dependency resolver, and every artefact store as a potential adversary entry point. Provenance must be verifiable at every step.” NIST SP 800-218 maps directly onto NIS-2 Article 21 requirements and provides a structured basis for audit evidence.
Container image signing with Sigstore and cosign
Sigstore is an open-source project under the OpenSSF that provides a transparency-log-backed signing infrastructure. The cosign tool signs OCI container images and attaches signatures and attestations (including SBOMs and SLSA provenance) to the image manifest in a compatible registry. In a sovereign deployment, the Rekor transparency log and Fulcio certificate authority that Sigstore uses publicly can be replaced with self-hosted instances, keeping all signing transactions within the sovereign boundary. Container registries such as Harbor or Zot, both CNCF projects, can enforce an admission policy that rejects any image not accompanied by a valid cosign signature.
SLSA provenance levels
The Supply-chain Levels for Software Artifacts (SLSA) framework, maintained by the OpenSSF, defines four graduated assurance levels for build provenance. SLSA Level 2 requires scripted builds and a hosted platform that produces provenance records. SLSA Level 3 additionally requires that the build platform prevents parameter injection and generates authenticated provenance. For regulated sectors under NIS-2 or DORA, Level 3 is the practical minimum target for production deployment pipelines.
Sovereign Package Mirrors and Container Registries
A pipeline that fetches npm, PyPI or Maven dependencies from upstream registries at build time routes traffic through Fastly, Cloudflare or AWS CDNs that are operated by US entities. Beyond the jurisdictional issue, upstream registries are a live dependency injection vector: a compromised package published to PyPI is immediately available to any pipeline that does not pin and mirror its dependencies.
The sovereign approach is to operate internal mirrors: Nexus Repository OSS or Artifactory CE for npm, PyPI and Maven, and a Harbor or Zot instance for OCI images. The mirrors pull from upstream on a scheduled basis, validate checksums and signatures, and serve all pipeline traffic internally. No build runner ever contacts an external registry directly. This architecture also enables the organisation to apply its own scanning policy before a package enters the mirror, acting as a gate rather than a passive cache.
HSMs for Artefact Signing and Post-Quantum Migration
A hardware security module (HSM) stores private signing keys in tamper-resistant hardware and performs cryptographic operations without ever exposing the key material. In a sovereign DevSecOps pipeline, the HSM is the root of trust for code-signing certificates, container image signing keys and SLSA provenance attestation keys. Cosign supports PKCS#11 interfaces, allowing a Woodpecker CI signing step to call a networked HSM such as a Thales Luna or Utimaco SecurityServer and receive a signature without the key leaving the device.
The post-quantum dimension is particularly relevant for code-signing certificates. The average cost of a data breach reached USD 4.45 million in 2023, according to IBM’s Cost of a Data Breach Report 2023, but the cost of a compromised signing key used to distribute malicious software at scale is qualitatively higher. A cryptographically relevant quantum computer would be able to forge RSA or ECDSA signatures retroactively, undermining the trustworthiness of all previously signed artefacts. NIST has finalised ML-DSA (CRYSTALS-Dilithium) as a post-quantum digital signature algorithm. Organisations designing a sovereign pipeline now should plan the signing infrastructure to support hybrid certificates that combine classical ECDSA with ML-DSA, so that the migration path is defined before quantum capabilities mature rather than after.
Generating Audit Evidence for NIS-2 and DORA
NIS-2 Article 21 and DORA Article 16 both require that regulated entities can demonstrate their security controls to supervisory authorities. For a DevSecOps pipeline, this means the audit evidence must be immutable, attributable and queryable.
Practical implementation involves four artefact types: append-only build logs exported to an immutable object store (such as a WORM-enabled MinIO instance on sovereign hardware); signed SBOMs attached to each container image via cosign attestation; Grype or Trivy scan reports stored alongside the artefact with a hash reference in the build log; and SLSA provenance documents generated by the build platform and counter-signed by the HSM-backed key. Together these four artefact types allow an auditor to reconstruct the complete provenance chain for any deployed container: what source commit it was built from, what dependencies it contained, what vulnerabilities were known at build time, and who authorised the signing.
For DORA specifically, ICT third-party risk assessments must cover the pipeline toolchain itself. A self-hosted stack based on Forgejo, Woodpecker CI and Harbor has a smaller and more auditable third-party dependency surface than a SaaS platform, but the dependencies that remain, including base container images and pipeline plugin containers, must be inventoried, scanned and governed under the same supply-chain policy as application code.
FAQ
Does hosting a GitLab CE instance in Europe remove CLOUD Act exposure?
Self-hosting the open-source GitLab CE edition on infrastructure that is neither owned nor operated by a US-controlled entity removes CLOUD Act exposure, because the Act compels US persons and US-incorporated companies to produce data, not arbitrary servers. Running GitLab CE on sovereign hardware in Switzerland or an EU jurisdiction, operated by a non-US entity, closes that legal gap. GitLab SaaS, however, is operated by GitLab Inc., a US corporation, and therefore remains subject to the Act regardless of where runner infrastructure is located.
What is the minimum SLSA level a regulated organisation should target?
SLSA Level 2 provides scripted builds and source provenance, which satisfies basic auditability. For regulated sectors under NIS-2 or DORA, SLSA Level 3 is the practical target: it requires a hosted build platform that generates authenticated provenance records and prevents build-parameter injection. SLSA Level 4 adds hermetic, reproducible builds and two-party review, which is advisable for critical deployment pipelines handling patient data, financial transactions or public-sector systems.
Can Woodpecker CI integrate with an HSM for artefact signing?
Yes. Woodpecker CI executes pipeline steps as container-based agents, which can invoke cosign or other signing tools that communicate with an HSM via PKCS#11. The signing step calls the HSM using a hardware-backed key that never leaves the device, and cosign writes the resulting signature and transparency-log entry alongside the artefact. The HSM itself can be a networked appliance such as a Thales Luna or Utimaco unit, accessible within the sovereign network segment.
What audit evidence does NIS-2 Article 21(2)(d) require for software supply chains?
NIS-2 Article 21(2)(d) requires essential and important entities to address supply-chain security including relationships with direct suppliers and service providers. In practice, supervisory authorities and auditors look for documented supplier risk assessments, evidence that software components have known and verified provenance, records of vulnerability scanning and remediation, and signed SBOMs that can be tied to deployed artefacts. Immutable build logs stored in append-only storage, cosign-signed container images referencing a transparency log, and periodic Trivy or Grype scan reports constitute the concrete evidence layer.
Why does post-quantum cryptography matter specifically for code-signing certificates today?
A cryptographically relevant quantum computer could retroactively break RSA or ECDSA signatures used to sign software artefacts collected today, a threat known as harvest-now, decrypt-later. For software deployed in long-lifecycle environments such as medical devices, industrial control systems or public-sector infrastructure, a signature issued today may need to remain trustworthy for ten or more years. Migrating code-signing to NIST-selected post-quantum algorithms such as ML-DSA (CRYSTALS-Dilithium) while the pipeline is still being designed is substantially cheaper than retrofitting a production pipeline after quantum capabilities mature.