 have identified a new software supply chain attack on the 

”. A series of malicious packages are masquerading as a new AI coding agent called 

, the malicious package was reported minutes after being identified as containing a malicious payload on the 

 community did a great job in removing these suspicious packages from the registry so quickly, the 

 advisories weren’t able to classify these packages in time. But that’s okay, since they have successfully been removed and pose no threat right now.

OSM scanned the binaries, and the payload appears to be infostealers focused on cloud and AI credential harvesting across 

 storage. These payloads are adjusted for Windows and MacOS environments. A list of 

As always, if you’re a Cloudsmith user, you can apply age-based (

) policies to block newly published packages. In the case of the stardrop campaign, the malicious npm packages were all removed less than a day after the campaign began.

 is one of the most effective ways to stop this class of attack, giving security researchers (like our friends at OSM) time to identify the suspicious payload. In 2025, 

99% of malicious npm packages were identified and officially verified within 72 hours

, so implementing a simple cooldown policy significantly reduces this kind of attack vector.

Stardrop: New cross-industry npm campaign

Developers work inside their editor. Every trip to a browser breaks focus and slows decisions.

The Cloudsmith VS Code Extension, which is also supported by Cursor and other IDEs built on the VS Code platform, started as a way to browse packages and inspect metadata without leaving your workflow. With v2.0.0, the extension has grown into a full package intelligence platform with security remediation, dependency health scanning, license compliance, upstream inspection, cross-repository promotion, and Infrastructure as Code export built directly into your development environment.

The result: fewer context switches, faster security decisions, and a tighter loop between what developers use and what security teams approve.

With software supply chain attacks growing in both frequency and sophistication, developers need security context where they're already working. Waiting for a CI build to discover that a dependency carries a critical vulnerability costs time at best and creates exposure at worst. The Cloudsmith VS Code Extension puts that context directly in the editor, so risks are visible at the point of decision rather than after the fact.

Export as Terraform: From repository to Infrastructure as Code

 feature represents a massive leap for developers who want to move beyond manual configuration and embrace IaC practices without the typical friction of writing HCL from scratch. By right-clicking a repository node, you can instantly bridge between your active development environment and a reproducible infrastructure setup.

The extension doesn't just dump a basic template, it actually crawls your existing Cloudsmith setup to generate a comprehensive HCL file that includes everything from format-specific permissions and storage regions to complex retention rules and upstream configurations. This process makes your current repository state portable, allowing you to sync environments or onboard new projects effectively in seconds rather than hours.

Beyond simple automation, this feature prioritizes security and best practices that are often overlooked during manual coding. By automatically deriving the correct 

 across various package formats and utilizing 

 for resource references, the generated code is inherently robust and ready for immediate use in production pipelines.

Crucially, the extension treats your security as a first-class citizen, which means that it never exports sensitive upstream authentication secrets as plaintext. Instead, it replaces those secrets with secure Terraform variable placeholders marked as 

, ensuring your credentials stay protected. Because the generated HCL opens directly in a new VS Code editor tab for review, you maintain total control over your configuration, allowing you to easily audit the logic before committing it to your codebase.

Before v2.0.0, the extension operated as a simple package browser. The new Package Search view supports the full Cloudsmith search syntax, giving developers the same query capability available through the API and web application, directly where development happens.

By integrating Cloudsmith's full-text query syntax directly into the VS Code interface, devs can hunt for specific components across their entire workspace or narrow their focus to individual repositories without ever leaving their editor. Results are paginated and scoped across your workspace.

A few examples of what you can run straight from the search bar:

name:flask AND format:python AND policy_violated:false

 to surface everything your policies have blocked

The addition of a guided, multi-step search is particularly powerful for maintaining software supply chain integrity, as it offers one-click filter presets that instantly surface quarantined packages, policy breaches, or license violations. A developer can use a single 

 command to immediately isolate risks using the 

 query syntax. This level of visibility ensures that dangerous packages are flagged and remediated long before they can break a build or compromise a production environment.

Efficiency is further baked into the workflow through smart history and pagination features that respect a developer's time. The ability to re-run recent searches with a single click, combined with a 

 option for deep-dive investigations, allows for a fluid, iterative debugging process.

Know what you're pulling before it enters your build

Every package includes a visual permissibility indicator. The package format icon identifies clean and completed packages. Yellow indicates vulnerabilities or other violations that may not block usage. Red flags quarantined or deny-policy-violated packages. A sync icon highlights packages still awaiting analysis.

