Sovereign OSPO: open source governance security baseline public sector

A sovereign Open-Source Programme Office (OSPO) is a dedicated governance function within a public-sector organisation that owns the full lifecycle of open-source software: procurement evaluation, licence compliance, dependency risk, vulnerability disclosure and long-term maintenance accountability. As European legislative and policy frameworks converge, establishing a mature OSPO is no longer a best-practice recommendation; it is the operational prerequisite for meeting binding obligations under the EU Open Source Strategy (June 2026), the Cyber Resilience Act (CRA) and NIS-2.

What the EU Open Source Strategy (June 2026) Actually Requires

The EU Open Source Strategy, updated as part of the European Technological Sovereignty Package, formalises the “open-source-first” principle: public administrations must actively evaluate open-source solutions before procuring proprietary software, document why a proprietary alternative was chosen if open source was set aside, and contribute improvements back to upstream projects when public funds finance the development. The strategy is not aspirational language; it feeds directly into the European Interoperability Framework and is expected to be operationalised through national action plans across member states.

Three governance expectations are embedded in the strategy that an OSPO must address concretely. First, procurement processes must produce a documented open-source evaluation record, not a checkbox. Second, contribution governance must define who is authorised to commit code on behalf of the organisation to public repositories, under what licence, and with what security review. Third, maintenance accountability must be assigned: if an administration relies on an upstream component, it must either track that component’s maintainer health or fund a support arrangement that guarantees patch delivery within defined timelines.

The Open Source Observatory (OSOR), maintained on the Joinup platform, provides the empirical reference layer for this work: case studies from member-state administrations, reuse assessments and interoperability guidance. The EU Open Source Solutions Catalogue on the same platform lists solutions already assessed in a public-sector context, giving procurement officers a defensible starting point rather than a blank sheet.

Building or Maturing an OSPO for CRA Compliance

The Cyber Resilience Act imposes concrete obligations on any organisation that develops, integrates or substantially modifies software placed on the internal market or used in critical infrastructure. For public-sector bodies running sovereign infrastructure, the CRA’s Article 13 obligations are the structural spine of an OSPO’s security function.

A mature OSPO must operate four systematic capabilities in parallel:

96 percent of codebases examined in the 2024 Synopsys Open Source Security and Risk Analysis (OSSRA) report contained open-source components, and 84 percent contained at least one vulnerability. (Synopsys OSSRA Report 2024) This is not a niche risk: it is the baseline condition of every public-sector software stack, and an OSPO without automated dependency scanning is operating blind.

Commission Security Baselines for Open-Source Repositories

The Commission has committed, as part of the Technological Sovereignty Package, to developing common security baselines for open-source code repositories hosted on EU infrastructure, with code.europa.eu as the reference implementation. These baselines are expected to cover four domains: continuous security monitoring (SAST and SCA tooling integrated into CI/CD pipelines), vulnerability management workflows aligned to CRA timelines, licence compliance gates and dependency risk scoring.

For regulated deployers, adopting these baselines before they become formally mandated is both a risk-reduction measure and an audit-readiness investment. Organisations that mirror the Commission’s baseline configuration in their own repository governance can point auditors to a published, EU-level reference standard rather than defending a bespoke approach. code.europa.eu itself demonstrates the model: it runs a self-hosted GitLab instance under EU jurisdiction, with access controls, audit logging and pipeline security policies that exclude non-EU infrastructure from processing repository content.

Unifying SBOM, NIS-2 and OSPO Governance into a Single Transparency Posture

The Cyber Resilience Act’s Article 13 SBOM obligation and NIS-2 Article 21’s supply-chain security requirement are often treated as separate compliance workstreams. In practice, they converge on a single data artefact: an accurate, current, machine-readable inventory of every software component in production. An OSPO that generates and maintains that inventory as a routine release artefact satisfies both obligations simultaneously.

The operational integration works as follows. Every build pipeline produces a CycloneDX or SPDX SBOM. That SBOM is ingested by a vulnerability management tool (such as Dependency-Track or a CSIRT-compatible feed) that correlates components against the NVD and ENISA’s known exploited vulnerabilities list. When a new CVE affects a component in the SBOM, the OSPO’s triage workflow activates automatically, assigning severity, owner and remediation deadline in line with the organisation’s NIS-2 incident response plan. The SBOM thus becomes the live evidence that both the CRA’s “without undue delay” patching obligation and NIS-2’s supply-chain risk management requirement are being met continuously, not retrospectively assembled for an audit.

Approximately 80 percent of European public-sector software spending flows to non-European vendors, according to European Commission impact assessments supporting the EU Open Source Strategy. (European Commission, 2024) An OSPO that replaces even a portion of that spend with auditable, EU-hosted open-source alternatives reduces foreign jurisdictional exposure and simultaneously improves SBOM transparency, because open-source components have public provenance that proprietary binaries do not.

