By submitting this form, you agree to our 

At Cloudsmith, we believe that visibility, control, and automation are essential to securing your software supply chain. That’s why we built Enterprise Policy Management (EPM) as a programmable enforcement layer to let developers and security teams define and apply rules that govern the behaviour of packages within your repositories.

This post lifts the curtain on the input data, technology stack, and policy lifecycle that drive Cloudsmith’s real-time, zero-trust decision engine - now extended to delay and block even the first download of non-compliant packages from upstream sources.


Rego is the policy language to manage Cloudsmith pipelines

At the core of EPM is Open Policy Agent (OPA) and its declarative language, Rego. OPA serves as the embedded decision engine, evaluating each package against the policies you define. Our CEO, Glenn Weinstein, already explained in a recent 

 why it makes sense to use open standard approaches that our end-users are already familiar with when managing artifact pipelines.

Cloudsmith wires OPA into the security scan phase of our 

. This phase processes every new package (whether uploaded directly or fetched from an upstream proxy) and applies the policies you’ve authored to determine the correct action to take (such as tagging, quarantining and blocking).

Input Schema provides the fuel for Policy Decisions

Policy logic in EPM is evaluated using a structured input document, passed to OPA. This document contains a complete snapshot of package context:

To avoid surprises, we strongly recommend, users write policies against known, documented fields. Some examples can be seen on our 

 to validate your logic against real package inputs. Finally, review the EPM 

 to confirm your policy is matching as expected.

OPA won’t throw errors for undeclared fields, but it also won’t enforce your intent unless the data is actually there.

Visualising the policy lifecycle from request to enforcement

EPM policies are evaluated during specific phases of the package lifecycle: when a package is uploaded and when new vulnerability advisories are discovered.



The lifecycle of an EPM policy begins when a 

 - typically during the first security scan of a package as it synchronises into a repository. At this point, Cloudsmith compiles the package’s metadata, including structure, uploader, repository, all into a versioned input document for policy evaluation. Link to the 

, the input is matched against the rego-based policy using the OPA engine. Each policy defines a set of conditions including checks for security vulnerabilities, licensing violations, naming conventions, or custom business rules. Furthermore, 

 are generated during the evaluation phase.

 begins. If the policy evaluation results in a match, a predefined sequence of actions is executed in precedence order. These actions (such as 

) allow you to enforce outcomes like tagging and quarantining packages. Actions are defined separately and attached to policies, and each can be configured to run in sequence, with the option to stop further execution if the action is marked as terminal.

Importantly, each policy is evaluated independently. This means multiple policies can match and execute their actions in combination, unless one of them is marked as 

, which halts further policy evaluation after it matches. Within a single policy, actions are executed in a deterministic order based on their 

 values, enabling precise control over outcomes like tagging or quarantining. This modular, layered approach allows you to compose nuanced lifecycle controls that align with your compliance and operational requirements.

Continuous security through CVE and EPSS feeds

Cloudsmith ingests vulnerability data from Common Vulnerabilities and Exposures (CVE) feeds. Each vulnerability includes standard metadata, such as CVSS v3 scores (via 

), the published dates, descriptions, and the associated identifiers. These allow granular rule logic based on severity, age, fix availability and more.

 (Exploit Prediction Scoring System) scores, which estimate the risk of a particular vulnerability to be exploited in the wild. These scores are embedded in each vulnerability record under 

, enabling policies that trigger on the high likelihood of exploitation, as opposed to having a high CVSS score but is unlikely to be exploited as a real threat to an organisation.

Through Continuous Security, Cloudsmith refreshes both CVE and EPSS data regularly. The CVE database via 

 is refreshed approximately every 6 hours. Likewise, the EPSS data is updated every 24 hours. These automated feeds ensure that EPM policies act on fresh vulnerability insights - even after a package is ingested. Unlike classic vulnerability management, where scans soon get outdated, we keep artifact scan results up-to-date with the most relevant vulnerability feeds, allowing users to automate their responses if anything changes.

Knowing how Cloudsmith’s EPM combines static package metadata with dynamic vulnerability intelligence (such as CVE+CVSS+EPSS) refreshed continuously, it provides users with a robust foundation to craft nuanced, data-driven policies. You can, for example, block only recently published EPSS‑high CVEs with fixes, or create aging ramp policies using published date logic.

