Just in case you missed it, the NSA, CISA and ODNI dropped a 60+ page recommended practice guide--Securing the Software Supply Chain for Developers--right before Labor Day Weekend in the US.
I think we're in a moment that's eerily reminiscent of early days Internet security standards and best practices, where government, vendors and standards bodies all came together to advance a common interest. Today we’re seeing this same type of private / public collaboration to solve this software supply chain security challenge that faces every industry.
In no particular order, here's what jumped out to me when I read the report:
1. SLSA and SSDF got a lot of love (mentioned 14 and 38 times respectively). Developers are hungry for the sort of guardrails that these frameworks provide in giving clear steps on how to lock down the software supply chain.
2. The stringency of the government's security is clearly on another level than mainstream enterprise. Your average developer is going to be incredulous at the guidance, for example, that "all development systems must be restricted to development operations only" and that "no other activity such as email should be conducted for business nor personal use." While these agencies have awesome experience and a wealth of knowledge to share, there are major differences between government and private security practices.
3. SBOM guidance continues to be underwhelming. It feels like government agencies keep underscoring the importance of SBOMs and the inevitability of their standardization - but where are the concrete threat and mitigation examples? The guidance to compare SBOMs to software composition analysis results also glosses over the fact that SCAs miss a lot of the transitive dependency- types of vulnerabilities that make software supply chain security a unique domain in the first place.
4. Where is the open source discussion? It's mentioned a number of times in the guidance, but it really doesn't get into the specifics of what developers should look for when deciding on new dependencies, how to evaluate the health of OSS projects, and the like. A developer's guide to supply chain security should really hyper focus on the OSS domain, and that felt like an odd omission (maybe there are some cool new findings around the corner though--would love to hear what these agencies' thought process is around OSS project security evaluation).
5. I'd like to see more guidance around software signing in the next version of this developer's guide. Sigstore is becoming the official software signing solution for just about every major platform (Kubernetes) and programming language registry (Python/PyPi | Java/Maven | Javascript/npm). Some guidance about what software signing is and where frameworks like Sigstore fit in these agencies' outlook on software artifact integrity is another double-click I'm hoping to see the next time around.
I wrote more about this topic over on Help Net Security if you want to read further. And as I concluded there, kudos to these super secretive government agencies for having the foresight to share their knowledge and lessons learned, so we get the "all boats rise" effect going as industry / vendors / standards bodies keep closing in on solving this very complicated security domain.