These indicators appear in search results, repository views, and dependency analysis. You know whether a package is safe before it ever enters your build.

For those looking to dig deeper into the 

 behind a blocked package, the extension now surfaces granular policy violation details as expandable child nodes directly under each entry. Whether you are dealing with EPM or legacy/classic policies in Cloudsmith, the specific reasons for a failure are accessible without switching contexts to a browser.

Upstream Awareness improves the repository view from a previously flat list of files into a better map of your entire software supply chain. By introducing a dedicated proxy and cache indicator at the top of repository nodes, the extension immediately alerts you when a repository is backed by external sources.

This visibility extends down to the individual package level, where cached artifacts are clearly tagged with a 

 label. For developers, this eliminates the 

 guesswork, and instead it provides an explicit origin detail node that distinguishes between direct uploads and those pulled from various upstream mirrors.

To ensure this level of insight doesn't come at the cost of IDE performance, the extension employs lazy-loaded configuration fetching with a smart 10-minute cache, keeping the UI snappy while minimizing API overhead.

When you need to audit your sources more closely, the 

 command launches a comprehensive WebView panel directly within VS Code. This allows you to inspect your full upstream architecture (including health and configuration) all without ever breaking your focus or navigating away from your primary workspace.

The Upstream Inspection engine provides a dedicated WebView panel that serves as a control center for your external dependencies. By grouping configured upstream sources by format, the extension offers a granular look at the DNA of your supply chain (from SSL verification and distribution details to active sync statuses) all while maintaining a native look and feel that respects your VS Code theme.

To help developers navigate the complexities of supply chain security, this update places a heavy emphasis on 

 is included because each upstream card includes contextual callouts that explain the real-world implications of your configuration.

 protection because the UI explicitly identifies Trusted upstreams (which bypass protections) versus Untrusted upstreams, which the extension highlights as the recommended path to prevent malicious packages from shadowing your private code.

 keeps the experience snappy. The extension batches API requests for all 

 in parallel, using intelligent rate-limiting and stale-request guards to ensure the data you see is both current and accurate.

 means that rather than showing a confusing empty screen if an API call hiccups, the panel uses partial-failure banners and specific error states to give you an accurate look at your repository health.

Where available, you can now monitor indexing states, package counts, and priority fields per upstream, giving you total visibility into how Cloudsmith is prioritizing your external traffic.

Cloudsmith repositories can proxy and cache packages from upstream sources like npmjs, PyPI, Maven Central, and others. The Upstream Proxy Resolution Preview answers a question that previously required a pull attempt or an API call: "If I request this package, will it resolve?"

For packages that don't yet exist locally in your repository, the preview shows whether the package can be served through a configured upstream proxy and what the resolution path looks like. This is particularly relevant for teams using Cloudsmith's 

 feature, where packages pulled from upstreams are held until policy evaluation completes. Knowing ahead of time whether a package will resolve, and through which upstream, saves the trial-and-error cycle of attempting installs and waiting for scan results.

Expanding any package with known vulnerabilities reveals the full security picture inline. Each CVE is listed with its severity rating, CVSS score, EPSS probability data, and the fixed version when one is available. The detail is comparable to what you'd find in the Cloudsmith web application, but accessible directly from the sidebar without opening a browser.

The remediation workflow is where this becomes more than a vulnerability viewer. The 

 command queries Cloudsmith for the nearest version of the package that resolves the flagged vulnerability without introducing new ones. Instead of tabbing over to a browser to search for a safe upgrade target, cross-referencing changelogs, and hoping you picked a version that's actually available in your repository, the extension handles that resolution for you.

, vulnerability data here reflects the same scan results that drive your policy decisions. A package quarantined for a critical CVE shows the same CVE detail in the extension that triggered the quarantine, connecting the "what happened" to the "why" in a single view.

The Dependency Health view reads your project's manifest files and cross-references every declared dependency against a target Cloudsmith repository. It supports package.json, requirements.txt, pom.xml, and other common formats out of the box.

When you trigger a scan, the extension parses your manifest, queries Cloudsmith in batched API calls, and populates a tree with the results. Each dependency gets a status: clean and available in Cloudsmith, flagged with a policy warning for packages already ingested that carry risk, or not found for dependencies that haven't yet been served through an upstream or ingested into your repository. You can see this in action below, where 

 has been ingested and carries a policy violation, while packages like flask, django, and fastapi haven't yet been pulled through the Cloudsmith supply chain.

