What is software supply chain security?
Software supply chain security (SSCS) allows security teams to identify, analyze, and mitigate the risks associated with weakness and vulnerabilities in software code throughout the software development lifecycle (SDLC), from design to deployment.
The software supply chain itself is an often-complex collection of components, dependencies, libraries, tools, and processes that are used to build applications. Many of today’s business applications — whether they come from third party vendors or are developed in-house — include both proprietary and open-source components, tools and processes, including:
- Binaries
- Libraries
- Plugins
- Container dependencies
- Assemblers
- Compilers
- Code analyzers
- Repositories
The interconnections between these components creates a complex supply chain in which a single vulnerability can be exploited, triggering compromises that spread far and wide. From a cyberattacker’s perspective, the software supply chain offers an expanded attack surface with access to high-value data and systems; it’s one effort to mug the whole crowd, as it were.
From a development point of view, increased reliance on open-source software and cloud-native technologies have made the software supply chain threat landscape more challenging. Without a paradigm shift in software supply chain cybersecurity management, the risk of compromise is expected to grow substantially.
SSCS secures all the elements used to build and publish applications. Starting at the design phase, SSCS uses automated processes to identify, analyze and monitor software, and any related vulnerabilities. SSCS tools like OX Active ASPM help development and AppSec teams understand everything in their CI/CD pipelines, from the entirety of the codebase to relationship and dependency mapping for third-party applications and infrastructure, through material code changes that happen throughout the application’s lifecycle.
Did you know?
The average organization has nine high, critical, or apocalyptic risks within their supply chain.
How software supply chain attacks work
There’s a good reason for this: When an attacker finds and exploits a vulnerability in a widely used application, they have the potential to tamper with every organization running it, à la Crowdstrike, SolarWinds and Okta. When you consider that ninety-one percent of organizations experienced at least one software supply chain security incident in 2023, it seems clear that, for attackers, the barrier to software supply chain compromise success is low: The average organization has nine high, critical, or apocalyptic risks within their software supply chain, that’s a lot of unlocked doors for attackers to try.
The most common software supply chain attack methods include:
#1: Targeting third-party / open-source software / third-party dependencies
ADR continuously monitors behaviors within and between application services, supporting comprehensive security observability.
An example of a third-party supply chain attack: The Clop ransomware group exploited a zero-day vulnerability in the widely used file transfer software MOVEit. The group stole data from leading global brands, including British Airways (via their payroll service provider, Zellis) and a U.S. government services contractor, Maximus.
#2: Infiltrating the software development pipeline
Between 40-80% of code in new software projects comes from third parties, much of it from open-source projects. Attackers can “seed” malicious code into repositories to infect the software development pipeline and create the opportunity to infiltrate targets via software updates, tools or dependencies.
An example of a supply chain attack involving the software development pipeline: The high-profile SolarWinds attack was a prime example of how attackers could use one vulnerability — a backdoor in a software update — to infiltrate multiple high-profile targets.
#3: Package typosquatting / dependency confusion attacks
These types of attacks occur when a threat actor creates a malicious software package and gives it a name very similar to a legitimate software package so that it seems real and trusted. Attackers exploit the human tendency to miss hard-to-spot typing errors, such as renaming a Python package “requests” instead of “requests,” or hijacking/creating domains with intentionally minor and common typos, such as gooogle.com.Another version of this is called combosquatting, in whichattackers combine common terms of known package names, e.g., twilio > twilio-npm to fool victims
An example of a supply chain attack involving package typosquatting or dependency confusion: Bug hunter Alex Birsan demonstrated the potential for dependency confusion in 2021 when he breached the systems of Shopify, Netflix and Tesla using the technique. In 2022, Meta’s PyTorch project suffered a supply chain compromise due to a dependency confusion attack.
#4: Targeting open-source software:
Open-source projects are widely used in software development. Attackers exploit this popularity (and the potential access that comes with it) by contributing malicious code or using phishing attacks to access developer accounts and upload malware from a seemingly trustworthy source.
An example of how an open source software project was used to launch a supply chain attack: The XZ Utils attack (CVE-2024-3094) in 2024 showed how an attacker called “Jia Tan” was able to become a trusted co-maintainer of a crucial library in several Linux distros. The attacker created a backdoor that had potential to impact embedded systems and cloud environments globally. Before it could be executed, the attack was uncovered accidentally.
Did you know?
Following a flood of malicious typosquatting projects, the maintainers of the Python Package Index (PyPI) suspended new user sign-ups in March 2024. Malicious packages targeting machine learning libraries such as Pytorch and Selenium were uncovered and, in some instances, appeared to be part of an automated process.
Why are so many organizations at risk from software supply chain attacks?
Companies that aren’t rooted in software development are building, developing, and shipping software, often without the tooling and integration with the CI/CD pipeline they need to make DevSecOps a reality. Bake in accelerated release cycles and an output that’s often going to the cloud, and it’s easy to understand why exploitation of vulnerabilities continues to be a key path to breach initiation.
Some key drivers of software supply chain risk are:
Short release cycles and rapid iterations:
The speed of development makes the introduction of vulnerabilities more likely. But keeping track and keeping up are a massive challenge for AppSec and DevOps teams. Add increased reliance on open-source code and the prevalence of coding flaws, and the risk surface expands even more.
Traditional approaches to AppSec can’t keep pace:
Accelerated SDLCs and everything-as-code are the new reality. Despite advances in tools and information, research into over 100 million supply chain security alerts from tens of thousands of repositories, applications, and organizations found that all three of the most prevalent software supply chain vulnerabilities have been around for years:
- Command injection (15.4% of applications)
- Sensitive data in log files (12.4% of applications)
- Cross-site scripting (XSS – 11.4% of applications)
Alert fatigue and complexity:
Despite widespread awareness threats like XSS are introduced during the development process all the time. This isn’t due to malice or oversight; it’s due to the fact that managing security in an accelerated development environment is tricky. Modern web applications are complex, with many interconnected components and dependencies — the likelihood of vulnerabilities slipping through the cracks is high. And if your AppSec team is wading through 100,000+ alerts, triage gets overwhelming pretty quickly.
Almost every organization has high severity risk within their software supply chain
Research shows that 95% of organizations have at least one high, critical, or apocalyptic risk within their software supply chain, with the average organization having nine.
What are the most common vulnerabilities in the software supply chain?
Five of the most common vulnerabilities in the software supply chain are:
1. Open-source libraries:
Many applications rely on open-source components containing known vulnerabilities.
2. Secrets leak:
Code repositories often expose sensitive information such as API keys and passwords, facilitating attacks.
3. The CI/CD pipeline:
Unsecured software development pipelines are vulnerable to attack and exposed to malicious injections and data leakage. Unsanitized metadata and excessive contributor privileges increase the risks.
4. Malicious packages in public registries:
Attackers upload legitimate-looking malicious packages to popular public registries, like PyPI and NPM.
5. Malicious installation scripts:
Malicious scripts can be injected into installation packages for legitimate software. These are executed during installation, compromising systems and potentially giving attackers wider access to resources to execute further attacks.
How to secure against software supply chain attacks
Supply chain and third-party risks accounted for 15% of breaches in 2023-2024 — a 68% YoY increase. Strategies and tactics for managing and addressing software supply chain risk include:
Vulnerability and patch management:
This starts with identifying, prioritizing, and patching known vulnerabilities, not just in already-deployed software, but throughout the build, preventing it from becoming an issue in the first place. already deployed. Context is key here: for your business, a high criticality vulnerability on a single, low-use server may not carry the same potential for negative business impact as a medium-grade vulnerability on a widely used application.
Third-party risk assessment:
The trend towards third-party risks has increased so much that Verizon’s 2024 Data Breach Investigation Report (DBIR) re-defined the concept of third-party breaches to include vulnerabilities in partner or third party software. In this environment, there is a clear advantage for both software developers and application users to adopt a proactive approach to gaining complete insight into the third party dependencies in their codebases and development environments. Supply chain security platforms help software developers to implement secure-by-design practices, in conjunction with frameworks such as the NIST Cybersecurity Framework (CSF) or ISO 27001. Organizations can take a proactive approach to third-party risk by vetting vendors to ensure that the
Implementing secure software development practices:
Integrate security from beginning of the software development lifecycle (SDLC) — from design to deployment. Secure coding practices — where code meets defined requirements and standards —and ensuring that vendors meet these same standards also reduce risk.
Software composition analysis (SCA):
Software composition analysis tools enhance AppSec and mitigate software supply chain risk by auditing code, including third-party components, and recommending patches. SCA also flags out-of-compliance code and facilitate software fixes during development.
Software Bills of Materials (SBOM):
SBOMs mitigate supply chain security risk through comprehensive, detailed visibility into the components and dependencies of software. This insight allows AppSec teams to identify and manage vulnerability across the organization’s specific software supply chain. SBOMs give defenders the data they need to make informed decisions about software security, making breach identification easier (and quicker). Organizations can generate their own SBOMs or request them from software vendors. OX Security’s proprietary Pipeline Bill of Materials (PBOM) standard takes SBOM to the next level, providing a comprehensive list of software lineage, from the first line of code to release, while identifying threats.
SBOMs are crucial in managing supply chain risk
The crucial role played by SBOMs in managing software supply chain risk was underlined by a White House Executive Order (EO) in 2021. The EO mandated that software providers to U.S. Federal agencies be able to generate SBOMs for the software they develop. Specifically, the EO stated:
“Understanding the supply chain of software, obtaining an SBOM, and using it to analyze known vulnerabilities are crucial in managing risk.”
How does Application Security Posture Management (ASPM) help with software supply chain security?
For AppSec defenders, ASPM is a new approach. It removes historical siloes between application and vulnerability scanning tools, which provides more context and gives AppSec practitioners the ability to prioritize, fix and track issues throughout the SDLC. For example, AppSec teams can now not only identify software libraries used in their code, but also see code flaws, dependencies and vulnerabilities, understand how the components impact one another and the business, and make informed risk decisions based on contextualized evidence, not just data.
The ability to trace source code to all its sources — along with accompanying vulnerabilities — allows teams to move beyond simple identification and into holistic risk management. With ASPM, AppSec and developer teams can evolve from simply finding CVEs to understanding and flagging libraries that are badly maintained/ have poor hygiene/are out of date. This adds the contextual component missing from siloed, traditional AppSec and DevOps processes.
What’s the difference between ASPM and Software Supply Chain Security (SCSP) platforms?
While ASPM focuses specifically on securing the application development lifecycle, from development all the way to production, supply chain security platforms focus on securing the entire software supply chain, from managing risks in third-party dependencies and open-source components through to the wider software ecosystem.
Which option is best for your organization?
ASPM is a strong option for application-centric organizations that need to secure their own, in-house developed software. It supports deep integration with DevSecOps workflows and drives policy enforcement for a more secure development environment.
Software supply chain security platforms are a good fit for organizations that have complex supply chains comprising multiple vendors, open-source libraries and external dependencies. In sectors where supply chain vulnerabilities have capacity to cause significant, serious impact – critical infrastructure, healthcare, etc. – the ability to identify and mitigate compromised components in vendor software is crucial.
Depending on the needs and size of the organization, ASPM and SCSP complement each other – organizations with complex supply chains that also develop applications could benefit from integrating both.
One in five applications contain run-time exposure
20% of all applications have high, critical or apocalyptic issues during execution, the phase at which attackers deploy malicious code. The most significant number of security issues are found in later attack phases, where the potential impact on business operations is higher.
What is the OSC&R framework and how does it help prevent supply chain attacks?
Inspired by the MITRE ATT&CK framework, the Open Software Supply Chain Attack Reference (OSC&R) framework is designed specifically to help organizations understand, analyze and mitigate software supply chain attacks.
OSC&R takes an attacker-centric view, with phases and TTPs (tactics, techniques, and procedures) specific to software supply chains, giving AppSec teams a new way of thinking about their environment. By understanding how attackers view and target the attack surface of the supply chain – and by using a common language to describe threats – AppSec, DevOps and security teams can align more effectively to mitigate risk at every stage of the SDLC, and in some cases, avoid introducing it in the first place.
Five ways AppSec teams can leverage OSC&R to improve software supply chain security
Understanding where your applications are most vulnerable from an attacker’s point of view can obviously be a great help to your AppSec strategy. The OSC&R framework takes tools to the next level, contextualizing risk and helping both AppSec and AppDev teams keep up with the latest supply chain attack trends.
Here are five ways to improve the security of your software supply chain immediately:
Continuously test posture and strengthen defenses:
OSC&R gives a uniform, thorough framework through which to evaluate security posture, pinpointing gaps and vulnerabilities, and enhancing context for AppSec and DevSec test outcomes.
Verify dependencies: open source, containers and operating systems:
Meticulously inspect dependencies, ensuring that every layer is not only secure, but free from critical vulnerabilities and potential backdoors.
Scrutinize code and APIs:
Use OSC&R for comprehensive analysis of codebase and APIs, identifying potential vulnerabilities and enabling a proactive approach to mitigation before they can evolve into pathways of exploitation for attackers.
Banish harmful residues, like passwords and secrets:
OSC&R provides a means to examine secrets through an attacker’s lens, understanding the TTPs they use to exploit them. Use this insight to eliminate unwanted, forgotten passwords and secrets from your codebase.
Meticulously inspect dependencies, ensuring that every layer is not only secure, but free from critical vulnerabilities and potential backdoors.
Ensure production integrity:
OSC&R enables teams to rapidly distinguish between critical security blockers – actual kill chains – and hygiene issues that, while not optimal, may not warrant a complete halt to the deployment process.
Why OX for software supply chain security?
Ox Security’s Active ASPM platform unifies application security practices and mitigates risk across the entire software supply chain. It effectively tackles the challenges of coverage gaps, delays, and workflows often seen in fragmented collections of widely used AST, ASPM tools, SBOM and Software Supply Chain platforms.
OX Security’s unique Pipeline Bill of Material (PBOM) and OSC&R framework provide comprehensive security coverage with end-to-end visibility from code to cloud. OX enables security and development teams to focus on the most critical vulnerabilities, cutting mean time to resolve (MTTR) from weeks to days.
Learn more, book a demo
