Open Source Security Measures¶
About this policy
These policies aim to ensure that open-source software used or produced by the public sector meets robust security standards. They establish requirements and guidelines for vulnerability management, secure development practices, and supply chain integrity, recognizing the strategic importance of OSS in national cybersecurity frameworks.
What we include
This section includes laws, strategies, and operational guidelines that address the security of OSS in government systems. These may include mandatory vulnerability disclosure rules, security-by-design requirements, guidance on using or contributing to secure OSS, and protocols for secure software development lifecycles and supply chain assurance.
🌍 Policies¶
🇨🇦 Canada¶
- 🔗 Address Security and Privacy Risks Guideline
-
📄 Overview:
The Address Security and Privacy Risks guideline provides a comprehensive framework for securing software, including OSS used in government systems. It outlines security measures across the full lifecycle, including threat modeling, automated and penetration testing, privacy impact assessments, encryption, and patch management. While not exclusive to OSS, the guidance supports open-source adoption by emphasizing transparency, modular security features, and continuous monitoring, helping ensure that open systems meet rigorous privacy and cybersecurity standards.
- 📄 Overview:
The Open First Whitepaper emphasizes security as a key advantage of open-source software, citing its transparency, auditability, and wide peer review. In the "Security" section, the document explains that public access to source code allows for early identification and remediation of vulnerabilities, aligning with NIST recommendations against relying on obscurity. OSS is favored by national security agencies due to its inspectability, and its security model based on hardening through open testing, is presented as more robust when projects are actively maintained and reviewed.
🇪🇨 Ecuador¶
- 🔗 Executive Decree No. 1014
- 📄 Overview:
Executive Decree No. 1014 requires Ecuador’s central government entities to ensure technical capacity before deploying open-source software, as stated in Article 3. This provision aims to safeguard the secure and effective implementation of OSS by mandating adequate support infrastructure, indirectly addressing OSS security through operational readiness and oversight by the Subsecretariat of Informatics.
🇫🇷 France¶
- 🔗 Interministerial Support and Expertise Contracts for Free Software
-
📄 Overview:
The interministerial support contracts for open-source software include mandatory upstream contributions of all fixes, including security patches, developed during maintenance. This policy ensures that vulnerabilities addressed within public systems are resolved at the source, enhancing security for both government and broader OSS users.
-
📄 Overview:
ANSSI’s guide “Sélection d’un logiciel libre” outlines cybersecurity criteria for evaluating and selecting open-source software used in public systems. While not binding, it promotes secure OSS adoption by recommending assessment of code transparency, maintenance practices, and community responsiveness, reinforcing France’s broader open-source security posture.
- 📄 Overview:
Under Article L. 2321‑4‑1 of the French Code de la Défense, all software publishers—including open-source developers—are required to report significant vulnerabilities or incidents affecting their products to ANSSI. This regulation ensures security issues in OSS are disclosed and addressed promptly, reinforcing national cybersecurity standards across both proprietary and open systems.
🇩🇪 Germany¶
- 🔗 FLOSS (Free/Libre Open Source Software) – BSI
- 📄 Overview:
The BSI’s FLOSS policy highlights open source as a key enabler of IT security by allowing independent vulnerability assessments and remediation without reliance on vendors. The policy promotes software diversity to reduce monocultures, supports open standards for interoperability, and demonstrates active government contributions to secure OSS tools like Gpg4win and SINA. These measures form part of a strategic approach to enhance the resilience of federal IT systems.
🇰🇷 South Korea¶
- 🔗 Software Supply Chain Security Guidelines 1.0 (2023)
- 📄 Overview:=
Issued by the Ministry of Science and ICT along with national security and digital agencies, the Software Supply Chain Security Guidelines 1.0 establish a detailed framework for securing open-source software used in government systems. Central to the policy is the use of Software Bills of Materials (SBOM) to identify, validate, and manage vulnerabilities in open-source components throughout the software lifecycle. The document outlines technical procedures, validation methods, and support structures—including testing labs and automated SBOM tools to build secure supply chains, especially for public institutions and SMEs adopting open-source software.
🇨🇭 Switzerland¶
- 🔗 Report on the Implementation of the National Cyber Strategy (NCS) 2024
-
📄 Overview:
Section 4.2.1 highlights the increasing importance of securing open-source software (OSS). It outlines a pilot project started in 2024 by the Federal Office for Cybersecurity (BACS) to test frequently used OSS products. This initiative aims to increase the transparency and security of OSS, reduce attack surfaces, and enhance Switzerland's overall cyber resilience.
-
📄 Overview:
Section 4.1, "Source code analysis," defines specific security protocols to be followed before any software is published. These mandatory checks include scanning source code to ensure it contains no secrets or credentials, conducting targeted security tests, and creating lists of all third-party libraries used. It also recommends establishing a public bug bounty program after release.
- 📄 Overview:
A specific security protocol for community-managed projects is mandated in Section 5.8. This policy requires the establishment of a confidential channel for reporting security-relevant errors. This ensures that potential vulnerabilities can be disclosed responsibly to the project maintainers without being made public immediately, similar to the process used in formal bug bounty programs.
🇬🇧 United kingdom¶
- 🔗 Open Source, Open Standards and Re‑Use: Government Action Plan)
-
📄 Overview:
The Action Plan addresses open source security through Action 4, which establishes regular assessments by the CIO Council to ensure that open-source products used in government meet defined standards of maturity, codebase security, and project sustainability. This measure aims to mitigate risks associated with deploying open-source solutions in critical public services by verifying the reliability and stability of the tools before widespread adoption.
- 📄 Overview:
The playbook defines security protocols for all procured technology, which inherently covers open source software. The "Cyber security assessment" key policy requires that all projects apply a robust level of security assessment to safeguard public data. As expanded upon in Chapters 8 and 9, this includes mandating standards such as the Cyber Essentials Scheme for contracts handling personal information or providing certain ICT services, ensuring that any OSS utilized in public systems is subject to the same rigorous security risk evaluation and management.
🇺🇸 United States¶
- 🔗 GSA Open Source Software Implementation Guide
-
📄 Overview:
The policy defines security protocols for releasing code publicly. Project teams are required to work with the IT security office to conduct regular code scans for vulnerabilities. Additionally, the guide notes that the CTO's office provides specialized scripts designed to help teams scrub source code for sensitive content before it is published as open source.
-
📄 Overview:
The Act establishes extensive security duties for CISA under Section 2220F. It mandates the creation of a public framework for assessing the risk of open source components, considering factors like memory safety and maintainer practices. CISA must use this framework to assess OSS on high-value federal assets, leveraging information from Software Bill of Materials (SBOMs).
- 📄 Overview:
This roadmap is a comprehensive security policy for OSS. Goal 2 outlines plans to create a public framework for OSS risk prioritization based on usage, maintenance, and code properties. Goal 4 focuses on hardening the ecosystem by advancing the use of Software Bill of Materials (SBOM) in OSS supply chains (Objective 4.1) and fostering better vulnerability disclosure processes (Objective 4.4).
🇪🇺 European Commission¶
- 🔗 Regulation (EU) 2024/2847 (Cyber Resilience Act)
-
📄 Overview:
The act imposes several OSS security measures. Article 13(5) mandates due diligence when integrating any third-party components, including OSS. Annex I, Part II requires manufacturers to produce a Software Bill of Materials (SBOM) for their products. Furthermore, Article 24 creates specific obligations for "open-source software stewards" to establish cybersecurity policies for the projects they support.
-
🔗 European Commission digital strategy: Next generation digital Commission
-
📄 Overview:
The strategy enhances security across the digital landscape, which includes open source software. Page 14 outlines plans for systematic vulnerability scanning for all digital solutions and security checks for purchased software. The document also acknowledges that OSS can increase IT security through multiple independent quality controls, integrating it into a secure-by-design approach.
- 📄 Overview:
Security is a core governing principle, as outlined in Section 5.5, titled "Secure." The policy mandates continuous, automated security testing for both the open source components the Commission uses in its applications and the code it intends to share publicly. This ensures that software is free from vulnerabilities, leveraging experience from the EU-FOSSA projects.
🤝 How to contribute¶
Want to add a policy?
See something missing? Open a policy suggestion