Policy enforcement at the point of ingress

With Cloudsmith's EPM, development teams can now enforce security and compliance policies before a package is ever downloaded, even on the very first request. Historically, packages fetched from upstream registries were cached and served immediately, with scanning and enforcement applied only after the first pull from upstream. This approach prioritised speed and developer velocity, but came with a trade-off: the earliest moment of ingress remained unchecked, allowing potentially vulnerable or non-compliant code into the development environment before any policy was applied.

" flow. While this isn't a unique flow to EPM, users can certainly use this flow within EPM. If a requested package isn’t already in your repository, Cloudsmith will pause the download until the package has been fetched, scanned, and evaluated against your defined policies. If it fails policy enforcement, either due to issues like high CVSS vulnerabilities, disallowed licenses, or missing metadata, the package will be blocked from being served entirely.


This approach changes Cloudsmith’s traditional model from reactive to proactive. It delivers true zero-trust enforcement from the outset, ensuring that no developer or CI pipeline can accidentally ingest unvetted software. Every package, whether direct or transitive, becomes subject to the same rigorous controls, ultimately helping organizations align with security frameworks like 

 and pass compliance audits with confidence.

All Cloudsmith EPM policies follow a consistent structure using Rego:

This logic fails the policy if the package’s license is not approved. In doing so it returns a clear, human-readable 

 message, which is helpful for debugging and explaining decisions. The standard structure sets 

, ensuring that matches are both explicit and traceable. Finally, it sets 

 only when there are one or more policy violations. In this way, OPA decisions are deterministic, explainable, and fast, making them ideal for secure automation.

Rego provides powerful primitives for matching package names, filenames, tags, and other strings. Some real-world examples:

Enforce filename prefix:


not startswith(pkg.filename, "internal-")

This flexibility allows you to enforce naming conventions, prevent shadow IT, or ensure metadata hygiene. If you are ever unsure about the supported fields that can be used in EPM Rego policies, check out the 

 for Cloudsmith. Alternatively, Cloudsmith’s Ralph McTeggart created a useful 

 to better understand how to construct and validate policies on the fly.

Advanced example of blocking high-risk vulnerabilities with fixes

You can also craft more sophisticated rules that incorporate CVSS severity, EPSS risk, and whether a fix is available. This lets you enforce “

” - only quarantining packages that are both severe and exploitable, and that could be remediated.

The above policy only matches vulnerabilities that already have a fix available. We explained in a previous 

 why this approach is important when tackling CVE tsunamis. This policy requires CVSS v3 score ≥ 8.0 (which is categorised as a HIGH severity). However, it also requires the EPSS score ≥ 0.5 (moderate to high likelihood of exploitation). As always, it should prevent high-risk downloads but also flags the issue with a descriptive message so DevOps teams can take action quickly.

By combining multiple data signals (severity, exploitability, fixability), you avoid noisy false positives and focus your policy enforcement on the vulnerabilities that truly matter. This balance helps developers ship securely, without drowning in alerts or blocking known harmless dependencies.

Cloudsmith’s EPM framework is driven by structured package metadata and enriched by real-time security scan outputs. This data forms the basis of each decision evaluation, allowing Rego-based policies to act deterministically based on concrete inputs such as CVSS scores, file counts, license data, and uploader identity. The integration of OPA ensures that every policy execution is reproducible, traceable, and fully customisable to suit the operational and security requirements of each workspace.

By embedding this decision logic at the point of package synchronisation, EPM supports early intervention and automated remediation, such as quarantining, tagging, or rejecting packages before they propagate through your CI/CD pipeline. The result is a policy engine that aligns tightly with your organisation’s compliance posture, operational norms, and internal trust boundaries, all without compromising the speed and automation you’ve come to expect from Cloudsmith.

Nigel Douglas

Head of Developer Relations

Pull back the hood on the data and tech that informs EPM

the artifact management market is up for grabs

. In a hot market, you’re going to see some interesting and not-entirely-logical attacks. And if I could creatively paraphrase 

, it’s hard to get someone to understand something when their company’s success depends on them not understanding it.

