TLDR
- Supply-chain attacks are rising toward US $60 billion in global impact, with Reddit discussions showing how often compromised libraries and poisoned AI models enter production, making dependency trust a central engineering concern across delivery pipelines.
- A 12% increase in exposed secrets and cases like ua-parser-js show how small gaps in package ecosystems scale into widespread compromise, turning a single dependency into a vector that reaches millions of systems.
- Attackers now corrupt open-source AI models, weights and datasets in ways scanners miss, expanding the supply chain across classical libraries and many AI components.
- Build pipelines, base images and registries from high-impact entry points where one altered component affects every downstream deployment, creating a steady spread across environments.
- Legacy tools lack provenance and lifecycle context, leaving teams with long issue lists but no clear linkage, which is why SBOM + PBOM lineage and constant monitoring are now mandatory.
- OX Security gives teams a complete application vulnerability assessment that unifies visibility across code, builds and runtime by integrating SBOM, PBOM and behavioral signals, creating a single source of truth that strengthens supply-chain control.
Software-supply-chain risk has shifted dramatically in the last six months. Forecasts from Cybersecurity Ventures now estimate the global cost will hit $60 billion by 2025, but the number itself isn’t the headline, the reason behind the spike is. Attackers are no longer tampering with isolated packages; they’re moving deeper into build pipelines, registries, model sources, and automation systems, bypassing the traditional gates DevSecOps, AppSec, and security leaders rely on.
Recent data reinforces the trend as well. The NTSC 2025 Software Supply Chain Security Report highlights a 12% increase in exposed developer secrets and sensitive artifacts across open-source ecosystems, not because teams became careless, but because the attack expanded into components that were never created to be monitored. Meanwhile, industry tracking shows supply-chain attacks doubling year-over-year in 2025, reflecting a shift toward upstream compromises that propagate silently across CI/CD workflows and dependency chains.
What stands out across the last half-year of incidents is not the volume, but the reach. One poisoned dependency, one compromised build job, or one manipulated model weight now affects entire fleets of applications.
Automation magnifies the blast radius. Integration hides the weak points. And traditional scanners, built to detect CVEs, not tampered artifacts, simply don’t see the failures happening between library updates, base-image inheritance, artifact promotion, and model sourcing.
For DevSecOps, this collapse of trust boundaries is already operationally felt. For AppSec, the definition of “software composition” has expanded far beyond third-party libraries. And for security leadership, supply chain has become the highest-impact attack with the lowest present-day visibility.
This is the gap OX addresses. OX links code changes, dependency shifts, build outputs, and runtime behaviour into a single view that reflects how software is actually assembled. It gives teams a way to observe what moves through the SDLC, who introduced it, and how it changed, which is critical in environments with many repositories, many services, and rapid update cycles.
This article explains why the last six months represent a turning point for software supply-chain risk, and what teams must do now to regain lifecycle-wide control before these upstream weaknesses become downstream incidents.
What “Supply Chain” Really Means for Software?
In engineering environments, the software supply chain extends far beyond dependencies. It’s the full ecosystem of components, tools, automations, services, and artifacts that participate in building and delivering software. Every one of these elements carries its own trust assumptions, and when any link is compromised, the impact propagates across downstream environments regardless of whether your code changed at all.
A supply chain includes internal code, third-party libraries, base images, build jobs, registries, model files, IaC modules, and everything in between. Seeing it as a single lifecycle, rather than isolated parts, is the only way to understand how attacks spread.
Here are the categories that now define software supply-chain risk:
Let’s break down each category of supply-chain elements. First, we have:
1. Dependencies and open-source components
Every direct or transitive dependency pulled from public ecosystems contributes to your supply chain. Applications easily accumulate hundreds of transitive packages across npm, PyPI, Maven, NuGet, and similar registries.
The risk lies in:
- deeply nested dependency trees no team watches
- abandoned or unmaintained packages susceptible to takeover
- dependency-confusion collisions between internal vs. public namespaces
- unsigned or unverifiable package versions
- typosquatted or version-bumped packages intended to bypass constraints
A compromised leaf-dependency doesn’t appear in your code review, but it flows through builds, containers, and deployments unnoticed, which is why dependency health and provenance tracking are important.
2. Base images, containers, registries
Containers inherit trust from whatever they’re built on. A flawed or tampered base image becomes part of every downstream workload that uses it.
Key risks include:
- minimal or distroless images carrying outdated system libraries
- registry mirrors serving modified image layers
- pulls based on mutable tags (latest, stable) rather than immutable digests
- shadow layers left behind in multi-stage builds
- unsigned image manifests lacking integrity guarantees
Because a single base image may underpin dozens of microservices, corruption at this layer creates a wide blast radius across environments.
3. Build pipelines and tooling
Build systems are part of the supply chain because they create the software you trust. Attackers growingly target CI/CD infrastructure because it has access to:
- source code
- signing keys
- cloud credentials
- artifact-publishing permissions
Practical risks include compromised runners or agents, malicious pipeline plugins, tampered build scripts, leaked secrets inside pipeline environments, and unauthorized artifact promotion. A breached pipeline can generate cryptographically valid but malicious artifacts, making prevention and monitoring far more important than post-build scanning.
4. AI/model artifacts and vector stores
AI components now function as software dependencies. Pretrained models, embeddings, tokenizers, and datasets sourced from public hubs often lack strong provenance or integrity controls.
Attack patterns include:
- poisoned datasets embedding hidden triggers
- manipulated model weights, altering behavior under specific inputs
- compromised tokenizers changing how models interpret text
- vector-store pollution that skews retrieval-augmented output
- unsigned or unverified model artifacts downloaded from public repositories
These issues rarely appear in classical vulnerability scanners, yet they have a direct impact on application correctness, security, and data exposure.
5. Deployment and runtime environment
Finally, once the software is built and deployed, the runtime environment, containers, serverless functions, orchestration platforms, and infrastructure-as-code modules extend the supply chain.
Application security testing covers some of these layers, but the operation remains broad because many runtime components are supplied or maintained by external parties. A managed container runtime, a third-party service broker, or a plug-in library can introduce new risks without any direct change in your codebase. Every runtime agent, service mesh plug-in or library loaded at run time forms part of that chain.
Software today is an assembly of interconnected elements, code, packages, images, pipelines, models, and operational services. The weakest link is rarely the application code itself; it’s far more often a small, inherited component buried in a dependency graph, a build step no one monitors, or a platform layer maintained by a third party.
Understanding the supply chain as a single continuous system is the only way to see where integrity truly breaks.
The Growing Threat Landscape
The scale of software supply-chain attacks is growing faster than most teams expected. Cybersecurity Ventures estimates global damages will reach US $60 billion by 2025, with projections climbing toward US $138 billion by 2031. These aren’t abstract numbers; they represent the rising cost of compromised build systems, poisoned dependencies, tampered containers, and upstream service breaches that ripple across entire ecosystems.
Industry tracking shows the same trend at the organizational level. As per Gartner, by the end of 2025, nearly 45% of companies are expected to have faced at least one software supply-chain incident. The expansion of engineering stacks, multi-language dependencies, distributed CI pipelines, container registries, AI models, and ephemeral cloud infrastructure creates more upstream entry points than most security programs can fully observe.
As adoption of automation, open-source components, and AI frameworks continues to grow, attackers gain new surfaces to exploit. Each new integration, package, model, or service adds another potential route into the pipeline. The result is a threat landscape where new attack paths continually emerge, and compromises upstream can scale far beyond their point of origin.
Attackers Exploiting Trust in Open Source and AI Components
Open-source software components have long been a supply-chain weak point; the increased use of open-source AI models adds fresh complexity. For example, Trend Micro warns that open-source AI models can embed backdoors or be tampered with in ways that evade typical static checks and SBOM (software bill of materials)-only approaches.
Key exploitation patterns include:
- Publishing or altering AI model weights such that benign-looking models contain hidden malicious triggers.
- Introducing poisoned datasets or vector stores that downstream consumers pull in without full provenance verification.
- Compromising registries or mirrors of AI model artifacts so that what is presented as a trusted source is actually the compromised one.
These scenarios underscore that open-source and AI-model supply chains are no longer “nice-to-have” audit points but vital parts of a comprehensive risk picture.
Build Pipelines and Containers as Emerging Blast Radius
The build pipeline (CI/CD tools, containerisation workflows, base-image registries) is evolving into a high-impact attack domain. For instance, a detailed analysis of CI/CD pipeline attacks outlines how threat actors may compromise a vendor’s build infrastructure and insert malicious artefacts that then propagate to thousands of downstream consumers.
Similarly, several analyses of container ecosystems have shown that malicious or tampered base images in public registries have propagated through derivative builds and remained in use long after detection. For example, the Sysdig Threat Research Team analysed over 250,000 public Linux images on Docker Hub and found a significant number containing cryptominers, embedded secrets, and other malicious payloads.
A compromised build agent or an altered base image can push unsafe code into every artifact that depends on it, which means the impact extends far beyond a single service. One weak point in the pipeline can spread the same modification to multiple deployments and customer environments, creating a wide and difficult-to-contain chain of impact.
What Traditional Supply Chain Risk Tools Miss
Most organisations still depend on CVE scanners, SBOM tools, and post-build checks. These tools give partial insight. They do not reflect how software is assembled. They do not reflect how attacks spread through a pipeline.
Here’s a diagram that explains well:
A scanner reports known vulnerabilities, but it does not confirm whether the affected code path is reachable. Now, this is where things get different; an SBOM lists dependencies, i.e, it does not show which build created the artifact or whether the artifact changed after the build. Post-build checks confirm policy at one point in time. They do not detect threats that activate during deployment or runtime.
In my experience, traditional security tools still revolve around fixed snapshots, even though environments rarely stand still. A scan runs during the build, an SBOM is generated for a release, and a policy check executes just before deployment. Everything looks accurate at that moment, yet the system keeps evolving around it.
Pipelines shift, teams pull new base images, and model files or transitive dependencies arrive at runtime without ever passing through the original validation step. By the time anyone revisits those earlier snapshots, the gaps are no longer obvious until something breaks.
When I work with teams, this often shows up as a fragmented understanding of their own pipelines. One tool holds the base-image information, another aggregates CVEs, and a third records runtime anomalies. None of these views connect cleanly, so the team ends up with pieces of evidence that do not explain how a vulnerability entered the system or how far it has travelled. All the information exists somewhere, but not in a form that helps engineers reason about the lifecycle as a whole.
This disconnect becomes especially clear during investigations. A single incident can prompt a long chain of questions that should be straightforward to answer. Which build created the affected artifact? Which dependency introduced the issue? Which service is currently running it?
I have seen teams spend days reconstructing these links because traditional tools were never made to merge pipeline history with runtime context. Even when the vulnerability is already documented, the lack of continuity between these systems slows down every step of the investigation.
“Known Vulnerability” Doesn’t Mean Reachable or Exploitable
A CVE in a dependency does not automatically mean the application is exploitable. Traditional scanners typically bring every vulnerability found in adjective components, but they cannot determine whether the application actually invokes the affected code path. This often leads to overwhelmed engineering teams struggling in long lists of issues that technically exist but cannot be triggered.
Attackers exploit this blind spot. They know organisations often prioritise based on CVE severity alone, not on exploitability in context.
A high-severity CVE buried in code the application never calls may create urgent alerts, while a tampered model file or poisoned dependency, without a CVE at all, can sail through to production unnoticed. Without reachability analysis, behavior analysis, or runtime correlation, teams end up focusing on what is “known,” not what is dangerous.
Lack of Context Across Build → Deploy → Runtime
Most supply-chain breaches involve more than a vulnerable component, they involve the journey of that component through the pipeline. Traditional tools cannot trace how a dependency discovered at build time maps to a deployed artifact or a container running in production. They cannot identify which commit, which build agent, or which registry supplied the compromised file.
This missing linkage forces teams to investigate in silos: SBOMs live in one system, CI logs in another, runtime telemetry in yet another. When an anomaly surfaces, engineers must manually stitch together provenance: Which image digest was deployed? Which dependency graph did it use? Which environment pulled it? Without a unified lineage across build, deploy, and runtime, root-cause analysis becomes a manual, time-consuming reconstruction exercise.
Supply-chain resilience today requires more than detection. It requires the ability to trace an issue backwards, from a runtime signal to the deployed artifact, from the artifact to the build that developed it, from the build to the dependencies and model files that shaped it. Traditional tools were never built for this, and that is where their limitations become operational risks.
What Good Supply Chain Risk Management Looks Like
Supply chain risk management is no longer a matter of producing a static SBOM or running a periodic vulnerability scan. Z2Data’s 2025 guidance emphasises real-time monitoring, supplier intelligence, and contextual analysis as foundational capabilities, while Qualys highlights the need for build-stage provenance, constant trust verification, and runtime correlation.
When combined, these expectations form a clear blueprint: strong supply-chain security requires full-lifecycle visibility, provenance-aware inventories, context-driven prioritisation, and an incident-ready posture that treats software components the same way manufacturers treat physical parts.
Effective supply-chain security also means replacing one-off checks with systems that measure change over time. A component is not risky only when it contains a vulnerability, it is risky when its behaviour, version, source, or metadata changes unexpectedly.
Qualys’ analysis of resilient software supply chains reinforces this point: the highest-impact improvements come from detecting anomalies as they emerge rather than waiting for downstream incidents.
Likewise, Z2Data stresses sub-tier supplier intelligence and the ability to track the originating source for each component as important to identifying cascading risks before they become outages or breaches.
So, instead of a vulnerability-management exercise, supply-chain security becomes an operational domain where product security, DevSecOps, and platform engineering work on a shared source-of-truth for what is being built, what is being deployed, and what is running. Below are the key capabilities that mark a mature program.
Real-Time Inventory and Provenance (SBOM + PBOM)
A supply-chain platform needs more than a static Software Bill of Materials (SBOM). It requires a real-time inventory of components, combined with a Provenance Bill of Materials (PBOM) that captures how and where each artifact was created.
The PBOM includes information such as build system identity, signing keys, base images, dependency trees, and model-artifact sources. This aligns with Qualys’ emphasis on strengthening the build stage through trustworthy provenance and tamper-resistant metadata.
Real-time inventory ensures teams know not just what is inside an artifact, but how it got there. This becomes critical when dealing with fast-changing ecosystems, transitive dependencies, or AI model files downloaded during installation or runtime. Z2Data’s guidance underscores the need for “centralized, real-time visibility” into component sources and sub-tier relationships, because a bill of materials without provenance only solves half the problem.
By integrating SBOM + PBOM, organisations establish lineage: a traceable view from component → build → artifact → deployment. This lineage is the foundation of trustworthy supply-chain security.
Prioritization Based on Use, Exposure, Context
Good supply-chain risk management goes beyond severity scores. It ranks risks based on the actual exposure of a component, how it is used, where it is loaded, and what it can impact. Z2Data notes that meaningful risk reduction requires context-rich prioritisation informed by supplier behaviour, component criticality, and environmental usage.
This approach solves a major problem with traditional CVE-focused workflows: noise. A high-severity vulnerability in a dependency is only relevant if the software uses the affected function, ships the affected code path, or deploys it to an exposed environment. Qualys similarly recommends applying “context and usage intelligence” to avoid wasting time on non-exploitable issues and focusing instead on components that shape the behaviour of the build.
Contextual prioritisation ties risk to actual operations. A model file with abnormal checksum drift, a base image pulled from an untrusted mirror, or a library invoked in a privileged service should rank higher than a generic CVE buried in an unused dependency. Without context, risk signals stay isolated; with it, they become decision drivers.
Constant Monitoring Through Build, Deploy, Runtime
Z2Data’s feature list calls out constant monitoring as one of the most critical capabilities for 2025. This means detecting changes at every stage, source, build, registry, deployment, and runtime. Qualys reinforces this by stressing the value of mapping build signals to runtime behaviour so teams can detect anomalies early.
In reality, constant monitoring includes:
- Detecting changes to base images or upstream suppliers during build.
- Watching for tampered or unsigned artifacts as they move through registries.
- Monitoring runtime environments for unexpected libraries, model downloads, or injected layers.
- Tracking drift between what was built and what is running in production.
This full-lifecycle monitoring closes the gaps left by point-in-time tools. It also reduces investigation times: when a runtime anomaly emerges, the system can trace it back to a specific build job, dependency update, or supplier event.
Incident Response and Threat Intelligence on Component Risk
Z2Data emphasises real-time threat intelligence on suppliers, components, and sub-tier networks as an important capability for supply-chain resilience. Good supply chain risk management uses this intelligence to enrich investigation workflows and shape incident response.
For example, if a supplier reports a compromised package, the system should immediately identify which builds, artifacts, or deployments used that component. Similarly, Qualys highlights the importance of linking runtime behaviour to build provenance so teams can respond quickly to tampering or anomaly signals.
Incident response in supply chains requires:
- Automated mapping from a compromised dependency to affected artifacts.
- Clear lineage showing which deployments use the artifact.
- Impact analysis that identifies affected services or customers.
- Workflow triggers that isolate or revoke compromised builds.
- Threat intelligence feeds covering vulnerabilities, malicious package reports, and AI-model supply-chain attacks.
This incident-ready posture transforms supply-chain security from a reactive vulnerability-management process to an operational capability that limits blast radius and speeds recovery.
How OX Enables Supply Chain Risk Visibility and Prevention
A consistent root cause across real supply-chain intrusions is the lack of verifiable, end-to-end lineage. Most engineering teams cannot reliably determine:
- which exact dependency versions the package manager resolved during build (including transitive substitutions)
- whether a base image or upstream layer changed between builds due to registry drift or mirror poisoning,
- whether a model file, tokenizer or dataset was modified at fetch time,
- whether an artifact’s digest in the registry matches the digest created by CI, or
- how the deployed workload’s file system, containers or sidecars differ from the original PBOM.
Without cryptographically anchored provenance across code, build systems, registries, and runtime, these changes are indistinguishable from legitimate pipeline activity. Attackers exploit these blind spots by injecting altered components at points where traditional scanners and SBOM tools have no visibility, downstream of CI, inside intermediate layers, or during runtime fetches.
OX brings prevention closer to where engineering teams actually work. It is one of the few ASPM tools that gives me a unified view of code components, AI-generated artifacts, build activity and live runtime signals in a single place. Instead of treating these as separate data streams, OX connects dependency information with provenance records and behavioral alerts so the entire picture stays intact as software moves through pipelines.
What I appreciate most is that developers and security engineers operate from the same context without jumping between tools or stitching evidence together manually.
Tracking Dependencies for Code and AI Models
OX records software dependencies and AI model files in one place. The platform tracks version changes, checksum drift, and source locations. Code packages, model weights, tokenizers, and vector files share the same inventory structure. This creates one reference point for investigation.
When I open the SBOM section inside OX, I see a complete list of every library discovered across my repositories. Each row shows the package name, license type, CVE status, update history, and the source registry. This screen becomes the central reference point when I want to verify changes in version, integrity, or provenance.
To inspect a specific dependency, I click the row. The panel at the bottom expands and shows the SHA, latest version, copyright status, repository metadata and linked components. This is useful when I track Python or Node.js packages, but it becomes even more important when I handle AI model files. Model weights, tokenizer files and vector assets follow the same inventory structure. Their checksums appear in the same PBOM chain, so I can confirm whether a model changed after a build.
A service loads a model at startup. OX lists the model version, the checksum, the download source and the build that packaged it. A sudden change in the checksum triggers a signal. The team checks the record and isolates the affected build.
Embedding Supply Chain Context into Build and Runtime
OX attaches context at build time and keeps it available during runtime. The platform includes build identifiers, dependency graphs, registry sources and signing details. Runtime signals link back to the exact build. The chain from component to execution stays intact.
The dashboard gives me a full overview of alerts, prioritization, and the AppSec Data Fabric. From here, I can jump into source-control issues, open-source security, SBOM findings, IaC scanning, and CI posture. This view tells me which part of the pipeline developed a given artifact and where dependency risks concentrate.
Next, I open the application list.
This screen shows each application with its PBOM consistency grid, severity issues, business priority, and “OX in Pipeline” status. When I select an application, OX expands the Application Flow panel at the bottom, repository source, CI/CD workflow, Kubernetes footprint, and cloud services. This is the chain I use for runtime incidents.
Automating Remediation and Avoiding Risk Before Deployment
OX blocks unsafe builds and automates remediation steps. The platform checks provenance, verifies signatures and validates dependency sources. Builds stop when components fail integrity checks. Deployments stop when runtime drift appears. Here’s a snapshot:
A CI job pulls a package from an untrusted publisher. OX checks the source and marks it unsafe. The build fails and the team receives a clear reason. The unsafe artifact never reaches deployment.
Conclusion: From Visibility to Control
Supply chain risk needs coverage across code, build systems and runtime environments. Legacy scanners give limited insight because they ignore provenance, exposure and behavioral drift. Teams gain control when every component has a traceable origin and every stage produces clear signals. A unified posture creates faster investigations and smaller blast areas.
OX supports this posture with one platform for dependency tracking, provenance records and runtime context. Code libraries, base images and AI model files share the same inventory. Build events connect to runtime alerts without manual stitching. Unsafe components stop before release. Drift becomes visible before it spreads.
Teams that adopt this approach reduce uncertainty and shorten response time. The entire pipeline gains clarity because each artifact connects to a trusted history.
If you want to move your supply chain program toward full visibility and clear control, you can start by mapping your current component flow inside OX and creating PBOM records for your next build.
