The NSA and CISA released the guide “Securing the Software Supply Chain: Recommended Practices Guide for Developers” last month and while David Wheeler, the director of open-source supply chain security at the Linux Foundation and OpenSS, welcomes it, he said there are some questionable requirements.
The guide covers aspects of security such as how to develop secure code, how to verify third-party components, and how to harden the build environment, among other things. It’s also part of the government’s effort to bolster supply chain security stemming from last year’s Executive Order, which aims to curb the 650% growth in supply chain attacks, according to Sonatype’s 2021 State of the Software Supply Chain.
The guide encourages developers to take regular and relevant security training and that they should be evaluated periodically, at least annually. The security training for the development team is ideally conducted by a centralized, expert security team that can help product teams grow their expertise in secure development.
One issue Wheeler finds is that the report assumes that all software is developed by large software development teams, but the reality is that it’s not true for all industries.
“They’re making all these assumptions about multiple reviews on large teams. And that’s assuming that there’s some sort of internal computer network,” Wheeler said. “For a lot of organizations, that doesn’t exist. And in fact, it’s moved towards zero trust to move away from trust in an internal network. And so they’re kind of making old school assumptions or whatever they get old, you’ll see that again, and again, they are making some really unreasonable development environment requirements.”
Wheeler said that there also seems to be a lack of understanding about open-source security (OSS).
“The term commercial item by definition includes open-source software, and yet they talk about commercial as though it’s not the same as open source software,” Wheeler said.
Lastly, there doesn’t seem to be any adequate industry interaction or public review for a draft during the creation of the guidance, according to Wheeler.
“Most software expertise is outside the U.S. government, not in it, as that’s where most software development is today. The document has many other problems, which in part stem from inadequate public review,” Wheeler said.
Wheeler is adamant that the education system and software supply chain needs to do better in teaching developers the basic fundamentals of designing software with security in mind, and welcomes the fact that the guide provides some guidance targeted at developers.
“Historically, the U.S. government is kind of famous for spending a lot of effort on trying to configure insecure software and somehow magically transform it into secure software. That hasn’t worked,” Wheeler said. “With this, I’m really glad that they’re putting in guidance for developers.”
Wheeler appreciates that the guide is encouraging developers to use design principles from the Saltzer & Schroeder list, that have withstood the test of time. The Saltzer & Schroeder list is a set of eight design principles for secure computer systems. The principles are named after their creators, Jerome H. Saltzer and Michael D. Schroeder, who published them in 1974.
He added that developers should at least know what the most common kinds of vulnerabilities are, including the CWE Top 25 and OWASP Top 10, and know the major kinds of security tools and how to apply them. Developers should know that they need to do “negative testing” and to understand the importance of high-coverage automated testing.
They should also know how to evaluate OSS, how to use tools like package managers to automate their management. Lastly, they should focus on protecting their environments and to start using MFA tokens that stop many attacks.
