We are now awash in necessary reminders: Secure your software supply chain!
You can’t say you haven’t been warned about software supply chain attacks. You also can’t say nobody gave you any advice on how to make your organization more resistant to them.
Because we are now awash in warnings and advice about them.
That’s a good thing. As cyber criminals have demonstrated far too many times in recent years, instead of hacking organizations one at a time, it can be much easier and more profitable to launch a single attack on an organization that supplies many others — sometimes tens of thousands or even millions — and let the supply chain do the work of attacking all of them.
President Joe Biden put the issue in the national spotlight more than a year ago by including mandates on software supply chain security in his Executive Order (EO) on Improving the Nation’s Cybersecurity, issued May 12, 2021. That’s been followed by multiple advisories from both public and private organizations.
The latest, Securing the Software Supply Chain, from the Enduring Security Framework (ESF) — a public/private cross-sector working group led by the National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA) — dropped a couple of weeks ago. It’s the first of three guidance documents on the topic from the ESF and is focused on security practices for developers. The next two will focus on suppliers and customers.
This latest guidance doesn’t break any major new ground. Its advice depends on (and credits) multiple organizations in both the public and private sectors that have released similar recommendations in the past. They include the Synopsys Software Integrity Group, the National Institute of Standards and Technology, the Open Web Application Security Project, Cisco, Carnegie Mellon University, the Association for Computing Machinery (ACM), the Computer Emergency Readiness Team (US-CERT), and OpenSSF.
Emile Monette, director of government contracts and value chain security with the Synopsys Software Integrity Group, agrees that there is “not much new” from ESF.
Necessary reminders
But he said it’s not a bad thing to be reminded to do the basics: Write secure code. Test it in multiple ways. Keep track of software components from other sources, whether they’re commercial or open source, and make sure they remain secure by installing necessary patches or updates.
“It’s nice to see ESF in particular picking up the good guidance that has been out for a while,” he said. “As we know, government generally lags behind the private sector in cyber, so while this doesn’t necessarily affect that lag, it’s another important voice in the government sector saying the right things.”
Unfortunately, it’s also still necessary. President Biden’s EO was in part a response to the catastrophic SolarWinds/Orion supply chain attack in 2021 that spread malware via a corrupted software update to at least 100 organizations plus multiple federal agencies including the departments of Homeland Security, State, Justice, Commerce and Treasury, plus NASA, the FAA, National Institutes of Health and National Nuclear Security Administration.
This, at a time when supply chain security basics ought to be mainstream. Software, made by imperfect humans, has never been perfect. Its defects have been exploited by cybercriminals since the digital world began.
So when it comes to the software supply chain, we all ought to know that one of the oldest clichés in history applies: A chain is only as strong as its weakest link. And if you don’t know about all the links in your chain — where they came from, who made them, and who is maintaining them (or not maintaining them), you’re asking for trouble. Because the bad guys are keeping track, in hopes that you won’t.
In many cases, the bad guys are skilled enough to be able to find vulnerabilities that nobody else knows about — so-called “zero days.” According to the ESF, “Rather than waiting for public vulnerability disclosures, threat actors proactively inject malicious code into products that are then legitimately distributed downstream through the global supply chain.”
So it should also be obvious that it’s crucial for any organization that makes a product to vet the suppliers of that product’s components for quality, safety, and security. And to keep track of those components — imagine the public ridicule, not to mention legal jeopardy, that would come down on a car company that didn’t fix or replace faulty airbags because it didn’t know what vendor supplied them.
Drop an SBOM on it
In fairness, it can be vastly more complicated to keep track of every software component in a codebase than it is to track physical objects. Virtually all software products rely on other software components, called dependencies, that go multiple levels deep.
Tim Mackey, principal security strategist within the Synopsys Cybersecurity Research Center, has used a simple Slack application with an Instagram interface as an example.
In a recent webinar, he noted that the app included eight declared dependencies, one of which originated from Slack itself, called Bolt. But Bolt has 15 dependencies of its own. One of those, called Express, has another 30. “When you peel back the onion on this, Slack/Bolt actually has 133 separate components in it,” Mackey said.
That’s 16 times the eight declared dependencies of just one app. And given that most organizations have hundreds to thousands of apps, it illustrates how complex and unwieldy tracking a software supply chain can be.
But it can be done. While collecting and maintaining all that information would be impossible manually, automated tools like software composition analysis can help find open source and third-party components in codebases as well as help to create a software Bill of Materials (SBOM).
And SBOMs are on their way to becoming mandatory. If the directives in the Biden executive order become reality, within a couple of years federal agencies won’t be allowed to buy software products that don’t come with an SBOM.
SBOMs aren’t the only guidance from the ESF. While the document goes into considerable detail — it’s 60 pages including appendices and includes several recommended mitigations for every potential vulnerability or risk — the focus is on developers so the major topics in the guidance are centered on the software development lifecycle (SDLC). Those topics are
- Develop secure code. That includes testing it in multiple ways with automated tools, managing the risks of open source software components, and minimizing the chance of exploitation (inadvertent or otherwise) of source code by insiders.
- Verify third-party components. This includes creating and maintaining SBOMs for all software products.
- Harden the build environment. This goes for both on-premises and cloud environments, which both need “the same [security] rigor and discipline” to keep threat actors from infiltrating the development network. That could mean malware injected into a codebase as it’s being built.
- Deliver code. Which means deliver secure code by making sure neither it nor its distribution system have been corrupted by an attacker.
How likely is it that such recommendations — and they are just recommendations, not mandates — will become mainstream?
“It depends,” Monette said. “Size, scale, and customer base all affect business decisions about whether to do or not do these kinds of things. The market of software assurance providers, tools, etc., is still growing and there’s a lot more growth and innovation that will happen as attention on software supply chain risk management continues.”
