By submitting this form, you agree to our 

Containers have been with us for a while and are ubiquitous in the Secure Software Development Life Cycle (SSDLC). According to some reports, 

 use containers for most or all of their production applications. It’s no surprise really, as containers provide consistency and standardization across the lifecycle while speeding up delivery pipelines. They revolutionized how we develop and deploy apps in the cloud and there is no sign of this changing anytime soon.

Like any part of the SSDLC, containers have security risks and can be breached. This can be due to misconfiguration of the containers, inherent vulnerabilities in the contained software, like missed OS patches, or vulnerabilities in the runtime code. These can manifest in various ways, but some common ones are vulnerabilities that provide root access to the OS, turn off security features, execute malicious code at run time, or run phantom processes silently in the background. And these breaches do happen. The most famous container breach is still the 2018 Tesla breach, where it was reported that hackers read AWS credentials from the breached containers and therefore gained further infrastructure access, allegedly launching cryptojacking operations using that infrastructure. So, with nearly 60% of organizations using containers in production, it's great to hear about Docker’s Hardened Images being announced last week.

 and records 11 billion pull actions on these images each month. Previously, they released Docker Official Images to provide confidence in the provenance of the images, SBOM support to give transparency on contents and Docker Scout for real-time insights. This focus on security has evolved again into Docker Hardened Images.

A hardened image is a container image prepared to reduce Common Vulnerabilities and Exposures (CVEs).

Ensuring they provide the core functions required

Reducing the target area for attacks by removing up to 95% of the contents

Providing a curation and governance process for images

The provenance and curation of these images should give organizations and developers confidence. Knowing that images will be checked and kept up to date by a reputable source like Docker can only be reassuring. However, the security of containers and images doesn’t stop here. At Cloudsmith, we are delighted to partner with Docker on this launch, as we know we can add more to securing container usage together.

The above image shows a typical example of how this works in practice. An organization’s CI/CD pipeline is configured to use Cloudsmith as a private registry for its artifacts, including container images. When a build is triggered during development, the CI/CD tooling requests the container image(s) it needs.

With an upstream proxy for container images configured, Cloudsmith will fetch the image(s) from Docker Hub. It is at this stage where a verifiable, trusted Docker Hardened Image can be fetched. There is no extra configuration required in Cloudsmith, so users can benefit from using these images right away. Pulling a Docker Hardened Image is the same as fetching any other image from Docker Hub. Maximum security and trust is built into the raw image. For customers that have specific compliance or security requirements, Cloudsmith will also enforce policies around licensing and vulnerabilities. 

See: link to enterprise policy management blog

. This ensures that organizations have the right blend of security at source and the flexibility to map to their own requirements.

How do organizations ensure developers use these images during code creation and the deployment lifecycle? Cloudsmith is already used by organizations worldwide for their Docker registries, and our advanced features provide tools built for global teams.

Our cloud native, global availability means an organization’s registries are available wherever its teams are. Policy creation and enforcement provide granular access to private and public images, ensuring a source of truth for the organization’s images and providing visibility to its security teams. We also support CI/CD workflows, meaning the organization can confidently see what is being promoted to production.

With seamless integration and zero tradeoffs between speed and compliance, combining the peace of mind provided by Docker Hardened Images with Cloudsmith’s Docker registry support and functions can produce even greater governance and confidence.

That's why we are delighted to collaborate with Docker for this launch, securing the software supply chain further than ever before.

Want to learn how to secure your software supply chain end-to-end?

Watch our webinar next week for an in-depth discussion on container security, hardened images, SBOMs, and how to build a zero-trust artifact lifecycle. 

 and get actionable insights from Docker and Cloudsmith experts.

Jack Gibson

Senior Software Engineer

Ralph McTeggart 

Principal Engineer

Securing Containers at Scale: Docker Hardened Images + Cloudsmith

