A Year of Supply Chain Attacks: How to Protect Your SDLC

One of the most worrisome trends in cybersecurity today is the skyrocketing incidence of supply chain attacks, such as the ones that hit SolarWinds last year and Kaseya more recently. Because they focus on compromising software development and delivery, supply chain attacks have forced developers and DevOps teams to scramble for solutions. 

Unfortunately, supply chain attacks are particularly challenging to prevent, detect and remediate, and, because of their stealthy nature, are often devastating. However, you can significantly reduce your risk of falling prey to these attacks by understanding how they work and adopting key best practices.

Read on to learn how you can protect your software development lifecycle (SDLC) from supply chain attacks, and ensure the software you deliver to your employees and your customers is safe.

What are supply chain attacks?

In supply chain attacks, hackers hide malware in legitimate software that then gets distributed via official channels to unsuspecting end users, whether the software is free and open source (FOSS) or sold commercially.

“These types of attacks affect all users of the compromised software and can have widespread consequences for government, critical infrastructure, and private sector software customers,” reads the U.S. Cybersecurity and Infrastructure Security Agency (CISA) paper “Defending Against Software Supply Chain Attacks.”

For example, in the case of IT monitoring vendor SolarWinds, hackers injected malware into the software build process of its Orion Platform. The breach went undetected for months, during which time SolarWinds inadvertently shipped product updates with the vulnerability.

About 18,000 customers received tainted updates, and several dozen got breached, including high-profile multinationals and large U.S. federal government agencies. The vulnerability was designed to help hackers compromise customers’ Orion servers using a backdoor.

Because of its scope and impact, the SolarWinds hack put the spotlight on software development security and on DevSecOps. In fact, it, as well as supply chain attacks in general, were mentioned by the White House as a motivation for U.S. President Joe Biden’s Executive Order on Improving the Nation’s Cybersecurity, issued in May.

“Supply chain attacks are scary because they’re really hard to deal with, and because they make it clear you’re trusting a whole ecology,” Nick Weaver, a security researcher at the University of California at Berkeley told Wired.

More recently, hackers exploited zero-day vulnerabilities in the software of Kaseya, a vendor of cloud-based IT management software for MSPs and IT teams, to unleash a massive ransomware attack against customers using its Kaseya VSA on-premises product.

Kaseya said the attackers bypassed authentication and ran arbitrary command execution, allowing them to leverage VSA to deploy the REvil ransomware to customer endpoints. However, Kaseya said it has found no evidence the VSA codebase was maliciously modified.

In taking responsibility for the attack, the REvil hacker group asked for a $70 million ransom payment, and said it had infected about 1 million systems, making this supply chain attack one of this year’s worst cybersecurity incidents, and possibly more destructive than SolarWinds’.

“This shines a light on a troubling trend, where attack targets are shifting from individual organizations to exploiting platforms, like Kaseya or SolarWinds, that allow for multiple organizations to be affected,” Forrester analyst Steve Turner wrote in the blog “Using Our Tools Against Us: Adversaries Continue To Abuse Trust In The Supply Chain.” 

“Supply chain attacks are becoming increasingly popular with attackers since they can access the information of larger organizations or multiple organizations through a single, third-party vendor,” the Identity Theft Resource Center (ITRC) stated when announcing its 2020 Data Breach Report. “Often, the attacked organization is smaller, with fewer security measures than the companies they serve.”

Why this should matter to you

Today, developers typically only write a small portion of their application’s codebase. The rest, which can be north of 90% of the codebase, is made up of third-party open source and commercial software components.

Developers must make sure that these third-party pieces don’t have security or compliance gaps, such as an unpatched critical vulnerability, malware or a misconfigured setting. Otherwise, their software can put employees and customers at risk for security and compliance breaches.

This is easier said than done. For example, commercial, proprietary software is often by design delivered as a black box that’s difficult or outright impossible to inspect. Meanwhile, open source software typically contains layers of dependencies — both direct and transitive — that can be hidden and difficult to understand.

This lack of visibility into the makeup of commercial and open source software can be improved with software bills of materials (SBOMs), which list and detail all components in a piece of software. Unfortunately, SBOMs aren’t yet a consistent industry practice.

Other challenges include package managers that pull components from public repositories by default, and attackers that increasingly target the earlier stages of the SDLC, where organizations tend to have fewer security checks.

What to do?

There are a number of ways to mitigate your supply chain risk.

  • Establish a supply chain vetting process: Maintain continuous communication with your software vendors to ensure they’re taking the necessary steps on their end to keep their products secure.
  • Shift security left: Add automated security checks throughout the SDLC, starting as early as the design phase.
  • Implement binary code integrity verification: You can do this by hashing the binary file of downloaded software and comparing it to the hash provided by the vendor. Better yet, choose package managers that do this automatically.
  • Do code analysis and testing: Always perform software composition analysis for tracking and analyzing OSS components and licenses; static code analysis to examine program source code, and detect issues like SQL injection attacks; and dynamic code analysis to examine code on a running system.
  • Demand an SBOM: Require that all software be accompanied by an SBOM. When an SBOM is missing or incomplete, scan the software with a tool that creates one.
  • Perform network-based assessments: This can help in detecting vulnerable software components, and even actual breaches, which is how the SolarWinds attack was uncovered.
  • Manage and prioritize vulnerabilities: Adopt a comprehensive vulnerability management program that includes threat analysis, so you can prioritize which bugs must be patched immediately, and which represent a minor risk.
  • Remediate, remediate, remediate: Address vulnerabilities by updating, patching, isolating or removing the affected software in a continuous, timely fashion, so that you stay a step ahead of hackers looking to exploit known vulnerabilities.
  • Protect your SDLC with multi-factor authentication (MFA): All critical sections of your SDLC should be configured to use MFA, to reduce the risk of attackers gaining access to your source code version control systems, package registries, container registries, artifact repositories, CI/CD pipelines, and build and developer machines.
  • Avoid dependency confusion and typosquatting attacks: Set up an internal, private registry that’s used by default by your DevOps teams, and that way reduce the chances of developers getting tricked into pulling tainted components from public repositories.
  • Use version pinning: Specify the package versions to be used, so that your teams don’t inadvertently install older, compromised versions.

A problem that can’t be ignored

Protecting your organization from supply chain attacks must be a priority, given how popular they’ve become among all sorts of online outlaws — individual “lone wolf” hackers, criminal cyber gangs, nation-state government actors. 

The uptrends are clear.

The number of supply chain attacks rose 42% in Q1 2021 compared to Q4 2020, with 137 organizations impacted at 27 different third-party vendors, and affecting 7 million people. “The rise in supply chain attacks is troubling,” said Eva Velasquez, president and CEO of the ITRC, a nonprofit organization focused on reducing identity compromise and crime.

In Q2 2021, supply chain attacks leading to data compromises increased 19%, with 32 new attacks compared to 27 in Q1 2021, impacting 292 organizations and affecting an estimated 5.5 million individuals, according to the ITRC.

At this rate, third-party risks are on track to surpass malware as the third most common root cause of data events by the end of 2021, the ITRC stated, adding that the Kaseya supply chain attack “also indicates that the scope and complexity of supplier attacks are increasing.”

At JFrog, we can help you prevent supply chain attacks and avoid their costly and destructive consequences. Our end-to-end JFrog DevOps Platform provides all the DevSecOps capabilities you need to boost your SDLC defenses against this type of attack. 

Check out our SDLC security resources to learn how our platform, combined with best practices and proven processes, can keep your organization safe from supply chain attackers.