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 - 

Nigel Douglas

Head of Developer Relations

OWASP CI/CD

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

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

Software Engineer

Securing Containers at Scale: Docker Hardened Images + Cloudsmith

Yet another supply chain attack has surfaced, this time using the xrpl library to sneak through malicious packages. 

 is recognised as the recommended npm library for integrating the 

 with JavaScript/TypeScript applications, and has over 140k downloads a week.

Our security team quickly responded to this threat and found that no Cloudsmith customers are currently using any of the affected versions.

The attack strategy was to introduce five suspect versions of the library, masquerading as genuine releases. They inserted a crypto-stealing backdoor by adding malicious code that could leak private keys and silently sign fraudulent transactions.

npmjs have recently released version 4.2.5, which overrides the compromised versions.

You can get a full and detailed description of the attack from Charlie Eriksen at 

XRP supply chain attack: Official NPM package infected with crypto stealing backdoor.

The vulnerability is logged with the CVE Dictionary Entry of 

XRPL Dependencies - A Critical Security Risk

The XRPL is a Layer 1 blockchain built for payments and asset transfers. Layer 1 blockchain is the foundational infrastructure of a blockchain. This is where core functions are handled, such as validating transactions, securing the network, and ensuring consensus around transactions and ownership.

The XRPL is used by financial institutions, fintech companies, developers, and startups, mostly for payments, asset tokenization, and building lightweight financial applications.

A supply chain attack on a package integrating with the XRPL can have serious implications. It could expose private keys, hijack transactions, or leak sensitive data, without compromising the ledger itself. If xrpl.js is compromised, any apps using it could unknowingly sign malicious transactions or leak user information, which could result in stolen funds. XRPL dependencies are critical to security.

Any security features can and should be tested against real-world threats. Cloudsmith’s Enterprise Policy Management (EPM) includes policy-as-code, meaning custom policies can be written against precise requirements to block known exploits.

For the xrpl.js attack, we know the bogus versions, so it’s easy to write Rego code that checks your repository against the known versions. Cloudsmith can then quarantine the packages if there’s a match against npm packages named xrpl:

For more information on setting up and configuring policy code, see 

Enterprise Policy Management Example: Quarantine Packages Using Policy as Code

 of Cloudsmith and see how it can stop supply chain attacks.

Ian Taylor

Tech Content Director

XRPL Supply Chain Attack and How to Block it Using Cloudsmith’s Enterprise Policy Management

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:

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

Enterprise Policy Management (EPM) is a programmable policy-as-code layer that controls the security, compliance, and flow of artifacts across the software supply chain. Teams can codify rules once and apply them continuously across repositories. With Cloudsmith’s platform, organizations extend policy enforcement across teams, environments, and geographies without introducing friction, including the open source packages that the chain depends on.

Our EPM solution is powered by data at every stage. The policy engine has access to all available package metadata to inform decisions. Every policy action is recorded with full context, providing detailed logs for customers to support audits and investigations. EPM includes compliance dashboards, that surface insights in security, compliance, and policy activity. This gives you continuous oversight and helps you refine your approach.

This article provides an overview of EPM and how it strengthens the software supply chain. For a worked example using policy as code, see 

We built EPM because governance should not slow you down; it should accelerate trust. Threats to your software supply chain are evolving faster than human oversight can track, and automation is the only viable path to resilience. EPM puts policy enforcement early in the development process. It makes decisions transparent and implements your security and compliance posture into something repeatable, testable, and version-controlled, like the rest of your codebase. Developers get immediate insight to help select packages. They know which meet policy standards for security, licensing, and quality.

Policies are codified rules that automate decisions and enforce rules on which packages are allowed in your software supply chain. They provide guardrails that ensure security, compliance, and operational consistency. Policies can block vulnerable packages, restrict problematic licenses, and control access.

For example, an enterprise may add a policy that stops packages with high-risk vulnerabilities from reaching production environments. The policy would be prescribed by logic as follows:

Define logic that evaluates vulnerability criteria and applies a quarantine action to affected packages.

The criteria specifies that the vulnerability must be listed in the Common Vulnerabilities and Exposures (CVE) database.

The policy then checks if the vulnerability exceeds a defined 

If conditions are met, the package can either be quarantined and blocked from promotion to production or tagged with additional context for further forensics.

This previous example is a vulnerability policy and is one of the types Cloudsmith EPM supports:

 prevent non-compliant code from being used.

 automate tagging, quarantining, or deleting based on metadata.

Without strong policy management, teams face increased risk and unnecessary effort:

