by: Michael Scott, Co-Founder and CTO, NetRise
When the Pentagon designated Anthropic and its products a supply-chain risk on March 4, 2026, the immediate headlines focused on the politics of the decision. But for security leaders, software buyers, and engineering teams, the real issue was not the dispute itself. It was the operational question that followed.
If a major supplier suddenly becomes restricted, off-limits, or too risky to use, can your organization quickly determine where that supplier exists across the software you build, buy, deploy, and depend on?
That is the larger lesson in this case, and it is why this report matters.
Public reporting and Anthropic’s own statements suggest the designation was not driven by a newly disclosed vulnerability. Instead, the conflict centered on model-use restrictions, procurement authority, and whether a frontier AI provider could refuse certain government uses of its technology. That distinction matters because it shows how supply-chain events now extend well beyond traditional vulnerability management. A supplier can become a mission problem overnight for reasons that have little to do with a bug.
When that happens, most organizations face the same challenge. They can name the supplier. They can usually identify the obvious packages. But they often cannot see, with speed and confidence, how far that supplier’s software and dependencies actually reach.
That is the gap this report set out to measure.
Download the full report: Anthropic Software Supply Chain Risk Blast Radius
Using internal platform data, package analysis, container SBOM analysis, Helm rendering, and GitHub repository review, the report maps both official Anthropic packages and the direct and transitive dependencies tied to them. The findings make clear that blast radius is not a narrow package-level problem. It is a cross-layer visibility problem that moves from registries into repositories, containers, deployment artifacts, and packaged enterprise software.
The topline numbers show why this matters. The analysis identified 476 official Anthropic package names spanning 3,434 package versions across seven ecosystems. From there, the dependency picture expanded to 127,441 direct or transitive dependent package versions. In downstream artifacts, the report found six affected public container repositories representing more than 203 million Docker Hub pulls in the analyzed cohorts, six affected Helm charts in the targeted Kubernetes cohort, and 19 affected GitHub repositories across selected cohorts totaling 130 repositories and more than 1.28 million stars.
Those counts are important, but the more interesting takeaway is where the exposure actually concentrates.
This was not a story of widespread contamination across generic infrastructure. In the report’s Docker Hub baseline, the top 50 generic library/* images produced zero affected results. Instead, the concentration appeared in AI-enabled application layers, orchestration stacks, MCP tooling, agent frameworks, workflow products, and developer-facing platforms. In other words, the blast radius clustered where organizations are moving fastest to adopt AI functionality and where dependency chains are often hardest to untangle.
That pattern showed up repeatedly.
In public container cohorts, affected repositories included products such as n8n, Flowise, AnythingLLM, Langflow, LangSmith backend, and LiteLLM. Some carried official Anthropic packages directly. Others pulled in Anthropic-related components indirectly through frameworks or optional integrations. That distinction is more than academic. Direct dependencies are usually easier to explain and remediate. Transitive dependencies are where teams lose time, because the affected component is often several layers removed from the team responsible for the product.
The Helm findings were even more operationally significant. Containers tell you what has been packaged. Helm charts tell you what is likely to be deployed. In the targeted cohort derived from the container analysis, all six rendered charts were affected. That bridges an important gap between software composition and deployment reality. These were not just code-level or image-level artifacts. They were packaged in forms operators can install in Kubernetes environments today.
The GitHub analysis pushed the findings further into the development ecosystem. In one broader cohort of 100 repositories selected for star count and recent growth, 13 were affected. A second cohort focused on GitHub’s MCP Registry found six affected repositories among 30 highly visible MCP servers. That matters because it shows the issue does not stop at end-user AI applications. It extends into the model tooling ecosystem itself, including the connectors and workflows developers use to link models to terminals, browsers, SaaS tools, documentation, and enterprise systems.
Internal NetRise Platform findings reinforced the public artifact analysis. Across six inventory groups, 15 internal assets were identified as affected, including large appliance images, platform SBOMs, self-hosted AI web interfaces, MCP server binaries, and AI framework packages. The key lesson is not any single product name. It is that exposure can exist deep inside packaged enterprise assets.
This is where the report becomes more than an analysis of Anthropic. It becomes a case study in what organizations should be able to do when any supplier-related event breaks.
The lesson is not that Anthropic is uniquely risky. The lesson is that a modern software supplier can become an urgent operational issue with very little notice, and most organizations still struggle to answer the first-order questions quickly enough.
- What official software components from the named supplier are in scope?
- What direct and transitive dependents also enter scope?
- Which source repositories, build artifacts, containers, and deployment charts contain them?
- Which of those artifacts are highest impact by operational footprint, pull volume, deployment prevalence, or mission criticality?
- What is the exact lineage that introduced the component, and what is the most direct remediation path?
Those are not edge-case questions. They are the core questions of software supply-chain response. And they need to be answered in minutes, not weeks.
That is why the report’s discussion of a one-keystroke response capability is so important. The term may sound ambitious, but the underlying requirement is straightforward. A response team should be able to name a supplier, project, maintainer, or component and immediately generate a cross-layer blast-radius analysis on demand.
In practice, that means more than collecting SBOMs and storing them somewhere. It means correlating package inventories, dependency graphs, source repositories, containers, deployment manifests, and compiled assets into a usable operational picture. It means preserving exact versions, digests, chart releases, and commit SHAs so findings can be defended in front of security leadership, procurement teams, legal counsel, or government stakeholders. And it means ranking results by operational relevance rather than just raw counts.
This is also where broader policy guidance is already pointing. Federal frameworks have pushed agencies and contractors toward secure development attestations, SBOM collection, and better supply-chain documentation for years. But this episode highlights the limit of artifact collection alone. Organizations do not just need more SBOMs. They need the ability to act on supply-chain data when a supplier event becomes operationally urgent.
That requires connecting software composition to deployment reality, and connecting both to provenance, trust, and policy. A supplier-related incident may stem from a vulnerability, but it might also come from sanctions, maintainer concerns, licensing shifts, country-of-origin issues, or abrupt offboarding decisions. In every case, the operational question is the same: where does this code or supplier appear across our portfolio, and where does it actually run?
That is the bigger story behind the Anthropic designation.
The headline is about one company. The structural lesson is about visibility.
As the report concludes, the blast radius of modern software supply-chain risk does not stop at a package registry. It propagates into containers, Kubernetes charts, popular source repositories, MCP tooling, and packaged enterprise assets. The organizations that respond fastest to the next supplier restriction, compromise, or policy shock will not be the ones with the biggest spreadsheets. They will be the ones that can identify the blast radius in one motion, preserve the evidence, understand the lineage, and prioritize action immediately.
Anthropic is the case study. The gap is structural. And for organizations building or buying modern software, closing that gap is starting to look less like a best practice and more like a non-negotiable requirement.
Download the full report: Anthropic Software Supply Chain Risk Blast Radius
Need quick help? Chat now with a Real NetRise Expert
Click here➡
No Slack account needed
