1<!DOCTYPE html> 2<html lang="en"> 3<head> 4<title>Sourceware Cyber Security FAQ</title> 5<META NAME="robots" CONTENT="index, follow"> 6<META NAME="description" CONTENT="Sourceware free software"> 7<META NAME="keywords" CONTENT="open source free software sourceware gcc egcs gdb cygwin binutils compiler debugger developer tools popcorn, peanuts, beer! Get yer popcorn, peanuts beer!"> 8<meta name="author" content="Jason Molenda, International Man Of Mystery"> 9 10<meta name="viewport" content="width=device-width, initial-scale=1.0"> 11<link rel="stylesheet" href="/sourceware.css"> 12</head> 13 14<body> 15<div class="logo"> 16<a href="https://sourceware.org/"><img src="/img/topbar-standalone.png" width=120 height=18 alt="sourceware"></a> 17</div> 18 19<div class="sidenav"> 20 <form method="get" action="/cgi-bin/search.cgi"> 21 <table> 22 <tr><td colspan="2"><a href="/index.html"><b>sourceware.org</b></a></td></tr> 23 <tr><td><code> </code></td><td><a href="/sourceware-25-roadmap.html">25 Roadmap</a></td></tr> 24 <tr><td><code> </code></td><td><a href="/sourceware-security-vision.html">Vision & Plans</a></td></tr> 25 <tr><td><code> </code></td><td><a href="/cyber-security-faq.html">Security FAQ</a></td></tr> 26 <tr><td><code> </code></td><td><a href="/sourceware-wiki/servers-and-services-2026/">Servers</a></td></tr> 27 <tr><td colspan="2"><a href="/mission.html"><b>Our Mission</b></a></td></tr> 28 <tr><td><code> </code></td><td><a href="/mission.html#organization">Organization</a></td></tr> 29 <tr><td><code> </code></td><td><a href="/mission.html#services">Services</a></td></tr> 30 <tr><td><code> </code></td><td><a href="/mission.html#sponsors">Sponsors</a></td></tr> 31 <tr><td colspan="2"><a href="/donate.html"><b>Donate</b></a></td></tr> 32 <tr><td><code> </code></td><td><a href="/sponsor.html">Sponsor</a></td></tr> 33 <tr><td><code> </code></td><td><a href="/financials.html">Financials</a></td></tr> 34 <tr><td colspan="2"><a href="/mirrors.html">Mirrors</a></td></tr> 35 <tr><td colspan="2"><a href="/news.html"><b>News</b></a></td></tr> 36 <tr><td colspan="2"><a href="/projects.html"><b>Projects</b></a></td></tr> 37 <tr><td><code> </code></td><td><a href="/binutils/">Binutils</a></td></tr> 38 <tr><td><code> </code></td><td><a href="https:///cygwin.com">Cygwin</a></td></tr> 39 <tr><td><code> </code></td><td><a href="https://dwarfstd.org">dwarfstd</a></td></tr> 40 <tr><td><code> </code></td><td><a href="http://elfutils.org/">elfutils</a></td></tr> 41 <tr><td><code> </code></td><td><a href="https://gcc.gnu.org/">GCC</a></td></tr> 42 <tr><td><code> </code></td><td><a href="/gdb/">GDB</a></td></tr> 43 <tr><td><code> </code></td><td><a href="/glibc/">GLIBC</a></td></tr> 44 <tr><td><code> </code></td><td><a href="/libabigail/">Libabigail</a></td></tr> 45 <tr><td><code> </code></td><td><a href="/newlib/">Newlib</a></td></tr> 46 <tr><td><code> </code></td><td><a href="/systemtap/">SystemTap</a></td></tr> 47 <tr><td><code> </code></td><td><a href="https://valgrind.org">Valgrind</a></td></tr> 48 <tr><td><code> </code></td><td><a href="/sourcecode.html">More projects...</a></td></tr> 49 <tr><td colspan="2"><a href="/lists.html"><b>Mailing Lists</b></a></td></tr> 50 <tr><td colspan="2"><a href="/suggestions.html"><b>Suggestions</b></a></td></tr> 51 <tr><td colspan="2"><input type="text" size="9" name="q" value=""></tr> 52 <tr><td colspan="2"><input type="Submit" name="submit" value="Search"></td></tr> 53 <tr><td colspan="2"><p></td></tr> 54 </table> 55 </form> 56</div> 57 58<div class="main"> 59 60 61<h2 align=center>Sourceware Cyber Security FAQ</h2> 62 63<p>In recent years various governments have started to try to "regulate" 64software services security. It is not always clear how these cyber 65security regulations might impact community Free Software projects as 66hosted by Sourceware.</p> 67 68<p>The <a href="https://sfconservancy.org/">Software Freedom 69Conservancy</a> is monitoring the various proposals and helps us 70determine the impact, if any, on the Sourceware services, and which
71policies our hosted projects might want to adopt.</p> 72 73<p>Two such "meta" regulations are the US Improving the Nation's 74Cybersecurity Executive Order 14028 and the EU Cyber Resilience Act 75(EU CRA), which are summarized below. The summaries also explain how 76this interacts with documenting the Secure Software Development 77Framework (NIST SP 800-218) practices for corporations providing 78software services to US government agencies, how those agencies use 79Zero Trust (NIST SP 800-207) cloud-computing environments and the CE 80mark requirements for commercial manufactures or importers on the EU 81market.</p> 82 83<p>After giving a summary of the proposed regulations, we'll analyze 84and give recommendations for policies to adopt by hosted projects 85(most projects already have such policies in place). Finally we'll 86give some practical suggestions for specific development practices to 87adopt.</p> 88 89<h3>US Improving the Nation's Cybersecurity Executive Order 14028</h3> 90 91 <p>The 92 <a href="https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity">US 93 Improving the Nation's Cybersecurity Executive Order 14028</a>.</p> 94 95 <p>This is a very broad executive order intended to improve the 96 American peopleâs security and privacy by making the prevention, 97 detection, assessment, and remediation of cyber incidents a top 98 priority of the administration.</p> 99 100 <p>It instructs government agencies to update their contracts with 101 (cloud) service providers so they share security threats and 102 incidents with the federal government through standardized common 103 cybersecurity contractual requirements. Government agencies are 104 instructed to use cloud-computing environments with a 105 <a href="https://csrc.nist.gov/pubs/sp/800/207/final">Zero Trust 106 (NIST SP 800-207)</a> architecture and to adopt multi-factor 107 authentication and encryption of data at rest and in transit. And 108 it provides agencies with guidance for using secure software 109 development environments.</p> 110 111 <p>That guidance includes criteria to evaluate the security 112 practices of government suppliers. Which includes ensuring and 113 attesting, to the extent practicable, to the integrity and 114 provenance of open source software used within any portion of a 115 product. And for government agencies to use Software Bill of 116 Materials to analyze known vulnerabilities in procured products.</p> 117 118 <p>It also establishes a federal Cyber Safety Review Board and has 119 guidelines for improving the Federal Governmentâs Investigative and 120 Remediation Capabilities. <i>note: The current administration has 121 dismissed all members of the Cyber Safety Review Board.</i></p> 122 123 <p>None of this impacts upstream projects directly. But companies 124 doing business with the US government are asked to document how they 125 implement 126 a <a href="https://csrc.nist.gov/pubs/sp/800/218/final">Secure 127 Software Development Framework (NIST SP 800-218)</a>. Which include 128 recommendations about documenting processes for checking the 129 integrity and provenance of sanctioned and vetted open-source 130 components used in their products. And to address any known 131 vulnerabilities in the components they ship. <i>note: A new 132 <a href="https://arstechnica.com/security/2025/06/cybersecurity-take-a-big-hit-in-new-trump-executive-order/">Executive 133 Order</a> issued June 2025 calls for a new (reference) 134 implementation of the SSDF which will supplant SP 800-218 and 135 removes the attestation requirement.</i></p> 136 137<h3 id="eu-cra">EU Cyber Resilience Act (EU CRA)</h3> 138 139 <p>The <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202402847">EU 140 Cyber Resilience Act (EU CRA)</a> on horizontal cybersecurity 141 requirements for products with digital elements.</p> 142 143 <p>This act tries to ensure that products with digital elements 144 placed on the EU market have fewer vulnerabilities and that 145 manufacturers remain responsible for cybersecurity throughout a 146 productâs life cycle.</p> 147 148 <p>The EU member states are currently (November 2024) trying to 149 harmonize the rules for the placing on the market of connected 150 hardware and software products. There will be requirements and 151 obligations for placing products for sale on the EU market by 152 manufacturers or importers. 153 154 <p>This essentially means that commercial goods which contain
155 software need to come with 156 a <a href="https://en.wikipedia.org/wiki/CE_marking">CE mark</a>. A 157 CE mark on commercial products indicate that the manufacturer or 158 importer affirms the goods' conformity with European health, safety, 159 and environmental protection standards. <i>note: The Cyber 160 Resilience Act has been officially published in December 2024, and 161 the main obligations of the CE marking will apply from December 162 2027.</i></p> 163 164 <p>The CRA contains exclusions for activities prior to commercial 165 deployment of the software, individual contributors to upstream 166 projects and charities managing these projects. Including exclusions 167 for operating a hosting service with open repositories, 168 collaboration platforms (like Sourceware) or providing software 169 through package managers (like Cygwin).</p> 170 171 <p>But downstream users who make the software available as a commercial 172 activity will need to pay careful attention to their 173 responsibilities under the CRA as well as to their liabilities to 174 consumers when creating and selling commercial products on the EU 175 market (there are exceptions for manufacturers that qualify as 176 microenterprises or as small enterprises).</p> 177 178 <p>Upstream projects are not seen as manufactures or importers 179 placing products onto the EU market. But some organizations or 180 individuals can still have some responsibilities as "open-source 181 software steward" if they have "the purpose or objective of 182 systematically providing support on a sustained basis for the 183 development of specific products with digital elements, qualifying 184 as free and open-source software and intended for commercial 185 activities, and that ensures the viability of those products".</p> 186 187 <p>Such stewards, who provide sustained support intended for a 188 specific product or support intended for commercial activities, are 189 responsible for providing clear documentation on how to report 190 security issues/patches and promote the sharing of information 191 concerning discovered vulnerabilities within the free and 192 open-source software community.</p> 193 194 <p><i>note:</i> Alexander Sander from the FSFE give a CRA Update 195 <a href="https://bbb.sfconservancy.org/playback/presentation/2.3/babe1c4c9dd3c9a100ec39cd9ce41cba18133d2d-1752767944363">Where 196 are we today, what is next, what to do?</a> for SFC Member Projects 197 on 7/17/2025.</p> 198 199<h3>Recommendations for Sourceware hosted projects</h3> 200 201 <p>Sourceware hosted projects have been doing collaborative secure 202 community development for a quarter century (or longer) 203 already. Some corporations and governments are now catching up. Most 204 of these practices are already second nature to most projects, but 205 not always well documented. So priority one should be to document 206 our existing secure software development practices.</p> 207 208 <p>While documenting the secure software development practices of a 209 project it is important to do this from the view of the active 210 developer community and other free software partners, like direct 211 downstream users, distros and projects that depend on the core 212 toolchain and developer tools.</p> 213 214 <p>The US Executive Order isn't law and it doesn't look like the 215 current administration is interested in moving executive orders from 216 the previous administration forward. The NIST recommendations are 217 written for companies doing business with the US government and for 218 government agencies who want to do their own secure development (in 219 the cloud). They are not practical for describing the secure 220 software development environment of upstream communities. But 221 elements can be used as inspiration. If only because it shows what 222 kind of documentation requests a project might get from companies 223 working with the US government.</p> 224 225 <p>Likewise the EU CRA is mainly aimed at commercial manufacturers 226 and importers placing products on the EU market seeking a CE mark to 227 do so. Manufacturers have an obligations when identifying 228 vulnerabilities in embedded free and open-source software to fix and 229 report such issues to the (upstream) project. And although voluntary, 230 manufacturers integrating free and open-source software components, 231 can also finance or contribute security attestations for upstream 232 projects. So it is beneficial to projects to clearly document 233 contribution and security reporting processes.</p> 234 235 <p>The EU CRA envisions such contributions to free and open-source 236 software projects to be made through "open-source software 237 stewards". We don't believe Sourceware, our hosted projects or the 238 SFC or FSF qualify as "open-source software steward", which is 239 defined as <i>systematically providing support on a sustained basis 240 for the development of specific products with digital elements
241 intended for commercial activities</i>. But even if a project isn't 242 providing sustained support of a specific products for commercial 243 activities, it might still be useful to act like one. Most hosted 244 projects already do everything expected from a "open-source software 245 steward". Document contributor policies, having a way to report 246 security vulnerabilities, and publicly and systematically announce 247 (security) updates.</p> 248 249 <p>Below we list some practical policies projects can adopt (if they 250 don't already) that would help show the project/community follows 251 secure development practices advocated in the above regulations.</p> 252 253<h3 id="policy-checklist">Suggested secure development policies for projects</h3> 254 255 <ul> 256 <li><p>Make sure to have a <code>CONTRIBUTING</code> file or webpage 257 explaining how and where to submit bugs, how and where to submit 258 patches, and which coding standards are used and which testing is 259 expected for contributions.</p></li> 260 <li><p>Document who can review and approve which patches and require 261 at least one reviewer for any non-trivial patch before 262 committing.</p></li> 263 <li><p>Record all review actions in the final commit using tags 264 like <code>Co-Authored-By</code>, <code>Approved-By</code>, <code>Reviewed-By</code>, 265 <code>Tested-By</code>, <code>Acked-by</code> 266 and add links to bugzilla and review threads on 267 <a href="https://inbox.sourceware.org/">inbox.sourceware.org</a>.</p></li> 268 <li><p>When closing a bug because a fix was checked in make sure the 269 exact commit has been added to the bugzilla issue (setup a commit hook 270 to do this).<p></li> 271 <li><p>Encourage signed git commits and store public keys in 272 gitsigur.</p></li> 273 <li><p>When using <code>b4</code> check the DKIM verification of email 274 contributions.</p></li> 275 <li><p>Add a <code>SECURITY</code> file that documents the security 276 policy, what kinds of bugs could be security issues, and which bugs 277 are not considered security issues, and how to report them.</p></li> 278 <li><p>Make sure to have a well documented way (announce list) for 279 new releases and security updates.</p></li> 280 <li><p>Clearly document who the release managers are and which PGP 281 signatures they will be using for official releases.</p></li> 282 <li><p>Have a webpage which list the release schedule and active 283 (supported) releases (and which versions are no longer 284 supported).</p></li> 285 <li><p>Defined a continuous integration (CI) build pipeline on 286 <a href="https://builder.sourceware.org/">builder.sourceware.org</a> 287 for all supported architectures.</p></li> 288 <li><p>Use <a href="https://snapshots.sourceware.org/">snapshots.sourceware.org</a> 289 to define a continuous delivery (CD) service so it is always clear 290 whether the project and documentation are in a releasable 291 state.</p></li> 292 <li><p>Use <a href="https://builder.sourceware.org/">builder.sourceware.org</a> 293 try-bots or a 294 pre-commit <a href="https://patchwork.sourceware.org/">patchwork.sourceware.org</a> 295 bot to check patches before committing.</p></li> 296 <li><p>Also setup automatic build pipelines that use static 297 analyzers (<code>gcc -fanalyzer</code>), hardening flags (<code>gcc 298 -fhardened</code>), sanitizers (<code>gcc -fsanitize=undefined</code>) and 299 run the testsuite under a memory checker like valgrind.</p></li> 300 <li><p>Store test results in bunsen for easy (historical) 301 analysis (and/or have a public testresults mailing list archive).</p></li> 302 <li><p>Make sure your <code>MAINTAINERS</code> file (or equivalent) is up to 303 date. Sourceware admins use that to check who has permission to approve 304 new committer accounts.</p></li> 305 <li><p>Sourceware provides a service to retire inactive accounts 306 (those who haven't pulled or pushed in a year) every 3 months.</p></li> 307 </ul> 308 309<h3 id="eu-cra-reply">Replying to EU CRA information requests</h3> 310 311<p>Corporations are trying to figure out what their responsibilities 312 are as manufacturer under the EU CRA and towards the Free Software 313 projects they are modifying, integrating and redistributing in their 314 products. They might sent requests for help to the upstream 315 projects. Although Sourceware hosted projects aren't vendors or 316 manufacturers this is an opportunity to explain which obligations 317 such corporations have towards the upstream projects and how they 318 can meaningfully contribute.</p> 319 320<p>It is important to set expectations by pointing out that the 321 project itself isn't a vendor or a manufacturer. And so doesn't fall 322 within the scope of the EU CRA regulation. But that as manufacturer 323 they are responsible for the security throughout their product's life 324 cycle. This includes reporting and providing fixes for security issues 325 to the upstream project. Given your project followed 326 the <a href="#policy-checklist">policy checklist</a> you can use the 327 following template:</p> 328 329<hr> 330<blockquote> 331<p>Thanks for your interest in integrating <i>project</i> into your 332 product. Note that <i>project</i> isn't a product and the <i>project</i> 333 community isn't a third party vendor or manufacturer itself.</p> 334 335<p>If you are a commercial manufacturer or importer that wants to put 336 products with digital elements on the EU market, then according to 337 the EU CRA regulation you are responsible for the cybersecurity 338 throughout your product's life cycle. This includes reporting and 339 providing fixes for security issues to the upstream project. Please 340 see <a href="https://sourceware.org/cyber-security-faq.html#eu-cra">https://sourceware.org/cyber-security-faq.html#eu-cra</a> 341 for some recommendations around the EU CRA. 342 343<p>You can find out about the <i>project</i> security policy and how 344 to report issues at <i>URL-to-SECURITY-file</i>. Announcements about 345 new releases and (security) fixes are published 346 at <i>URL-to-announcement-mailing-list</i>. See 347 also <i>URL-to-CONTRIBUTING-file-or-webpage</i> how to follow our 348 secure development practices.</p> 349 350<p>If you would like to financially contribute to the project hosting
351 infrastructure 352 see <a href="https://sourceware.org/donate.html">https://sourceware.org/donate.html</a></p> 353</blockquote> 354<hr> 355 356<p>See also 357the <a href="https://sourceware.org/sourceware-security-vision.html">Sourceware 358infrastructure security vision</a>.</p> 359 360</div> 361</body> 362</html> 363
Line numbers count LF bytes from the start of the resource, as the search results do. Vendor segments are library code the classifier recognised; they are stored but not indexed. Bytes are shown as Latin1 characters, one per byte.