All application components and map your CI/CD from cloud to code to build an inventory & SBOM
November 10 2021 | 6 min read
Executive, Technical | November 10 2021 | 6 min read
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.
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.
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, Infra as Code cloud misconfigurations, vulnerabilities, CI/CD build-time code insertion, and dependency confusion.
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.
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:
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.
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 & 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!
Organizations must then use that risk visibility to contextually address each individual attack vector:
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:
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.
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 use 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.