Government guide for supply chain security: The good, the bad and the ugly

Just as developers and security teams were getting ready to take a breather and fire up the BBQ for the holiday weekend, the U.S.’s most prestigious security agencies (NSA, CISA, and ODNI) dropped a 60+ page recommended practice guide, Securing the Software Supply Chain for Developers.

My first reaction was that it’s great to see these agencies adding to the public discourse in these still heady days where we’re all sorting out software supply chain security best practices. This is an important voice in shaking out the still many requirements, frameworks, and best practices, and kudos to them for sharing some of their hard-fought lessons learned.

But I think it’s also important for developers at large to weigh what makes sense in the most extraordinarily sensitive national security environments, versus what makes sense for the average enterprise developer and security team.

Here’s what stuck out to me as the good, bad, and ugly implications of the report.

The good

There are some excellent, prescriptive recommendations in the report where these agencies are advocating specific frameworks like Supply chain Levels for Software Artifacts (SLSA, pronounced “salsa”) and Secure Software Development Framework (SSDF). The report mentions these frameworks 14 and 38 times, respectively, and for developers and security teams that realize they have a software supply chain security problem but don’t know where to start, now they have a clear path to take their first steps.

The upshot of these frameworks is they give developers clear guidance on (1) how to develop secure code, from design issues to organizational structure issues for more secure software; (2) build system integrity (making sure malicious code isn’t being injected in our build systems); and (3) what happens after software is built and how to operate systems security (vulnerability remediation, monitoring, those types of aspects).

I also think the report does an excellent job of emphasizing what software signing buys developers in terms of artifact security, and how by making the investment in signing and verifying at the start of the software development lifecycle, you can save yourself a lot of toil not having to worry about the security of the package managers further down the line.

The bad

The guide suggests that “all development systems must be restricted to development operations only” … and goes on to say “no other activity such as email should be conducted for business nor personal use.”

I can’t see a future where developers are told they can’t do Slack, email and web browsing on their dev machines, and here’s an example where what’s mandatory in air-gapped environments like the NSA don’t really map out to mainstream developer scenarios.

I also find that the SBOM guidance has great points, but also misses concrete threats and mitigation examples. Overall the industry continues to tell everyone to use SBOMs, but doesn’t really explain what to do with them or what the real benefits are. And while I like the guidance to compare SBOMs with software composition analysis (SCA) results, the reality is that today’s vulnerability scanners actually miss a lot of the transitive dependencies that make software supply chains an attractive threat surface in the first place.

The ugly

While open source is mentioned 31 times in the guide, it’s mostly superficial references, with no new recommendations. We all know most source code being used today is open source, and it has unique aspects for security – the report doesn’t pay any care to how to choose which open source projects to use, what to look for when deciding on a new dependency, approaches to scoring systems, or how to tell the security health of an OSS project.

There’s quite a bit of information overload. Half of the document explains what its contents are, and the other half presents a couple of frameworks and the intersections of those frameworks. I think what we’re going to see next is a tidal wave of security vendor product whitewashing, claiming to have the first capabilities conforming to these guidelines – but it’s important to remember that there is no accreditation process, and most of this will simply be marketing bluster.

What’s next

Software supply chain security is pretty unique – you’ve got a whole lot of different types of attacks that can target a lot of different points in the software lifecycle. You can’t just take one piece of security software, turn it on, and get protected from everything.

Guides and recommendations like this that come down from the most sophisticated organizations that have gone through the early paces give a lot of great clues for developers at large, and I hope the NSA/CSA/ODNI will continue to disclose this type of insight … even if it may require some decoding for what applies to more mainstream developer scenarios outside of the Pentagon.