Why Does the NSA Care about the Software Supply Chain?
The release of the National Security Agency (NSA), Cybersecurity and Infrastructure Security Agency (CISA) and the Office of the Director of National Intelligence (DNI), office of the director of national intelligence ODNI, and CISA “Securing the Software Supply Chain for Developers” reflects more of the industry-wide lack of proper security for the supply chain than it does as a working document organizations can use. Given that the NSA is known for spying on U.S. citizens as well as ostensibly nefarious persons of interest — as all world governments with the technological capabilities do as well — the NSA’s and co-agencies’ true motivation for releasing the report might be called into question. After all, one could intuitively guess that it is in the NSA’s interest to not give hostile governments, data thieves and other nefarious actors information about how they can protect themselves from counterintelligence and defenses launched against them while attacking infrastructure in the U.S.
At least, the NSA’s guide helps to show that the U.S. government, including the NSA, CISA and the DNI is aware of the seriousness of supply chain threats both to U.S. interests and the software industry as a whole. It follows President Biden’s May 2021 Executive Order on cybersecurity. It listed supply chain-specific mandates, such as how software supplies must provide software bill of materials (SBOMs) when working with the U.S. government. Supply chain risks especially came to the forefront following the discovery of the Apache Log4j’s Log4Shell vulnerability last year, which will likely remain a problem for years to come. Also, infrastructure forms the bedrock for the U.S.’s largest tech companies that are also increasingly dependent on highly distributed cloud native architectures and for which supply chain security is especially critical.
“Securing the Software Supply Chain for Developers” is at least a step in the right direction. “While there are often some well-founded reservations about the NSA’s motives, the fact is they have made genuine contributions to cybersecurity overall,” Mike Parkin, senior technical engineer at Vulcan Cyber, a provider of SaaS for enterprise cyber-risk remediation, told The New Stack. “While ‘consider the source’ might apply, their advice is usually sound and in line with industry best practices.”
Flaws and Debt
The guidelines do have their flaws. The report states: “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. Over the last few years, these next-generation software supply chain compromises have significantly increased for both open source and commercial software products.” This is not necessarily true. Vulnerabilities in runtime libraries and other sources developers use are often rampant with vulnerabilities that were not proactively injected by attackers.
Attackers are also discovering and exploiting vulnerabilities once applications have been deployed upon discovery of the vulnerabilities that did, however, originate from bad early in the supply chain. In many cases, attack vectors are accessible because well-known and potential attack vectors are left exposed after commercial vendors fail to release patches or when users do not apply the patches. The NSA’s guidelines are just that, guidelines that just outline and scratch the surface of supply chain security as they do not address the nuances of rampant vulnerabilities, and especially, false positives in code originating from libraries and other sources from outside of the organization.
“You still come around to the opportunity cost of tech debt. All products have tech debt consisting of unpatched vulnerabilities in your dependencies. It comes down to an interesting discussion on what your definition of false positives is because if anyone goes to engineering and says you have 10 exploitable vulnerabilities in your codebase, they’re going to go ‘holy crap’ and fix it right away,” Thomas Owen, chief information security officer for Grafana Labs told The New Stack. “If you go to an engineer and say you have an unreachable vulnerability in a library that isn’t used by the application on a container that you ship, they might say ‘thank you very much. I will get to that at some point’ in the indefinite future.”
Still, the NSA’s guidelines reflect how the industry is moving towards realizing, discussing and hopefully commoditizing tools and processes to one day make the supply chain at least reasonably secure. At the same time, SBOMs, as well as other supply chain verification tools and processes such as supply chain levels for software artifacts (SLSA), signature-checking processes and other options remain very nascent and are just beginning to be implemented on a wide scale. “The NSA guidelines do not really provide solutions. The problem is technological and cultural,” Owen said. “The very long government report won’t change the majority of cultures.”
Developer Centric
The NSA guidelines are ostensibly aligned with the role of developers who might loathe the thought of security teams slowing down the cadence of their deployments. They are also typically the first stakeholders to make pull requests with at least some code ones gleaned from third-party libraries, and hence are on the front lines of supply chain risks.
The NSA’s “guidance for developers illustrates a change in mindset for development teams. Rather than focusing on hard requirements, it expresses security issues in terms of risk elements and mitigations. While that change in vernacular will eventually benefit the software development industry, in the near term it’s likely to be met with some resistance. One way organizations can accelerate the change is to look at each section as a template for a threat model on how their teams produce software,” Tim Mackey, principal security strategist at the Synopsys Cybersecurity Research Center, told The New Stack. “Over the course of the last several years, we’ve seen a number of new attacks that target how software is created or deployed. By identifying weaknesses in processes or assumptions that might facilitate attacks, development teams can resolve them before a successful attack occurs and they’re forced to delay features while responding to a cyber incident.”
Progress is also being made. “Vendors are starting to make SBOMs for their software available to procurement teams and the topic of application security is now front of mind for business leaders. That being said, these guidelines aren’t hard requirements because hard requirements only exist when there is context,” Mackey said. “For example, the security requirements for software will vary based on if it’s deployed in a home setting, a bank or a power plant. That context impacts the risk assessment for the software as the outcome of a cyberattack could be very different in each of those scenarios.”