In the race to ship software faster, many teams have turned to automation, decentralised tools, and powerful pipelines. But lurking under the surface of these streamlined processes is a growing and often invisible Identity and Access Management (IAM) threat vector. — a core vulnerability in modern 

This post is Part 2 in our ongoing blog series exploring the OWASP Top 10 CI/CD Security Risks, based on insights from 

, which is a must-read for anyone serious about pipeline security. Today, we shine a light on 

OWASP CICD-SEC-2: Inadequate Identity and Access Management

Principle of Least Privileged Access in CI/CD

Modern software delivery pipelines span dozens (if not hundreds) of interconnected systems. From source control to build agents to artifact repositories and deployment targets, each component relies on a web of human and machine identities to function.

But managing all these identities (especially ensuring they follow the principle of least privilege) is no small feat. IAM often ends up inconsistent, outdated, or overly permissive, creating significant vulnerabilities across your CI/CD toolchain.

Through research and real-world incident response, several recurring IAM security issues emerge when it comes to identity and access management in CI/CD environments:

In most organisations, engineers are given broad access to systems like Git, CI tools, or artifact registries (oftentimes with far more access than they need). This makes compromise of a single identity disproportionately dangerous.

When a single identity, for example an AWS IAM role, holds excessive permissions, it becomes a high-value target. An attacker who compromises that AWS identity doesn't just gain access to one part of the cloud provider - they gain a foothold in many, and in some cases, nearly all other connected systems such as CI systems. This lateral movement potential amplifies the blast radius of what could have been a contained incident.

In many businesses, user accounts (especially those of former employees or outdated systems) are often overlooked once they're no longer actively used. These are referred to as 

. They pose a serious security risk if not regularly audited and removed.

When an employee leaves or a service account becomes obsolete, the account should be disabled or deleted promptly. However, due to oversight, lack of automation, or unclear off-boarding procedures, these accounts can linger in the system. Even if they're not in active use, they can still have valid credentials and potentially high levels of access to sensitive data or internal systems.

When individual tools or systems manage their own user accounts (commonly referred to as local identities) rather than integrating with a centralised 

 (IdP), it significantly undermines the ability to enforce uniform security policies. This fragmented approach creates operational silos, where critical security practices such as 

 (MFA), password complexity and rotation policies, or standardised de-provisioning processes become inconsistent or are entirely absent. As a result, the business is now exposed to greater risk, with increased chances of credential sprawl, orphaned accounts, and compliance gaps.

Not only do shared credentials violate security best practices, but they also break accountability and audit trails. This would be a real nightmare scenario during incident investigations. When multiple people log in under the same account, it becomes nearly impossible to determine who did what, when, and why. This lack of traceability destroys accountability and renders audit logs practically useless.

During a security incident or forensic investigation, this can turn an already stressful situation into chaos. Not knowing who accessed sensitive data or executed a risky command is a major obstacle to containment and remediation. Simply put, shared IAM accounts turn manageable risks into security blind spots.

Accounts associated with personal or untrusted email domains (such as 

) introduce a heightened level of risk, particularly when they’re granted access to internal systems. These external collaborators often fall outside the scope of centralised identity and access management, making it harder to enforce consistent security policies, monitor activity, or revoke access when necessary.

, which allow users to create their own accounts without vetting or approval. This can open the door to impersonation, fraud, or other unauthorised activities. Combined, these scenarios significantly widen your development team's attack surface, increasing the likelihood of data leaks, unauthorised access, or compliance violations.

Case Study: New York State’s GitLab Exposure

To highlight how real these risks are, let’s look at a stark example.

 operated by New York State’s IT department was left exposed to the internet, configured to 

. Anyone, from anywhere, could create an account and access repositories that contained 

secret keys, passwords, and other sensitive data

, the breach exposed the state’s infrastructure to potentially catastrophic consequences. It’s still unclear how long the server was exposed, but the lack of proper IAM (including no registration restrictions, stale secrets, and unrestricted access) created a perfect storm.

