By submitting this form, you agree to our 

Answer twenty questions about your artifact and supply chain practices. Get a custom report card showing your maturity score against key regulatory and compliance frameworks.

Artifact Security Maturity Assessment

 is a software supply chain weakness that arises from how package managers resolve dependencies across multiple sources.

It does not rely on complex exploits. It relies on normal dependency resolution.

If a build resolves from both private and public registries, and a public package shares the same name as an internal dependency, the public package may be selected. That is sufficient to introduce unintended code into a build.

Modern dependency trees often include extensive transitive dependencies, increasing the number of automatic resolution decisions made during builds.

when researchers demonstrated it against more than 35 large organizations by publishing public packages that matched internal names. Since then, dependency confusion has remained a known and preventable risk in modern build systems.

If resolution rules are not explicit, package managers make decisions on your behalf.

Different ecosystems provide different structural protections and different pitfalls.

PyPI operates on a flat global namespace. There are no built-in organizational scopes and no domain bound identifiers. Package names are globally unique and first come, first served.

This means internal package names, for example acme utils or internal ml core, are structurally indistinguishable from public ones unless additional controls are applied.

Python projects frequently configure multiple indexes. It is common to see:

Vendor-hosted repositories such as PyTorch wheel indexes for CUDA builds

Python tooling such as pip, uv, and Poetry evaluates candidate versions across configured sources. If the same package name exists in more than one index, the resolver may select the highest compatible version, regardless of origin.

Real-world incidents demonstrate this behavior. 

In 2022, a malicious package mimicking a PyTorch dependency

 was published to PyPI and installed via pip resolution during nightly builds, leading to data exfiltration before detection.

Without explicit trust boundaries or source mapping, this multi index behavior introduces ambiguity. If an internal package name is exposed and a higher version appears on a public index included in resolution, the public package may be selected.

Python’s flat namespace model, combined with common multi index configurations, makes careful source control particularly important.

npm supports scoped packages using the @org/package format. Once registered, a scope is controlled by that organization.

However, unregistered scopes remain claimable. If an organization uses scoped internal packages but has not reserved the scope publicly, an attacker could register it and publish similarly named packages, for example @org/app. A configuration mistake in development or CI could then result in the malicious package being resolved and executed, including via lifecycle hooks such as preinstall.

Unscoped internal package names carry exposure similar to Python.

Maven Central uses domain-based groupId verification, providing stronger ownership guarantees when correctly configured.

However, inconsistent repository usage or additional repositories can reintroduce ambiguity in resolution order if trust boundaries are not clearly defined.

While NuGet supports ID prefix reservation to prevent public name squatting, resolution ambiguity can still arise if multiple feeds are configured.

ID prefix reservationReserve your organization’s package ID prefix on nuget.org to prevent public impersonation.

Package Source Mapping Use NuGet 6+ source mapping to bind specific package IDs or prefixes to a single trusted feed.

Strict nuget.config configurationClear default feeds and explicitly define approved sources to prevent unintended restores.

Signature enforcementNuGet repository signing using X.509 certificates. When signature verification is enforced in the NuGet or .NET CLI, consumers can verify that a package originated from the expected repository and has not been tampered with.

Docker Hub differs from language ecosystems because image references are typically registry qualified, making classic multi-source confusion less common.

Implicit Docker Hub fallback when no registry is specified

These are mitigated through fully qualified image references, namespace reservation, digest pinning using SHA256, and image signing.

Preventing dependency confusion does not require dramatic changes to developer workflows. It requires clear trust boundaries in how dependencies are resolved.

In practice, this is implemented through an internal artifact repository that controls how dependencies are proxied, cached, and resolved.

Enforcing artifact signing and verification

Route all builds through a central artifact repository that acts as the single source of truth for dependencies. Public packages should be proxied and cached internally rather than resolved directly from the internet.

Explicitly distinguish between trusted and untrusted sources.

Cloudsmith provides upstream trust controls that allow repositories to designate upstream sources accordingly and control how packages are blended during resolution. If a package exists in a trusted source, it cannot be overridden by an untrusted one.

Cloudsmith’s Upstream Trust currently supports:

Support for additional ecosystems is expanding. In addition to source trust controls, policy enforcement provides another layer of protection. 

 allows organizations to define rules around what packages are permitted, including conditions based on vulnerability data, malware data, version constraints, or upstream origin. This enables teams to combine resolution boundaries with policy-based controls.

Namespace ownership significantly reduces collision risk.

Lockfiles improve determinism, traceability, and visibility into unexpected changes. They do not eliminate dependency confusion, but they reduce instability and make tampering easier to detect.

Signing adds cryptographic integrity to artifacts.

Cloudsmith signs hosted packages by default. Cloudsmith supports both native and non-native signing across package formats, including native signing for 

