Software supply chain security with Cloudsmith

Enforce trust across your software supply chain.

Block malicious dependencies, define guardrails for what’s allowed, and enforce policies automatically as AI-assisted development introduces dependencies faster than ever.

Today's reality

Software assembly has gotten faster, more automated, and harder to manually review. The controls most teams rely on weren't built for this.

    Detection isn’t enough. Teams need enforcement.
    Most security controls evaluate software at a specific point in the pipeline: a PR check, a CI scan, a post-deploy audit. These points matter, but gaps remain. Not every pipeline is configured the same way and enforcement isn’t always consistent.
    Point-in-time evaluation has a shelf life.
    A package that cleared ingestion this morning can be a liability by afternoon if new CVEs drop or threat intelligence changes.
    AI has changed how fast dependencies get pulled.
    Developers ship faster and pull more dependencies than ever. Some are chosen deliberately; others installed at the tool's suggestion without a review. The volume of software entering your environment has outpaced any team’s ability to manually evaluate it.

Cloudsmith is the control plane for your software supply chain.

Control every dependency in your environment and enforce policy directly at the artifact repository every developer, pipeline, and AI agent pulls from.

Policy management

Threat signals shift by the hour, faster than teams can manually respond. Policy management interprets them and automates the response.

  • Apply cooldown policies to block newly published, untrusted packages
  • Use industry standard OPA Rego to define software usage policies
  • Apply policies from ingestion through production, to every package and container that flows through Cloudsmith
  • Perform actions based on your policies
  • Manage exemptions when a package needs to move forward outside standard policy

A newly published package can carry risk no one has reviewed yet. Cooldown policies hold it until it clears.

  • Set a cooldown window that holds newly published packages until they clear policy checks
  • Resolve automatically to the latest compliant version so builds succeed on the first try
  • Enforce the cooldown at the repository, not in individual pipelines or client-side tooling
  • Now supports npm, Python, Go, Maven, and NuGet, giving teams consistent protection across the ecosystems they rely on most

Outcomes

Dependencies can enter from anywhere, unverified. Control what enters your environment at a single trusted point.

  • Proxy and cache all registries through Cloudsmith, serving every dependency from a single trusted source
  • Set policy once and enforce it across every team, every pipeline, and every format.
  • Stop vulnerabilities, malicious packages, and license violations before they move downstream
  • Block dependency confusion attacks by defining trusted and untrusted sources

New threats surface faster than manual review can track. Stay current automatically.

  • Cloudsmith continuously ingests the latest vulnerability and malicious package intelligence
  • Checks your repository instantly when new records are published
  • New threats automatically trigger policy evaluation to flag or block affected packages before they reach downstream teams.

Your AI agents can pull packages no one approved. Govern dependency selection by your AI agents just like you do your developers.

  • Route every install, human or AI-driven, through one dependency firewall, leaving no separate path to govern
  • Apply the same policies to agent and assistant pulls automatically, catching unsafe packages before use
  • Enforce license policies at the repository, blocking incompatible licenses

Risk already in your environment can stay invisible for months. Use SBOM data to see it and act.

  • Generate SBOMs for container images automatically
  • Store and share SBOMs alongside the artifacts they describe
  • Surface risk in components already in your environment as threat intelligence changes

Continuous risk detection

Packages are continuously re-evaluated against the latest advisories, surfacing newly disclosed risks automatically.

License reporting

Report on license types across repositories and organizations to support compliance management.

Policy-as-code

Define rules with OPA/Rego, enforced automatically across every pipeline.

Cooldown policies

Prevent newly published packages from being consumed until a configurable time window elapses.

Package quarantine

Prevent packages from being distributed to teams and pipelines when they fail policy checks.

Upstream trust

Stop trusted packages from being overridden by identically-named packages from untrusted sources.

SBOM management

Automatically generate SBOMs for container images including transitive dependencies and license metadata.

Custom signing keys

Ensure packages have not been tampered with by signing with your own custom encryption keys.

Powerful Features. Simple Control.

Ease of access to vulnerability information - and the ability to act on it - has been the biggest change for us... We’re a stone’s throw away from having zero high or critical vulnerabilities in our supply chain.

Rich Dammkoehler

VP Architecture & Governance @ ConstructConnect

Before

The InfoSec group at ConstructConnect demanded stronger software supply chain security. Artifact organization was fragmented, data usage and storage constraints were challenging to manage, and the JFrog platform lacked visibility, leading to limited overall control and security assurance. With their contract set to expire in July 2025, it became clear that staying on JFrog would continue to restrict velocity, security, and scalability.

With Cloudsmith
  • Secure software supply chain
  • Fully-managed, cloud-native platform
  • Scalable infrastructure
Results
  • Minimized high or critical vulnerabilities in our supply chain
  • Reduced the management burden
  • Faster, more reliable builds with automation and integrations

Go deeper on software supply chain security

blog

NX npm Supply Chain Attack: How Cloudsmith Would Have Contained the Blast Radius

On August 26, 2025, attackers published malicious versions of the popular Nx build system and several plugins to npm, abusing a post-install script (telemetry.js) that ran on Linux and macOS to sweep developer machines and CI for secrets (SSH keys, GitHub/npm tokens, API keys, crypto wallets). Uniquely, the payload also tried to co-opt local AI CLI tools (Claude, Gemini, q) to help with recon and exfiltration, one of the first documented cases of malware doing so. 

blog

Policy Management Example: Quarantine Packages Using Policy as Code

Cloudsmith's policy management capabilities are built on Open Policy Agent (OPA), using Rego to define policy as code. These policies control how packages move through your systems. They're versioned, reviewable, and enforceable. Policy management is in early release, but it already draws on extensive metadata Cloudsmith collects from your artifacts: format, version, tags, license, vulnerability, malware scan results, and digital signatures. Policies tap into this data to take action based on what matters to your team. This article follows the example provided by Ciara Carey, a Solutions Engineer at Cloudsmith, shown in the video below. Viewing Code-Based Policies From the Cloudsmith interface, navigate to the Policies section. Select the Block Risky Packages policy to view the policy-as-code rules, written in Rego, for an example policy. These code-defined policies give you fine-grained control over artifact behavior. Exploring Policy Code This policy evaluates multiple risk indicators across all known vulnerabilities for a package to determine whether it should be flagged and quarantined. These indicators include CVSS and EPSS scores, the presence of a patch, and the age of the vulnerability. Adding Declarations At the top of the code, we set up our policy as code, written in Rego, with the necessary dependencies: We then declare the match variable to store whether the vulnerability matches our criteria: We’re testing against parameters including EPSS and CVSS scores, repo name, age, and CVE exclusion, and these are declared as variables: Detecting a Match The match is determined using a match if block, which evaluates the conditions for each vulnerability and sets match to true if all pass: This example uses a nuanced policy that checks for several risk factors before it triggers an action. Let’s examine these checks and the code they use. Target Repository and Iterate Vulnerabilities Make sure we are targeting our preferred repo: Then loop through each reported vulnerability. The policy then applies the conditions to every vulnerability in the dataset. A vulnerability is bound to the vulnerability parameter: Apply and Evaluate Conditions for Each Vulnerability The following checks are then applied to each vulnerability for the package: CVE on a user-maintained ignore list – Skips known and accepted vulnerabilities to reduce unnecessary noise: This uses a simple Rego helper rule to check if the vulnerability is in the ignore CVE list: Fix availability – This check ensures that a patched version of the package exists. If not, the policy will not trigger: Exceeds CVSS score threshold – Evaluates the severity of any vulnerability using a configured CVSS threshold: This uses a helper rule to check if the EPSS score exceeds our limit: Exceeds EPSS score threshold – Evaluates the likelihood of vulnerability exploitation using the configured EPSS threshold: And the helper rule: Check age of vulnerability – This checks the vulnerability's age by comparing its published date to a threshold of 30 days ago. This gives the vulnerability a grace period to establish itself. If the vulnerability was published before that date, it meets the age condition for further evaluation: Putting it all Together You can see the full listing below: Actioning and Enabling the Policy Using the Actions panel, you can add a series of actions taken in response to a policy trigger. In this example, Cloudsmith performs the following automated actions: Tags the package as "risky" – Adds a visible marker so teams can immediately identify problematic artifacts. Quarantines the package – Blocks the artifact from being downloaded, deployed to infrastructure, or promoted to other repositories. Once the actions have been added, toggle the switch to the right of the policy name to ensure the policy is active. Triggering the Policy To test the policy, upload a package that matches the policy conditions. For example, one with a known vulnerability that exceeds the configured CVSS and EPSS thresholds. Click Repositories and select one for upload. Then use Push/Pull Package to push a package that triggers the policy. Cloudsmith automatically scans the package, extracts metadata, and applies the policy. In the example, if the conditions match, Cloudsmith: Tags the package as risky Quarantines it to block deployment, download, and promotion Logs the decision for audit and review Using the API The API offers a range of instructions to manage policies as part of policy management. For example, use the simulate API to test policies without enforcing them. This returns results as if the policy were active, helping teams validate changes safely. Checking the Decision Log Open the decision log to examine how the policy responded. Locate the policy ID and view the result. The interface shows the evaluated Rego policy and the triggered event's full context. You'll find detailed metadata from the package, including: Checksum values Vulnerability scan results Tags Repository name This information forms the basis for policy evaluation. Scroll to the bottom to see what actions the policy took. The decision log provides a transparent record of what happened and why.

Frequently asked questions

  1. Cloudsmith policy management evaluates packages against defined criteria and takes automated action the moment a match is found, including at the repository index itself, before a package is ever pulled into your environment.

  2. Yes. Policy as code is built on Open Policy Agent and Rego, so you can define precise, version-controlled rules for vulnerability severity, license compliance, and more, with exemptions when a package needs to move forward outside standard policy.

  3. A cooldown policy holds newly published packages until they clear an age or review threshold, while continuous malicious package detection matches packages against threat intelligence in near real time, so risk is caught before it reaches downstream teams.

  4. Cloudsmith generates Software Bills of Materials for the artifacts in your workspace, listing components, licenses, and dependencies so you can trace exactly what each package contains and act as new threat intelligence surfaces risk already present.

Get started with Cloudsmith