IAM doesn’t have to be a liability. With the right processes and tools, organisations can regain control over identity management in CI/CD. Here are some key recommendations:

: Continuously inventory every identity across SCM, CI, CD, and artifact systems. (whether they’re human or machine identities). 

machine identities outnumber human identities by a ratio of 45 to 1 ratio

. Similar to human identities, machine identities require authentication to access critical resources, and this is often done through shared secrets such as OAuth tokens and access keys.

: Set expiry dates for access and ensure external collaborators only receive what’s absolutely necessary. This leads on to the topic of the 

. Do not provision accounts with the intention of them being used as “shared accounts”. This makes auditing employee-specific behaviour almost impossible.

: Review actual usage vs. granted permissions and dial down access accordingly.Optimising permissions for IAM users, roles, and policies across various cloud and CI services isn’t easy, but it's required to align with the principle of least privilege.Check out 

 on implementing least privilege access for secrets in Github Actions.

: Define inactivity thresholds and routinely disable or remove dormant accounts.By establishing an acceptable timeframe for disabling or removing inactive IAM identities within your cloud providers and CI/CD platforms, you can better enforce the deactivation of identities that surpass this predetermined period of inactivity.There are lots of unique ways to approach the issue of deleting inactive identities in the cloud, such as this automated approach from 

: Use centralised IdPs wherever possible; avoid local user accounts.Ensure that users no longer requiring access are disabled or removed and that IAM security policies align with the organisation’s standards.

 is like leaving the front door unlocked. Anyone can walk in, and they might bring trouble with them. Many platforms, by default, grant new users baseline permissions that could expose sensitive features or data. Unless your application is explicitly designed for open user access, always disable self-registration. This reduces the attack surface and ensures only vetted users can create accounts, maintaining tighter control over who gets in and what they can access.

The Bigger Picture: IAM as a Security Priority in CI/CD

We’ve established that Identity & Access Management isn’t just a backend concern. IAM is a core part of securing your software delivery pipeline. As CI/CD systems continue to evolve, a single misconfigured credential from a year ago, or an overly permissive role for a junior engineer, could open the door to serious breaches, often with immediate impact.

This post is just a glimpse into what’s covered in Cloudsmith’s OWASP CI/CD Security Guide. Inside, we break down each control in depth, discussing the practical CI/CD risk mitigation strategies, as well as exploring any real-world case studies to help you strengthen your software delivery process from the inside out.

of the OWASP CI/CD Security Guide today and take the next step toward securing your CI/CD pipeline from the inside out.

Nigel Douglas

Head of Developer Relations

OWASP CI/CD

OWASP CI/CD Top 10: Inadequate IAM

 and broader questions about long-term support for cybersecurity infrastructure, one thing is clear: controlling what you can is more important than ever.

This is abundantly clear in modern software development practices which rely heavily on CI/CD systems, which in turn serve as the primary conduit from a developer’s local environment to production. The adoption of DevOps practices and the proliferation of microservices have greatly diversified the CI/CD landscape:

Development stacks now span multiple languages, frameworks, and tools, including GitOps and Kubernetes.

New technologies are adopted faster, often without significant integration hurdles.

Automation and Infrastructure as Code (IaC) are standard practices.

Third-party components (whether services or code dependencies) are commonly integrated with minimal effort, sometimes by simply adding a line or two of code.

While these capabilities significantly accelerate and enhance software delivery, they also introduce a broader and more complex attack surface. Threat actors, recognising the strategic importance of CI/CD infrastructure, are increasingly targeting these environments to gain access to critical systems and data.

 in a series diving into the OWASP Top 10 risks for CI/CD systems, based on Cloudsmith’s 

 that explores these risks in detail and offers practical guidance for securing your software pipelines.

This risk involves an attacker exploiting weak or missing safeguards within the CI/CD pipeline (such as in 

) to push unauthorised or malicious code without triggering any manual checks or secondary validation.