. Signature validation workflows in supported ecosystems provide an additional verification layer if substitution is attempted.

Signing strengthens integrity guarantees but does not replace resolution controls.

Dependency confusion is not a sophisticated exploit. It is a consequence of ambiguous resolution behavior across multiple sources.

A central artifact repository serving as the single source of truth for dependencies

Clear boundaries remove ambiguity. Removing ambiguity removes the attack path.


Stop leaving your build integrity to chance. 

 today to see how Cloudsmith's enterprise-grade repository controls can remove ambiguity and harden your delivery process.

Ciara Carey

Solutions Engineer

Dependency confusion and trust boundaries in modern builds

Why we chose it, how we built on it, and where we’re going next

Ensuring the integrity of open source software is a growing priority for organizations of every size. But doing it in a way that doesn’t slow down developers is hard.

We believe the right long-term answer is a curated repository of known-good open source software that is continuously verified, with your organization’s security and compliance policies applied, and deeply integrated into your core workflows.

Cloudsmith is the right place to do this. We’re not just hosting packages; we’re providing the control plane and data plane for the software supply chain. And that starts with how we handle vulnerability data and threat intelligence.

We chose Trivy as the base for vulnerability scanning at Cloudsmith because it’s open source, fast, and widely trusted. 

We integrated Trivy into our cloud-native platform, giving our customers access to 

We’re expanding beyond Trivy, ingesting multiple data sources and ultimately adding pluggable security integrations.

 A curated, secure, resilient software supply chain that keeps developers productive and organizations safe.

 early on, as we were building Cloudsmith. It’s open source, well-supported, and widely trusted. It offers support for containers, OS packages, language dependencies, SBOMs and secrets scanning. It’s also well-maintained; with over 27,000 GitHub stars, millions of downloads, and millions of users, the global developer community clearly values the capability that Trivy provides.

It’s no surprise that Trivy is the default scanner in many other platforms. But integrating it into a cloud-native platform like Cloudsmith, where artifacts are constantly being pushed, pulled and promoted across repositories, meant solving for cloud scale, automation, and extensibility.

Trivy helped us get high-quality results fast. Here’s how we super-charged it for our customers.

Every artifact pushed to or cached through Cloudsmith is scanned automatically, without any manual configuration or setup required. This means security is built into the pipeline from the very first interaction. The scans run in the background, ensuring zero friction for developers while giving teams continuous visibility into security risks.

: Every Docker/OCI image published to Cloudsmith is automatically accompanied by an SBOM in the CycloneDX format. CycloneDX is widely supported across security tools and ecosystems, making it easy to integrate SBOMs into your broader supply chain risk management processes. By leveraging Trivy’s SBOM capabilities, we ensure that every image has a clear and standardized inventory

Because Cloudsmith is a universal artifact management platform, we can centralize vulnerability data for our customers across all of their formats and surface that information to them across their workspace. 

Cloudsmith is designed to work at global scale, so when we integrated Trivy as our scanner, we knew it needed to keep up too. Cloudsmith is 

proven to handle > 1 million requests per minute

 and we execute millions of vulnerability scans as customers add to their repositories.

Quarantine or notify when users are accessing insecure packages using Cloudsmith’s OPA based 

SAML, SCIM, OIDC, logging, and ISO 27001 compliance ensure a 

With Trivy running reliably across our platform, we started rethinking how to keep vulnerability data fresh and actionable.

We ingest CVE data continuously, from Trivy and also from additional sources like 

. And we apply that data to artifacts already in your repositories. That means no need to trigger rescans.

New advisory published? We re-check your existing packages against fresh data.

Define rules using CVSS, EPSS, license metadata or any other detail about your package, and act on them automatically.

 Every match, every decision, and every policy action is logged.

So we can add data sources like OSV.dev and package health signal data.

This turns scanning into a real-time feedback loop, so you can catch new risks as soon as they emerge.

The presence of CVEs isn’t the only signal about the quality of software packages. Our goal is to help you make better decisions about all the software in your supply chain based on trust, context, and quality, in addition to known vulnerabilities.

 New feeds (OSV, GitHub advisories, OpenSSF Scorecards) deepen our vulnerability data and unlock additional package formats.

 Build policies based on how well-maintained a package is, whether it has good documentation, how widely it’s been adopted, and other indicators of package health

 SBOM generation for additional formats, so you can build custom policies from your SBOM metadata.

Trivy kickstarted it. Cloudsmith takes it further.

Push an artifact. Let Cloudsmith scan it, sign it, apply policies, and let you know when new threats emerge. Security shouldn’t slow you down. With Cloudsmith, it doesn’t.

 Push an image or package and watch your policies kick in, so you can sleep easier tomorrow when the next CVE lands.

Using Trivy Inside Cloudsmith

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.

Policy management demo

From the Cloudsmith interface, navigate to the 

 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.

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.

At the top of the code, we set up our policy as code, written in Rego, with the necessary dependencies:

 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:

 from the lower setting in the video, to reflect a more realistic threshold.

 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 

Apply and Evaluate Conditions for Each Vulnerability

The following checks are then applied to each vulnerability for the package:

 – 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:

– This check ensures that a patched version of the package exists. If not, the policy will not trigger:

 – 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:

 – Evaluates the likelihood of vulnerability exploitation using the configured EPSS threshold:

– 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:

 panel, you can add a series of actions taken in response to a policy trigger. In this example, Cloudsmith performs the following automated actions:

 – Adds a visible marker so teams can immediately identify problematic artifacts.

 – 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.

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.

 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:

Quarantines it to block deployment, download, and promotion

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.

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:

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.

Ian Taylor

Tech Content Director

Policy Management Example: Quarantine Packages Using Policy as Code

OpenID Connect (OIDC) provides ephemeral tokens, reducing the risk of long-lived credentials being exposed. For many organizations, artifact management tokens are among the most widely used credentials, making them a significant target for security breaches.

Shifting to OIDC is an excellent way to strengthen security posture, offering substantial benefits with minimal implementation effort. While direct 

Dependabot integration with OIDC in GitHub Actions isn’t available

, API-based token rotation offers a reliable workaround.

This guide will walk you through configuring GitHub Dependabot to authenticate with Cloudsmith using OIDC. It includes steps for setting up a Cloudsmith service account, configuring OIDC in Cloudsmith, setting up GitHub permissions, and creating a GitHub Actions workflow to dynamically update the Dependabot API key.

Step 1: Create a Service Account in Cloudsmith

 that the service account should be associated with for broader permissions.

Step 2: Configure OIDC Authentication for GitHub Actions in Cloudsmith

: Enter a descriptive name (e.g., GitHub Actions).

: Enter https://token.actions.githubusercontent.com.

 as the required claim for GitHub OIDC tokens to restrict access to your specific GitHub organization.

, select the service account created in Step 1 (Dependabot Service Account).

OIDC setup with GitHub Actions in Cloudsmith

Step 3: Set Up Access Controls in Cloudsmith

 for the repository where you want Dependabot to manage dependencies.

Step 4: Add a Fine-Grained Personal Access Token (PAT) in GitHub for Dependabot

 to the specific repository where you want to use Dependabot.

Add a new secret with the name FINE_GRAINED_PAT and paste the PAT as the value.

Step 5: Create DEP_CLOUDSMITH_API_KEY Secret for Dependabot

, enter a placeholder value (e.g., INITIAL_VALUE or a temporary token from Cloudsmith).

This sets up DEP_CLOUDSMITH_API_KEY as a Dependabot-compatible secret so that the GitHub Action can later overwrite it with an ephemeral OIDC token each time it runs.

The initial value doesn’t need to be valid long-term, as it will be regularly replaced by the OIDC-generated token.

After this initial setup, the GitHub Actions workflow you configured will take over, updating DEP_CLOUDSMITH_API_KEY with each run.

Step 6: Configure the dependabot.yml File

In your GitHub repository, create or update .github/dependabot.yml. The example below uses a Maven repository configuration, but this works with other package ecosystems, including npm, pip, and more (see the Dependabot configuration guide for details).:

Replace YOUR-ORG and YOUR-REPO with your actual Cloudsmith organization and repository details. This configuration will enable Dependabot to connect to Cloudsmith for dependency updates.

Step 7: Set Up a GitHub Action Workflow to Overwrite the Dependabot API Key with an Ephemeral OIDC Token

This workflow will authenticate with Cloudsmith via OIDC, generate a short-lived token, and overwrite the DEP_CLOUDSMITH_API_KEY used by Dependabot. Given that Cloudsmith’s OIDC tokens expire every 2 hours, this example schedules token rotation every 11 hours to align with Dependabot’s run schedule. If your setup requires more frequent rotations or encounters token expiration issues, adjust the schedule accordingly.

In your repository, create a file at .github/workflows/update-cloudsmith-key.yml.

Replace YOUR-ORG with your Cloudsmith organization slug.

Replace YOUR-SERVICE-SLUG with the slug of the Cloudsmith service account created earlier.

This workflow uses OIDC to obtain a JWT from Cloudsmith, overwriting the DEP_CLOUDSMITH_API_KEY Dependabot secret with an ephemeral, short-lived token.

 in your GitHub repository and manually run the workflow.

Ensure Dependabot is fetching updates from Cloudsmith and creating pull requests as expected.

This setup allows Dependabot to use a short-lived Cloudsmith OIDC token, enhancing security by overwriting the DEP_CLOUDSMITH_API_KEY secret with each token request.

Next: Learn how to leverage Cloudsmith with Dependabot to streamline your dependency management 

Integrating Dependabot with Cloudsmith Using OIDC

 is a modern CI/CD platform designed for Kubernetes and microservices applications. It provides developers with fast, powerful pipelines and deep integration with Kubernetes. The platform’s features, such as enhanced caching, parallelization, and flexible triggers, allow teams to optimize their continuous integration workflows.

 to offer a comprehensive GitOps platform for Kubernetes. GitOps helps teams automate their infrastructure and application management, using Git as the single source of truth for deployments. By leveraging Argo within Codefresh, developers can employ advanced deployment strategies such as canary releases and blue-green deployments, improving release quality and reducing risks.

Benefits of Using Codefresh and Cloudsmith Together

, a cloud-native artifact management platform, with 

 enhances your CI/CD workflows in several significant ways. This powerful combination automates artifact handling, simplifies deployments, and enables the adoption of GitOps practices for Kubernetes deployments.

By automating artifact publishing within Codefresh pipelines, developers can significantly reduce manual steps, minimizing errors and ensuring artifacts are securely available for deployment. Cloudsmith’s support for multiformat repositories ensures that microservices using different package formats—such as Docker, npm, Helm, and Maven—can be managed and retrieved consistently.

Integrating Cloudsmith with Codefresh streamlines deployment processes by allowing developers to pull artifacts directly into their Codefresh pipelines. Whether deploying Docker images or Helm charts, this integration ensures consistency across all environments, from development to production, reducing deployment discrepancies.

, developers can ensure that only approved and secure components are used in their pipelines. Features like quarantine and upstream proxying add further control over unapproved or vulnerable dependencies. This guarantees a secure, compliant software supply chain.

Adopting GitOps for Kubernetes Deployments

Combining Cloudsmith and Codefresh enables teams to fully adopt GitOps practices for Kubernetes deployments. GitOps ensures that deployments are automated and aligned with the desired state defined in Git repositories. With Argo built into Codefresh, continuous reconciliation of your Kubernetes clusters keeps your infrastructure consistent with what’s declared in your codebase.

By integrating these platforms, you automate artifact handling, simplify deployments, and enhance security—all while adopting GitOps practices for Kubernetes deployments. This empowers your team to focus on delivering value—writing code, innovating features, and improving products—while the integration handles the complexities of artifact management and deployment.

How to Set Up a Pipeline with Codefresh and Cloudsmith

Setting up a CI/CD pipeline that integrates Codefresh and Cloudsmith is straightforward. Below is a guide to configure your pipeline for seamless artifact management and deployment using either 

 and create repositories for your artifacts.

: Ensure you have access to a Kubernetes cluster connected to Codefresh for deployments.

Open your Codefresh pipeline and go to the 

Name the variable (e.g., CLOUDSMITH_API_KEY), input your API key, and toggle 

Reference the API key in your pipeline YAML using ${{CLOUDSMITH_API_KEY}}.

 in Cloudsmith (required for OIDC to work with Cloudsmith).

Claims: For example add your Codefresh account ID to restrict access. For more information on claims consult the 

Assign the service account you created earlier.

In Codefresh, set up OIDC authentication by configuring your pipeline to request OIDC tokens during execution.

Add steps in your pipeline YAML to obtain and use the OIDC token for authenticating with Cloudsmith.

Modify your pipeline YAML to include steps that push build artifacts to Cloudsmith after successful builds.

To publish Helm charts, you need to use the Cloudsmith CLI. Ensure that the CLI is installed in your pipeline environment. For more details, refer to the Cloudsmith Helm documentation.

Deploying Artifacts from Cloudsmith Using Codefresh

Codefresh offers several ways to deploy your Docker images and Helm charts to your Kubernetes cluster using artifacts stored in Cloudsmith:

Using the Codefresh GUI to Deploy on Demand

: Choose Docker images from your connected Cloudsmith Docker registry.

: Select Helm charts from your added Cloudsmith Helm repository.

: Use Docker images stored in Cloudsmith within your pipeline steps.

: Utilize the Helm step in your pipeline to deploy charts from your Cloudsmith Helm repository.

Kubernetes Templating (cf-deploy-kubernetes)

Cloudsmith Blog

Dependency confusion and trust boundaries in modern builds

Using Trivy Inside Cloudsmith

Policy Management Example: Quarantine Packages Using Policy as Code

Integrating Dependabot with Cloudsmith Using OIDC

GitOps Pipelines with Codefresh and Cloudsmith

How to Manage Your Package Promotion Workflows with Cloudsmith

Level up your private npm registries in Deno with Cloudsmith

Reflecting on ShipItCon 2024: High-performing teams need flow

Using Cloudsmith as a Dependency Firewall

Fortify Dependency Management With Cloudsmith + Dependabot

Implementing Zero Trust Security With Cloudsmith in 5 Steps

Enhance Security with Chainguard and Cloudsmith