I’m thinking about a curious criticism that one of our competitors, JFrog, leveled at us in a 

. They said they spotted some “red flags” about Cloudsmith, the first and most damning being that we are “

packaging [a] competitor’s open source as an enterprise solution,

[s]elling a paid ‘security’ solution that’s little more than a thin UI layer over someone else’s open-source tool.

 and the underlying Trivy DB as one source of software package vulnerability data.)

They stick to this point pretty persistently, saying we are “

charging you for an open-source solution,” 

rely on open source software as [our] SCA solution,

“if Trivy becomes unsupported or compromised, Cloudsmith’s entire SCA capability could suffer, leaving users vulnerable.

JFrog has it wrong on several counts here.

For starters, pretty much every enterprise tool in the last few decades, including 

, is built on foundations of open-source software (OSS). Does this mean we’re all “charging” customers for “packaging” OSS as an “enterprise solution” in some nefarious way? Like most OSS, Trivy DB is “generic by nature,” which leaves room for developers and software vendors to build custom capabilities on top of it. Which is exactly what Cloudsmith has done. If Cloudsmith is wrong for using “generic” OSS, then we’re all wrong.

In accusing Cloudsmith of using a “competitor’s” OSS, they’re referring to Aqua Security. They’re confused on several key points.

First, they’re failing to acknowledge the distinction between the role of a primary OSS maintainer and a commercial vendor. Aqua Security, the company, is the primary maintainer of the Trivy OSS project. It is also the vendor behind Aqua Enterprise, a commercial product that is built around Trivy.

Second, they’ve tellingly assumed that Cloudsmith considers Aqua Security to be a competitor. We very much don’t. We regard Aqua as a complementary solution; we support integration between Cloudsmith and Aqua Security; and we see Cloudsmith as the data plane & control plane for software supply chain security, so customers can process metadata and execute policies based on vulnerabilities identified by Cloudsmith’s scanning process, or sourced from third-party vulnerability data from the likes of Aqua Enterprise or others, or a combination.

 software can “become unsupported.” But that actually tends to be a much bigger risk with commercial software than with OSS. Trivy is published under an Apache 2.0 license. Even if the maintainers stop publishing future versions as open source, the community could fork an older version. We don’t think this will happen, but if it does, Cloudsmith relies on multiple data sources, and we can easily change our mix from time to time. There are numerous other providers of data similar to Trivy’s.

So why is JFrog attacking Cloudsmith so stridently for relying on OSS, like virtually every commercial software company does, and specifically for relying on Trivy? I can only speculate, but JFrog sees its own security product, Xray, as an important revenue source, and they seem to regard Aqua Security, along with other similar companies, as competitors to Xray.

To state the obvious point: of course we embrace open source. 

 about Cloudsmith’s support for OSS projects, and we Cloudsmithers all believe deeply in the power of software reuse via OSS. I’m old enough to remember when reuse was essentially an unsolved problem in software; we never could have envisioned back in the 1990s how OSS would fundamentally change that. The core functionality of our platform helps enterprises everywhere to efficiently and securely manage the thousands of OSS artifacts and dependencies that make up such a large part of any company’s software supply chain.

And to state another obvious point: we’re not just serving up generic OSS and then somehow convincing customers to pay us for it. It’s what Cloudsmith has built on top of OSS that we’re really charging for. Things like our unmatched global cloud-scale infrastructure, our 24x7 service levels, our policy-as-code enterprise policy manager (EPM) that evaluates every package using your company’s risk criteria, our ability to proxy and cache public upstream registries at unmatched performance levels, our artifact synchronization process that performs scanning and metadata enrichment before a package even hits your repository and gets served to CI/CD pipelines or developer IDEs, our stellar customer support, and much more.

Yes, we rely on OSS, and we think that’s a significant strength from which customers benefit.


Glenn Weinstein

Of Course We Embrace Open Source!

When talking about DevOps and software delivery pipelines, security, compliance, and governance should all be native to the development workflow. Yet traditional approaches to software supply chain security often feel bolted-on. Proprietary black boxes are hard to integrate - and harder still to understand or extend. Instead of adapting to your workflows, you’re expected to adapt to theirs, with little room for customisation or clarity about what they’re actually doing under the hood.