CI/CD processes are designed for speed and efficiency. Code can be committed and deployed to production in minutes, often with little or no human oversight. Without robust flow control mechanisms, a compromised account or system could push changes that go directly into production unchecked.

Committing code to a monitored branch that automatically triggers deployment.

Using manual triggers to deploy unauthorised code.

Publishing malicious updates to shared libraries used in production.

Exploiting auto-merge rules to introduce malicious changes.

Circumventing weak branch protections by using excluded users or branches.

Uploading manipulated artifacts to repositories where they are automatically consumed by deployment processes.

Modifying production code or infrastructure directly, such as through a misconfigured AWS Lambda, without audit or approval.

Real World Example: Bypassing required reviews using GitHub Actions

 was exploited by leveraging GitHub Actions to bypass branch protection rules that rely on pull request review requirements. Normally, organisations set up branch protection rules that prevent users from merging code into sensitive branches without at least one approval from another team member. However, GitHub Actions is enabled by default in all repositories, and anyone with Write permissions can configure a workflow.

The attacker, after compromising a user account, could push a malicious workflow along with their code. This workflow, using the default 

 with elevated permissions, could automatically approve the pull request via the GitHub API, effectively bypassing the human review process. Because GitHub considered the bot’s approval valid, the code could then be merged without oversight, despite the protection rules in place.

, which highlights risks stemming from weak or absent enforcement of process and policy within CI/CD pipelines. In this case, the lack of granular flow control in how GitHub Actions interacts with protected branches allowed a user (or an attacker with access to their account) to subvert established safeguards.

The CI system failed to properly distinguish between trusted, manual reviews and automated approvals, blurring a critical boundary in the pipeline's security model. Ultimately, this allowed attackers to exploit CI behaviour to escalate privileges and execute unauthorised changes in production workflows, showcasing the real-world implications of insufficient control mechanisms in CI/CD environments.

To reduce the risk of unauthorised changes being pushed through CI/CD pipelines, businesses should establish controls that require multiple layers of validation. Here are several ways to enhance pipeline integrity:

 Apply strong protection policies on critical branches. Avoid exempting any user or branch from these rules. Ensure that users who can bypass code review cannot trigger deployment processes.

 Restrict the use of automatic merging and thoroughly validate any such configurations. Avoid using third-party scripts for auto-merge unless they are well-audited and sandboxed.

Require Multi-Person Approval for Deployments:

 Implement controls that require a 2nd-party to review or approve builds before they can be promoted to production.

 Only allow artifacts produced by trusted, pre-approved CI service accounts to enter the deployment pipeline. Artifacts from unknown or unauthorised sources should require secondary review before use.

 Use tooling to continuously detect inconsistencies between production code/infrastructure and its source. Automatically flag or roll back unauthorised changes.

To further strengthen your CI/CD security posture, consider integrating the following 

OpenSSF (Open Source Security Foundation)

: Helps verify the origin and integrity of artifacts through cryptographic signing. You can ensure that only signed and trusted artifacts progress through your pipeline.

: Evaluates the security posture of your project repositories, including branch protection, CI usage, and dependency update practices.

: Supply-chain Levels for Software Artifacts is a security framework designed to improve the integrity of software supply chains. SLSA can help enforce provenance and prevent untrusted code from entering the build or deployment pipeline.

: An automated policy enforcement tool for GitHub repositories. It can be used to enforce best practices such as required reviews and branch protections.

By combining policy enforcement, robust configuration, and the adoption of security-focused tools like those offered by OpenSSF, organisations can greatly reduce the likelihood of a single point of compromise leading to full pipeline exploitation. If you like the content here, and would like to know more about the OWASP Top 10 for CI/CD systems, check out our free Cloudsmith eBook - 

OWASP CI/CD Top 10: Insufficient Flow Control in CI/CD Pipelines

Modern development teams often rely on Continuous Integration (CI) pipelines to automate testing, building, and deployment of their code. These pipelines are typically defined through configuration files stored within the source code repository. 

