CISA, in collaboration with the other Five Eyes cybersecurity authorities (as well as Germany and the Netherlands agencies), just published draft guidance for software companies on secure-by-design and default. The guide, Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and Default, represents a first-of-its-kind collaboration between the agencies to provide specific technical guidance for the production of secure software.

The guidance reinforces the need to integrate security considerations throughout the software development lifecycle and ensure that security is an inherent quality of all software and not just a set of feature capabilities. It also represents a strong push by the cybersecurity agencies to convince software manufacturers to make secure configurations the default for all software and require operators to specifically enable insecure configurations.

Sente Security’s Jarred White breaks down the most important bits below.

1. The publication explicitly calls for product and roadmap tradeoffs in favor of security. In my view, this is a big deal. Specifically, it calls on software manufacturers to “revamp their design and development programs to permit only Secure by Design and Default products to be shipped to customers. It also admits that tradeoffs to the business may be complicated and expensive but says “top business executives” must “make security a business priority.”
2. In one of its most impactful statements, it calls for manufacturers to end the practice of charging extra for security features such as Single Sign On (SSO) and other security configurations and capabilities. It likens the inclusion of security features at no charge to how “seatbelts are included in all new cars.” It will be interesting to see how the industry responds to this one, since the dreaded “SSO tax” and extra costs for security features viewed as premium are commonplace today. In general, the guide suggests that all security features should be made available to customers at no additional cost.
3. While the guide concludes that customer input is important in prioritizing how and when security standards are improved for a given product, “the authoring agencies have observed important cases where customers have been unwilling or unable to adopt improved standards.” It also says it’s important for manufacturers to “create meaningful incentives for customers to stay current and not allow them to remain vulnerable indefinitely.” This addresses a prevalent issue in the software industry where large customers can often influence a company to support their legacy implementations by including weaker algorithms, protocols, and capabilities to ensure backward compatibility. It boldly states that software makers should “prioritize security over backward compatibility, empowering security teams to remove insecure features even if it means causing breaking changes.” This is – so far for the software industry – an unprecedented concept and the impact on roadmaps and product teams could be substantial.
4. The guidance calls for traditional Secure-by-Design activities like threat modeling, SAST and DAST, and Code Reviews for integrating security considerations into the SDLC. But it goes further by suggesting that Software Bill of Materials (SBOM) inclusion becomes a mandatory component of software release. It also urges software manufacturers to double down on CVE completeness to ensure that consumers of software can clearly understand whether a CVE is applicable to their use case in a given scenario. Publishing CVEs is not a new concept for major software producers, but the guidance seems to be honing in specifically on areas of perceived weakness in the current system.

The guidance appears to build on concepts presented in the United States’ National Cybersecurity Strategy document released in March – specifically Pillar III “Shape Market Forces to Drive Security and Resilience” – which represents a broader initiative to require software producers to take greater responsibility for the security of their software and its consequential impacts on their customers’ security.