The practical value is closing the gap between "what my project declares" and "what my organization can actually serve." Developers working behind a Cloudsmith Dependency Firewall or upstream proxy configuration can immediately see which dependencies are already available through the governed supply chain and which are missing. For packages that are present and flagged, right-clicking gives you direct access to vulnerability details or the "Find safe version" workflow. For packages not yet in Cloudsmith, the signal is equally valuable: these are dependencies your upstream proxies haven't cached yet, which means they haven't been scanned or evaluated by your policies.

Scanning can be triggered manually from the sidebar or configured to run automatically when a workspace opens, which is especially useful for teams that want continuous visibility without relying on developers to remember to check.

Each package generates a format-native install command pre-configured with your Cloudsmith registry URL. Right-click a Python package and get the 

 command with your repository endpoint baked in. Do the same for npm, Maven, Docker, NuGet, Cargo, Helm, Composer, and others.

Install commands are available for every package format Cloudsmith supports, so regardless of your ecosystem, the correct registry-configured command is one click away. No more copying registry URLs from the web app and stitching together install commands manually.

License visibility and risk classification

Every package in the extension now displays its detected license alongside a risk classification: permissive, weak copyleft, strong copyleft, proprietary, or unknown. The classification logic mirrors what Cloudsmith's Enterprise Policy Manager uses, so what the extension reports is consistent with what your organization's policies enforce.

Where this gets particularly useful is in filtering. You can search for packages by license type using Cloudsmith's query syntax directly from the search bar, which means surfacing every AGPL or GPL-licensed package across a workspace takes one query rather than a manual audit. For teams operating under legal or compliance constraints that restrict copyleft or proprietary licenses, this turns a historically painful review process into something that takes seconds.

The license detail node on each package is expandable, showing the full SPDX identifier and classification. If a package carries a license your organization considers restrictive, that information is visible alongside the vulnerability and policy data, giving you the complete risk picture in one place rather than spread across three different tools.

Packages in most organizations follow a progression: dev to staging, staging to production, or some variation of that pipeline. Before this release, promoting a package between Cloudsmith repositories meant either using the web application, writing API calls by hand, or scripting it into a CI job.

The extension now supports promoting packages between repositories within the same workspace, directly from the package context menu. Select a target repository, confirm the operation, and the promotion executes. Once the package lands in the destination repository, any tag policies configured there take effect, so your production-tier governance applies automatically without additional manual steps.

For teams that maintain separate repositories for internal development, partner distribution, and customer-facing releases, this removes a manual step that was easy to get wrong and tedious to get right. Promoting a hotfix from a staging repo to production while you're already looking at the package details is a workflow that should have always existed in the IDE.

When a package gets quarantined, the first question is always "why?" The answer usually involves navigating to the Cloudsmith web application, finding the package, locating the policy evaluation log, and reading through the decision chain. The 

 brings that entire investigation into the extension.

Right-clicking a quarantined package and opening the trace launches a dedicated WebView panel that lays out the full quarantine report. At the top, the quarantine reason is displayed prominently, including the specific policy that triggered the action and the custom remediation message configured by your policy authors. Below that, the panel breaks down the policy details: the policy name and ID, the action taken, and the full-detail message explaining what happened and what to do next.

This is especially powerful for organizations that have invested in writing descriptive EPM policy messages. In the example above, the policy message tells the developer exactly what to do: check for Dependabot or Renovate PRs, reach out to a specific Slack channel, or open a Jira ticket. That guidance surfaces directly in the IDE rather than living in a wiki page the developer has to go find.

The "Find safe version" button at the bottom of the panel kicks off the version resolution workflow, querying Cloudsmith for the nearest clean version. "Copy quarantine report" copies the full trace to your clipboard, which is useful for pasting into a Jira ticket or Slack thread when you need to escalate or request an exemption. The feedback loop between "this package is blocked" and "here's what I need to do about it" collapses into a single panel.

Entitlement tokens are one of Cloudsmith's unique distribution mechanisms, and the extension now surfaces them directly in the repository view. Each repository node shows its configured entitlement tokens along with their scope, status, and usage constraints.