Selecting Sovereign Open-Source Alternatives: Decision Criteria for IT Decision-Makers

The EU Open Source Strategy’s open-source-first principle requires a structured evaluation, not just a preference signal. When replacing proprietary middleware, identity providers or collaboration tools, IT decision-makers should apply the following criteria in sequence.

First, jurisdictional control: the software’s primary maintainer and any associated SaaS hosting must be subject to EU or equivalent jurisdiction. A project governed by a US-incorporated foundation and hosted on US infrastructure remains exposed to CLOUD Act demands even if the source code is openly licensed.

Second, licence provenance: the licence must be OSI-approved and compatible with the organisation’s intended use, including any internal distribution or SaaS deployment. Copyleft obligations (GPL, AGPL) require explicit legal review before deployment in environments where the software is exposed to external users.

Third, security certification: for identity providers and network security components, look for solutions that have undergone evaluation against Common Criteria, BSI C5 or SOC 2 Type II. For EU public administrations, solutions listed in the EU Open Source Solutions Catalogue with documented NIS-2 alignment carry a reduced due-diligence burden.

Fourth, maintainer health: check release cadence, number of active maintainers, funding model and response time on security issues. A project with a single funded maintainer outside the EU and no succession plan represents a concentration risk equivalent to a single-vendor proprietary dependency.

Proving Audit-Readiness to Supervisory Authorities

The IBM Cost of a Data Breach Report 2024 puts the global average breach cost at USD 4.88 million, with government and public-sector organisations consistently among the most frequently targeted. (IBM, 2024) Supervisory authorities under NIS-2 and sector-specific regulators under DORA are increasingly requesting evidence of software supply-chain governance, not self-attestation.

An OSPO demonstrates audit-readiness through four documentary artefacts. The dependency inventory, maintained as a live SBOM per release, shows what is in production. The patch log, timestamped and linked to CVE identifiers, shows that known vulnerabilities were addressed within the organisation’s stated SLAs. The licence compliance register, generated by automated scanning and reviewed by a named responsible person, shows that no unlicensed or incompatible components are deployed. The maintainer health report, produced quarterly, shows that the OSPO actively monitors the continued viability of upstream projects rather than assuming indefinite availability.

Organisations that align their OSPO practices with the OSOR’s documented case studies and the Commission’s code.europa.eu security baselines can reference those external standards when responding to auditor inquiries, reducing the burden of defending bespoke methodologies. The goal is a governance posture where the answer to “how do you know this component is safe to rely on” is a retrievable record, not a verbal explanation.

FAQ

Is an OSPO legally mandatory for EU public administrations after the EU Open Source Strategy (June 2026)?

The EU Open Source Strategy (June 2026) does not impose a one-size-fits-all legal mandate for an OSPO entity by name, but it does require public administrations to demonstrate open-source-first procurement evaluation, contribution governance and long-term maintenance accountability. An OSPO is the recognised governance structure for meeting those requirements systematically, and national transposition measures in several member states are moving toward explicit OSPO obligations.

What exactly must a Software Bill of Materials contain under Cyber Resilience Act Article 13?

Article 13 of the Cyber Resilience Act requires manufacturers to prepare an SBOM covering at minimum the top-level dependencies of a product with digital elements. It must identify each component by name, version, supplier and known licence. The SBOM must be kept current and made available to market surveillance authorities on request. For public-sector deployers using open-source stacks, this obligation extends to self-developed integrations layered on top of upstream components.

How does code.europa.eu differ from a standard Git hosting platform like GitHub?

code.europa.eu is the European Commission’s self-hosted GitLab instance, operated under EU jurisdiction and subject to EU data protection law. Unlike GitHub, which is a US-incorporated service subject to the CLOUD Act and FISA 702, code.europa.eu provides hosting that does not expose repository metadata or code to foreign government access demands. For sovereign infrastructure projects, this jurisdictional difference is material, particularly when repositories contain pre-release vulnerability information or security configurations.

How do NIS-2 supply-chain obligations interact with OSPO licence and dependency governance?

NIS-2 Article 21 requires essential and important entities to manage security risks arising from supplier and third-party dependencies. For organisations running open-source stacks, each upstream library is in effect a supplier. The OSPO’s dependency inventory, combined with an up-to-date SBOM, provides the evidence trail that auditors and competent authorities need to verify that supply-chain risks have been assessed and that patches are applied within the organisation’s defined remediation timelines.

What is the EU Open Source Solutions Catalogue and how should procurement officers use it?

The EU Open Source Solutions Catalogue, maintained on the Joinup platform, lists open-source software solutions that have been assessed or deployed by EU institutions and member-state administrations. Procurement officers can use it as a starting point to identify alternatives to proprietary middleware, identity providers and collaboration tools that have already demonstrated interoperability in a public-sector context. Inclusion in the catalogue is not a security certification, so OSPO teams must still conduct their own licence, dependency and vulnerability assessment before deployment.