A number of high profile supply chain attacks against software vendors (SolarWinds, Codecov, Kaseya, etc) have highlighted the need for better software supply chain security. These kinds of attacks highlight key supply chain threats, including:

• Public Repositories – compromised open source code is mistakenly imported into the organization as a result of typosquatting, dependency confusion, author impersonation, or similar exploit.
• Build Systems – CI/CD pipelines and other build processes are compromised due to a lack of security controls and checksum verifications that allow threat actors to upload or insert components into the build process.
• Distribution Systems – vulnerabilities in public-facing distribution systems allow hackers to hijack software updates, upgrades and new versions of software/apps intended for customers. 

The result puts not only the developer’s organization at risk but also all their customers, as well.

What are the top 3 software supply chain threats?

The top 3 software supply chain risks include vulnerabilities, compromised third party code and build system integrity. With modern software development, application security starts with the software supply chain and extends throughout the software development lifecycle involving all stakeholders, not just security teams. Typical security issues include the following attack vectors:

• Common Vulnerabilities and Exposures (CVEs) – aka vulnerabilities in software code are the most common way for hackers to exploit codebases slow to remediate them. 
• Compromised Dependencies – open source dependencies that have been compromised by malicious code (trojans, spyware, viruses, backdoors, etc) provide hackers with the ability to compromise a software developer’s networks and systems.
• Build System Integrity –  build systems that are not locked down and secured can provide a vector for hackers to introduce compromised code into a build step. The resulting built software then gets propagated downstream to customers, offering a vector for compromise of their networks and systems.

Software Supply Chain Threat Mitigation

The best way to mitigate software supply chain threats is to address them during the import, build and usage workflows of a secure software development process:

• Import – the process of importing third-party tools, libraries, code snippets, packages and other software resources in order to streamline development efforts.
• Build – the process of compiling, building and/or packaging code, usually via an automated system that also executes tests on built artifacts.
• Use – the process of working with, testing and running built artifacts in development, test and production environments.

Secure Supply Chain Import Controls

You can mitigate the risk of importing third-party code from public repositories by limiting the import of prebuilt binaries and securing the import process:

• Verify the identity of uploader(s)/ author(s) haven’t suddenly changed.
• Verify that at least two reviewers have reviewed the submission.
• Verify that the timestamp of the submission is valid.
• Verify the revision history. A lack of history can be indicative of typosquatted packages.
• Verify the URL/ immutable reference to counter dependency confusion.

Secure Supply Chain Build Controls 

DevOps can mitigate the risk of hackers compromising your build system by implementing the following controls:

• Ensure builds are scripted and have no manual inputs.
• Ensure builds are run by a dedicated service (as opposed to on a developer’s workstation that might have lax authentication permissions).
• Ensure build steps are executed in ephemeral environments that are discarded at the end of the step.
• Ensure build steps are executed independently in isolated environments.
• Ensure build steps are executed in hermetically sealed environments that have no public network access.
• Ensure builds are reproducible.

Secure Supply Chain Usage Controls

You can mitigate the risk of using compromised software components in your development process by implementing the following controls:

• Ensure all built artifacts are signed
• Ensure all signed artifacts include the following information via a cryptographic hash:
  • Output artifact
  • Build system used
  • Source (ie., an immutable reference to the build script)
  • Transitive dependencies (ie., dependencies of dependencies)
  • Build parameters, if any
  • Software Bill Of Materials (SBOMs)
  • Software Attestations

Learn more about securing your supply chain: AppSec Guide: The Open Source Supply Chain Can Be Fixed. 

What are software supply chain attacks?

Software supply chain attacks are an emerging class of cyberattacks that target software developers and the third party software they import or use during their development process.  Typically, a hacker will either compromise a third-party library or else directly compromise a software vendor’s network in order to introduce malicious code into a vendor’s application before it is distributed to their customers. 

In this way, instead of probing each target organization for potential vulnerabilities that might be exploited, the hacker seeds exploitable code at thousands or even tens of thousands of organizations by compromising a single vendor.

Read more about how to perform supply chain risk management, improve cybersecurity and combat supply chain attacks in the white paper: Business Leader’s Guide to Establishing Software Supply Chain Trust.

What are some software supply chain risks?

Software supply chain security risks include:

• Software vulnerabilities are poorly coded software routines in third party software that offer hackers an exploitable point of attack. 
• Trojans typically appear to be harmless third-party code but in reality contain malicious code that can compromise the system they’re deployed on.
• Spyware is typically malicious code inserted into third-party software that will scan the system, codebase, network, or other entity with which it comes into contact. It can be used to exfiltrate passwords, certificates, API keys, etc.
• Viruses are typically embedded in third party code and used to infect systems, network and codebases when that third party code is run.
• Backdoors are typically embedded in third party code and provide unauthorized users with a way to avoid security measures while gaining high level user access to the system or network they’re deployed on.
• Malware (aka malicious software) is a general class of third-party code that can infect, explore, steal or otherwise provide an exploitable vector of attack.
• Tampered build scripts typically occur when build systems require manual intervention to kick off, giving hackers the potential to access and modify the build script.
• Unconstrained packages included in a build process may attempt to overstep the bounds of the build environment and compromise the build system itself.
• Dynamic packages included in a build process may attempt to download malicious remote resources during their build step.
• Dependency Confusion can occur when a build system mistakenly pulls in a similarly named dependency from a public repository rather than your private repository.
• Typosquatting occurs when a hacker uploads a malicious package to a public repository and names it similar to a popular package (i.e., request vs requests)
• Brandsquatting is similar to typosquatting but in this case the hacker names their malicious package identical to a popular package in a different ecosystem.

Read Similar Stories