By David A. Wheeler, OpenSSF
In April 2023 the US Cybersecurity and Infrastructure Agency (CISA), along with other government agencies inside and outside the US, released a paper emphasizing software secure-by-design principles and approaches. In October 2023 a significant update was released, now titled Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software. Here we’ll summarize some of its changes.
The October 2023 update has the same overall themes and structure, but greatly expands the details. The original paper was 14 pages; the update is 36 pages. Some of that increase is from formatting changes, but not most of it. As noted in the update, this increase was due to feedback from hundreds of individuals, organizations, and trade associations. It also reflects expanded authorship; the old version listed 10 government organizations (including CISA) as authors, while the new one lists 17 organizations as co-authors. This means the update has a significantly larger set of non-US government organizations as co-authors.
For Software Manufacturers and Corporate Customers
The intended audiences are software manufacturers (who they urge to adhere to its principles) and corporate customers. Among customers, they specifically ask for companies buying software to ask hard questions and for enterprise customers to incorporate these practices into their procurement processes. Their manufacturing focus is really on large software manufacturers. They explicitly acknowledge that “smaller software manufacturers may struggle to implement many of these suggestions”. Some of the specifics may be especially challenging or impractical for developers and users of open source software (OSS) to directly apply, especially in cases where the users don’t pay the developers for the software. Some of the points only apply to software delivered as a finished good, not software intended to be used as a component within delivered software. Still, there are some useful ideas and some approaches that can be applied even in that case.
Secure by Design and Secure by Default
Like the original document, the update emphasizes that software should be:
- Secure by design: Built to protect against attack.
- Secure by default: Be resilient against exploitation without reconfiguration.
In support of these properties, this update continues to advocate three principles:
- Take ownership of customer security outcomes. The burden of security should not fall solely on the customer.
- Embrace radical transparency and accountability.
- Build organizational structure and leadership to achieve these goals.
The update adds more details about how to implement these principles. In fact, the first two have so much material that each is subdivided into 3 major subsections (secure by default practices, secure product development practices, and pro-security business practices). For example, the update adds a discussion about using field tests to observe “how customers deploy and use their products in real-world environments [to gain] insights into the usability and effectiveness of their security features and controls” (see page 15 for more).
The update keeps much of what made the original useful and interesting. For example, it expressly recommends reducing the size of hardening guides. Users often don’t apply hardening guides, users sometimes make mistakes when applying them, and the guides are often expensive to apply. It’s better to make the software secure by default instead.
Improving the Security of OSS
We in the OpenSSF are focused on improving the security of open source software. We’re always interested in learning what others say about securing software, such as their needs and how it could be achieved. This paper provides an interesting perspective from the point-of-view of many governments.
Overall, this is a worthwhile update, especially if you’re a large software manufacturer or a large organization interested in improving the security of the software you buy. It also has useful ideas for any developer or selector of software, though some of its suggestions may be too challenging to apply outside of its primary audience. We encourage those involved in software development or acquisition to take a look at this guidance, especially if you’re in a larger organization.