That’s where Cloudsmith’s Enterprise Policy Management (

) differs from other legacy approaches. This is a powerful, flexible, and developer-friendly way to implement policy-as-code using the Open Policy Agent (

) and its associated Rego, natively within your artifact management pipeline.

Legacy artifact management systems typically offer pre-baked security gates that require manual reviews, or offer minimal configurability. While these should solve some business outcomes, they often don’t scope well to your specific business logic. Cloudsmith gives teams full access to define policies using Rego, a standard open-source policy language used in many enterprise solutions.

This familiar policy language is ideal for teams who are automating supply chain security controls. Cloudsmith’s EPM enables fine-grained, conditional control over package handling during security scanning. Additionally, Cloudsmith’s policy implementation integrates with automation tools via Cloudsmith's robust REST API. With EPM, you can go beyond one-size-fits-all policies and encode the exact rules that matter to your organization, whether it's license restrictions, CVSS thresholds, naming conventions, or internal workflows.

Cloudsmith policies are evaluated during package synchronization, after a security scan completes. This gives teams a reliable hook to enforce quality, security, and compliance gates before artifacts move deeper into production pipelines. Here’s what makes it practical:

: 
All policies are written in Rego and must follow a specific schema. As long as Cloudsmith supports the specific built-in functions required in the policy, it should be valid. Rego is incredibly flexible. 

As seen in the example below, you can use RegEx within OPA Rego to match specific package filenames that contain a semantic versioning for the file name, or use RegEx to scope the unique business context that matters to you.

This Rego policy is designed to enforce a naming convention for packages in a Cloudsmith repository. Specifically, it ensures that package filenames starting with 

The policy implements filename prefix check to target only packages where the filename starts with 

. The regex match for SemVer, scans those h11- files, and it enforces a filename pattern where 

Finally, policy introduces mismatch handling, where the filename does not conform to this SemVer pattern with an approved extension, the policy matches and produces a human-readable message explaining why.

Policies are considered terminal by default. When a match occurs, execution stops and the associated actions trigger. This is the policy evaluation flow. Policies are evaluated in order of their precedence (lowest number = higher priority). When a policy’s Rego rule evaluates to 

, it’s considered a match. By default, Cloudsmith stops evaluating any further policies after this match. The actions associated with that matching policy (like tagging, quarantining, or changing state) are immediately triggered.


For a Cloudsmith EPM policy to be enforced, it needs an associated 

 that defines the name and description of the policy, but also whether it’s enabled by default or is terminal, and more importantly defines the precedence at which it’s read:

Upon creation, the API returns a success response indicating the policy has passed validation and is active. The policy is also reflected in the Cloudsmith UI almost instantaneously, ensuring immediate visibility and enforceability within your package governance workflows.


Terminal behaviours matter, and this design is intentional. It allows users to short-circuit processing for high-priority rules, as well as avoiding conflicting actions across multiple policies and keep policy logic simple and predictable.

To apply the policy, you can create a HTTP POST request to the policies API with the 

 reflecting the data that is being sent to that API:

While terminal behaviour is the default, non-terminal policies can be configured explicitly by setting:

This lets evaluation continue to the next policy, even after a match. You can use this when you want multiple policies to apply, if you're using multiple independent tagging or analysis rules, or if you need layered enforcement, like tagging, then quarantining.

 (to Quarantine package and render them unusable) or 

 (with context for further reviews) via the API. Each policy can have multiple actions with a defined precedence. Once you have a Policy Slug generated from the created Cloudsmith EPM policy, you can assign a tagging action for your policy ID:

A straightforward way to test this policy is to take a package that already has a valid SemVer-compliant filename and rename it by replacing the version number with a placeholder like “test.” For example:

Cloudsmith's REST API enables full Create, Read, Update, Delete (CRUD) operations on policies and their components. This is where automation shines:

Create or update policies dynamically from CI/CD scripts.

Simulate policy evaluations with real or staged package metadata.

