Artificial Intelligence, zBlog
Software Supply Chain Security: SBOM, SLSA & What Engineering Teams Must Do
trantorindia | Updated: March 31, 2026
Software supply chain attacks more than doubled globally in 2025, with over 70 percent of organizations reporting at least one incident linked to third-party software. Global costs reached $60 billion and are projected to hit $138 billion by 2031. Sonatype identified over 454,600 new malicious packages in 2025 alone, bringing the cumulative total past 1.2 million. SBOMs, SLSA, and Sigstore have matured from buzzwords to operational requirements — driven by U.S. Executive Order 14028, the EU Cyber Resilience Act, and accelerating regulatory pressure worldwide. This guide covers what each standard does, where they overlap, what they do not solve, and the concrete steps engineering teams must take to secure their software supply chains in 2026.
What Is Software Supply Chain Security?
Software supply chain security is the discipline of protecting the integrity, provenance, and trustworthiness of every component, dependency, tool, and process involved in building and delivering software. It encompasses the open-source libraries your applications depend on, the build systems that compile and package your code, the CI/CD pipelines that deliver it to production, the container images that run it, and the developer environments where it originates.
The threat model has fundamentally shifted. Attackers no longer need to breach your production perimeter. They compromise a single upstream dependency, a build tool, a CI/CD action, or a developer credential — and the malicious code propagates downstream through the same automated pipelines that make modern software delivery fast and efficient.
The scale of the problem in 2026 is difficult to overstate. Software supply chain attacks more than doubled globally during 2025, with over 70 percent of organizations reporting at least one incident linked to third-party software or upstream components. Cybersecurity Ventures forecasts that global annual costs from these attacks reached $60 billion in 2025, climbing from $46 billion in 2023, and projecting to $138 billion by 2031 at 15 percent annual growth. Sonatype’s 2026 State of the Software Supply Chain Report identified over 454,600 new malicious packages in 2025, bringing the cumulative total of known malware past 1.233 million packages across npm, PyPI, Maven Central, NuGet, and Hugging Face.
Modern applications are built on open source. 70 to 90 percent of modern applications consist of open-source software dependencies. The average application has approximately 150 dependencies, 90 percent of which are indirect (transitive) dependencies that create hidden vulnerabilities. 80 percent of application dependencies remain un-upgraded for over a year, and 95 percent of the time when a vulnerable component is consumed, a fixed version already exists.
Three converging forces are pushing software supply chain security from best practice to baseline requirement: an accelerating threat landscape, regulatory mandates, and the operational reality that you cannot secure what you cannot see.
What Is an SBOM and Why Does It Matter?
A Software Bill of Materials (SBOM) is a machine-readable inventory of every component — libraries, packages, modules, dependencies — that makes up a piece of software. It is the ingredient list for your application, analogous to a nutritional label on food packaging.
An SBOM answers a deceptively simple question: what is actually inside this software? For most organizations, the honest answer before SBOM adoption was “we don’t know” — particularly for transitive dependencies (the dependencies of your dependencies) that can cascade several layers deep.
What an SBOM Contains
A well-formed SBOM includes the component name, version, supplier, the relationship between components (direct vs. transitive dependency), the package manager source, and any associated license information. The two dominant SBOM formats are SPDX (Software Package Data Exchange), maintained by the Linux Foundation, and CycloneDX, maintained by OWASP. Both are machine-readable and widely supported by tooling.
What SBOMs Enable
Vulnerability management at scale. When a new CVE is published for a widely used library (think Log4j), organizations with SBOMs can immediately identify which applications are affected. Without SBOMs, this becomes a manual, days-long investigation that often misses affected systems.
License compliance. The 2025 Black Duck OSSRA report found that 56 percent of scanned codebases contained open-source license conflicts, and 33 percent contained components with no discernible license. SBOMs make license risk visible and manageable.
Regulatory compliance. U.S. Executive Order 14028 (2021) required SBOMs for critical software sold to federal agencies. The EU Cyber Resilience Act (CRA), now law, requires software makers to create and maintain SBOMs in a standardized, machine-readable format. CISA’s updated guidance requires SBOMs to use SPDX or CycloneDX formats to aid automation.
Incident response. When a supply chain compromise is discovered, SBOMs allow teams to determine within minutes which systems are affected, rather than spending days or weeks investigating.
What SBOMs Do Not Solve
SBOMs tell you what is in your software. They do not tell you whether it was built from the code you think it was, whether the build process was compromised, or whether the artifact you received matches what the publisher intended to ship. As AquilaX’s analysis notes: “The SolarWinds attack didn’t need to tamper with the SBOM — it injected malicious code into the build process. An SBOM would have correctly listed SolarWinds’ own components, none of which were ‘vulnerable’ in the CVE sense.”
This is the fundamental limitation that SLSA and build provenance address.
The Current State of SBOM Adoption
SBOM adoption is accelerating but uneven. More than 60,000 SBOMs were published in the past year. Docker has fully embraced SBOMs in its Hardened Images, with complete SBOMs and SLSA Level 3 provenance. Major package ecosystems are integrating SBOM generation natively into build tools. However, many organizations still struggle with SBOM accuracy, completeness, and operationalization. The question has shifted from “Can your suppliers provide SBOMs?” to “Are the provided SBOMs accurate and actionable?”
What Is SLSA and How Does It Differ From SBOMs?
SLSA (Supply-chain Levels for Software Artifacts, pronounced “salsa”) is a security framework that addresses what SBOMs cannot: the integrity of the build process itself. While SBOMs tell you what is in the software, SLSA tells you how the software was built — and whether you can trust that the build process was not tampered with.
The Problem SLSA Solves
The most sophisticated supply chain attacks do not target the ingredients. They target the kitchen. SolarWinds, the GhostAction GitHub Actions compromise of 2025, and the XZ Utils backdoor all exploited the build process or developer toolchain rather than introducing known-vulnerable components.
Build provenance — a cryptographically verifiable record of how an artifact was produced — answers the questions SBOMs leave open: Was this artifact built from the source code it claims? Was the build environment compromised? Who triggered the build? What inputs were used?
SLSA Levels Explained
SLSA defines a graduated set of security levels, each providing stronger guarantees about build integrity.
SLSA Level 1: Provenance exists. The build process generates provenance metadata documenting how the artifact was built. This is the minimum bar — it provides traceability but does not prevent tampering.
SLSA Level 2: Hosted build, signed provenance. The build runs on a hosted service (not a developer’s laptop), and the provenance is cryptographically signed by the build platform. This prevents the most common attack pattern: a compromised developer machine injecting malicious code into a build.
SLSA Level 3: Hardened build platform. The build runs on a platform with specific security properties — isolated build environments, non-falsifiable provenance, protection against insider threats. This is the target for critical components and regulated industries.
SLSA Level 4 (aspirational): Full dependency verification. All transitive dependencies also meet SLSA requirements. This level represents the end-state goal but is not yet practical for most organizations.
Why SLSA Level 2 Is the Near-Term Target
Most organizations should target SLSA Level 2 as their near-term goal. It is achievable on GitHub Actions or GitLab CI in a day or two of implementation work, and it dramatically raises the bar against the most common supply chain attack patterns. Level 3 is appropriate for critical components or regulated industries. The Linux Foundation released SLSA 1.2 in late 2025, defining more granular build and source tracks for tracking provenance.
What Is Sigstore and How Does It Fit?
Sigstore is an open-source project — backed by Google, Red Hat, and Purdue University, now a Linux Foundation project — that provides free, keyless artifact signing using short-lived certificates tied to OIDC identities.
The Key Management Problem
Traditional code signing requires managing long-lived private keys — storing them securely, rotating them, and revoking them if compromised. For most engineering teams, this is operationally burdensome and error-prone. Compromised signing keys have been the entry point for multiple high-profile supply chain attacks.
How Sigstore Eliminates Key Management
Sigstore’s approach uses short-lived certificates issued by its Fulcio certificate authority, tied to an OIDC token from GitHub Actions, Google, or other OIDC providers. The developer or CI/CD system authenticates with their existing identity, receives a temporary certificate, signs the artifact, and the signing event is recorded in Rekor — an immutable, append-only transparency log.
The result: anyone consuming the artifact can verify that it was signed by a specific identity at a specific time, without either party needing to manage long-lived keys. This dramatically lowers the barrier to artifact signing for the majority of engineering organizations that have never signed their builds because traditional PKI was too complex.
Sigstore in Practice
The practical workflow for a GitHub Actions pipeline looks like: build the artifact → authenticate via OIDC → sign with cosign → push to an OCI registry with the signature and provenance attached → consumers verify the signature and provenance before deploying.
Sigstore’s cosign tool, Fulcio certificate authority, and Rekor transparency log are production-ready and widely adopted. Combined with SLSA provenance generation, they create a complete chain of trust from source code to deployed artifact.
The 2025 Threat Landscape: What Engineering Teams Are Defending Against
Understanding the current threat landscape is essential for prioritizing security investments. The attacks observed in 2025 represent a decisive escalation in both scale and sophistication.
Malicious Packages at Industrial Scale
Sonatype identified over 454,600 new malicious packages in 2025, with 99 percent concentrated in npm. The cumulative total of known malware has exceeded 1.233 million packages. This is not a collection of amateur experiments. North Korea’s Lazarus Group published more than 800 packages in npm using multi-stage payload chains combining droppers, credential theft, and persistent remote access.
The ReversingLabs 2026 Software Supply Chain Security Report documented malware up 73 percent on open-source platforms, attacks targeting developer tooling, and efforts to infiltrate AI development pipelines. ReversingLabs found a 1,300 percent increase in malicious threats in open-source repositories between 2020 and 2023, a trajectory that has only continued.
CI/CD Pipeline Compromise
The GhostAction attack of March 2025 was a watershed moment. Attackers compromised the widely used GitHub Action ‘tj-actions/changed-files’ by modifying the action’s code to exfiltrate CI/CD secrets from any repository that used it. Because repositories pinned the action by tag rather than commit SHA, every repository using @v1 automatically pulled the compromised version. The action had millions of weekly uses across tens of thousands of repositories.
This attack pattern — compromising a trusted CI/CD component to harvest credentials at scale — represents the most efficient supply chain attack vector available. It exploits the trust relationships baked into modern build pipelines.
Self-Replicating Malware
The Shai-Hulud attack in September 2025 marked an inflection point: the first known self-replicating npm malware that spread autonomously across developer environments and packages. It compromised more than 500 packages in days by stealing maintainer credentials and publishing poisoned updates — propagating without any manual publication step.
This shifts the threat model from “attacker publishes a bad package and waits” to “attacker releases a worm that spreads itself through the ecosystem.” The containment challenge changes dramatically.
AI Pipeline Poisoning
As organizations build and deploy AI models, the AI development pipeline — training data, model weights, deployment artifacts — becomes a new supply chain attack surface. ReversingLabs’ report documented increasing efforts to infiltrate AI development pipelines, and Sonatype identified malicious packages on Hugging Face targeting the ML ecosystem specifically. The concept of “vibe coding” — AI-assisted development that prioritizes speed over verification — is introducing new categories of risk as AI-generated code inherits dependencies and patterns that developers do not fully review.
The Regulatory Landscape: What Is Now Required
Software supply chain security is no longer voluntary. Multiple regulatory frameworks now mandate specific practices.
U.S. Executive Order 14028 (2021) required SBOMs for critical software sold to federal agencies and established the Secure Software Development Framework (SSDF) as a baseline. The OMB set a due date requiring all federal agencies to comply with the SSDF.
EU Cyber Resilience Act (CRA) — now law — requires software makers to create and maintain SBOMs in standardized, machine-readable formats, implement vulnerability handling processes, and provide security updates for the lifetime of the product. This applies to any software sold in the EU market.
EU NIS2 Directive imposes supply chain security obligations on essential and important entities across the EU, including requirements for supply chain risk management and incident reporting.
CISA SBOM guidance requires machine-readable formats (SPDX or CycloneDX) and provides baseline SBOM elements that must be included. CISA updated its guidance to emphasize automation of SBOM generation and consumption.
FDA medical device requirements mandate SBOMs for pre-market submissions of cyber devices, reflecting the healthcare sector’s recognition of supply chain risk.
Industry-specific frameworks from the NSA, Auto-ISAC (automotive), and IMDRF (medical devices) have all incorporated SBOM requirements. The regulatory direction is unambiguous: SBOMs and supply chain security practices are becoming table stakes for any organization selling software.
What Engineering Teams Must Do: A Phased Implementation Plan
Securing the software supply chain is not a single project. It is a set of practices that must be embedded into development workflows, CI/CD pipelines, and organizational governance. Here is a phased approach that balances urgency with practical execution.
Phase 1: Gain Visibility (Weeks 1 to 4)
You cannot secure what you cannot see. The first phase is about understanding what you are currently shipping.
Generate SBOMs for all production artifacts. Use tools like Syft (from Anchore), Trivy, or CycloneDX generators to produce SBOMs for your container images, application packages, and deployed artifacts. Automate SBOM generation in your CI/CD pipeline so that every build produces a current, accurate SBOM.
Audit your dependency tree. Identify all direct and transitive dependencies. Flag components that are unmaintained, unlicensed, or known-vulnerable. Pay particular attention to dependencies that have not been updated in over a year — 80 percent of application dependencies fall into this category.
Inventory your CI/CD pipeline components. Map every third-party action, plugin, tool, and service that has access to your build process. Identify which are pinned by commit SHA versus mutable tags. The GhostAction incident demonstrated why tag-pinned actions are a critical vulnerability.
Phase 2: Establish Build Integrity (Weeks 4 to 8)
With visibility established, the next phase is ensuring that what you build is what you intend to build.
Implement SLSA Level 2 provenance. Configure your CI/CD system (GitHub Actions, GitLab CI, or equivalent) to generate and sign build provenance for every artifact. On GitHub Actions, the SLSA GitHub Generator produces SLSA Level 3 provenance out of the box. This is achievable in days, not weeks.
Adopt Sigstore for artifact signing. Integrate cosign into your build pipeline to sign container images and other build artifacts using Sigstore’s keyless signing. Record signing events in Rekor for transparency and auditability.
Pin dependencies by digest, not tag. For container base images, GitHub Actions, and any external dependency that supports it, pin by content-addressable digest (SHA) rather than mutable tag. This prevents the class of attacks where a tag is updated to point to compromised content.
Phase 3: Enforce Policies (Weeks 8 to 16)
Generating SBOMs and provenance is necessary but insufficient. The data must be acted upon through automated policy enforcement.
Block deployments that fail provenance verification. Use admission controllers (Kyverno, OPA/Gatekeeper, or Sigstore’s policy-controller) to enforce that no container image can be deployed to production without valid SLSA provenance and a verified signature.
Enforce vulnerability thresholds. Define policies that block deployment of artifacts containing components with critical or high-severity CVEs above a defined threshold (e.g., CVSS 7+) unless a VEX (Vulnerability Exploitability eXchange) document confirms the vulnerability is not exploitable in your context.
Automate SBOM consumption. Do not just generate SBOMs — consume them. Integrate SBOMs into your vulnerability management workflow so that new CVE disclosures automatically trigger identification of affected systems. Tools like GUAC (Graph for Understanding Artifact Composition), Dependency-Track, and Grype automate this correlation.
Phase 4: Mature and Scale (Ongoing)
Target SLSA Level 3 for critical components. For your most security-sensitive software — anything that handles authentication, payment processing, PII, or infrastructure management — invest in hardened build platforms that meet SLSA Level 3 requirements.
Monitor for supply chain-specific threats. Deploy repository firewalls (like Sonatype’s Repository Firewall) that block known malicious packages before they enter your development environment. Monitor for dependency confusion attacks, typosquatting, and maintainer account compromises.
Prepare for VEX at scale. As SBOM adoption grows, the volume of vulnerability alerts will increase dramatically. VEX documents — which communicate whether a known vulnerability is actually exploitable in the context of a specific product — become essential for preventing alert fatigue and enabling effective triage.
Extend to AI pipelines. If you are building or deploying AI models, apply supply chain security practices to your ML pipeline: sign model artifacts, generate SBOMs for training environments, verify training data provenance, and monitor model registries (including Hugging Face) for supply chain threats.
Where SBOM, SLSA, and Sigstore Overlap and Complement Each Other
These three standards are not alternatives. They are layers of a comprehensive supply chain security posture.
SBOM answers: “What components are in this software?” It provides the inventory needed for vulnerability management, license compliance, and incident response.
SLSA answers: “Was this software built securely and verifiably?” It provides assurance that the build process was not tampered with and that the artifact matches the intended source code.
Sigstore answers: “Can I trust the identity of whoever built this?” It provides the cryptographic infrastructure for signing and verifying artifacts without the operational burden of traditional key management.
Together, they create a layered defense: you know what is in the software (SBOM), you know it was built correctly (SLSA), and you know who built it (Sigstore). Removing any layer creates a gap that attackers can exploit.
Docker’s Hardened Images exemplify this approach: complete SBOMs, SLSA Level 3 provenance, and cryptographic signatures — providing a verified chain of trust from source to container.
Common Mistakes Engineering Teams Make
Generating SBOMs but not consuming them. An SBOM that sits in a repository unread provides zero security value. SBOMs must be integrated into vulnerability management, incident response, and policy enforcement workflows. The organizational discipline to consume and act on SBOM data is what transforms SBOMs from compliance artifacts into security tools.
Pinning dependencies by tag instead of digest. Mutable tags are an invitation for the exact attack pattern used in GhostAction. Every external dependency that supports content-addressable references should be pinned by digest. This includes container base images, GitHub Actions, and any third-party artifact your pipeline consumes.
Treating supply chain security as a security team responsibility. Supply chain security lives in the build pipeline — which means engineering teams, platform teams, and DevOps teams must own and operate it. Security teams set policy; engineering teams implement it. Organizations that treat supply chain security as “something the security team handles” inevitably have gaps between policy and implementation.
Ignoring transitive dependencies. Direct dependencies are visible. Transitive dependencies — the dependencies of your dependencies — are where most vulnerabilities and most supply chain attacks hide. Sonatype’s data shows that 95 percent of the time when a vulnerable component is consumed, a fixed version already exists — but teams do not update because they do not know the vulnerable component is in their dependency tree. Your SBOM tooling must resolve the full dependency tree, not just the first level.
Assuming the build is safe because the code is safe. Code review catches bugs in your code. It does not catch a compromised CI/CD action, a poisoned base image, or a malicious package that entered your dependency tree through a transitive path. Build integrity (SLSA) and artifact signing (Sigstore) are required because code review alone is insufficient.
Underestimating the AI development pipeline risk. Organizations adopting AI-assisted development — “vibe coding” — often do so without extending their supply chain security practices to the AI toolchain. AI-generated code inherits dependencies that developers may not fully review. Model artifacts pulled from public registries like Hugging Face carry the same classes of risk as npm packages: typosquatting, backdoors, and data exfiltration.
How AI-Assisted Development Is Changing the Supply Chain Threat Model
The rise of AI-assisted coding introduces a new dimension to software supply chain risk that most organizations have not yet addressed.
When developers use AI coding assistants to generate code, the AI frequently suggests importing third-party libraries and dependencies. The developer may accept these suggestions without the same level of scrutiny they would apply to manually chosen dependencies. The result is an expanding dependency surface driven by AI recommendations rather than deliberate engineering decisions.
The Sonatype 2026 report explicitly flags this risk: “AI-assisted development is introducing a new class of risk — automation can amplify bad inputs at machine speed.” When an AI coding assistant suggests a package that happens to be a typosquatting variant of a legitimate library, the mistake propagates through every project that accepts the suggestion.
Additionally, AI model registries — Hugging Face being the most prominent — are now part of the software supply chain for any organization building AI/ML applications. These registries face the same classes of threats as npm or PyPI: malicious model artifacts, data poisoning, backdoors hidden in model weights, and supply chain attacks targeting the training pipeline. In 2024, over 100 LLMs on Hugging Face were found to contain hidden backdoors capable of executing malicious code.
Engineering teams must extend their supply chain security practices to AI workflows: generate SBOMs for training environments, sign model artifacts, verify provenance of pre-trained models, and treat AI model registries with the same suspicion they apply to public package registries.
The Organizational Model: Who Owns Supply Chain Security?
Software supply chain security sits at the intersection of multiple teams — and that intersection is precisely where organizational gaps form if ownership is not explicitly defined.
Platform engineering teams own the build infrastructure: CI/CD pipelines, container registries, build environments, and developer tooling. They are responsible for implementing SLSA provenance generation, Sigstore signing, and policy enforcement at the pipeline level.
Application engineering teams own the dependency decisions: which libraries to use, when to update, and how to respond to vulnerability disclosures. They are responsible for maintaining clean dependency trees, upgrading vulnerable components, and ensuring their SBOMs are accurate.
Security teams own the policy framework: defining vulnerability thresholds, SBOM requirements, provenance verification standards, and incident response procedures for supply chain compromises. They are responsible for threat intelligence, policy definition, and audit.
Compliance and legal teams own the regulatory response: ensuring the organization meets SBOM and supply chain security requirements under EO 14028, the EU CRA, NIS2, FDA guidelines, and industry-specific frameworks.
The most effective model is shared accountability with clear ownership boundaries. Platform teams build the guardrails. Engineering teams operate within them. Security teams verify compliance. And leadership funds the investment based on the risk — which, at $60 billion in global annual costs and climbing, is no longer theoretical.
Frequently Asked Questions
What is software supply chain security?
Software supply chain security is the practice of protecting the integrity, provenance, and trustworthiness of every component and process involved in building and delivering software — including open-source dependencies, build tools, CI/CD pipelines, container images, and developer environments. Attacks on the software supply chain doubled in 2025, with global costs reaching $60 billion and projected to hit $138 billion by 2031.
What is an SBOM?
An SBOM (Software Bill of Materials) is a machine-readable inventory of all components — libraries, packages, modules, and dependencies — that make up a piece of software. It enables vulnerability management, license compliance, and incident response by answering what is actually inside the software. The two standard formats are SPDX and CycloneDX. SBOMs are now required by U.S. Executive Order 14028, the EU Cyber Resilience Act, and FDA medical device guidelines.
What is SLSA?
SLSA (Supply-chain Levels for Software Artifacts) is a security framework that ensures the integrity of the software build process. It provides graduated levels of assurance — from basic provenance documentation (Level 1) to hardened build platforms with tamper-proof provenance (Level 3). SLSA addresses the attacks SBOMs cannot: compromises of the build system itself, like SolarWinds and the GhostAction GitHub Actions incident. Most organizations should target SLSA Level 2 as their near-term goal.
What is Sigstore?
Sigstore is an open-source project that provides free, keyless artifact signing using short-lived certificates tied to OIDC identities. It eliminates the need for traditional long-lived signing keys, which are operationally burdensome and have been the entry point for multiple supply chain attacks. Sigstore’s components include cosign (signing tool), Fulcio (certificate authority), and Rekor (transparency log). It is backed by Google, Red Hat, and the Linux Foundation.
How do SBOM, SLSA, and Sigstore work together?
They are complementary layers. SBOMs tell you what is in the software (inventory). SLSA tells you how it was built (build integrity). Sigstore tells you who built it (identity verification). Together, they create a complete chain of trust from source code to deployed artifact. Removing any layer creates a gap that attackers can exploit.
Are SBOMs legally required?
Yes, in multiple jurisdictions. U.S. Executive Order 14028 requires SBOMs for software sold to federal agencies. The EU Cyber Resilience Act requires SBOMs in standardized, machine-readable formats for all software sold in the EU market. The FDA requires SBOMs for cyber medical device pre-market submissions. Industry frameworks from the NSA, Auto-ISAC, and IMDRF have also incorporated SBOM requirements. SBOM mandates are expanding globally.
How long does it take to implement SLSA Level 2?
For teams already using GitHub Actions or GitLab CI, implementing SLSA Level 2 provenance generation and Sigstore signing can be achieved in one to two days of engineering effort. The SLSA GitHub Generator produces Level 3 provenance out of the box on GitHub Actions. The primary investment is in policy enforcement — configuring admission controllers to require provenance verification before deployment — which typically takes an additional two to four weeks.
What were the major supply chain attacks in 2025?
The most significant included the GhostAction GitHub Actions compromise (March 2025), which exfiltrated CI/CD secrets from thousands of repositories through a single compromised action; the Shai-Hulud self-replicating npm worm (September 2025), which autonomously compromised over 500 packages; over 800 Lazarus Group malicious npm packages targeting developer credentials; and the continued exploitation of dependency confusion and typosquatting attacks across npm, PyPI, and NuGet registries.
How should teams handle the volume of vulnerability alerts from SBOMs?
VEX (Vulnerability Exploitability eXchange) documents are the key mechanism. VEX allows software producers to communicate whether a known vulnerability is actually exploitable in the context of their specific product. This reduces false positives and enables consumers to prioritize remediation on vulnerabilities that represent real risk. Integrating VEX into your SBOM consumption workflow prevents the alert fatigue that can make SBOMs operationally counterproductive.
Does software supply chain security apply to AI/ML pipelines?
Yes. AI development pipelines introduce new supply chain attack surfaces: training data poisoning, model weight tampering, compromised dependencies in ML frameworks, and malicious packages on model registries like Hugging Face. Sonatype identified malicious packages targeting the ML ecosystem in 2025. Engineering teams should apply the same supply chain security practices — SBOMs, signed artifacts, provenance verification — to AI/ML pipelines that they apply to traditional software.
Conclusion
The software supply chain is now the primary attack surface for sophisticated adversaries. State-backed groups, ransomware operators, and financially motivated attackers all treat open-source registries, CI/CD pipelines, and developer environments as delivery channels for malicious code. The attacks are industrialized, the costs are in the tens of billions, and the regulatory response is unambiguous: SBOMs, build provenance, and artifact verification are no longer optional.
The standards are mature. SLSA 1.2 is released. Sigstore is production-ready. SPDX and CycloneDX are widely supported. The tooling works. What remains is organizational will — the decision to treat build pipeline security with the same seriousness that production infrastructure security receives.
The engineering teams that secure their supply chains now will not just reduce risk. They will ship with confidence, comply with regulations without scrambling, and respond to incidents in minutes instead of weeks. The teams that defer will learn the lesson the hard way — when a compromised dependency, a poisoned build action, or a malicious package teaches them what the SolarWinds, Log4j, and GhostAction teams already know.
At Trantor, we work with engineering organizations to build secure, scalable software delivery infrastructure. From DevSecOps pipeline design and container security to SBOM implementation, SLSA compliance, and cloud-native architecture, we help teams ship software that is fast, reliable, and verifiably trustworthy. Because in a world where trust at scale is the central engineering challenge, the organizations that can prove their software is what it claims to be hold the ultimate competitive advantage.
