NSA Software Supply Chain Guidance

First things first. The National Security Agency (NSA) isn’t just breaking into other people’s communications. The NSA is also all about protecting communications from snoopers. So, it is that the NSA made the original secure Linux (SELinux); has written guidelines on how to secure video conferencing, text chatting, and collaboration tools; and now explains how to harden Kubernetes against attackers. And, now, along with the Cybersecurity and Infrastructure Security Agency (CISA) and the Office of the Director of National Intelligence (DNI), they’re working on securing the software supply chain.

Why? Because we’ve been getting our noses rubbed into the sad, simple fact that our software supply chain security is as strong as Swiss cheese. Numerous high-profile attacks, breaches, and exploits, such as the SolarWinds fiasco and the Log4J vulnerability, have made it clear we must improve its security. When it got so bad, President Joseph Biden issued an executive order calling for us to all secure the software supply chain, you know stuff has gotten serious.

Not Just Unpatched Holes

Historically, software supply chain attacks were made on unpatched security holes in released programs. This still happens every day.  But, in the last few years, the source code software supply and patching systems themselves are being compromised. These next-generation software supply chain compromises attack both open source and commercial software products.

So, the NSA and friends have released Securing the Software Supply Chain for Developers. The Enduring Security Framework (ESF) wrote this report This public-private working group provides security guidance addressing high-priority threats to the nation’s critical infrastructure.

Specifically, it brings together the resources and best practices developers need to secure their software. Looking ahead, the ESF will be releasing a similar document for software suppliers and customers. Developers alone can’t secure our software chain. Everyone needs to help.

These new attacks commonly include exploitation of software design flaws, incorporation of vulnerable third-party components, infiltration of the supplier’s network with malicious code prior to software delivery, and injection of malicious code that is then deployed by the customer. Fixing this isn’t easy. Securing the software development lifecycle is a process, not a product.

It’s also a tremendous amount of work. To quote from the report, “Security training for the development team is ideally conducted by a centralized, expert security team who can help product teams grow their expertise in secure development.” Does your company have such security experts who are also programming savvy? I’ll answer that question for you: Chances are you don’t. Few businesses do.

Recommendations

The report also supports top-down security management. With 40+ years in computing behind me, I can safely say it seldom works well.

On the other hand, they also recommend using automated tools to help make it easier for developers to secure their software development chain. I highly recommend this. It’s far easier to use shift-left security software processes such as Supply-Chain Levels for Software Artifacts (SLSA, pronounced “salsa”); Software Package Data Exchange (SPDX)/Software Bill of Materials (SBOM); and Static Application Security Testing (SAST) and Interactive Application Security Testing (IAST) to secure programs than to train up developers to be security experts as well.

One way or the other, though, we must secure our software supply chains. We can’t afford many more security disasters.