Why software supply chain security must evolve beyond code, libraries, and container images to include AI artifacts.
Every application is built on software its developers didn't write. Open-source libraries, packages, container images, and countless other software artifacts have become the building blocks of modern software development. They accelerate innovation, reduce development time, and allow engineering teams to focus on creating differentiated products instead of reinventing existing functionality.
But every dependency introduced into an application also represents a trust decision. Where did it come from? Has it been modified? Can its origin be verified? Does it comply with organizational policies? Over the past decade, software supply chain security has evolved around answering these questions through better visibility, provenance, signing, and governance of software artifacts. Every major shift in software development has expanded the software supply chain. Open source introduced reusable libraries. Cloud-native development introduced container images and Kubernetes artifacts. AI-native development is now introducing an entirely new class of software artifacts.
The recent security incident at Hugging Face, one of the world's largest repositories for AI models and datasets, illustrates why. According to the company's disclosure, attackers exploited vulnerabilities in the platform's data processing pipeline using a malicious dataset, enabling remote code execution, privilege escalation, and lateral movement across infrastructure before the activity was contained. Hugging Face confirmed there was no evidence that publicly hosted models had been compromised or distributed to users. The attack targeted the infrastructure responsible for processing AI artifacts rather than the artifacts themselves.
At first glance, this may appear to be another cloud infrastructure compromise. But the larger lesson extends far beyond a single platform or security incident.
The Hugging Face incident exposed something the software industry is only beginning to recognize: AI models, datasets, prompt templates, agent tools, and other AI-native components are becoming part of the software supply chain. They influence how applications are built, what AI coding assistant generates, what dependencies developers adopt, and how intelligent systems behave in production.
The software industry has spent the last decade learning how to secure software dependencies. The next decade will be about securing AI dependencies.
That is because AI is not creating an entirely new software supply chain. It is expanding the one we already have.
When AI Artifacts Become Software Dependencies
For years, software supply chain security has focused on protecting the software artifacts that developers intentionally introduce into their applications. Source code, open-source libraries, packages, container images, and binaries have become familiar components of the modern software stack. Organizations have invested heavily in understanding where these artifacts come from, how they are built, whether they can be trusted, and whether they comply with internal security and compliance requirements.
AI is fundamentally changing that landscape.
Modern applications are no longer built solely from code and traditional software components. They increasingly rely on foundation models, fine-tuned models, datasets, embedding models, prompt templates, agent tools, and Model Context Protocol (MCP) servers. These components influence how software is developed, what AI coding assistants generate, which dependencies developers adopt, and how intelligent systems behave in production.
Although these technologies are often discussed as AI resources, they are increasingly functioning as software artifacts. Like a container image or an open-source library, they are consumed from external repositories, integrated into development workflows, updated over time, and become part of production applications. They introduce functionality, but they also introduce trust assumptions.
What makes these components software artifacts isn't simply that they use AI. Like libraries and container images, they are versioned, distributed, updated, shared through repositories, integrated into development workflows, and ultimately become dependencies that influence application behavior. They are consumed, versioned, trusted, and maintained throughout the software lifecycle. In every practical sense, they are software artifacts.
The Hugging Face incident exposed this shift. The initial compromise wasn't the result of a malicious application or a vulnerable container image. It began with a dataset that became part of an automated processing pipeline. That distinction matters because it challenges a long-held assumption that AI components are simply inputs to software. Increasingly, they are becoming software dependencies in their own right.
The expansion of the software supply chain extends beyond models and datasets. Developers today routinely connect AI coding assistants to external MCP servers, incorporate third-party agent frameworks, adopt pre-trained embedding models, and integrate community-built prompt libraries into their applications. Each of these decisions introduces another externally sourced artifact into the development process. Each one expands the software supply chain and creates a new trust relationship that organizations must understand and govern.
In many organizations, AI assistants are no longer just writing code; they are influencing architectural decisions, dependency selection, and software composition itself.
The industry's definition of what constitutes a software artifact is changing. The challenge is ensuring that our security and governance practices evolve just as quickly.
Verification Must Expand Beyond Code
As organizations embraced open source and cloud-native development, they learned an important lesson: visibility alone wasn't enough. Knowing which libraries or container images existed in an environment did not answer the more important questions. Could their origin be verified? Were they built from trusted sources? Had they been modified? Did they meet organizational policies before being deployed?
The same questions now apply to AI artifacts.
A foundation model downloaded from a public repository, a dataset used to fine-tune an application, or an MCP server integrated into an AI workflow can influence application behavior just as significantly as a software library or container image. Yet many organizations still evaluate these components differently, often treating them as AI resources rather than software dependencies that require the same level of governance.
It must extend to every artifact that influences how software is built, executed, or behaves in production. That includes libraries, container images, models, datasets, agent frameworks, MCP servers, and other AI artifacts. Organizations need confidence that every artifact entering the software supply chain is authentic, traceable, policy-compliant, and verifiable throughout its lifecycle.
The challenge is not unique to one repository or one technology. AI ecosystems are growing rapidly, with new models, datasets, prompt libraries, agent frameworks, and developer tools emerging every day. Developers will continue to consume these artifacts because they accelerate innovation. The objective should not be to slow adoption but to ensure that every artifact entering the software supply chain can be verified before it becomes part of production.
This shift also requires expanding how we think about software supply chain posture. For years, organizations have measured their ability to discover, inventory, and govern traditional software components. The same posture must now include AI artifacts. Without visibility, verification, and governance across both traditional and AI-native software artifacts, organizations risk securing only part of their software supply chain while leaving an increasingly important part unmanaged.
As the industry embraces AI-native development, verification will become the common foundation across all software artifacts. Whether an application depends on a container image, an open-source library, or a foundation model, the underlying principle remains the same: trust should be established through verification, not assumption.
Looking Beyond the Incident
The Hugging Face incident will not be remembered simply because it involved AI. It will be remembered because it exposed a shift that has been quietly unfolding across modern software development.
Applications are no longer assembled solely from source code, open-source libraries, and container images. They increasingly depend on AI artifacts sourced from a rapidly expanding ecosystem. These artifacts influence how software is built, how applications behave, and, in many cases, what software is ultimately deployed into production.
This changes the scope of software supply chain security.
For security and engineering leaders, this means asking the same questions of AI artifacts that they already ask of open-source software. Where did it come from? Can its provenance be verified? Who maintains it? Does it comply with organizational policy? These questions should apply consistently across every software artifact entering production.
For years, organizations have focused on governing the software they write and the dependencies they intentionally consume. The next challenge is governing the AI artifacts that development teams and intelligent systems increasingly rely on. That requires expanding software supply chain security beyond traditional software components and adopting the same principles of provenance, integrity, verification, and governance for every artifact that enters the development lifecycle.
Organizations that recognize this shift early will be better positioned to adopt AI confidently. Rather than slowing innovation, they can establish trusted sources for AI artifacts, define policies for their use, verify their origin and integrity, and ensure they meet organizational and regulatory requirements before they become part of production systems. This is the same discipline that has strengthened software supply chains over the past decade. AI simply expands where that discipline must be applied.
The conversation should no longer be about whether AI artifacts are different from software components. Increasingly, they are software components. They deserve the same level of scrutiny, governance, and verification as every other artifact that influences the security and integrity of modern applications.
The software industry has spent years securing software dependencies. The next chapter is securing AI dependencies.
That doesn't require a new philosophy. It requires expanding an existing one.
AI artifacts are software artifacts. The software supply chain has expanded. Our approach to trust must expand with it.