Apply tagging or quarantining logic that integrates with your observability or DFIR tools.

 is currently the best fit for automating Cloudsmith EPM policies due to its flexibility in shell scripting (such as 

). Github Actions also provides an easy integration with rego files stored in your repo, secure handling of secrets such as the API Key, as well as built-in CI/CD lifecycle for validation, simulation, and deployment.

 before applying policies in production. This dry-run capability helps ensure your Rego logic behaves as expected, reducing the risk of false positives, which could result in things like blocking good artifacts.

The response contains a list of packages that were tested, with fields like 

 that would be taken if the policy is enabled. You can add a package search query to filter the packages being evaluated. This reduces all the packages to apply the policy to.

You can disable the policy either on policy creation, or at a later time via the API, as seen here:

 will tell users whether the policy matched the scope of their package:

Once the package is pushed to Cloudsmith, you can check your 

 package name to see if the package data is the data you expected to see in the policy evaluation:


If the policy is no longer required, you can use the 

By combining EPM with Cloudsmith's flexible REST API, you unlock a powerful new paradigm:

Governance that’s automated and programmable.

Policies defined by your logic, your rules.

With Cloudsmith, developers and platform engineers can treat security and compliance as first-class, automated citizens in their CI/CD systems. Whether you’re integrating with Terraform, GitHub Actions, or your own orchestration tooling, Cloudsmith EPM gives you the control you need to secure your software supply chain your way.

Unlocking policy-as-code automation with Cloudsmith EPM

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.

Ciara Carey

Solutions Engineer

Using Trivy Inside Cloudsmith

Over the past few years, Platform Engineering has gained traction as more enterprise organisations adopt the practice of creating centralised, self-service platforms that give developers easy access to the tools they need to focus on what they do best: building great software.

At the heart of every Golden Path lies the ability to reliably produce, store, and consume build artifacts, from container images to internal libraries. Without artifact management platforms, even the best developer workflows quickly break down under the weight of inconsistency and manual overhead.

If you haven’t already heard the term “Golden Path” in relation to Platform Engineering, you’re sure to encounter it along your journey through the modern software development ecosystem.

a preconfigured, paved road that provides an end-to-end workflow for developers, typically enabled via an Internal Developer Platform (IDP).

Without Golden Paths, each team is left to build their own workflows and pipelines from scratch. This results in:

: Teams reinvent the wheel, spending valuable time wiring up their CI/CD, security scans, and deployment steps instead of focusing on product work.

: With no shared templates, security, compliance, and operational practices become fragmented, which introduces risk and makes governance harder to achieve.

: Developers moving across teams face steep learning curves, as every team’s stack and practices are different.

: Introducing platform-level improvements such as security updates, new tooling, and organisation-wide polices become slow and error-prone because there’s no consistent delivery mechanism.

: Finally, without centralised artifact management practices, teams duplicate efforts, store untracked builds, and rely on manual conventions that lead to debugging nightmares and deployment inconsistencies.

Golden Paths addresses these challenges by providing a pre-defined, paved route for delivering software, backed by self-service templates, sensible defaults, and secure, reusable components. This self-service approach not only accelerates development cycles but also reduces cognitive load, promotes consistency, and allows developers to focus on building value rather than maintaining the infrastructure.

There is more to Golden Paths than just combining tools and services - it’s also about intentionally understanding the needs of your developers and crafting a path that will actually benefit the developer’s day-to-day tasks. Below are the core pillars of Golden Paths:

A golden path should empower developers to operate independently by providing automated, well-documented, and secure self-service tooling. This means developers can provision everything they need, such as infrastructure, repositories, pipelines, environments, and service templates, all without relying on manual interventions from platform, DevOps, or infrastructure teams. By reducing the need to open tickets or wait in queues, teams can move faster, experiment safely, and maintain momentum. This not only improves developer productivity but also reduces bottlenecks and operational overhead for supporting teams. A strong golden path makes the right way the easy way to self-serve by default and scalable by design.

Golden Paths should embed security, compliance, and governance controls directly into the desired developer workflow - automatically and invisibly. This means that secure defaults, access controls, audit logging, policy enforcement, and regulatory compliance are all baked into the tooling and templates provided. Developers shouldn’t have to worry about configuring these aspects manually or remembering compliance checklists afterwards. The golden path handles it all for your teams, reducing the risk of human error and ensuring consistency across teams. By baking these controls into the system instead of relying on external gates, golden paths help teams meet compliance or security standards by default, because it’s already handled in those paths.