- Missing automation allows known CVEs or malicious packages to reach production.

 - Teams must scramble for audits instead of demonstrating continuous compliance.

- Engineers spend hours reviewing dependencies or waiting for late-stage approvals.

Without shared policies, standards vary across teams and environments.

Without codified policies, organizations cannot fully benefit from the scale and speed of the cloud.

Catching vulnerabilities early in the software delivery lifecycle reduces both the financial cost of remediation and the risk of reputational damage.

EPM was built to avoid these issues in response to real-world supply chain threats and close collaboration with our customers. Codification and automation provide a unified approach for teams to enforce decisions that were previously enforced manually and inconsistently, proving less robust or scalable.

In an automated delivery environment, policies are essential for reducing manual overhead, preventing costly mistakes, and proving compliance, and have particular relevance within the organization:

-For CISOs, policies are the cornerstone of a secure software supply chain. They enable proactive threat mitigation, enforce compliance with frameworks like SLSA and SC2CF, and provide the audit trails required for regulatory confidence. Cloudsmith’s EPM lets CISOs shift from just enforcing checklists to actively collaborating with engineering teams by using the same tools. Implementing automated policies makes it easier for the engineering team to build securely.

- CTOs are focused on enabling product velocity without compromising architectural integrity. Effective policy management acts as a safeguard for CTOs, giving them confidence to move fast with greater safety, supporting both innovation and security goals. With EPM, they can align engineering output with business goals, ensure consistent implementation of best practices, and reduce the operational burden of manual reviews.

Teams immediately benefit by switching from public repositories to Cloudsmith as a curated repository for their developers. Policies then provide clarity, speed, and safety for engineering teams. Instead of guessing what is allowed, developers get immediate feedback when a package or dependency violates a rule. Our EPM integrates policy checks directly into the artifact pipeline, shifting decision-making left and reducing the noise and frustration caused by late-stage security reviews. 

EPM: Cloudsmith’s Approach to Policy Management

Maximum Flexibility: Policy-As-Code, Open Policy Agent, and Rego

Cloudsmith builds for developers, and EPM continues that focus by applying code's flexibility and automation to policy management. EPM takes a policy-as-code approach using an engine built on codification to make policies flexible, versioned, testable, and part of the everyday development workflow. It uses repeatable logic and brings security and compliance into the same toolchain engineers already use.

 - Teams write policies in Rego to define clear, actionable rules that operate on artifact metadata, repository structure, and scan data. We chose 

 because it is an established, open-source policy language widely used in infrastructure and platform security. Rego allows teams to write expressive, testable rules and reason over structured data, which aligns with how Cloudsmith models package metadata and security inputs.

 OPA is a general-purpose policy engine that evaluates rules written in Rego. Cloudsmith integrates OPA into its EPM engine to provide a programmable, scalable way to enforce policy across artifacts. Because OPA is already well established in platform tooling like Kubernetes and Terraform, teams can manage policies in a format they know and trust, without switching tools or inventing new processes.

- EPM also offers key features through the Cloudsmith UI. This supports essential policy management controls, letting users operate EPM without the need to dive into policy-as-code.

You can see an example of the Rego code used to implement the policy given in 

Cloudsmith’s policy engine lets you create and automate vulnerability policies to an exact specification. Policies evaluate packages as they arrive and apply structured logic to make decisions based on severity, exploitability, and metadata. We made package data available so you have the information to tailor and align your policies to the datasets that matter most.

The following capabilities form the foundation of Cloudsmith’s approach to automated vulnerability policies:

Vulnerability Management & Dependency Awareness

 - EPM scans artifacts continuously and examines both the dependencies developers choose directly and the ones that come bundled with them. This helps teams understand the full scope of their exposure, especially when vulnerabilities are introduced through nested packages or upstream registries.

Cloudsmith blog

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

Securing Containers at Scale: Docker Hardened Images + Cloudsmith

XRPL Supply Chain Attack and How to Block it Using Cloudsmith’s Enterprise Policy Management

OWASP CI/CD Part 3: Dependency Chain Abuse

Enterprise Policy Management Example: Quarantine Packages Using Policy as Code

Enterprise Policy Management with Cloudsmith

OWASP CI/CD Top 10: Inadequate IAM

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

Scaling up to 1 Million Requests per Minute: How Cloudsmith Delivers Extreme Performance

Full Support for Arbitrary Files in Maven Repositories with Cloudsmith

Reproducible Builds, Fedora 43, and What It Means for the Software Supply Chain

Kubernetes 1.33 – What you need to know