Software Supply Chain Attacks: The NCSC and the NCSC Concur That They Are A Major Risk in our World

Software Supply Chain Attacks: The NCSC and the NCSC Concur That They Are A Major Risk in our World

Did you know that there are two NCSC’s in the World, and both of them highlight the risks of the software supply chain? In the US, the NCSC (National Counterintelligence and Security Center) has just published a short preface on attacks to the software supply chain, and it's a great introduction to the threat [here].

Overall, an adversary can inject some malicious code into the production lifecycle of sofware, and that can go undetected by those who build and maintain the software. An example attack is to insert a backdoor into one of the libraries which are integrated into the software build. While a developer may check their own code, they often care little about the libraries and external code that they adding. While compilers could be a major risk, it is unlikely that any compiler would be allowed to be related which had significant backdoors. More likely, is the integration of external code in libraries and which has been produced by external entities.

Some languages are great for version control, others not so good

While some software languages, such as Rust, have excellent tool chain integration, there are others, such as Node.js, which are generally weak with version control (and often just pick the latest version for updates). With Rust, we build a project with:

cargo new bulletproof

And then create a cargo.toml file which locks-down the specific versions of the libraries we want to use [here]:

[package]
name = "bulletproof"
version = "0.1.0"
authors = ["billatnapier"]
[dependencies]
curve25519-dalek = "1.2.3"
merlin="1.3.0"
bulletproofs="1.0.4"
rand= "0.6.0"
hex="0.4.0"

Unfortunately, many developers care little about the source of their external code and do little in the way of checking the code integration. Open-source software, especially, can be open to modification for malicious purposes. Along with this, there are risks when external parties — such as contractors — produce software which must integrate with the final build. If a contractor is sloppy with their implementation, they can introduce bugs, and, as a worst case, might introduce intentional bugs which can be later exploited. Some people, like it or not, might be offered brides to put backdoors into software that they produce for companies, or might just do it for fame or because they are disgruntled.

Design, development, deployment and maintenance attacks

The examples defined in Figure 1 show that attacks can hit the design (Goldenspy, here), development (MN ban, 2021), deployment (Havex, here) and maintenance process (SolarWinds, 2020).

Overall, SolarWinds is well known for its attack on the maintenance of software, and where an adversary manages to gain access to the digital certificate with the signing key for the SolarWinds software. They then inserted a backdoor into the software and pushed out digitally signed updates.

The NCSC (in the US) classifies that the risks related to software supply chain attacks, software supply chain attacks, and software-enabled attacks (Figure 2).

A key focus in protecting software is often to implement methods that verify software integrity, including code signing, and hashing, but it should be noted that there is no guarantee that implementing these things will always work, and an adversary could gain access to the keys used to prove the integrity of the software.

With Open-Source Software (OSS), we have the advantage of being to identify bugs in the software, but it can also be used to adversaries to insert a back door before anyone notices. This bug can be intentional or non-intentional. With Heartbleed, and unintentional bug was added to the OpenSSL software, and it took a few years to finally find it — but which time, it allowed access to sensitive areas of the memory running on servers. The NCSC document particularly outlines that state actors have often been at the root of attacks sourced in OSS.

The NCSC 12 basic principles

In the UK, the NCSC (National Cyber Security Centre) has been promoting related risks:

For this, the NCSC provides 12 basic principles for effective control [here], and defined four main categories.

Understand the risk:

• Understand what needs to be protected and why
• Know who your suppliers are and build an understanding of what their security looks like
• Understand the security risk posed by your supply chain

Establish control:

• Communicate your view of security needs to your suppliers
• Set and communicate minimum security requirements for your suppliers
• Build security considerations into your contracting processes and require that your suppliers do the same
• Meet your own security responsibilities as a supplier and consumer
• Raise awareness of security within your supply chain
• Provide support for security incidents

Check your agreements:

• Build assurance activities into your supply chain management

Continuous improvement:

• Encourage the continuous improvement of security within your supply chain
• Build trust with suppliers

Any company involved in any part of the software supply chain should really read these guidelines, and put into place processes that understand the risks.

TrueDeploy

From our side, we are so lucky to have researchers who understand software trust and integrity, and our next spin-out company (TrueDeploy) has the software supply chain risks as their core focus. If you want to find out more about them, try here:

Conclusions

I hate to say it, but we can be lazy in the way we build software, and in a way we would not allow in most other areas of business. Imagine if a car manufacturer didn’t check the electronic units that went into their cars, or for mechanical parts they receive. Basically, it is the manufacturer of the software that is mainly responsible for all parts of their product, and they should check the standards of their suppliers, and of their own production.

Don’t see software as any different from any other product … check the quality at every stage of its design, production, deployment and maintenance, otherwise, your company’s reputation is on the line. And, in the worst cases, it could lead to a loss of life and significant risks to our critical national infrastructure.