Golden Paths should be highly repeatable and standardised, serving as the “blessed” or recommended approach to solving common problems. This consistency helps ensure that developers across different teams are using the same tools, patterns, and workflows, which reduces cognitive load, lowers onboarding times for new engineers, and minimises error or inconsistencies in implementation. By following a well-defined golden path, we avoid variation between teams and can instead focus on delivering value. We want to avoid repeatedly making the same foundational decisions.

Golden Paths are designed not just for individual use cases, but to operate reliably and efficiently at organisation-wide scale. This means the recommended patterns, tools, and platforms can handle high volumes of usage, large teams, and complex systems without degradation in performance or user experience.

For example, a Golden Path might define a standard CI/CD pipeline that includes automated testing, security scanning, and deployment to production. Rather than each team building their own version, hundreds of teams can adopt the same pipeline template, which is backed by a shared, scalable build infrastructure like Github Actions runners or a managed ArgoCD setup.

They should be resilient by default, fault-tolerant, and implement redundancy to ensure it performs consistently across geographies, teams and workloads. Whether deployed in a single region or across global environments, golden path solutions should maintain predictable reliability, ensuring fast feedback loops even under high load.

One of Cloudsmith’s own pillars, tooling is intuitive, fast, and well-documented so developers stay in flow and don’t need tribal knowledge.

Golden Paths require tooling that is flexible, secure, and invisible when it needs to be. Cloudsmith’s cloud-native, fully managed architecture supports Platform Engineering teams in building paved roads with minimal friction.

Where and how Cloudsmith enables Golden Paths

Now that we’ve covered each of the core pillars, let’s explore how Cloudsmith best enables Golden Paths:

Cloudsmith’s architecture was designed from the ground up to prioritise speed and simplicity. These are core pillars of Golden Paths. There’s no need to manage infrastructure, patch servers, or wrestle with upgrades.

With a streamlined golden path, developers can:

Create and manage artifact repositories for multiple formats

Configure upstream proxies for public dependencies

Create, manage, and rotate Entitlement Tokens

Create and manage service accounts with OIDC

Bootstrap a full microservice project with a dedicated repository with upstream proxy

This self-service approach makes it easier for Platform teams to build repeatable workflows that scale across dev squads. Next we’ll look at how Cloudsmith’s multi-format repositories make automation easier while improving self-service for developers. They’re a perfect fit for how we scale our internal platform and support modern delivery workflows.

At a high-level, Cloudsmith allows businesses to host all supported package types in a single repository (npm, Docker, Python, Maven, NuGet, Ruby and more) without sacrificing compatibility with native tooling. This flexibility opens a door to unified, scalable, and an automated approach to artifact management.

This enables flexible repo structures where platform teams can organise based on environment (such as dev, staging, prod), product lines, teams, or any kind of structure that fits your workflow, without being constrained by package formats. The very nature of centralising artifacts allows teams to monitor, and more importantly audit all formats from a “single source of truth” with detailed stats, versioning, tooling compatibility and entitlement token controls.

Security shouldn’t slow you down - and with Cloudsmith, it doesn’t.

Golden Paths can bake governance into the developer experience, enabling teams to move fast without bypassing standards. Rather than embedding artifact verification logic inside individual pipelines (which quickly becomes unmanageable at scale), platform teams can use Enterprise Policy Management (EPM) to abstract these controls into centrally managed, observable policies as code.

Cloudsmith Blog

Pull back the hood on the data and tech that informs EPM

Of Course We Embrace Open Source!

Unlocking policy-as-code automation with Cloudsmith EPM

Using Trivy Inside Cloudsmith

Golden Paths Made Easy With Cloudsmith

OWASP CI/CD Part 9: Improper Artifact Integrity Validation

Security is a leading priority for 2025

The Artifact Management Market Is Up For Grabs

Adding AI to applications using the Model Context Protocol

OWASP CI/CD Part 8: Ungoverned Usage of 3rd Party Services

Goodbye imagePullSecrets, Hello Kubernetes Credential Providers

Prototyping an MCP Server