, or other contributors with the appropriate permissions frequently need to edit these files to adjust workflows, add new checks, or support evolving project requirements.

However, if a user with access to these configuration files (or to other files that the CI pipeline consumes) intentionally or inadvertently introduces malicious commands, they can compromise the security of the CI process. This is known as “poisoning”, where the altered pipeline executes unauthorized or harmful commands during its automated runs.

What is Poisoned Pipeline Execution (PPE)?

Poisoned Pipeline Execution (PPE) occurs when malicious actors exploit vulnerabilities in CI/CD pipelines to execute unauthorized code - whether that’s potentially compromising credentials, modifying production artifacts, or establishing persistent backdoors.

In this blog post, we dive deep into the anatomy of PPE, drawing from real-world incidents and outlining actionable best practices to defend your pipelines against this insidious attack method.

At its core, PPE occurs when an attacker manipulates files that influence how CI/CD pipelines operate. This can be the pipeline configuration itself, or indirectly, any file referenced by it - like build scripts, Makefiles, or test configurations.

: The attacker modifies the CI configuration file directly.

: The attacker alters files referenced by the CI config. (scripts, Makefiles, tests).

: Attacks via public or shared repositories consumed by the pipeline.

The crux of the problem? Pipelines often run unreviewed code - especially when triggered by events such as 

. If this code is malicious, the pipeline executes it with all the power and trust granted to the CI system.

 attack, adversaries manipulate the CI/CD configuration file. For example, this simple 

But with write access or an accepted pull request, an attacker can inject malicious commands. In this case, they are piping out the environmental variables of access key and secret key to a remote server in 

A seemingly simple change can exfiltrate AWS credentials stored in GitHub secrets to an attacker’s server, granting them access to your production cloud environment.

 (a well-known open-source, infrastructure identity platform) identified a critical vulnerability in its CI/CD infrastructure, which relied on Drone CI and Kubernetes. The issue stemmed from the use of privileged Docker-in-Docker (DIND) containers. A malicious pull request could exploit this setup to escape the container sandbox and access secrets from neighboring pods. Some of these secrets included credentials tied to Teleport’s production environment.

Although no breach ultimately occurred, the exposure highlighted a dangerous architectural flaw: the compromised Drone instance was responsible for both internal and external CI/CD workflows. As a result, the stolen secrets had the potential to impact a wide range of critical assets, including release artifacts for Teleport and Gravity, backend services for Teleport Cloud, legacy billing systems, and private GitHub repositories.

This incident could also be categorised as a 

 attack since it allowed attackers from the public internet to create a pull request in a public Github repository linked with the Drone CI pipeline, which allowed the adversary to modify the CI conf file that executed the malicious pipeline.

I-PPE: The Subtle Art of Indirect Poisoning

In some setups, attackers may not have the ability to change the CI config itself - but they can alter referenced files like Makefiles, test scripts, or shell scripts. This is 

 is fetched from a protected branch, but the 

During the build stage, AWS credentials are loaded as environment variables. When the 

 command runs, the attacker’s malicious command sends the entire environment (including credentials) to the remote server.

public AWS-operated website was exposed to I-PPE

 file that attackers could manipulate via a pull request. Due to insufficient validation, the pull request triggered 

 with deployment privileges. The attacker uploaded a test file directly to production - demonstrating full deployment access.

Why PPE Is a Critical CI/CD Security Risk?

PPE attacks are particularly dangerous because CI/CD pipelines often run with high privileges. A successful attack may lead to:

: Attackers may implant malware in production artifacts.

: Environment variables and secret stores are frequent targets.

: PPE can be a foothold for long-term espionage or control.

: Privileged access to cloud resources, databases, or internal networks.

How to Protect Your CI/CD Pipeline from PPE

The good news? While PPE is a serious threat, it’s far from unstoppable. With the right strategy, you can significantly reduce the risk. Here’s how to think about building a safer CI/CD pipeline:


Not all code deserves full access to your build environment - especially code coming from forks or pull requests submitted by external contributors. Treat these with caution. Set up isolated build environments where unreviewed code can run safely, and ensure that any IAM roles tied to these builds are stripped down to the bare minimum. Above all, never expose secrets or sensitive credentials to jobs triggered by external PRs.


Your pipeline configuration files are just as sensitive as application code (maybe more so). Store them in protected branches, enforce peer reviews for any changes, and consider keeping your build logic (like scripts or Makefiles) in a separate, locked-down repository. A poisoned pipeline often starts with a poisoned config file. Don’t let that door swing open.


If users don’t absolutely need write access, don’t give it to them. Protect your branches, especially the ones that trigger CI workflows. Keep an eye on changes to build-related files, and make it someone’s job to monitor for anything suspicious. This is basic hygiene.


Credentials should never be treated as default baggage in your builds. Inject them only when absolutely necessary, and scope them as tightly as possible. Even better: rotate your secrets regularly and audit their usage. That way, even if something does leak, the blast radius is small.

Finally, think twice about what triggers your pipeline.


Do all pull requests really need to kick off a full build and deployment? Probably not. Instead of letting every PR fire off a pipeline, add a manual approval step, or use automated policies to screen them first. This gives you a chance to spot anything fishy before it gets too far downstream.

PPE in CI/CD Pipelines is Real. And It’s Here.

PPE isn’t some theoretical risk - it’s a very real, rapidly evolving threat. As breaches at organizations like AWS and Teleport have shown, even experienced engineering teams can be blindsided when trust assumptions in CI/CD systems are exploited.

Open-source projects are especially vulnerable. By design, public repositories invite contributions from anyone, anywhere - making them prime targets for Public PPE (or 3PE) attacks. When these public pipelines run unreviewed code on shared CI infrastructure, they can inadvertently expose internal secrets and compromise sensitive assets from private projects.

But this isn’t a hopeless situation. By enforcing clear trust boundaries, hardening build environments, and embracing Zero rust tooling like Cloudsmith, teams can make PPE-style attacks significantly harder to pull off. As your software delivery grows more complex, securing your CI/CD pipeline requires far more considerations than just the potential pipeline poisoning. That’s why the OWASP Top 10 for CI/CD systems was published.

If you found this content helpful and want to dive deeper into securing your CI/CD pipelines, be sure to check out our free Cloudsmith eBook on the OWASP Top 10 for CI/CD systems - 

OWASP CI/CD Part 4: Poisoned Pipeline Execution (PPE)

As more teams rely on public repositories in their software supply chain, the dependency chain has become both a critical foundation and a potential blind spot. Dependency chain abuse is not new, but a growing list of attack vectors - like typosquatting, dependency confusion, and now slopsquatting - means security leaders need to respond quickly as attackers adopt new techniques.

Let’s take a look at how dependency chain abuse works, why it’s growing more dangerous in the age of GenAI, and what you can do to protect your supply chain.

Dependency chain abuse refers to a broad set of attacks that exploit how software dependencies are sourced and managed - whether accessed during development, within CI/CD pipelines, or across runtime environments. Attackers can manipulate the package retrieval process, tricking systems into installing malicious software that poses as a legitimate dependency.

Most development teams rely on a mix of internal registries (like Cloudsmith) and public ecosystems like 

, etc. But this open and distributed model creates a porous perimeter. A single unverified or malicious package could potentially lead to:

Compromising the entire software supply chain

Classic Dependency Chain Abuse in the Wild

 documentation cites some of the better-known ways attackers exploit dependencies:

 Dependency Confusion Uploading malicious packages to public repositories with names matching private ones. Dependency Hijacking Gaining control of a maintainer’s account to inject malware into popular packages. Typosquatting Using misspelled or lookalike package names to trick developers. Brandjacking Imitating trusted organizational naming conventions to gain developer trust.

These methods rely on lapses in developer vigilance or CI/CD misconfigurations - but now there’s a new adversary for compliance teams: GenAI.

 is a novel attack vector that exploits a well-known weakness of generative AI systems: their tendency to "

