Secure Your Software Supply Chain

Auto parts, peanut butter, and medical supplies all have supply chains: links of goods, services, and interconnecting processes that turn small pieces into finished items and get them to their consumers. Software products are the same. A lot of components go into the creation of any software product. And at any time, the build process can, theoretically, be attacked. So there is a lot of attention today paid to software supply chain attacks, some of which have been carried out with devastating results. Each of us must educate ourselves on the challenges in this area to make sure our software projects stay out of the inevitable upcoming news story on The Next Big Hack.

Is your organization’s software supply chain protected? Let’s look at what we can do. In this article. We’ll cover:

• What the software supply chain is.
• Significant threats and attacks we’ve seen.
• Concrete actions you can take to harden the security of your software supply chain.

What Is a “Software Supply Chain?”

Modern enterprises depend on open-source software. According to a report by Gartner, as much as 95% of organizations use open-source software in their mission-critical IT workloads. This isn’t surprising, considering the quality, maturity, and community of many open-source projects.

Open-source projects themselves often depend on code from other open-source projects. When you include a piece of open-source software in your system, whether it’s a container image or a library, you also include—and, therefore, implicitly trust—the entire graph of dependencies of that project. In addition, the tools used to build or update the software components in those open-source projects also rely heavily on open-source software.

Your software supply chain consists of all the projects, libraries, packages, and tools that you use—both directly or indirectly—in the development and delivery of your software.

(As usual, xkcd captures it best.)

When an organization’s software supply chain is broad and deep, the security risk is greater. Every new version of a library has the potential to introduce new vulnerabilities inadvertently. On occasion, a project owner might release malicious software that provides real value to the user but introduces some hidden vulnerability intentionally.

How great is the risk? Let’s look at some recent software supply chain attacks to get a sense of the danger.

A Timeline of Infamous Software Supply Chain Attacks

December 2020: SolarWinds Orion

SolarWinds is a company that delivers the network and application monitoring platform called Orion. In December 2020, Orion was compromised. The impact was massive. The breached customers of Orion included:

• Almost 90% of US Fortune 500 companies
• The top ten US telecommunications companies
• The top five US accounting firms
• The US Military, Pentagon, and State Department
• Hundreds of universities across the world.

February 2021: dependency confusion

In February 2021, security researcher Alex Birsan published an article claiming that he used a software supply chain attack known as dependency confusion to breach dozens of tech companies including Microsoft, Apple, Tesla, and PayPal.

April 2021: Codecov, Passwordstate

In April 2021, it was discovered that Codecov, a code coverage tool, had been compromised for two months. The attackers used a sophisticated software supply chain attack against a base Docker image.

In that same month, Click Studios revealed that their Passwordstate enterprise password manager was compromised. The impacted customers include hundreds of thousands of security and IT professionals and tens of thousands of companies around the globe. The attack targeted the software’s update mechanism.

May 2021: Executive Order 14028

In May 2021, President Biden issued Executive Order 14028, crafted to bolster cybersecurity.

July 2021: Kaseya MSP

The attacks didn’t stop there, of course. In July 2021, Kaseya suffered an attack on its cloud-based MSP platform. This led to the installation of ransomware on many of their downstream client companies and the businesses supported by those clients.

November 2021: Open-source poisoning attacks

In November 2021, open-source poisoning attacks were used to compromise 3 NPM packages: COA, RC, and ua-parser-js.

December 2021: Log4Shell

Then in December 2021, the Log4Shell 0-day vulnerability allowed attackers to launch thousands of software supply chain attacks against their victims. This was especially damaging because of the ubiquity of Log4J in Java-based applications and the depth of recursive dependencies.

January 2022: color.js and faker.js

On January 9, 2022, the developer and maintainer of color.js and faker.js purposely corrupted these packages because he didn’t want to support large corporations for free anymore. Countless commercial and open-source projects depended heavily on these two libraries, and the cascading effect of this action was highly disruptive.

The abridged timeline of events from above only covers 14 months, but the impact of these attacks was far-reaching. What makes software supply chain risks so dangerous?

Why Software Supply Chain Attacks are Pernicious

Software supply chain attacks are difficult to contain using common security best practices like defense in depth or the principle of least privilege. There are two primary reasons why this is challenging.

1. Third-party software often legitimately needs privileged access.
2. Third-party software often legitimately needs to communicate over the network.

Ironically, third-party security software is often the target of breach attacks. These systems need to observe the entire system, write to audit logs, and communicate back to the vendor for updates. It is terrifying how much havoc security software—if compromised—could wreak and how easily it could cover its tracks.

From another angle, we also understand why an attacker would seek to compromise a low-level library. The reach of that attack can be enormous, as seen with many of the examples discussed above.

How to Protect Your Software Supply Chain

All is not lost. You can take concrete steps to defend against software supply chain attacks.

Complete inventory of all dependencies and versions

As a first step, performing an inventory of your supply chain is imperative. You must have a bill of materials (BOM) for your software. This gives you visibility and a baseline to create, validate, and check all the dependencies.

Use lockfiles

Lockfiles pin your dependencies to specific versions and prevent new—and thus potentially malicious or vulnerable—versions from entering your software without an explicit version bump. For example, if your software depends on version 1.6 of a library and you have verified that version as safe, then a lockfile ensures that your package manager will not automatically update the library to version 1.7 without your approval.

Use DevSecOps

Incorporate security into your software delivery life cycle (SDLC). With the blistering speed of today’s continuous delivery pipelines, you must catch security issues—and this especially includes software supply chain issues—early in development. Integrate tools like Scorecards from the Open Source Security Foundation to assess the security of your dependencies.

Defend against dependency confusion attacks

A dependency confusion attack occurs when your software depends on a private internal package, but your package manager is tricked into updating your software with a public package of the same name but with a higher version. Your internal package may be safe and trusted, but the public package that substitutes for it may contain malicious code.

You can defend against dependency confusion by ensuring you control the public packages that correspond to your private packages or by making sure public packages will never get prioritized over your private package.

Use signed images

Signed images give you the confidence that the image you are using was indeed created by an actor you trust.

Image scanning and verification

While signed images are an exercise of security through authentication, using a signed image doesn’t guarantee that that image is free of vulnerabilities. Image scanning can detect vulnerable images and alert you to issues so you can respond.

Vet your vendor

Make sure you work with vendors that also follow secure SDLC best practices.

Conclusion

Modern software, with its heavy dependency on open-source software, exposes a large surface area for vulnerability. It’s no wonder that software supply chain attacks are on the rise and the challenge of protecting modern software is becoming increasingly complex. However, integrating sound DevSecOps best practices into your CI/CD pipeline and managing your dependencies carefully will give you a path forward.

Join our daily livestream from the DevNet Zone during Cisco Live!

Stay Informed!
Sign up for the DevNet Zone Cisco Live Email News and be the first to know about special sessions and surprises whether you are attending in person or will engage with us online.

We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!

LinkedIn | Twitter @CiscoDevNet | Facebook | YouTube Channel

Share: