Why Is Software Supply Chain Security Important?

Supply chain cyber security is so hot right now. According to the ENISA Threat Landscape 2021 report, software supply chain attacks are at #9 of the most common cyberattack vectors. CISA and NIST have issued guidance on Defending Against Software Supply Chain Attacks. And there is a whole section dedicated to enhancing software supply chain security in the United States Executive Order on Improving the Nation’s Cybersecurity.

It may seem not that big of a deal, as software supply chain attacks are in the arsenal of so-called APTs (nation-state sponsored hacker groups) and may not threaten smaller companies. However, this kind of thinking has proven wrong, as the cybercrime gangs embrace the APT’s arsenal day by day.

Alright, what are supply chain cyber security threats, and why do they matter? Briefly, digital supply chain security means trust in software components, products and services your computer systems depend upon. And cyber security supply chain attack exploits some sort of such trust. Software supply chain risk management is all about building and maintaining that trust in a safe manner. Because once a trusted party is a software supply chain is compromised, things go south immediately. I will give you a few examples of software supply chain attacks.

Trust is inevitable in supply chain information security. For instance, we trust our hardware suppliers to an extent, because it is unrealistic to scrutinize all the hardware components we use. This is why a hardware supply chain attack reported by Bloomberg for SuperMicro motherboards, were big news.

Also, we trust our operating systems vendors, as their code is so close to hardware that we cannot do anything with computers without it. This is why the Russian hackers from Nobelium, the authors of the SolarWinds supply chain attack that has compromised a bunch of their clients, Microsoft included, have made the news and continue to specialize in supply chain attacks.

Application software is at the supply chain cyber security risk, too. Although not as stealthy as hardware and operating system bugs, application vulnerabilities could introduce supply chain security threats. Especially if vulnerable applications are widespread and users run them with admin permissions. NotPetya cyberattack is an example: a Russian cyberattack against Ukraine that went out of control, struck thousands of companies worldwide, and caused unprecedented financial damage. And remember those cryptocurrency-mining NPM packages that are in the news almost weekly?

Hardware, firmware, system and application software, software development libraries and frameworks, and cloud infrastructure are not the only areas of cyber security risks in the supply chain. The most subtle and obscure place that demands a security software supply chain with appropriate security controls is a compiler. It is a tool that translates software from human-written code to low-level machine instructions. And there are incredibly clever attacks that hit the spot.

For instance, a recently discovered flaw in several Unicode-supporting compilers allows a malicious developer to introduce a backdoor into a piece of code. Then, another developer down the supply chain could exploit it. Nicholas Boucher and Ross Anderson found the vulnerability, and it affects C, C++, C#, JavaScript, Java, Rust, Go, and Python. The attack variants are already tracked as CVEs, and there is a research paper that describes everything in detail. Of course, as any significant vulnerability these days, it has a cool name and a website – the Trojan Source. I encourage you to visit it and see the attack examples on the front page: it is awe-inspiring.

So, cyber supply chain risks exist because we trust our suppliers. This trust is inevitable nowadays because no organization, with the rare exception of military and intelligence agencies, can afford to verify all the code and equipment they use. Trust, but verify, they say. Is there a classic improvement strategy, such as a supply chain cyber security policy or a supply chain security risk assessment?

But the computer industry is just too complex to verify everything, so what can we do? The Trojan Source example shows that ironically, even an expert’s manual source code review could miss such invisible bugs. Then what about the static analysis tools that could be backdoored similarly? It seems that common supply chain security best practices cannot solve the problem. Is there an efficient strategy for supply chain security risk management? 

I am not sure, but there might be. The fatalistic approach to cybersecurity sometimes looks overdramatic for a simple reason. Many experts measure security by comparing the AS-IS level of protection to a hypothetical, ideal TO-BE vision of the future, usually an industry standard or a set of so-called best practices.

This perspective is kind of simplistic to me; I prefer measuring progress instead of the gap. The “nonconformity” between the present and the desired future may always be non-zero, but what really matters is change and trajectory. In other words, if the security effort leads to change, and if this change is positive, this means we are making progress.

So before diving into software supply chain risk management, first think about why it bothers you at all. Is there a version of the future where everyone trusts each other? Where every human being and organization are absolutely trustworthy? Knowing a bit about human psychology, I strongly doubt that. Then why compare the state of affairs with this unrealistic utopia?

Why instead not make gradual progress by identifying trustworthy supply chain elements – providers, software, and systems – and working on local improvements to preserve and maintain that trust? Yeah, I know; we had a shot at a zero-trust future with Blockchain, and look how well it worked out.

This leads me to a conclusion. Any relationship in this world involves some level of trust. The amount of trust may vary based on cultural differences, but some of it is always there. Any kind of cooperation must verify and maintain trust, and there are ways to do so. In software security, it would be mainly evaluating and mitigating software supply chain security risks.

In other words – carefully applying proven secure and trustworthy tools, components, and practices. But there is no such thing as trust by default: security does not suddenly appear out of nowhere. Only complexity (e.g., insecurity) does so.