" - that is, to produce plausible but incorrect or fabricated information - especially when generating code..

A Comprehensive Analysis of Package Hallucinations by Code-Generating LLMs

, examined 16 popular large language models using two distinct prompt datasets. The researchers generated 576,000 code samples across two programming languages and analyzed them for hallucinated packages. Their findings revealed that, on average, commercial models hallucinated packages in at least 5.2% of cases, while open-source models did so at a much higher rate of 21.7%. Alarmingly, they identified 205,474 unique hallucinated package names, highlighting just how widespread and serious this vulnerability has become

Why Dependency Chain Attacks Are So Damaging

Once a malicious dependency is in play, it’s often too late. Even if the payload is dormant or the package "works as advertised," it could potentially:

Harvest environment variables and secrets

Pivot across systems and escalate privileges

Remain unnoticed across builds and deployments

These attacks go well beyond the developer’s workstation. These are full-on supply chain threats with long-lasting consequences.

Mitigating the Risk of Dependency Chain Abuse

Securing the software supply chain requires a multi-layered approach, particularly when managing dependencies across various language-specific package managers and build environments. While configurations may differ, the core principle remains the same:

 clients should never fetch packages directly from untrusted or public source

s. Instead, all third-party packages should be routed through 

, enabling organizations to enforce security controls, log activity, and respond quickly in the event of an incident.

Wherever possible, direct access to external repositories should be disabled, and clients should be configured to pull only from internal, pre-vetted repositories.

To further reduce risk, organizations should implement 

. This includes enforcing checksum and signature verification for all packages, avoiding use of "

" tags in favor of fixed, vetted versions, and using lockfiles or version pinning mechanisms provided by each language ecosystem. All internal packages should be properly namespaced to the organization, with clients configured to only retrieve scoped packages from internal sources. Configuration files (e.g. 

) must reside within project repositories to override any insecure global settings on developer machines.

By enforcing trust boundaries, verifying package integrity, and adopting zero-trust tooling like Cloudsmith, organisations can significantly reduce their exposure to dependency chain abuse. As software supply chains grow more complex and AI-generated code becomes more common, securing how and where your dependencies are sourced has never been more critical. If you found this content helpful and want to dive deeper into securing your CI/CD pipelines, be sure to check out our free Cloudsmith eBook on the OWASP Top 10 for CI/CD systems – 

OWASP CI/CD Part 3: Dependency Chain Abuse

Cloudsmith built Enterprise Policy Management (EPM) on Open Policy Agent (OPA) and uses Rego to define policies as code. These policies control how packages move through your systems. They're versioned, reviewable, and enforceable.

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

Enterprise Policy Management with Cloudsmith

This article follows the example provided by Ciara Carey, a Solutions Engineer at Cloudsmith, shown in the video below.

EPM edited

From the Cloudsmith interface, navigate to the 

 policy to view the Rego-based rules 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 Rego script with the necessary dependencies:

 variable to store whether the vulnerability matches our criteria:

Cloudsmith blog

Securing Containers at Scale: Docker Hardened Images + Cloudsmith

OWASP CI/CD Top 10: Inadequate IAM

OWASP CI/CD Top 10: Insufficient Flow Control in CI/CD Pipelines

OWASP CI/CD Part 4: Poisoned Pipeline Execution (PPE)

OWASP CI/CD Part 3: Dependency Chain Abuse

Enterprise Policy Management Example: Quarantine Packages Using Policy as Code

KubeCon London 2025 Recap: Cloud-Native Insights on Security, Wasm, and More

Fortify Dependency Management With Cloudsmith + Dependabot

Implementing Zero Trust Security With Cloudsmith in 5 Steps

How to Audit Your Software Supply Chain Security

The EU Efforts To Secure Open Source Software [On-demand Session]

SBOMs: The New Standard in Supply Chain Security [On-demand Session]