The software supply chain and zero days

Vulnerabilities enter at every stage of the software lifecycle

Libraries, packages and container images bring other people’s code into your program. A vulnerability in a popular library can reach every project that depends on it. That is the supply chain problem.

Where vulnerabilities enter. Vulnerabilities are usually thought of as flaws in code logic, such as an edge case nobody considered. The lecture says they can arrive at any stage of the software lifecycle.

• Development. For example, use of third-party libraries.
• Installation and deployment. For example, insecure default configurations.
• Maintenance (upgrade, patching). For example, a vendor hacked so that it distributes malware.

From an attacker’s point of view, this is a highly effective way to spread malware and steal secrets at scale. The notes add that the software development lifecycle has existed for nearly 60 years, yet security is often overlooked in it.

Dependencies inherit their authors’ security practices

Third-party libraries and package managers. Libraries reduce the time needed to program functions. They are often distributed through package managers backed by online repositories, such as PyPI, npm, RubyGems and Maven Central, and their use has grown massively over the past ten years.

Using a library means an implicit dependence on how its developers behave.

• Protecting write access to their code. ESLint was hacked to steal credentials. A study of weak npm credentials is cited on the slide, and Koa, a JavaScript framework with 160,000+ weekly downloads, had password=password.
• Keeping their own dependencies patched. If Package A lists Package B as a direct dependency, and B depends on a package C affected by a vulnerability, then A transitively depends on C and may be vulnerable.

Containers. Malicious images can be distributed through DockerHub, a repository for Docker containers. The slide’s example is cryptominers deployed over Docker. Running automated scripts found on the internet means a developer can unknowingly deploy a cryptominer on their infrastructure. The slide’s closing line for this section: untrusted input does not always come in through web forms.

An attacker compromises a library author’s account, a package’s own dependency, or a container image that many developers pull. The malicious code then arrives inside software the victim chose to trust, and from a vendor whose normal updates install it.

Dependency checks and protected accounts reduce known risks

The lecture’s mitigations come in two groups.

• When depending on third-party software. Use dependency checker tools to guard against known vulnerabilities: GitHub dependency graph alerts (Dependabot alerts), OWASP dependency check, and npm audit. Update and patch third-party software that you control regularly. The slide adds that this is much easier said than done.
• When developing libraries others use. Use password managers to generate unguessable passwords, and protect commit access with multi-factor authentication.

The limit: these tools match against vulnerabilities that are already known. The next section is about the ones that are not.

Honeypots and behaviour can reveal exploitation of unknown flaws

Zero days. Everything up to here concerns known vulnerabilities. The notes define a zero day as a vulnerability in software, hardware or firmware that threat actors exploit before the vendor can identify and patch it, and a zero day exploit as one that attacks it. The lecture’s question is how to detect something you do not know about.

Two mitigations are on the slide.

• Honeypots. A server masked to look like an unsecured server. It can be used to study attackers’ tactics and motives inside a network. It can also be used for detection: when a credential from this server is used, alerts can be issued.
• Behavioural analysis. Look at the common sequences of commands attackers run after compromising a host, for example whoami and cat /etc/passwd.

Neither fixes the vulnerability. Both aim to notice the attack from what it does afterwards.

Pitfall

A dependency checker will not find a zero day, because it compares your packages against a list of already known issues. If a question asks how to detect an unknown vulnerability being exploited, the answer is honeypots and behavioural analysis, not npm audit.

Exam detail

Expect questions on the three lifecycle stages with their examples, the definition of a transitive dependency, the named dependency tools, and the two zero day mitigations. The notes’ practice quiz says supply chain attacks are hard to detect, because the attack appears to come from a legitimate vendor with the correct certificates. The wording there goes as far as saying targets have no way to suspect it. Treat that as the lecture’s claim about difficulty.

Optional aside

The notes name SolarWinds as one of the largest supply chain attacks, linking to a Wired article in the practice quiz. Zero days carry higher risk because no patch exists and the vendor does not know yet.

Recall

Where do supply chain vulnerabilities enter, and how do known-risk controls differ from zero-day detection?

• Vulnerabilities enter in development, installation and deployment, and maintenance, and supply chain attacks spread them at scale.
• A library creates a dependency on its authors protecting their accounts and patching their own dependencies, including transitive ones.
• Checker tools (Dependabot alerts, OWASP dependency check, npm audit), regular patching, password managers and MFA reduce the known risks.
• Zero days are unknown to the vendor. Honeypots and behavioural analysis help notice the attack.