Response to the Enduring Security Framework (ESF) Guide for Developers

At Snyk we invented developer-first security. We believe involving developers in the practice of security is key to building and running modern applications. This is exactly why the recent publication, Recommended Practices Guide for Developers by the The National Security Agency (NSA), Cybersecurity and Infrastructure Security Agency (CISA), and the Office of the Director of National Intelligence (ODNI) piqued our interest. We were excited to see the government publish such a document and felt the information was good but missed the mark on being a practical guide for developers, especially given this quote in the press release: “The developer holds a critical responsibility to the security of our software.”

The Practice Guide itself covers the right topics around Software Supply Chain Security. It’s broad, covering the need for secure design, comprehensive security testing throughout the software development life cycle, new tools to extract the Software Bill of Materials (SBOMs), emerging threats related to build and development environments, and more. There is some good advice throughout the document.

However, the guide has some flaws that are important to note, in particular its presentation. There are around 27 million developers in the world today, and it’s important to acknowledge the different types of programming languages, tool preferences, and settings that developers write code in. There isn’t one developer persona but many. In my experience, most developers will be unlikely to read a 64-page PDF guide with two full pages of acronyms in the 24-page appendix. And for many developers outside of Government (and for some inside) the overuse of the word “cyber” often marks this as not for them.

Contrast this with documents that have influenced the developer population at large. The Twelve-Factor App (which codified and then influenced modern architectures), the 4 values and 12 principles from Agile Software Development, and the OWASP Top Ten. Maybe more recently the four levels of the SLSA Supply chain Levels for Software Artifacts framework.

Here are just a few suggestions on how to improve future guides such as this when addressing developers.

1. Meet developers where they are.  Developers are curious, savvy, and efficient by nature. Most developers prefer to read documentation via web-friendly formats so they can bring the content into their preferred reading tools. PDFs are nice but rigid and harder to use.

2. Communicate in a developer-friendly way. Too often the challenge for security experts working with developers isn’t knowledge, but communication. It’s the communication challenges (and often misaligned incentives) that lead to the “us vs them” mentality that DevSecOps tries to avoid. As noted, we believe the Practice Guide covers the right topics. But presenting that information in a way developers can follow, like these cheat sheets, would help it have a bigger impact on the target audience.

3. Provide real-life samples. Developers love to tinker and test out new ideas. They want code samples and new tools they can test out and try themselves, just like we provided in the recent PyPl malicious packages blog post. Giving them real-world examples to play with is probably the best way to get them to go beyond just reading some new information and start adopting it.

At Snyk we’re committed to communicating security topics like these in a way we believe is approachable for developers. Here are a few examples; a lesson from Snyk Learn on Threat Modeling and a Cheat Sheet on Secure Code Review, both topics mentioned in the Practice Guide. Watch this blog, and Snyk Learn, for more developer-focused material on Software Supply Chain Security topics coming soon too.