By submitting this form, you agree to our 

Explores AI-driven development, rising supply chain attacks, and new regulatory requirements.

2026 Artifact Management Report

In the current landscape of software development, the primary threat to the supply chain isn’t necessarily a lack of information – it’s a lack of action. Our 

 reveals a growing "enforcement gap": the dangerous interval between identifying a vulnerability and successfully applying a security policy.

While organizations are getting better at generating security data, they are struggling to operationalize it. Visibility without automated enforcement is a front-row seat to disaster.

The manual audit trap: Visibility without velocity

 they are vulnerable, but they struggle to tell you 

 is affected. While our report shows that identification speeds are improving, legacy infrastructure and manual processes hamper teams’ ability to act on that information.

One of the first questions after discovering a malicious artifact may be: “Who downloaded this and where did it go?”

The answer for many teams is far from instantaneous. Our survey found that 

 find it difficult to identify exactly which users or systems have accessed a specific compromised artifact, often requiring manual deep-dives into logs and system data for answers.

This manual toil is more than an inconvenience; it is a security risk. In a world of automated, AI-driven attacks, relying on human-speed investigations is a losing strategy.

Fragmented scanning: The “CVE-only” blind spot

Another major challenge contributing to the enforcement gap is toolchain fragmentation. Many organizations treat different types of threats as separate problems, using separate tools that don't talk to each other.

Our data indicates that while CVE scanning is becoming standard, many organizations are still missing logic-based threats and malicious package injections. In fact, 

 have a fully automated process for verifying the chain of custody or cryptographic origin of their artifacts.

When your security stack is a patchwork of third-party scanners and manual spreadsheets, deny-by-default governance is impossible to maintain.

The 24-hour countdown: Why the CRA changes everything

The enforcement gap is no longer just a security concern, it’s becoming a legal liability. The 

 introduces strict reporting mandates for any company selling digital products in the EU. Reporting requirements for the CRA begin in September 2026.

The notification windows for CRA compliance are narrow, requiring an “early warning” within just 24 hours of discovering an active vulnerability. If your team relies on manual effort to quarantine and remediate threats, meeting these legal timelines becomes a statistical improbability. To remain compliant, organizations must move away from static, compliance-only SBOMs and toward real-time, automated gatekeeping.

Cloudsmith was built to eliminate the friction between identifying a threat and stopping it. By providing a unified, cloud-native control plane for all your artifacts, we help you transition from reactive remediation to proactive governance.

 Don't wait for a scan to finish to decide on a package. Cloudsmith lets you write policies that can automatically quarantine any new dependency at the point of ingestion, ensuring nothing reaches your developers until it clears your specific security hurdles.

 We consolidate CVE scanning, malicious package detection, and license compliance into a single source of truth. No more parsing server logs; you get granular audit trails that show exactly who, when, and where every artifact was accessed.

 Cloudsmith automates the verification of digital signatures and maintains a cryptographically secure chain of custody for every binary. This ensures that what you build is what you deploy.

The velocity of modern software development demands infrastructure that can scale security as fast as it scales code. By automating the enforcement of your security policies, you don't just close the gap; you build a more resilient foundation for everything your team creates.

Get all the data on software supply chain security.

This post highlights a few of the challenges facing modern DevOps and Security teams. Download the 

, which contains data and analysis on the state of software supply chain security.

Jason Myers

Technical Content Marketer

Closing the enforcement gap: Why visibility isn’t enough for supply chain security

The binary gap is the lack of visibility into the compiled code that actually runs in production. Most security happens at the source level, but the binary is where the actual risk lives. Binary Lifecycle Management bridges this gap.

What is the "binary gap"?

DevSecOps focuses on code and libraries. MLSecOps adds a layer of protection for AI model weights, training data, and the specialized protocols (like MCP) that agents use to operate.

How does MLSecOps differ from traditional DevSecOps?

It shouldn't. The key to agentic remediation is the test loop. The agent doesn't just apply a patch; it runs the entire test suite to ensure no breaking changes are introduced before submitting the PR.

Can agentic remediation break my code?

No. A private registry stores binaries. A tool (like Cloudsmith) provides the governance, curation, policy-as-code, and auditability layers that turn a registry into a security control.

Is a "software supply chain platform" just a private registry? 

