Sourceware Cyber Security FAQ

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.

US Improving the Nation's Cybersecurity Executive Order 14028

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. note: A new Executive Order issued June 2025 calls for a new (reference) implementation of the SSDF which will supplant SP 800-218 and removes the attestation requirement.

EU Cyber Resilience Act (EU CRA)

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.

note: Alexander Sander from the FSFE give a CRA Update Where are we today, what is next, what to do? for SFC Member Projects on 7/17/2025.

Recommendations for Sourceware hosted projects

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.

Suggested secure development policies for projects

Make sure to have a CONTRIBUTING file or webpage explaining how and where to submit bugs, how and where to submit patches, and which coding standards are used and which testing is expected for contributions.
Document who can review and approve which patches and require at least one reviewer for any non-trivial patch before committing.
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.
When closing a bug because a fix was checked in make sure the exact commit has been added to the bugzilla issue (setup a commit hook to do this).
Encourage signed git commits and store public keys in gitsigur.
When using b4 check the DKIM verification of email contributions.
Add a SECURITY file that documents the security policy, what kinds of bugs could be security issues, 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.
Have a webpage which list the release schedule and active (supported) releases (and which versions are no longer supported).
Defined a continuous integration (CI) build pipeline on builder.sourceware.org for all supported architectures.
Use snapshots.sourceware.org to define a continuous delivery (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.
Store test results in bunsen for easy (historical) analysis (and/or have a public testresults mailing list archive).
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.

Replying to EU CRA information requests

Corporations are trying to figure out what their responsibilities are as manufacturer under the EU CRA and towards the Free Software projects they are modifying, integrating and redistributing in their products. They might sent requests for help to the upstream projects. Although Sourceware hosted projects aren't vendors or manufacturers this is an opportunity to explain which obligations such corporations have towards the upstream projects and how they can meaningfully contribute.

It is important to set expectations by pointing out that the project itself isn't a vendor or a manufacturer. And so doesn't fall within the scope of the EU CRA regulation. But that as manufacturer they are responsible for the security throughout their product's life cycle. This includes reporting and providing fixes for security issues to the upstream project. Given your project followed the policy checklist you can use the following template:

Thanks for your interest in integrating project into your product. Note that project isn't a product and the project community isn't a third party vendor or manufacturer itself.

If you are a commercial manufacturer or importer that wants to put products with digital elements on the EU market, then according to the EU CRA regulation you are responsible for the cybersecurity throughout your product's life cycle. This includes reporting and providing fixes for security issues to the upstream project. Please see https://sourceware.org/cyber-security-faq.html#eu-cra for some recommendations around the EU CRA.
You can find out about the project security policy and how to report issues at URL-to-SECURITY-file. Announcements about new releases and (security) fixes are published at URL-to-announcement-mailing-list. See also URL-to-CONTRIBUTING-file-or-webpage how to follow our secure development practices.

If you would like to financially contribute to the project hosting infrastructure see https://sourceware.org/donate.html