New federal guidance codifies lessons from the SolarWinds hack, including for securing third-party code and development pipelines. A software bill of materials (SBOM) is central. Here are four key takeaways.
The U.S. Federal Government dropped what may be its most significant statement on software supply chain security — on the eve of the last holiday weekend of summer, a time associated more with family barbecues or beach parties than software build processes.
The guidance, in the form of a document titled "Securing the Software Supply Chain" (PDF document), was released last week. The report was created by the Enduring Security Framework (ESF) Software Supply Chain Working Panel, comprising representatives from the National Security Agency (NSA), the Cybersecurity and Infrastructure Security Agency (CISA) and the Office for the Director of National Intelligence (ODNI). It is intended as a “compendium of suggested practices for developers, suppliers, and customer stakeholders” to help ensure a more secure software supply chain.
The new guidance weighs in at 64 pages — a hefty tome intended to set the record straight on secure development processes. "Securing the Software Supply Chain" is a must-read for software development organizations concerned about threats to their software development process, including open source risk and sophisticated, SolarWinds-style tampering attacks.
The new guidelines are a kind of roadmap to building a healthy software development environment, said Tomislav Peričin, co-founder and chief software architect for ReversingLabs. That map includes a Software Bill of Materials (SBOM) for describing the components of software, active monitoring for vulnerabilities and software supply chain attacks, and a secure build environment and development team, he said.
Here are four key takeaways from the report's recommended practices for development teams.
[ Get a free SBOM and full supply chain risk analysis report | Plus: Matthew Rose explains the ESF guidelines in ConversingLabs ]
1. Focus on software supply chain risk
The new recommended practices are a continuation of the U.S. Federal Government’s heightened focus on supply chain risk, especially following the notorious hack of the SolarWinds Orion software in 2020. A key goal of the practices guide is to highlight supply chain risk as a priority for both software development organizations and consumers, and to re-orient security resources accordingly. As the document notes, organizations traditionally manage software supply chain activities separately from downloads, but a new generation of less conspicuous attacks looks to blur those lines: injecting malicious code into products that are then passed downstream and consumed by other development organizations or end users in the global software supply chain.
This shift in tactics warrants a similar shift by software publishers and defenders. As we noted in our recent analysis of the National Vulnerability Database (NVD), that’s still a work in progress. With vulnerabilities like Log4J, for example, it's clear that the risk profiles of open source modules and CI/CD platforms are gaining attention and driving more submissions to the NVD. But progress is slow. The NVD, for example, still does not enlist prominent source code platforms and application providers as CVE Numbering Authorities (CNAs) to better capture supply chain vulnerabilities such as those in open source repositories, development tools, and platforms.
That’s a long-winded way of observing that the guide succeeds in what might be its most important goal: highlighting the supply chain cyber risk, while also providing something like a roadmap for development organizations to improve defenses against supply chain threats and attacks.
2. A software supply chain security Rosetta Stone is born
Another big accomplishment of the supply chain guide is in its function as a “compendium.” In fact, the document functions as a kind of Rosetta Stone for supply chain security: pulling together a wealth of public and private sector guidance on secure development and supply chain security practices and then correlating their recommendations.
The guide compiles a wide range of sources on topics such as secure development lifecycle (SDLC) and creating SBOMs. Tables correlate recommended security mitigations with critical resources like NIST SP 800-218 “Secure Software Development Framework (SSDF),” while appendices spell out recommendations pertaining to developers, suppliers and customers and match them up to government and private sector frameworks like SSDF and Supply Chain Levels for Software Artifacts, or SLSA.
These days, software development is a ubiquitous activity and resources for doing secure development are likewise spread far and wide. The new guidelines provide a great resource and starting point for anyone looking to level up their software development and software supply chain security.
3. Bet big on binary analysis
Another major achievement of the guide is focusing attention in an area that is often overlooked: the threat posed by malicious binaries that can corrupt otherwise secure software supply chains. The guide notes that source code analysis can provide much needed attention to the security of uncompiled source code as well as open source components. However, organizations that rely on third-party software modules that have already been compiled are, in essence, counting on security “black boxes” that obscure risks from the development team or organization using them.
Accordingly, the guide makes a strong recommendation in Section 2.3 that development organizations employ binary scanning and software composition analysis (SCA) tools that are capable of detecting unknown files and open source components (and their associated security weaknesses) hiding within compiled binary packages. In the early planning and assessment stages, these tools can reveal possible threats — such as vulnerabilities or possibly compromised open source components — that a third party module may bring with it. That kind of information can then inform decisions about whether to use a given module.
For modules that are already part of the software supply chain, such scans can be matched up with SBOMs for source code — provided by the supplier — so that development teams can ensure that delivered code is consistent with what the supplier has attested to.
4. Secure your software development process
Another major accomplishment of the guide is its focus on the security of both developers and the development environment. Section 2.2 of the document, Develop Secure Code, contains recommendations for development organizations, including vigilance for developer-centric threats. Those include commonplace “ease of development” features like temporary “back doors” that find their way into production code as well as the myriad risks posed by poorly trained software engineers. The document also weighs in on more subtle (but dangerous) risks such as malicious insiders, rogue developers and compromised development systems.
Attention has been given to hardening software development environments to encompass the modularized nature of IDEs, which became the de facto standard with the advent of code editors such as Visual Studio. Having build provenance data matters far less, for example, when the environment in which software is developed can not be audited and trusted. The guidelines rightly identify IDE plugins and scripts as a huge attack surface that goes unchecked by most development organizations. That needs to change, as looking at software supply chain risk only through the lens of vulnerabilities risks overlooking a wide range of other exposures and cyber risks.
The guide's recommendations to address these risks are straightforward. Development organizations are encouraged to conduct automated static and dynamic testing of newly checked-in code to look for vulnerabilities, and to take the time to map newly created code back to clearly identified features and to implement authenticated code check-ins to guard against compromised development systems. Critical code — such as requiring elevated privileges, accessing sensitive resources or using or implementing cryptographic functions — should be subject to reviews and given a high priority.
For developer systems, the report recommends implementation of strong, multi-factor authentication and virtual private networks (VPN), as well as continuous monitoring of developer systems. Peričin said the guide should help deliver the transparency that is needed to achieve better software supply chain security.
"The forward-looking aspects like reproducible builds, SBOM unknowns, IDE ecosystem security, and least privilege as the default, should be openly welcomed by both software producers and consumers. Transparency required to make this process work seamlessly for the software consumer is a huge win for all security minded organizations.”
—Tomislav Peričin
Guidance is good, but surging software risk demands more
The Securing the Software Supply Chain practices guidelines are a welcome and timely addition to the federal government’s fast-evolving library of secure development and supply chain security resources. More than previous publications, it captures the complexity of the software supply chain problem, which encompasses everything from secure development practices, to the security of open source and third party code and threats that target developers, developer organizations and development tools and platforms.
As the press release for the report notes:
"As the cyber threat continues to become more sophisticated, adversaries have begun to attack the software supply chain, rather than rely on publicly know vulnerabilities. This supply chain compromise allows malicious actors to move throughout networks seemingly undetected. In order to counter this threat, the cybersecurity community needs to focus on securing the software development lifecycle."
But, like any other guidelines, guidelines are only useful to those development organizations that read them and expend the time, money and human resources needed to implement their recommendations. For everyone else, the ESF Practice Guidelines are just another document languishing on a government website.
That’s why the next steps taken by U.S. Government agencies needs to be of the “carrot and stick” variety. Development organizations must have tangible incentives to shift practices in ways that the guidance suggests. Investments in technologies like source code analysis, binary scanning, SBOM generation, and hardening of development organizations constitute major changes for many (especially smaller) development organizations — and won’t happen simply because new guidance has been released.
Strong market and regulatory incentives to embrace secure development practices — along the lines of those in Executive Order 14028 on Improving the Nation's Cybersecurity — are necessary to turn the solid recommendations and guidance into tangible improvements in the security of deployed software and services.
ConversingLabs episode explains the new ESF guidelines
