Software is being built faster than ever, but application security has not kept up.
Modern applications are no longer written from scratch. They are assembled from open source packages, third-party components, APIs, containers, and AI-generated code. That shift accelerated development, but also introduced a new reality: most of your software is not code written by you.
As software supply chains grow more complex, attackers follow the same path. Rather than attack finished applications, threat actors now target the very systems, dependencies, and workflows used to create them — turning the software delivery process itself into the new attack surface.
Open source is the foundation of modern development, enabling teams to move faster, reuse proven components, and focus on delivering value.
But that efficiency comes with trade-offs.
Public ecosystems now contain hundreds of thousands of malicious or compromised packages, many designed to blend in with legitimate components. Here are a few common techniques:
Attackers use typosquatting to publish packages that closely mimic popular libraries with slight name changes.
Some packages contain hidden malicious behavior that only activates under specific conditions, making detection more difficult.
Trusted packages become compromised over time, either through maintainer account takeovers or malicious updates.
The challenge isn't just identifying malicious packages, but understanding the entire dependency chain behind each component. A trusted library can pull in dozens of indirect dependencies, each with its own risk.
As dependency usage scales, so does uncertainty.
While dependencies are one entry point, the delivery pipeline is another.
CI/CD systems, build servers, and artifact repositories are designed to automate delivery, but they also concentrate trust. If something goes wrong here, it affects everything downstream.
This makes the pipeline an attractive target because:
Sensitive data such as credentials, API keys, and tokens are often exposed in code or configuration files, turning repositories into high-value targets.
Attackers can modify pipelines or bypass checks, allowing malicious code to move through trusted workflows.
In some cases, attackers inject code during the build process, so even clean source code produces compromised artifacts.
Compromised developer tools, including IDEs and AI-assisted tools, can directly introduce risk into development without clear signals.
When the pipeline is compromised, trust in the output breaks down.
The third area of risk is less visible but just as critical: the development environment.
Modern software delivery relies on interconnected systems like repositories, build machines, and cloud services, which all communicate through service accounts and automated workflows. Often, these systems operate with more access than they actually need.
That creates an opportunity for attackers. Once inside, they can move laterally across systems, escalate privileges, and access sensitive resources. Without clear insight into who has access to which systems, it becomes difficult to detect abnormal behavior or contain a breach early.
Across all three areas — dependencies, pipelines, and environments — the pattern is the same.
Software delivery relies heavily on implicit trust:
Trust that dependencies are safe.
Trust that pipelines haven't been altered.
Trust that internal systems are secure.
That model no longer holds. As software supply chains become more distributed and automated, trust needs to be verified, not assumed.
This is where traditional security approaches fall short. Perimeter defenses and post-build scanning can catch some issues, but they do not address how risk enters the system in the first place. By the time issues are detected, they're often already embedded in the delivery process.
Rather than try to secure the edges, organizations can focus on securing the process itself, from the moment a dependency is introduced to the moment software is deployed.
That means:
Controlling what enters the development environment.
Verifying the integrity of code and artifacts throughout the pipeline.
Reducing unnecessary access across systems.
Monitoring for unexpected behavior in real time.
In other words, shifting from reactive defense to proactive integrity.
This is the foundation of a software supply chain security playbook — a set of practices designed not only to detect risk, but also to prevent it from entering the system in the first place.
Software supply chain risk is not a new category of security. It's the natural result of how modern software is built.
As development becomes faster and more dependency-driven, the attack surface expands alongside it. And as that happens, security must evolve from something applied at the end to something embedded throughout the SDLC.
The organizations that adapt will be the ones that reduce implicit trust, increase visibility, and treat software delivery itself as something that must be secured.
For a deeper look at these trends, explore the full Software Supply Chain Security Playbook research from Gartner®.
Gartner, The Software Supply Chain Security Playbook, Aaron Lord, Manjunath Bhat, Mark Horvath, 23 October 2025
GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.