SOFTWARE SUPPLY CHAIN
Four takeaways from the NSA's software supply chain security recommendations
September 10, 2022
In late August, the Enduring Security Framework ("ESF")—an externally-facing communications program of the National Security Agency—published a guidance document for securing the software supply chain. Unfortunately, while the document was heavy on application security activities, it was light on useful software supply chain security guidance. We list key takeaways and important items that are missing.
In late August, the Enduring Security Framework ("ESF")—an externally-facing communications program of the National Security Agency—published a guidance document for securing the software supply chain. This publication, the first of a three-part series, is directed at software developers. Subsequent publications will focus on software suppliers and customers.
This is a guidance document provided for general informational purposes. This means the document is advisory in nature and does not carry a legal / regulatory obligation. For it to carry that kind of obligation congress would have needed to pass a new law or the agency would have been required to undergo a public comment period. Unfortunately, this guidance would have benefited from a public comment period as it ignores many hard-learned lessons (more on that later).
Bottom line: you are not legally bound to adhere to the document’s recommendations.
Much of the guidance centers on having an application security program. Many so-called supply chain attacks such as Log4Shell, Heartbleed, and java deserialization attacks work by exploiting vulnerabilities in third party code. These aren’t attacks against the supply chain itself. By integrating vulnerable components, developers turn their software (by way of the software supply chain) into an attack vector that can be used against their customers. If those third-party components weren't vulnerable to begin with—if the developers of the third-party components had an application security program that prevented them—the attacks could never have happened.
The biggest concern that I have with this section—and the document as a whole—is how rigid its guidance is for SDLC elements:
"The process starts when the supplier’s program management team collects feature requests from their customer’s user-base, technical base, and marketing teams. These features include both operational and security enhancements to the product and are used to generate use cases that are then formulated into prioritized requirements. The supplier and developer management teams work together to define the requirements that are used to produce the architecture and high-level design which a development team uses to produce a product. In addition, the combined management team defines the product development security policies and practices that are used when producing the product."
Anyone seriously interested in taking these recommendations to heart would have to:
What you’re left with is a software development lifecycle that looks a lot more like the largely obsolete waterfall methodology. It is important for software development organizations to have an application security program, but the ESF seems misguided in what these programs look like in the industry.
Software supply chain security is a field rich with different problems to solve and novel solutions. SBOMs (Software Bills of Material) are one such solution, but a lot of security pros stop there and think they are done. This misses things like overly permissive development permissions, secrets incorrectly stored in source code and many other risks an organization should also track. It’s rather like when network security was young, and people thought they could pen test and patch their way to a secure network.
That said, the ESF’s document helps expand the conversation by addressing topics such as:
Lots.
As mentioned above, the ESF recommends a nearly comprehensive software security program. The only common practice not recommended is having a metrics program. Perhaps if you find that following the recommended secure design practices, reinforced with recommended threat modeling, and you adhere to the recommended secure coding practices then you'll find that you aren't getting a lot of value out of at least some of the recommended SAST and DAST and IAST and RASP and penetration testing and red teaming AND secure quality analysis AND fuzzing AND black box testing, AND software composition analysis.
Everyone who depends on software wants the developers of that software to do all they can to produce secure software. But development organizations of limited means—a category which includes every organization except the NSA, curiously—must make resource allocation decisions that don’t always put security first. Otherwise, they lose out in areas that customers care about just as much if not more, like user experience, time-to-market, and feature set.
Also, the guidance leaves out several software supply chain security activities that development organizations must be responsible for: detection of anomalous developer behavior, scanning for hardcoded secrets, and maintaining minimal access to code come immediately to mind. Much of what guidance they do have is antiquated pseudo-security, such as this advice on securing development environments:
“In addition, all development systems must be restricted to development operations only. No other activity such as email should be conducted for business nor personal use. If possible development systems should not have access to the Internet and may be deployed as local virtual systems with host-only access.”
This guidance ignores decades of hard lessons that enterprise security had to learn to avoid becoming the dreaded “Department of No.” Developers need internet access to do their jobs effectively. We’re developing in the cloud now, as I’m sure some part of the NSA knows. You can’t develop for the cloud in such an environment, much less in it. If you take away internet access on their workstations, developers will use workarounds that will expose you to greater risk.
Ultimately, the ESF’s guidance is a set of already outdated solutions to a set of problems of breathtaking size and scale. We appreciate the attention paid to software supply chain security and the visibility raised, but at Arnica we are working on advanced, frictionless solutions instead of air-gapped development environments and inefficient approval processes.
.png)