There are lots of terms used to generalize what a mature application security program looks like. Find & Fix. Continuous Remediation. Code to Cloud, Unified Risk. The underlying message in these buzzwords is the same: security needs to be systemic. Defense in Depth is preached as a security best practice by leading cybersecurity agencies like NIST and CISA, and these principles are especially relevant to the metastasizing software supply chain risk seen across enterprises. Veracode’s 2026 State of Software Security Report found that third-party code continues to dominate critical security debt, now representing 66% of the most dangerous, long-lived vulnerabilities across application portfolios.
These dangers have been realized in the wake of high-profile attacks like the Shai-Hulud worms and the increased usage of open-source code from coding agents, prompting organizations of all sizes to harden and mature their software supply chain security. Balancing a high level of security with fast development velocity and a reasonable budget is difficult. It requires security checks across various “layers” of the Software Development Lifecycle (SDLC), which corresponds to preventing the introduction of supply chain vulnerabilities, discovering and responding to existing supply chain risk, and mitigating damage from a supply chain incident.
To have a mature software supply chain security program, organizations should implement supply chain detection and response across the device, repository, and production layers in order to implement a “Defense in Depth” approach to their third-party risk. The key to Defense in Depth is that no single layer is sufficient on its own; each layer both protects its own environment and reduces the burden on the layers that follow it; a breach that originates at the device layer and another originating from the production layer carry the same ultimate implication: once an attacker gains a foothold, they can traverse the network, escalate privileges, and reach production systems. Securing each layer in sequence ensures that an attacker must defeat multiple independent controls rather than a single point of failure.
The First Layer of a Mature Software Supply Chain Security Program: The Device Layer
Following along with the stages of the SDLC, the device layer is the first environment at risk, as developers are constantly downloading and creating new features with third-party packages from public ecosystems.
The Problem
The critical attack vector at the device layer is developers downloading and executing malware through common package managers. Workstations harbor sensitive data such as passwords, customer information/projects, and propriety codebases, making them a prime target for attackers – and subsequently an essential asset to protect. Worm-based attacks in popular ecosystems such as npm have become commonplace as seen by Shai-Hulud worms, and most recently the ChainDrop attack, which compromised over 400 high-profile packages.
The relatively sudden increase in supply chain risk is attributed to AI adoption and its improved capabilities in a few ways. The enterprise standards for development velocity have multiplied. Managers expect new adoption of coding agents to yield faster features, which it generally does; new features often require third-party components, and with increased time constraints, developers have less time to research libraries they’re utilizing. Often developers themselves aren’t the ones introducing these libraries. Coding agents will automatically install libraries to assist with feature development and due to the increased velocity, agents have less supervision over low-level changes or package introduction.
Crucially, a compromised developer device is not just a device problem; it’s the first link in the chain that leads to production. A developer workstation is an entrypoint into the corporate network, with access to source code repositories, build pipelines, and cloud credentials. Once malware establishes a foothold on a device, an attacker can traverse from that workstation into the network, move laterally toward production systems, and exploit misconfigurations they find along the way. This is why the device layer matters to the production layer: stopping malware at the device prevents it from ever becoming a launchpad for a network-wide breach. The same traversal path that a production-layer misconfiguration enables can be initiated from a compromised device, which is why Defense in Depth demands that the device layer serve as the first checkpoint, not the only one.
In addition to gaining protection from malware, integrated security at the device layer makes security at subsequent layers significantly easier. This is why organizations have been trying to “shift left” for years, to make security more of a continuous process that’s baked into every delivery.
The Solution
A package firewall incorporates security into every build of your project. Firewalls act as a proxy that sits between developer devices and the public repository, filtering every package downloaded to determine what is safe to download and what should be blocked from developer devices.
Scanning every unique hash of a package protects developers from worm-based malware, targeted malware campaigns and other unknown packages that are pushed to the registries. The package firewall also strengthens traditional vulnerability detection by preventing the introduction of security debt earlier in developer’s workflows. Think of your firewall as a vaccine where traditional Software Composition Analysis (SCA) tooling would be the cure. By blocking malicious packages before they ever touch a developer device, the firewall removes the very foothold an attacker would need to traverse into the network and reach production. This reinforces the Defense in Depth chain at its first and most exposed link.
The Second Layer of a Mature Software Supply Chain Security Program: The Repository Layer
Code repositories are the ultimate source of truth for an application, accessed by developers on a daily, even hourly basis. Protecting the integrity of this source of truth manages the security of the application in production, by removing any vulnerabilities that would be propagated into production systems.
The Problem
With an effective device-layer security solution in place, code repositories become the second line of defense. The consequences of software vulnerabilities aren’t realized until production, and these consequences consists of vulnerabilities that can cause information leakage or remote code execution via attack vectors such as insecure deserialization, SQL injection, or flawed authentication. This is where Defense in Depth shows its value: the repository layer catches the vulnerabilities that slip past the device layer’s package firewall, ensuring that even if a risky dependency makes it onto a developer’s machine, it is identified and remediated before it can propagate into production and become an exploitable weakness there.
The Solution
This is why SCA remains the foundation of any mature AppSec program. Advanced capabilities such as identifying deeply nested transitive dependencies, reachability of a vulnerability, and supporting a wide variety of coding languages and package managers are the minimum expectation now.
Most importantly, the effectiveness of any scanning tool is limited by its data; a solid SCA vendor needs up-to-date vulnerability reporting, the ability to discover new vulnerabilities, and a prioritization process to more accurately reflect the severities of vulnerabilities. Even most sophisticated detection tool won’t find anything without a proper data backing.
A bonus is if your SCA integrates seamlessly with your package firewall. Marrying the detection from these two layers gives a couple advantages:
- Consistent Policy Enforcement: A consistent list of prohibited packages is blocked uniformly, from the developer’s initial download to the final build step. There’s no discrepancy in packages that are allowed on developer machines but fail CI/CD pipelines.
- Centralized Visibility: For leaders on the hook for managing and responding to supply chain incidents, having a central place to visit for monitoring your 3rd party package risk, whether it’s at the repository or device level, can be invaluable and a huge time save.
The Third Layer of a Mature Software Supply Chain Security Program: The Production-facing Layer
If vulnerabilities make it into production code or can’t be removed from production code for various reasons, mitigation kicks in. That’s why the third layer of a mature software supply chain security program is the production-facing layer. This is the final checkpoint in the Defense in Depth chain, meaning its the layer that contains the blast radius when an attacker has already slipped past the device and repository layers.
The Problem
A misconfigured container where a vulnerability is exploited acts as the catalyst for a sophisticated, network-wide security incident. As demonstrated in our “Defending the Modern Supply Chain” webinar, after achieving Remote Code execution attackers can escalate privileges, traverse networks, and access further information if given root access within a container. If container environment variables are exposed, secrets can be stolen to open additional attack vectors and persist the attack. This is the same traversal pattern that a device-layer compromise enables, which is precisely why both layers must be secured. Whether an attacker’s foothold begins on a compromised developer workstation or inside a misconfigured production container, the result is the same: lateral movement across the network, privilege escalation, and access to sensitive systems. Defense in Depth means that the production layer must be hardened to contain a breach regardless of where it originates.
Making sure your containers are correctly configured and are operating under least privileges, whether it’s within an on-premise or a cloud environment, can significantly limit the damages from a breach exploiting one of these vulnerabilities.
The Solution
Traversal and attack surfaces are effectively managed by a Cloud Security Solution. These can be deployed in cloud environments, native, or third-party to cloud providers, like Wiz,. They can be run as static solutions as well.
Traversal and attack surfaces are effectively managed by a Cloud Security Solution, and organizations generally have two paths to choose from. The first is leveraging the built-in detection capabilities of the cloud provider itself; AWS, for example, ships its own security services that monitor for misconfigurations and suspicious activity within your environment. The second, and often the more comprehensive option, is adopting a Cloud-Native Application Protection Platform (CNAPP). These platforms unify container scanning, infrastructure-as-code analysis, and runtime monitoring into a single view, giving security teams a clearer picture of risk across their entire cloud footprint than provider-native tools tend to offer on their own.
Under the hood, many of these solutions rely on eBPF (extended Berkeley Packet Filter), a technology that has become the standard for accurately monitoring cloud containers at runtime. eBPF allows security tools to observe system calls, network connections, and process behavior inside containers with minimal overhead, making it possible to detect traversal and privilege escalation as it happens rather than after the fact.
While some live-network monitoring is essential, network risk can also be captured from scanning static configuration files such as Dockerfiles, terraform manifests, and helm charts. IaC and Container scanning solutions are fast, cheap, and can run on every pull request to monitor the security of a network on every new commit. By catching misconfigurations before they reach a running environment, container scanning closes the last gap in the Defense in Depth chain. This ensures that even when a vulnerability or a compromised device has cleared the earlier layers, the production environment itself is hardened against traversal and escalation.
Next Steps to Mature Your Software Supply Chain Security Program
The emergence of additional security tools over recent years has been intentional to mitigate different attack vectors for organizations. Software Supply Chain Security should be moderated across three layers: the developer (and now general employee) device layer, the repository code layer, and the production-facing container layer. There is no substitute for a good dependency scanning SCA tool to help identify and prioritize vulnerabilities in your code. However, these traditional tools will not help you secure the device and production layers, so supplementing these with a package firewall and a container scanning tool promises a robust security solution that has the critical components of a SSCI management program. Combined, this covers your prevention, detection/response, and mitigation.
An attacker only needs to defeat one of them to initiate a breach, but Defense in Depth means they must defeat all of them to succeed. A package firewall identifies, quarantines and reports on malware before it’s execution. SCA in the repository catches vulnerable dependencies before they reach production. Container scanning hardens the production environment against traversal and escalation. Each layer reduces the burden on the next, and together they ensure that a breach originating at any single layer is contained before it can cascade across the network.
To save cost, reduce time to remediation, and maximize tool capabilities, many enterprises choose to consolidate their different tools under one vendor. This streamlines the support process and improves visibility into your security program. To find the best vendor to cover all software supply chain risks, explore the KuppingerCole 2026 Software Supply Chain Security Leadership Compass which identifies the top solutions.
