Face it. Your software supply chain is under attack. You'd have to be hiding under a rock or in a bunker under the sea not to realize it. From SolarWinds-style attacks to language-specific repositories, supply chain compromises aren't going away—they're rising.
Do you understand why software supply chain attacks are increasing? Have you internalized the attacker's motivation to pollute your software supply chain and embedded this knowledge within your security culture? Ending supply chain attacks requires awareness of why attackers pay attention to these types of attacks.
To understand attacker motivations, stop and ponder the threat actors and their motivations. Due to the complexity of the software supply chain, threat actors will play differently in each scenario. Here are three case studies to illustrate, so that you can mitigate.
1. Plain web application or mobile vulnerability
The basic exposure in this case arises from a known issue in an open-source package or library that is reported via CVE. A tool such as npm audit or OWASP Dependency Check throws an alert that there's a problem. This issue likely appears somewhere on the OWASP Top 10 and should have been easy to avoid. The exploit is possible when developers don't update the package for some period of time, which could be weeks, months, or, in a worst-case scenario, years.
The attacker's motivation in exploiting a plain vulnerability is to gain access to a web application and then complete a data breach in order to exfiltrate data to some attacker-controlled location on the Internet. Attackers breach data to sell it on the underground market for a profit, and such attackers are most likely cyber criminals.
Mitigating factors:
- Software composition-analysis tools quickly detect known vulnerable code issues. If you don't have one, get two of these and place them in your secure software pipelines:
- OWASP Dependency Check for scanning, and OWASP Dependency Track for managing open-source and third-party risk using a software bill of materials (SBOM)
- Npm audit for Node.js
- Retire.js for JavaScript
- Bundler Audit for Ruby on Rails
- Python Safety
- Maintain a healthy dose of skepticism toward the security of open-source and third-party software that your team includes in your software. Remember, while it may not be your code, it is your problem when a vulnerability strikes. Customers don't care that a vulnerability in your application was in a package you included. If your name is on the application, the vulnerability is your problem.
2. Compromised build pipeline
In the second case, an attacker profiles and discovers a weakness in your software build pipeline. The flaw could be because your pipeline is exposed to the public Internet (gasp!) or because the attacker was already inside your internal network and pivoted to focus on the pipeline.
The attacker's motivation is to plant a weakness in your software build. After it is downloaded and installed at a large number of organizations, the attacker connects to each of them using the planted vulnerability. The level of coordination and preparation for this class of attack usually suggests a nation-state attacker—funded and resourced sufficiently to gain access to a software producer's internal network and orchestrate a pipeline compromise.
Mitigating factors:
- Harden your build environments against attack. Your build environment should be one of your most well-protected systems. Unfortunately, many build environments still suffer from the notion that, since they are contained inside the firewall or as part of the internal network, they don't need much additional security protection.
- Generate and distribute a SBOM with any software that you compose. An SBOM is an ingredient list for your software and offers transparency for your customers about the contents of a given release/build.
3. A malicious package sneaked into a repository
In the third case, an attacker sneaks a malicious package into a language-specific repository. The attacker's primary purpose is to get that version of the package downloaded and embedded into many production applications in order to do crypto-mining attacks: A malicious package contains extra code that connects to a central service and receives a workload for processing. The attacker uses the compromised systems as a cluster to mine cryptocurrency.
We've been lucky that malicious package attacks have not been more destructive or damaging. However, nothing prevents an attacker from using a malicious package to establish a back door (case study 2) or perform a data breach (case study 1). It's only a matter of time.
Mitigating factors:
- Use SCA (see above) to detect malicious packages (only works after someone has discovered the issue without an SCA tool).
- Establish a set of package questions for every developer to ask and answer. If a prominent package has recently had a new package maintainer take complete control of the package, that is a giant red flag of a potential compromise.
- Use an internal repository and vetting process that controls how new versions get to the internal package. This is a bit of a chicken-and-egg problem, because immature programs don't have the resources or know-how to vet packages, but you must strive to get there.
The best mitigation: Awareness
The software supply chain carries with it a certain amount of danger. You're essentially relying on software created by people who don't work for you, many of whom are working for free. If you simply trust these people and projects, you may escape unscathed, but that's not going to last forever.
If you've avoided software supply chain attacks so far, you've been lucky. The mitigating factors discussed here will help, but the best mitigating factor is awareness of the inherent risk in the software supply chain. Make sure everyone within your organization has that awareness. The package you patch or pipeline you harden may be the one that blocks a crippling supply chain attack.
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