Frequently asked questions (FAQs)

 has moved beyond the "visibility era" into the 

 a framework that treats AI agents as primary actors in the supply chain. Key 2026 pillars include 

 to collapse MTTR. To survive the current regulatory climate (CRA, CMMC 2.0), organizations must move from manual audits to a queryable 

1. What is software supply chain security?

Software supply chain security is the end-to-end protection of every artifact, pipeline, and actor, human or agent, involved in the creation and delivery of software.

In 2026, software supply chain security mandates a 

 to govern the integrity of open-source libraries, AI model weights, and Model Context Protocol (MCP) servers. The goal is to move from static snapshots to agentic governance, ensuring every production binary is backed by a queryable regulatory system of evidence.

Here is a reality check for every engineering leader: the most sophisticated supply chain attack of 2025 didn’t happen because a hacker guessed a password. It happened because a "clean" npm package used by thousands of enterprises was compromised through a sophisticated social engineering attack targeting a single maintainer. The malicious code sat dormant for six months before activating during a production build. By the time it was detected, the "poisoned" binary had already been distributed to millions of end-users.

 in 2026. We are no longer dealing with a theoretical risk or a simple compliance checkbox. The supply chain is now a living, breathing, and highly volatile ecosystem. It touches every line of code your developers write, every third-party dependency your CI/CD pipeline imports, and every AI model your agents query in production.

Five years ago, "securing the supply chain" was largely synonymous with 

, basically, checking a list of libraries against a database of known vulnerabilities. Today, that definition is narrow. In 2026, securing the software supply chain means establishing absolute control over:

 Curation of open-source libraries at the point of entry.

 of the environment where code becomes binaries.

Managing the lifecycle of JARs, Wheels, and Docker images from "cradle to grave".

 Protecting the weights, data, and provenance of LLMs.

 Governing the servers that allow AI agents to talk to your data.

2. The problem: Static SBOMs and the temporal decay trap

 (SBOM) was the poster child of the 2021 security boom. The idea was simple: create a list of ingredients for your software. By 2026, however, we’ve hit a hard ceiling on how much value that list provides if you don’t act on it.

Most SBOMs generated today are what we call compliance snapshots. They are produced at the end of a build, filed in a digital drawer, and never looked at again. That is a static SBOM process, and the problem isn’t the document itself; it’s the absence of any operational workflow around it. 

A clean library today might have a zero-day discovered tomorrow.

Transitive dependencies (the dependencies of your dependencies) shift without warning.

A static SBOM process is like printing a map of a city where the roads change every 24 hours.

The real shift in 2026 is moving from a static 

 to an operational one. An SBOM is, by nature, a document, a point-in-time record. What matters is whether that document is woven into a continuously updated, queryable system. Organizations that are surviving audits today aren’t necessarily generating better SBOMs; they are operationalizing them: correlating SBOM data against real-time vulnerability feeds, enriching records with contextual analysis, and using that intelligence to drive active policy decisions.

If your SBOM data can’t tell you, right now, which production services are exposed to a CVE discovered ten minutes ago, it isn’t a security control; it’s a paperweight.

Enterprise reliance on open-source software has never been higher. On average, a modern enterprise application is composed of 80% third-party code, and that figure keeps climbing. Rather than a breaking point, this represents a critical dependency that organizations have accepted as the cost of moving fast.

But that dependency now extends well beyond traditional libraries. Developers today are pulling in AI model weights from registries like Hugging Face and container images from unverified sources, often at the direction of AI coding assistants that prioritize speed over security. This creates a compounding risk chain:

Heavy OSS reliance is the baseline norm, not a temporary state.

OSS has inherent risks: abandoned maintainers, licence ambiguity, and a growing surface area for targeted compromise.

 pull in OSS packages rapidly and at scale, often without manual risk review.

This bypasses traditional governance, meaning attack vectors reach production faster than ever.

Tricking build systems into pulling a malicious public package instead of a private internal one.

Hijacking the credentials of a trusted maintainer to inject malware into a foundational library.

Introducing subtle backdoors into the training weights of open-source LLMs that only trigger under specific prompt conditions.

 a primary engineering concern. You can no longer afford to scan "after the fact". You must adopt a 

 model, blocking malicious, vulnerable, or license-incompatible packages at ingestion, not at production.

3. The transition: MLSecOps and the "binary gap"

AI changed everything: The rise of MLSecOps

The emergence of AI-assisted development fundamentally expands the attack surface. This is where 