For teams distributing software to external consumers, entitlement tokens provide granular read-only access to repository content without requiring full Cloudsmith user accounts. A single multi-format repository hosting Docker images, Helm charts, and Python packages can serve all three to an external contractor or partner through one entitlement token. That contractor gets access to exactly what they need, nothing more, and the token can be rotated or revoked independently of any user account.

The extension makes it easy to see which tokens are active on a given repository, which is useful when onboarding new consumers or auditing access. For repositories configured as 

 for public consumption, entitlement tokens control who can access the content and under what conditions. Having that visibility in the IDE means a developer publishing a new package version to a broadcast repository can verify that the distribution access is configured correctly without switching to the web application.

This is also relevant for internal teams managing multiple environments. A staging repository might have a narrow set of entitlement tokens scoped to the QA team, while the production repository has broader distribution tokens for downstream services. Seeing that configuration alongside the packages themselves helps maintain a clear picture of who can pull what from where.

Repository nodes display storage usage, bandwidth consumption, and package counts. Workspace nodes aggregate these metrics across repositories. Platform teams can monitor usage patterns without leaving the editor.

The extension supports authentication via Cloudsmith API keys and Service Account tokens. API keys are entered through the key icon in the sidebar menu and stored securely in VS Code's built-in secret storage, not in plaintext settings files or workspace configuration.

For organizations using Service Account tokens for CI/CD and shared tooling, the same authentication flow applies. The extension treats both credential types identically from a capability standpoint, so teams can standardize on whichever token strategy fits their security posture.

Session management is handled automatically. The extension validates credentials on connection, surfaces clear error messaging when authentication fails, and supports disconnecting and reconnecting without restarting VS Code. If a token expires or is revoked, the extension prompts for re-authentication rather than silently failing.

The features in this release are designed to pull security and code quality decisions forward into the development workflow rather than catching them after the fact in CI or production.

Vulnerability details with CVSS and EPSS data give developers the context to evaluate risk at the point of dependency selection, not days later in a security review. The "Find safe version" workflow means remediation starts the moment a vulnerability is identified, not after a ticket gets triaged and assigned. Dependency Health scanning validates that your project's declared dependencies are actually available and clean in your governed supply chain before you push a commit. License classification flags compliance risks at the same time you're evaluating a package, not during a quarterly legal audit.

Permissibility indicators across every view in the extension create a persistent, ambient signal about the health of the packages you're working with. You don't need to run a separate scan or check a dashboard. The red, yellow, and green indicators are always visible, always current.

For platform and security teams, the Quarantine policy trace makes policy enforcement transparent to the developers affected by it. When a developer can see exactly why a package was blocked and what the remediation path is, policy compliance becomes a collaborative process rather than a friction point. That transparency also creates a tighter feedback loop for policy authors, who can see whether their rules and remediation messages are landing effectively.

The net effect is that security posture, license compliance, and dependency governance become part of the normal development cycle rather than a separate process that runs in parallel and generates tickets after the damage is done.

Software supply chain attacks aren't slowing down. In the past week alone, we've seen multiple incidents targeting public registries and open source ecosystems (see 

). The gap between when a vulnerability or malicious package is introduced and when a developer actually learns about it is where real damage happens. The Cloudsmith VS Code Extension closes that gap by putting package intelligence, vulnerability remediation, policy enforcement, and promotion pipelines directly in your editor, so risks surface at the point of decision rather than in a post-incident review.

 and bring Cloudsmith's supply chain security controls into the place where you actually write your code.

Cloudsmith in your IDE: Package intelligence, security remediation, and Infrastructure as Code inside your editor

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.

Cloudsmith Blog

TanStack npm packages compromised in Mini Shai-Hulud attack

We built Cloudsmith for this moment

The AI speed trap: Securing the future of software supply chains

Your upstream registry is not your friend: Why security teams are demanding package cooldown policies

Mini Shai-Hulud reaches Packagist: the intercom/intercom-php compromise explained

Cloudsmith Broadcasts: Distribute software on your own terms

Performance matters: How infrastructure impacts CI/CD

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

The AI speed trap: Securing the future of software supply chains

Stardrop: New cross-industry npm campaign

Cloudsmith in your IDE: Package intelligence, security remediation, and Infrastructure as Code inside your editor

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

Axios 1.4.1 and 0.30.4 NPM packages compromised

Layered defense for dependencies: Why dependabot needs an upstream gatekeeper

How Cloudsmith can protect against the LiteLLM attack