Deploying Open Source Software in an Age of Global Security Mandates
Discover tightened global software security, key regulations, and open-source impacts on compliance and societal resilience.
Governments wield new regulations in the ever-changing landscape of software security. Luis Villa, co-founder and general counsel at Tidelift, delves into the implications for organizations reliant on open source. Understand the why and how behind the upcoming changes.
Ensuring the open source code your organization relies on is secure and healthy has long been a good idea, but increasingly, software security standards are being mandated by government requirements, with a growing web of international regulations and enforcement mechanisms. This article will survey some of the most important new requirements and their impact on organizations that use open source.
In recent years, governments have become increasingly aware that poor software security can have massive societal impacts. As a result, the US and EU are increasingly turning to actively regulating software design and implementation. It’s now critical for software executives—up to and including C-levels—to start understanding the implications of these new obligations so their organizations are prepared and compliant.
The Big Two: CRA and Executive Order 14028
White House Executive Order 14028 in the US (US EO) and the Cyber Resilience Act in the EU (EU CRA) are the two most important new regulatory actions that will start having a real impact this year and next.
Executive Order 14028 was originally issued by the Biden White House in 2021, but (as is common for something this complex) it has taken time for the executive branch to turn its high-level guidance into explicit requirements. Critically, because it is an executive order rather than a law passed by Congress, the reach of the EO is somewhat limited—it can direct the government to issue guidance. Still, that guidance is only mandatory for vendors selling software directly to the government. Still, because the US government is the world’s largest purchaser of commercial software, setting a higher security bar for software sold to the government will raise the bar for software security overall, which is part of the intent.
The CRA, in contrast, is an act of the European Parliament, and so must be implemented across the EU by all vendors who make “products with digital elements” “available to the market”—in other words, vast swathes of modern industrial output. However, like Executive Order 14028, it will also pass through a long implementation period to develop various required standards and be implemented into law in each EU country.
1. Key requirements
The US Executive Order’s forthcoming requirements are all rooted in the Secure Software Development Framework, a sixteen-page list of best practices from the National Institutes of Standards and Technology (NIST). These practices cover (in briefest form) organizational practices, software protection, software production, and vulnerability response.
These best practices are now being translated into requirements for vendors selling software to the US government. Two primary vectors for these requirements, so far, are:
- The Federal Acquisition Regulatory Council’s proposed FAR 52.239-ZZ covers the reporting of security problems and will be required for all software procured by the government.
- The Cybersecurity and Infrastructure Security Agency’s (CISA) forthcoming Secure Software Development Self-Attestation Form. This can be seen as tackling the production of good software and will be required for all software “used” by the government (with some exceptions). There are also likely to be future CISA auditing requirements for high-risk software, which will move past self-attestation and into third-party verification. There may be future requirements around securing software “by design.”
The EU CRA’s requirements are not as far along since it was only finalized in the fall of 2023. However, the requirements will be much more sweeping when complete and implemented (in 2027). In particular, all software products or products that contain software will be required to conduct audits of their software development processes. For high-risk products, those audits must be conducted by a third-party auditor.
2. Knowns
A variety of common themes run through both sets of requirements. Most critically:
- Security is no longer an optional add-on once products are done; it must be baked into the software’s design and the processes that produce the software, and governments will attempt to verify this. This will include (among other things) audits, red-teaming, and automated scanning for known vulnerabilities.
- Vendors must know what code is in their software. This requirement (sometimes short-handed as “SBOM” for Software Bill of Materials) is the basis for everything else in the EO and the CRA because you can’t remedy problems if you don’t know what’s in your software.
3. Interaction with open source
In today’s enterprise, over 90% of applications contain open-source components; in many cases, open-source makes up more than 70% of the code base. As a result, any new regulation on software as a whole must consider open-source software. However, because money only sometimes flows from buyers into the hands of open-source maintainers, the impact of these regulations on software doesn’t necessarily follow the predictable mechanisms that regulators are used to. As a result, all software creators will have to learn some new patterns.
Most open-source projects are not directly affected because the US Executive Order only directly impacts government vendors. However, the NIST Secure Software Development Framework’s requirements for provenance and security tooling will require vendors to understand the open source they are using. It may require a certain level of attestation that open projects used by a commercial vendor are developed securely.
The relationship between the CRA and open source was the subject of protracted negotiation between the software industry, the open source community, and the European Commission. This resulted in steward,” which allows a genuinely non-profit, pro-community organization to be exempted from some of the CRA’s requirements. However, there will still be many touchpoints with open source. In particular, it is interesting that the CRA will require vendors who create a security patch to submit it upstream to open-source projects—perhaps the first government mandate for the open-source contribution!
4. Unknowns
There remain many unknowns in both requirements.
For example, in the US, both CISA and the FAR Council are still processing consultations conducted in late 2023, which will help shape the final self-attestation forms and FAR requirements. These details will be critical—for example, CISA has not yet assessed whether the attestation requirements apply to open source.
In the EU, many requirements, including the form of audits and the nature of national-level enforcement, remain in the air and will be the subject of fierce negotiation. It will be interesting to see to what extent the open source community is invited to the table or whether there will be a last-minute scramble to “fix” broken requirements—as there was for the CRA itself.
With dozens of pages of new requirements, we’re only beginning to understand the brave new world of software security regulation. However, we know it is now inevitable—and will require all software vendors in the EU, and many in the US, to deeply understand the open source they are using. Hopefully, it will also help us realize the intended outcome: improving the security of the software we depend on.
How can the evolving software security landscape affect organizations? Why is open-source understanding crucial? Let us know on Facebook, X, and LinkedIn. We’d love to hear from you!
Image Source: Shutterstock
MORE ON SOFTWARE SECURITY STANDARDS