MLSecOps is the practice of applying DevSecOps principles to the machine learning lifecycle. In 2026, an AI model is just another third-party dependency, but it’s one that traditional scanners can't read.

Many AI models are distributed in formats (such as pickle) that allow remote code execution upon loading.

 Who trained this model? Was the training data poisoned?

 Just as you have an SBOM for code, you now need an 

 for your models, documenting training data, architecture decisions, and safety benchmarks.

Binary lifecycle management: The missing layer

There is a massive gap in most security programs between the 

A binary artifact (a JAR, a Docker image, or a Python wheel) is a transformed version of the source code. During that transformation (compilation, linking, packaging), risk can be introduced. 

 is the practice of treating these artifacts as tracked, governed entities throughout their entire useful life.

In 2026, effective binary management requires:

 One secure repository where every approved binary lives.

 (Supply Chain Levels for Software Artifacts) to cryptographically sign every step of the build process.

 of 2026 security. It’s the ability to ask, "This

 library has a CVE, but is that specific vulnerable function actually reachable in my code?"

 Without contextual analysis, your security team is drowning in 500 "Critical" alerts, the majority of which are phantom risks.
This is where the distinction between CVE and EPSS becomes operationally critical. A Common Vulnerabilities and Exposures (CVE) is simply an identifier for a known vulnerability; it tells you a flaw exists. The Exploit Prediction Scoring System (EPSS) goes further, estimating the probability that a vulnerability will be actively exploited in the wild within the next 30 days. Prioritizing by EPSS score, combined with reachability analysis, is what separates teams that fix the right things from teams that chase every alert.

4. The future: Agentic governance and remediation

What agentic AI means for the supply chain

 will write, test, or deploy nearly half of all enterprise code

 These agents aren't just "tools"; they are actors. They make decisions. They pull packages. They trigger CI/CD.

 is the framework that ensures these agents follow the rules. It means:

Ensuring every action an agent takes is traceable to a specific model version and prompt.

Enforcing guardrails that prevent an agent from pulling an unvetted package just because it’s the fastest way to solve a coding task.

As board-level scrutiny of AI risk intensifies, agentic governance is the only way to prove to regulators that your AI isn't going rogue in the supply chain.

The "Detection-to-Fix" cycle in most companies is broken. It takes days to find a vulnerability, hours to triage it, and weeks to patch it. Agentic remediation collapses this cycle.

An agent detects a new CVE in a production binary.

If exploitable, the agent identifies the safe upgrade version.

The agent creates a branch, runs the tests, verifies no breaking changes, and submits a pull request.

A human developer reviews the agent’s activity logs, inspects the proposed patch, and validates the test results before approving the PR. The human remains the decision-maker; the agent handles the toil.

5. MCP governance: The dark horse of 2026

One of the most critical, yet overlooked, components of the 2026 supply chain is the 

 MCP is the emerging standard for how AI agents communicate with your data, tools, and internal APIs.

If you deploy MCP servers without a governance layer, you are essentially creating a backdoor into your organization’s data. 

 Cataloging every MCP server in your environment.

Logging every query an agent makes to an MCP server.

 Ensuring an agent can only access the specific context (data) it needs for its current task.

In 2026, an ungoverned MCP server is as dangerous as an unvetted npm package.

6. Building a regulatory system of evidence

". With laws like the EU Cyber Resilience Act 

 and the Cybersecurity Maturity Model Certification 

, the U.S. Department of Defense’s tiered framework that mandates verified cybersecurity practices for all contractors handling controlled unclassified information, and the full enforcement of these requirements, you can no longer satisfy an auditor with a spreadsheet.

. This is a queryable, immutable record of your supply chain data. It answers three questions:

 (The continuous scan + contextual analysis).

When an auditor asks, "Did you use a vulnerable version of Log4j in June?" you shouldn't be searching emails; you should be running a query against your 

7. Supply chain security best practices for 2026

Consolidate into a single source of truth: 

You cannot secure what you cannot see. Centralize all artifacts and packages, container images, AI models, and MCP definitions into a single, governed, private repository. This is the only way to enforce policy at scale.

Stop generating "paper SBOMs". Use a platform that continuously updates your inventory and enriches it with Vulnerability Exploitability eXchange (VEX) data.

. Focus your security team’s energy on 

 vulnerabilities, not just "high" scores. This single shift has been shown to dramatically reduce alert fatigue and reclaim meaningful developer time.

