In recent years various governments have started to try to "regulate" software services security. It is not always clear how these cyber security regulations might impact community Free Software projects as hosted by Sourceware.
The Software Freedom Conservancy is monitoring the various proposals and helps us determine the impact, if any, on the Sourceware services, and which policies our hosted projects might want to adopt.
Two such "meta" regulations are the US Improving the Nation's Cybersecurity Executive Order 14028 and the EU Cyber Resilience Act (EU CRA), which are summarized below. The summaries also explain how this interacts with documenting the Secure Software Development Framework (NIST SP 800-218) practices for corporations providing software services to US government agencies, how those agencies use Zero Trust (NIST SP 800-207) cloud-computing environments and the CE mark requirements for commercial manufactures or importers on the EU market.
After giving a summary of the proposed regulations, we'll analyze and give recommendations for policies to adopt by hosted projects (most projects already have such policies in place). Finally we'll give some practical suggestions for specific development practices to adopt.
The US Improving the Nation's Cybersecurity Executive Order 14028.
This is a very broad executive order intended to improve the American people’s security and privacy by making the prevention, detection, assessment, and remediation of cyber incidents a top priority of the administration.
It instructs government agencies to update their contracts with (cloud) service providers so they share security threats and incidents with the federal government through standardized common cybersecurity contractual requirements. Government agencies are instructed to use cloud-computing environments with a Zero Trust (NIST SP 800-207) architecture and to adopt multi-factor authentication and encryption of data at rest and in transit. And it provides agencies with guidance for using secure software development environments.
That guidance includes criteria to evaluate the security practices of government suppliers. Which includes ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product. And for government agencies to use Software Bill of Materials to analyze known vulnerabilities in procured products.
It also establishes a federal Cyber Safety Review Board and has guidelines for improving the Federal Government’s Investigative and Remediation Capabilities. note: The current administration has dismissed all members of the Cyber Safety Review Board.
None of this impacts upstream projects directly. But companies doing business with the US government are asked to document how they implement a Secure Software Development Framework (NIST SP 800-218). Which include recommendations about documenting processes for checking the integrity and provenance of sanctioned and vetted open-source components used in their products. And to address any known vulnerabilities in the components they ship.
The EU Cyber Resilience Act (EU CRA) on horizontal cybersecurity requirements for products with digital elements.
This act tries to ensure that products with digital elements placed on the EU market have fewer vulnerabilities and that manufacturers remain responsible for cybersecurity throughout a product’s life cycle.
The EU member states are currently (November 2024) trying to harmonize the rules for the placing on the market of connected hardware and software products. There will be requirements and obligations for placing products for sale on the EU market by manufacturers or importers.
This essentially means that commercial goods which contain software need to come with a CE mark. A CE mark on commercial products indicate that the manufacturer or importer affirms the goods' conformity with European health, safety, and environmental protection standards. note: The Cyber Resilience Act has been officially published in December 2024, and the main obligations of the CE marking will apply from December 2027.
The CRA contains exclusions for activities prior to commercial deployment of the software, individual contributors to upstream projects and charities managing these projects. Including exclusions for operating a hosting service with open repositories, collaboration platforms (like Sourceware) or providing software through package managers (like Cygwin).
But downstream users who make the software available as a commercial activity will need to pay careful attention to their responsibilities under the CRA as well as to their liabilities to consumers when creating and selling commercial products on the EU market (there are exceptions for manufacturers that qualify as microenterprises or as small enterprises).
Upstream projects are not seen as manufactures or importers placing products onto the EU market. But some organizations or individuals can still have some responsibilities as "open-source software steward" if they have "the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products".
Such stewards, who provide sustained support intended for a specific product or support intended for commercial activities, are responsible for providing clear documentation on how to report security issues/patches and promote the sharing of information concerning discovered vulnerabilities within the free and open-source software community.
Sourceware hosted projects have been doing collaborative secure community development for a quarter century (or longer) already. Some corporations and governments are now catching up. Most of these practices are already second nature to most projects, but not always well documented. So priority one should be to document our existing secure software development practices.
While documenting the secure software development practices of a project it is important to do this from the view of the active developer community and other free software partners, like direct downstream users, distros and projects that depend on the core toolchain and developer tools.
The US Executive Order isn't law and it doesn't look like the current administration is interested in moving executive orders from the previous administration forward. The NIST recommendations are written for companies doing business with the US government and for government agencies who want to do their own secure development (in the cloud). They are not practical for describing the secure software development environment of upstream communities. But elements can be used as inspiration. If only because it shows what kind of documentation requests a project might get from companies working with the US government.
Likewise the EU CRA is mainly aimed at commercial manufacturers and importers placing products on the EU market seeking a CE mark to do so. Manufacturers have an obligations when identifying vulnerabilities in embedded free and open-source software to fix and report such issues to the (upstream) project. And although voluntary, manufacturers integrating free and open-source software components, can also finance or contribute security attestations for upstream projects. So it is beneficial to projects to clearly document contribution and security reporting processes.
The EU CRA envisions such contributions to free and open-source software projects to be made through "open-source software stewards". We don't believe Sourceware, our hosted projects or the SFC or FSF qualify as "open-source software steward", which is defined as systematically providing support on a sustained basis for the development of specific products with digital elements intended for commercial activities. But even if a project isn't providing sustained support of a specific products for commercial activities, it might still be useful to act like one. Most hosted projects already do everything expected from a "open-source software steward". Document contributor policies, having a way to report security vulnerabilities, and publicly and systematically announce (security) updates.
Below we list some practical policies projects can adopt (if they don't already) that would help show the project/community follows secure development practices advocated in the above regulations.
Record all review actions in the final commit using tags like Co-Authored-By:, Approved-By:, Reviewed-By:, Tested-By:, Acked-by and add links to bugzilla and review threads on inbox.sourceware.org.
Add a SECURITY file that documents the security policy, what kinds of bugs are, and which bugs are not considered security issues and how to report them.
Make sure to have a well documented way (announce list) for new releases and security updates.
Clearly document who the release managers are and which PGP signatures they will be using for official releases.
Use snapshots.sourceware.org to define a continious deliver (CD) service so it is always clear whether the project and documentation are in a releasable state.
Use builder.sourceware.org try-bots or a pre-commit patchwork.sourceware.org bot to check patches before committing.
Also setup automatic build pipelines that use static analyzers (gcc -fanalyzer), hardening flags (gcc -fhardened), sanitizers (gcc -fsanitize=undefined) and run the testsuite under a memory checker like valgrind.
Make sure your MAINTAINERS file (or equivalent) is up to date. Sourceware admins use that to check who has permission to approve new committer accounts.
Sourceware provides a service to retire inactive accounts (those who haven't pulled or pushed in a year) every 3 months.
See also the Sourceware infrastructure security vision.