Secure your SDLC to avoid being the source of a supply chain attack

Software supply chain attacks have changed the application security landscape and are one of the most insidious and sophisticated threats to businesses and governments. From SolarWinds to Codecov, software supply chain attacks have resulted in billions of dollars of damage, but companies are left with only piecemeal techniques to defend themselves. 

A comprehensive, coordinated risk-based Application Security program that spans from design to code to cloud is what is required in order to mount an effective defense.

The challenge is that there are many ways for an attacker to compromise the Software Development Lifecycle (SDLC), which changes on a daily basis. While most organizations are focused on identifying “vulnerabilities” in custom and open source code, the risks to their software are much broader.

From design flaws to compromised developer identities in Git to secrets in code, sensitive data exposure, vulnerable dependencies, infra-as-code cloud misconfigurations, and CI/CD build-time code insertion, one risk in an otherwise stellar Application Security program can lead to malicious code embedded in production code that is shipped to customers.

What is a software supply chain attack?

According to NIST, a software supply chain attack is defined as:

“A software supply chain attack occurs when a cyber threat actor infiltrates a software vendor’s network and employs malicious code to compromise the software before the vendor sends it to their customers. The compromised software then compromises the customer’s data or system.”

Malicious code may be inserted into a software package at the outset or introduced via an update process, which means organizations have to be continuously vigilant.

Why are supply chain attacks so difficult to prevent?

Whenever an organization installs software from a third-party vendor or uses open source dependencies, they are assuming an element of risk. They trust that the software has been developed in a secure manner by developers that are knowledgeable about security and are working in an environment with the right security processes and tools in place.

But developing software is a complex process. Even the most security-conscious vendors can have lapses that lead to the insertion of malicious code that is then passed along to their customer base. A number of weaknesses that may lead to the compromise of the SDLC, including software design flaws, git misconfigurations, compromised developer identities, IaC misconfigurations, vulnerabilities, CI/CD build-time code insertion, and dependency confusion.

What is a dependency supply chain attack?

Software today is assembled as much as it is written. Developers first look to open source packages and connect components instead of writing programs from scratch. While there are advantages to having the eyes of thousands of developers on a piece of code, this also leads to a tangled web of dependencies that are difficult, if not impossible to follow. 

These dependencies have dependencies themselves, so the chain of trust stretches backwards. This situation poses a serious threat category, focusing on dependency chain-of-trust abuse. The most recent example of the above category is dubbed a “Dependency Confusion” attack, which has rapidly become a considerable threat vector.

How does a dependency confusion attack work?

A blog post published by Alex Birsan in February 2021 follows an experiment regarding internal dependencies’ behavior within many enterprises, including Microsoft, Apple, and Paypal.

To perform a dependency confusion attack, the malicious person or organization:

• Spots internal-looking dependencies in a repository’s software bill of materials (e.g., package.json for npm)
• Creates a malicious package by the same name that will be pushed and reside on a default and public registry
• Leverages the fail-open behavior of dependency management systems of looking for the identified dependencies in case it is missing from the environment in which the code is trying to execute on.

Once such a dependency lookup results in failure on first-order registry, then the natural behavior will be to query the next-order registry, which usually defaults to a public one, thus waiting for those mishaps to happen (hence, confusion) and silently and voluntarily install the malicious code planted by the attacker.

How can you defend against Dependency Confusion attacks?

• Educate developers on the risk by commenting on their PR to add the context
• Designate specific registry source/scope in BOM, if that option is available
• Scan for dependency name leakage and use a dependency combobulator

How can you secure your SDLC?

Securing your SDLC requires a multidimensional, risk-based approach that analyzes signals and data from design to code to cloud in order to identify critical risks and anomalies. Organizations need visibility, context, and control in order to defend against each individual attack vector.

The first steps in any risk-based Application Security program are to define success and gain visibility into your applications and infrastructure so you can understand your security and compliance risks based on the business impact. Establishing success criteria up-front pushes you to take a strategic view of what you need to accomplish. When it comes to securing your entire SDLC, this means less of a traditional focus on vulnerabilities while taking on a broader concept of risk across the design, development, and deployment process.

Risk visibility and asset discovery

Visibility in application and cloud security is ripe for innovation. True application risk visibility requires clarity from end-to-end; from design to code to cloud. Data from all stages of the SDLC can help you make better decisions early in the development process, improving security and reducing unnecessary rework.

Visibility starts with asset discovery that creates an inventory of application and infrastructure code components, developer knowledge, and business impact. This inventory must be automatically and continuously updated for every code change and not like a CMDB system that relies on people and manual processes..

The recent Executive Order on Improving the Nation’s Cybersecurity requires an SBOM for any software sold to the government. This level of visibility into the software supply chain will be increasingly required by non-governmental entities as well.

While some vendors are putting together SBOM functionality purely based on the open source components that make up a software build, they are not comprehensive enough to provide appropriate risk visibility across all software components.. Ensure that your SBOM extends across all application components, sensitive data, open source software, and infrastructure components, because these days everything is code!

Attack vectors

Organizations must then use that risk visibility to contextually address each individual attack vector:

How do Zero Trust principles apply to SDLC security?

Zero Trust is a principle and framework often applied to networks, identities, and access controls but it is often ignored when it comes to application security. This is a critical mistake that leaves software with risks on multiple levels. Zero trust principles can be applied to application security by ensuring software integrity at each stage of development:

• First, developer identities need to be protected with multi-factor authentication and continuously analyzed using specialized User and Entity Behavior Analytics (UEBA) with developers’ knowledge to flag potentially compromised accounts. For example, if a front-end developer who works on one application commits back-end code on another application at an unusual time and in an unexpected location, that may be an indication of a breach.
• Second, code must be continuously verified at each stage from commit to pull request to CI/CD. In the SolarWinds attack, code was inserted on the build server before it was digitally signed. Organizations must examine their binaries and compare them to the source code. Zero Trust principles demand that software is protected even in the event of a server breach in CI/CD.

How can you secure your software supply chain?

The key to securing your software supply chain is to get visibility into their application security programs and risk management processes. Ensure that they are focused on risk, not individual vulnerabilities, and can continuously and automatically identify risky changes that are introduced at any point in the SDLC.

Following the principle of “trust but verify”, organizations should also demand a comprehensive SBOM that covers not only code components but also open source software and infrastructure.

Putting it all together

Your SDLC needs to be secure at every step. This means having visibility into risk across the entire process, from design to code to cloud and using that visibility to understand and respond to risk. With the appropriate controls in place, you can confidently accelerate software delivery and assure your customers that they will not be the next victim of a supply chain attack.