Most application security programs still treat dependency risk like an inventory problem. Generate an SBOM, scan a manifest, sort the findings, and hope that process will stop modern supply chain exploits.
Attackers do not need a known CVE in a declared dependency to win. They need a trusted path into your build runner, developer workstation, release pipeline, plugin system, or production workload. Manifest scanning delivers hygiene and visibility, which still matter, but prevention now depends on watching how third party code behaves while it is being resolved, installed, loaded, and executed.
For application security leads and chief product security officers, this changes where control has to live. The center of gravity moves away from static dependency lists and toward real-time runtime analysis in CI, build, and production. Software engineers feel this shift first because the failure mode is operational, not theoretical. A package with a clean history can still spawn a shell during install, reach an unexpected endpoint, scrape tokens from the environment, or load code paths your scanner never modeled.
Manifest Scans See Declarations, Attackers Target Execution
Traditional application security scanners were built for a world where known vulnerable components were the main dependency problem. That world still exists, but it no longer defines the sharp edge of supply chain risk. In recent registry compromises and dependency abuse campaigns, malicious code arrives through normal package flows, executes during installation or build, steals credentials, then spreads through the same trusted channels your teams use every day.
A manifest or lockfile cannot tell you enough about that moment of execution. It cannot tell you whether an install script launched a child process, whether a build step reached a new domain, whether a runtime loader pulled an unexpected library from the environment, or whether the deployed service is actually running the component version your SBOM declared. AppSec teams keep asking static tools to answer behavioral questions, then act surprised when blind spots turn into incidents.
The core mistake is making the trust decision at execution time, while the control is stuck at declaration time.
Runtime Analysis Changes the Unit of Trust
Teams have spent years treating the package and version as the main unit of trust. Real prevention requires a different one, the observed execution event tied to provenance, context, and behavior.
Map it to how exploits actually unfold, and the sequence gets concrete. A package gets resolved from a registry. An install hook runs. A build container inherits cloud credentials. A test job opens outbound network connections. A service starts and dynamically loads code that never appeared in the original manifest. Those are the moments that matter, because that is where attacker intent becomes visible.
Real-time runtime analysis gives AppSec a way to inspect those moments directly. It can show which dependencies were actually loaded, which vulnerabilities are reachable in executed paths, which processes a package spawned, and whether its runtime behavior matched the trust assumptions established in build provenance and policy. That is a much sharper control surface than a list of components with known issues.
Prevention Depends on Policy at the Right Execution Points
Security leaders often make this harder than it needs to be. They hear “runtime” and imagine a heavy production control that slows engineering and floods teams with noise. That kind of control fails fast, so the better move is targeted enforcement at the highest-risk execution points.
Start where third party code first gains power inside your environment. CI runners, build agents, package installation steps, release signing workflows, and privileged production services deserve the strongest inspection. A focused policy set usually carries the most value:
- Block first-seen packages or versions from privileged build paths until behavior is observed.
- Flag install and postinstall scripts that invoke shells, make outbound connections, or inspect environment variables.
- Alert when runtime-loaded components do not match approved manifests, lockfiles, or attestations.
- Prioritize flaws that are actually reachable in executed code paths.
- Require stronger provenance verification for components entering sensitive products or services.
This is where basic scanners fall short by generating backlog, while runtime analysis creates decision points. That difference matters to product security, because backlog can be ignored for months, while a build gate or runtime policy changes attacker economics immediately.
SBOMs Still Matter, but They Need a Live Counterpart
There is no reason to swing from scanner worship to scanner rejection. SBOMs, VEX data, provenance, and software composition analysis remain useful for procurement, triage, governance, and incident response. They help teams understand what should be present and where public vulnerability intelligence applies. Product security programs need those artifacts.
What they do not provide is proof of current behavior. A declared dependency graph is a design artifact, while a runtime dependency graph is an operational fact. Mature AppSec programs compare the two continuously. When they drift, the issue is not clerical. Drift can mean automatic updates, environment-based resolution changes, compromised build inputs, or malicious code loading through trusted extension points.
Modern supply chain exploits keep exploiting that gap between declared intent and observed execution. For business decision makers, the lesson is that transparency without validation creates a false sense of control.
Ownership Has to Cross AppSec, Platform, and Product Engineering
Many teams miss the organizational problem after they understand the technical one. Runtime analysis for supply chain risk does not fit neatly inside a single scanner budget or a narrow AppSec workflow. The telemetry often sits with platform engineering, the build controls with DevOps, and exception handling with product teams, while accountability for customer impact sits with the product security office.
That split explains why weak controls survive for so long. Every group can point to something it already does. AppSec scans manifests, platform logs processes, engineering pins versions, and security architecture reviews CI, yet nobody owns the full trust path from dependency resolution to runtime behavior. Chief product security officers should close that gap by assigning one operating model for policy, exceptions, and response. Without that, runtime analysis becomes another isolated tool instead of a prevention layer.
A Product Release Scenario That Exposes the Gap
A software team is preparing a release for a customer-facing platform built from several services, a front end, and internal shared packages. One service pulls a routine package update from a public registry through the standard build process. The manifest scanner reports no known vulnerability, so the pipeline continues.
During installation, the updated package runs a script that spawns a shell, reads environment variables, and attempts outbound network access from the build runner. A real-time runtime analysis policy catches the behavior because install steps in privileged CI are not allowed to launch unexpected child processes or touch secrets outside an approved path. The build is stopped before the release artifact is signed.
Without that runtime control, the package would have entered the artifact stream with a clean bill of health from static dependency tooling. That is how modern supply chain exploits reach production even when the scanner dashboard looks green.
Actionable Takeaways
- Treat manifest scanning as a hygiene control and governance input, not as your main prevention layer for dependency abuse.
- Instrument CI, build, and high privilege workloads so AppSec can observe package behavior where trust is granted.
- Write policies around execution events that matter most, including install scripts, unexpected network egress, dynamic loading, and secret access.
- Compare declared component inventories with what is actually loaded and executed in deployed environments.
- Assign a single operating model for exceptions and response so platform, engineering, and product security are enforcing the same trust rules.
The Trust Boundary Has Moved
Application security leaders who still anchor supply chain defense in traditional scanners are defending the wrong boundary. The decisive moments happen when external code enters a trusted workflow and starts doing work on your systems. That is where your controls need to be sharp, fast, and enforceable.
Modern supply chain exploits thrive in the time gap between “this dependency looks acceptable” and “this dependency is executing inside a trusted environment.” Close that gap with runtime analysis, and the scanner regains its proper role. Leave it open, and the cleanest manifest in the world will not save your release pipeline.
