By submitting this form, you agree to our 

A practical guide for AI artifacts and LLMOps

Securing non-deterministic systems

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 Blog

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