Traditional supply chain attacks impact the production of physical goods. Your supply chain might include partners delivering raw materials, suppliers with component parts used in manufacturing, as well as trucks for distribution of finished goods.Disruption of that supply chain could result in production shutdowns, aging inventory, degraded partner relations, and financial loss.
But that's not the kind of supply chain we're talking about here today. Instead, we're focusing on the software supply chain — an important new challenge to manage as businesses the world over undergo massive digital transformations. And yes, the software supply chain can have an impact on your traditional supply chain as more and more software is used to automate, monitor, and control many of the hard production processes.
What Are Supply Chain Attacks?
As more companies invest in digital initiatives and expand their IT infrastructure technologies and business processes, they also add software development and DevOps staff. And with the addition of software development life cycle (SDLC) practices to build and deploy applications, we’ve seen increasing use of open source software and dependencies on public packages to accelerate schedules.. Of course, stringent security measures should be in place to prevent poor selection of that code, but ultimately, open-source options abound, and engineers will use those options to create the applications required.
Hence, the emergence of the software supply chain attack: any attack that infiltrates your software life cycle. To counter these attacks, organizations must:
- Inspect before Build (e.g. read our blog on PyPI package malware in SupPy Chain Malware – Detecting malware in package manager repositories)
- Inspect before Ship
- Inspect before Deploy or Update (e.g. read our blog on ASUS Live Update attack in Forging the ShadowHammer)
Perhaps one of the most significant attack vectors is via the selection of code from public package manager repositories. In short, a supply chain attack is one in which the attacker isn't targeting your organization, specifically, but instead the code your organization will use.
This attack vector is primarily covert because the contributing person or vendor are assumed to be trusted entities. As more package manager repositories emerge, and more and more developers openly source the component building blocks they require to accelerate their own projects, supply chain attacks will only continue to increase. These attack types present challenges all companies have experienced before - but they're more nuanced and even more frightening than the challenges of the past.
Supply Chain Attack Protection Challenges
What are best-in-class organizations doing to protect their systems from these attack types today? The answer is at once encouraging and disappointing: Not enough. But that's not unexpected given the many, unique challenges presented by supply chain attacks.
In our experience, companies are used to looking at managed software, either as it enters or exits their organization's controlled environment. They'll have known trusted suppliers and discreet installers, and more likely keep their focus on delivering production-ready software and less on application security. So, what happens in-between?
As more tools pop up in new repositories, developers use whatever they need to get the job done. It might be a containerized deployment architecture for one application and something else entirely for another. Most companies are not looking at the components within their environment, or the security of this software. And while that's true to an extent, it isn't always true.
It's possible that there's a perception, among developers, that the community self-patrols itself. And while this may be true, the community simply can’t predict developer behavior. For example, the potential to mis-type package names and erroneously download typosquatting malware. The challenge, then, is: Volume and Proliferation. There are more tools in use, more people using them, and they're being examined only as they are in motion during entry or exit.
Another challenge comes to mind in considering how many people use each tool, and when: Ownership. Quality Assurance has always fallen to someone in the organization, but it's largely a measure of whether an application is working and usable, not whether it contains malicious objects. In today's world, QA belongs to developers, while the SecOps team handles inbound threats and data leakage. However, more and more Security teams are being pulled into examining Application Security, and the broader software lifecycle - even if they don't own it. So, who does own examining that code? Is it developers? SecOps? Or the community providing the packages?
And with all of these challenges, what can you do to begin to protect your system, even as your engineers leverage open-source components and your SecOps team focuses on what's coming in and going out?
How to Protect Your System From Supply Chain Attacks
First things first, a traditional antivirus will not successfully thwart software supply chain attacks. We can dismiss that as an option.
What will help keep the increasingly porous software lifecycle free of vulnerabilities and malware? Largely, process. Of course, technology is required as well, but ultimately, software development can't be secure unless you insert new security procedures into the process of pulling code out of repositories and using it for your own applications- whether for internal use or external distribution, and into the process for validating 3rd party applications- as a second check on the source.
Let's say you add a checkpoint for every time a new (to you — it already exists elsewhere) piece of code is about to be brought into the software lifecycle. What do you do at that checkpoint to ensure nothing in the software has any malicious components? Executing in a sandbox for every package leaves you with gaps, still; not every file or piece of a file is a simple executable.
Instead, you have to look — really look — at the code you want to bring in, using static analysis. With static analysis, you can see characteristics of the files that are indicative of certain malicious content types, allowing you to flag and further analyze said file.
(To learn more about how static analysis can find malicious code within a package manager repository and get all the details, listen to our podcast hosted by Cyberwire: Detecting Malware in Package Manager Repositories)
The way to protect your systems and your software supply chain best, then, is to analyze content you download from 3rd party repositories so your developers can feel more confident using what's at their disposal. Rather than requiring developers to alert anyone when they need a new piece of code, and rather than waiting until pushing that code to production, they can place that code in another repository — one designed for malware analysis.
From there, the malware analysis can be automated and retro hunting enabled, allowing the process of review and alert to run seamlessly once you have the right solution in place. As alerts are generated, threat hunters and analysts will know exactly where to intervene, and any bad code engineers unknowingly pull from a trusted repository will not make it into production. Your software supply chain stays clean.