Don't let trash into your environment. Set up automated policies to block packages that are too young (less than 30 days old), have no maintainers, or use restrictive licenses.

Move beyond simple GPG keys. Use the SLSA framework to provide a verifiable "chain of custody" for every binary that reaches production.

Govern AI agents as first-class citizens: 

Assign every AI agent a non-human identity. Audit their "package pulls" and "MCP queries" just as you would audit a human developer’s access.

Stop the manual patching cycle. Use AI agents to handle the boring parts of security, identifying fixes, running tests, and opening PRs.

Ensure every decision made in your pipeline is logged in a way that is immutable and queryable. Compliance should be a side-effect of your engineering process, not a separate project.

8. Cloudsmith software supply chain platform

 require more than just a storage bucket for binaries; they require a sophisticated governance engine. 

 is the universal software supply chain platform designed to address these challenges head-on, providing the connective tissue between DevOps, security, and compliance teams.

, consolidating proprietary code, open-source dependencies, and AI model weights into a single, highly secure repository. This centralization is the prerequisite for binary lifecycle management. By enforcing a single point of entry, Cloudsmith allows organizations to implement curation policies that block malicious or non-compliant packages before they ever reach a developer’s environment.

, Cloudsmith provides the necessary infrastructure to manage non-human identities. Whether it is a CI/CD bot or an autonomous AI coding agent, Cloudsmith tracks every pull, push, and query, creating an immutable audit trail. This data forms the backbone of your evidence, allowing you to satisfy audits for CRA, DORA, or CMMC 2.0 with on-demand reporting rather than manual data collection.

Furthermore, Cloudsmith natively addresses the "Static SBOM" problem. By generating and managing Living SBOMs, Cloudsmith continuously correlates your inventory with real-time threat intelligence. When paired with contextual analysis, Cloudsmith helps your team ignore the noise and focus on reachable vulnerabilities. For organizations moving toward agentic remediation, Cloudsmith provides the secure sandbox and rich metadata required for AI agents to identify, test, and patch vulnerabilities autonomously. With Cloudsmith, software supply chain security isn't just a policy; it’s a continuous, automated, and verifiable reality.

 in 2026 is an architectural commitment to 

. The shift from static artifacts to active governance reflects a world where software is built at the speed of AI.

The organizations that will lead the next decade will be those that consolidate their binaries into a 

Parul Jhawar

Marketing

The 2026 guide to software supply chain security: From static SBOMs to agentic governance

, an extremely popular HTTP client for JavaScript, suffered a malicious payload injection attack. While the malicious code was removed within a matter of hours, the package’s popularity means that millions of build systems may have been infected.

This attack is the latest in a growing list of software supply chain attacks, this time linked to 

, where the actors took advantage of the popularity of open source packages to serve malicious payloads to millions of victims. npm credentials have repeatedly emerged as a weak point that malicious actors attack.

The attack vector appears to have been a compromise of the

npm account of one of axios’s maintainers, giving a malicious actor the ability to publish new versions of axios to the 

 registry and add malicious dependencies to the payload.

The malicious payload was added to two branches of axios between 00:20 and 01:00 UTC on 31 March. The malicious version remained live on npm for around 2 hours, in part because the maintainer’s

npm account was the only admin account, preventing other collaborators from shutting down the attack until the case was picked up by npm’s administrators.

The attack appears designed to facilitate crypto-related fraud. The attacker modified 

, which is a new malicious software package that did not exist before yesterday.

 was published 18 hours before the axios updates. The compromised payload, in a new version of 

, deploys a remote access trojan that’s tailored for the host’s operating system. This is a textbook supply chain malware injection incident. Systems that configure their build managers to install the latest version by default are subject to compromise in this style of attack. That’s probably a huge number of systems, given that 

 is a popular project, with over 100 million weekly downloads on 

How to secure your supply chain against future attacks

The axios breach comes less than a week after another popular package, 

, the canonical Python public registry. Very popular open source packages are an attractive attack vector for malicious actors. Once a malicious payload like this enters your software supply chain, it can do irreversible damage almost immediately. Cleanup is often a slow and frustrating process, and regulations such as the EU's Digital Operational Resilience Act (DORA) and the Cyber Resilience Act (CRA) require companies to report these incidents within 24 hours, or face substantial fines.

Here’s how to protect your software supply chain:

Route all package requests through a private registry proxy, like Cloudsmith.

 Sitting between your developers and public registries, Cloudsmith creates a checkpoint, applying security policies before packages reach build environments or developers’ local machines.

This proxy buffer is a key component of Cloudsmith. With Cloudsmith as your control plane, every public package, and base Docker container image, is subject to scanning and security policies before anything reaches your build systems.

 was created less than a day before the attack. It was published specifically as part of a malicious payload before the compromised axios versions were published. Blocking package versions less than 7 days old (the specific age is configurable) is one of the most effective ways to stop this class of attack, giving security researchers time to identify the vulnerability.

In 2025, 99% of malicious npm packages were identified and officially verified within 72 hours – implementing a simple cooldown policy significantly reduces the attack vector.

Cloudsmith users with a cooldown policy in place would block 

 even before malicious behaviour was reported, protecting their software supply chain from this attack.

You can configure cooldown policies in many package managers, but Cloudsmith allows you to set the policy at an organisational level, so it’s enforced across formats, teams, and build systems consistently.

Subscribe to real-time threat intelligence feeds.

 Cloudsmith subscribes to databases like OSV.dev and the OpenSSF Malicious Packages project, which update in near real-time.

. Using a system like Cloudsmith to integrate these feeds into your package policies means you get automatic protection as new threats are identified.

 can act on these intelligence feeds, so anti-malware policies trigger even after the cooldown period ends. We’ve written before about how 

Cloudsmith’s policy manager protects your software supply chain

Creating a Malicious Package policy in Cloudsmith

. This one serves as a malware detection gate. EPM runs 

 the Cloudsmith security scan completes during package synchronisation, making scan results available as 

. In this case, the policy code loops over the 

 array, which is the OSV malware data from the scan. For each vulnerability object, it checks, “does the ID start with the string 

So what does this policy do in practice? It flags any package that has been reported as known malicious as part of the OpenSSF Malicious Packages project. "

" is used specifically in vulnerability feeds to indicate malware-related findings. Once a match is found, Cloudsmith will execute the 

 for this policy, such as to quarantine, tag, or block package promotion.


If you are interested in evaluating proactive security policies for poisoned/malicious software packages, 

 about protecting your software supply chain from attacks like the one on axios.

Nigel Douglas

Head of Developer Relations

Axios NPM distribution compromised: What happened and how to prevent malicious packages from reaching your builds

 Dependabot is great at keeping dependencies current, but update automation and ingestion control solve different problems. Cloudsmith acts as an upstream gatekeeper; ensuring packages are verified before they ever enter your environment. Together, they cover more of the supply chain than either does alone.

Let’s frame a scenario: a new dependency version is released. Within hours, Dependabot opens a pull request to upgrade your application.

The change looks routine. The PR is merged.

But this version wasn’t just an update - it was part of a coordinated malware campaign.

Before long, the compromised package has made its way into your build environment, cache layers, and developer workstations. Your security team is pulled into incident response, and a difficult question follows:

How did this get through so quickly, and how do we prevent it next time?

How dependency updates become a supply chain risk

To understand how this scenario unfolds, it’s worth breaking down what actually occurs between a dependency being published and a pull request being merged. When a new version of a package is released by a maintainer (or malicious actor in this case), it becomes immediately available in upstream registries such as npmjs, pypi, Maven Central, or DockerHub.

Tools like Dependabot continuously scan your repository’s dependency files for updates. As soon as a new version is detected, Dependabot compares it against what your application is currently using. If a valid upgrade path exists, it automatically opens a pull request with the updated version. From a developer’s perspective, everything looks normal:

The dependency comes from a trusted source

Cloudsmith Blog

Closing the enforcement gap: Why visibility isn’t enough for supply chain security

The 2026 guide to software supply chain security: From static SBOMs to agentic governance

Axios NPM distribution compromised: What happened and how to prevent malicious packages from reaching your builds

Layered defense for dependencies: Why dependabot needs an upstream gatekeeper

AI artifacts: The new software supply chain blind spot

7 key metrics to measure software supply chain security

How artifact management enables S2C2F maturity

The 8 core principles of S2C2F

Understanding S2C2F: How it strengthens OSS security

What is software supply chain integrity?

Slopsquatting and Typosquatting: How to Detect AI-Hallucinated Malicious Packages

DevOps guide to mitigating software supply chain risks