By submitting this form, you agree to our 

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

Artifact Security Maturity Assessment

Kubernetes has become the de facto platform for orchestrating containers. Open standards complement Kubernetes by defining best practices for its implementation. These standards are developed by the open-source Kubernetes community (not a single vendor), ensuring vendor neutrality, easier integration with other tools, and overall system efficiency.

, a Linux Foundation project, was created to establish open, industry-wide standards for container formats and runtimes. It focuses on two core specifications:

: A reference container runtime engine used by most container platforms, including Docker. It serves as the foundation for many modern runtime environments.

: Defines how containers are built, distributed, and executed. While Docker remains widely used, OCI represents the community's commitment to standardized, open container technologies.

, it became possible to use OCI-compliant container registries for storing and distributing chart packages. With the release of 

, OCI support moved from experimental to stable and is now enabled by default.

This shift has driven demand for registries that support Helm chart storage in OCI format. 

Cloudsmith is proud to be one such registry

, fully supporting Helm charts with OCI compliance.

Cloudsmith support moves from EA to GA for OCI

 released today (5th June 2025), we’re announcing full support for Helm OCI. Previously, Cloudsmith offered a Docker registry (

) that was fully compliant with the OCI v1.1 standard. While users could push any OCI artifact to this registry, non-Docker artifacts were still displayed as Docker packages.

This functionality had been marked as Early Access (EA) in our documentation, as the user experience was fully optimized only for Docker. Although users could technically push and pull any OCI artifact, display limitations persisted for non-Docker types.

With today’s update, we’ve significantly improved our support by fully enabling Helm OCI. We've reworked the implementation and introduced a dedicated endpoint (

) which allows users to push and pull Helm charts as OCI artifacts, now correctly identified and displayed as Helm packages.

In addition, we're introducing a compatibility bridge that enables legacy Helm charts and OCI-based Helm charts to coexist. We are now in a unique position to support legacy Helm chart repositories and OCI, allowing our users to push via legacy means and pull via OCI - offering greater flexibility and smoother transitions.

 is a tool that enables pushing, pulling, and managing 

 in OCI-compliant registries. It extends the OCI specification beyond container images, turning registries into general-purpose artifact stores.

 formalizes this approach, allowing for a broader range of artifacts, like SBOMs, Helm charts, and signatures, to be stored and retrieved without being disguised as container images. ORAS has become the 

 highlighted how ORAS is transforming registries into multi-purpose artifact platforms. They demonstrated pushing multi-architecture images along with their security metadata - all as native OCI artifacts.

As the ecosystem matures, there’s a clear trend: 

treating everything (from Helm charts to SBOMs) as first-class OCI artifacts

. At Cloudsmith, we're seeing growing demand for comprehensive support of these use cases, including secure metadata attachments and provenance tracking.

, which allows artifacts to reference related files such as SBOMs, signatures, or provenance records.

Nigel Douglas

Head of Developer Relations

Open Container Initiative (OCI) Support in Cloudsmith

In a recent PlatformEngineering.org virtual webinar, Nigel Douglas, Head of Developer Relations at Cloudsmith, led a deep dive into an increasingly critical topic: 

Identifying vulnerabilities in public Kubernetes Helm charts

With the growing popularity of tools like 

, many teams consume Helm charts without fully understanding the potential security risks they introduce. Over the course 

, Nigel explored practical techniques for analysing, scanning, and securing Helm charts - especially those sourced from public repositories. From using tools like 

 to implementing proper upgrade strategies and understanding runtime behaviour, the webinar provided a wealth of actionable insights for platform engineers, DevOps teams, and security-minded developers.

Although the live session covered a broad range of security concerns, several thoughtful questions from the audience remained. We've gathered them here (along with Nigel’s direct responses) to ensure you don’t miss any of the knowledge shared during this engaging and educational event.


What’s your take on maintaining and upgrading helm charts after we've installed them? How important it is, how often it should be done, how it should be done, etc.

Maintaining and upgrading Helm charts after installation is essential for keeping your Kubernetes workloads secure, stable, and compatible with the evolving ecosystem. Over time, charts can reference outdated container images or 

, which may expose your apps to vulnerabilities or operational issues. Saying that, regularly upgrading your charts can ensure that your apps benefit from upstream improvements such as bug fixes, performance enhancements, or improved and updated best practices as the projects evolve in maturity.

In general, upgrades should be considered every few weeks for critical applications, or at least quarterly for lower-risk workloads. Security patches, however, should be applied immediately when relevant. The upgrade process should involve reviewing chart release notes, performing a 

, as discussed in the webinar, and ideally using tools like the 

 plugin to understand exactly what will change. Automation can also help, using tools like Renovate or GitOps pipelines to track and apply updates. Ultimately, treating Helm charts as living infrastructure (not one-time installations) is the real key to ensuring long-term reliability and security.


Isn't the common factor of all these vulnerabilities a careless/knowledge of the result of a deployment?

We could say the same about quite a few security-related configurations. Many Helm-related vulnerabilities stem from a lack of awareness about the full implications of what a chart deploys - whether that’s in overly-permissive RBAC rules, exposed secrets, or insecure defaults. Helm makes deployment easy, but that convenience can lead to oversight if users don’t audit the rendered manifests or understand what the chart is configuring in the cluster. It’s why tools like helm template, helm diff, and scanners like Trivy are so valuable: they help surface risky configurations before they’re applied. Ultimately, secure Helm usage depends as much on the operator’s vigilance as it does on the chart’s design. As seen with the Microsoft research last month, this type of insecure configuration is rampant in the software supply chain since we consume charts that often don’t enforce these controls by default.


Could you please share recent Kubernetes vulnerabilities and top mitigation techniques?

To find recent Kubernetes-specific vulnerabilities, the best sources are the 

, and tools like Trivy or kubescape that maintain up-to-date vulnerability databases. Top mitigation techniques include enforcing least privilege access (via 

), enabling audit logging, restricting container capabilities, setting 

, and scanning workloads and Helm charts regularly. Incorporating security checks early in the CI/CD pipeline is also key to reducing risk before deployment.


Is there any website or page where we can find Kubernetes vulnerabilities?

Yes, the Kubernetes project provides an official, auto-refreshing CVE feed that publicly lists known Kubernetes vulnerabilities. Since 2022, this feed has been maintained to help users stay informed about security issues as they arise. You can access it here: 

https://kubernetes.io/blog/2022/09/12/k8s-cve-feed-alpha

. It's a valuable resource for tracking vulnerabilities in the Kubernetes ecosystem and planning timely mitigations.


How can we verify that this Helm chart is not vulnerable to attacks? What steps should we follow to perform this assessment?

After scanning your Helm chart with a trusted security tool like Trivy, it's important to address all vulnerabilities marked as 

. Once remediated, scan the chart again to confirm that those issues have been resolved. Rather than repeating this process manually each time, we recommend uploading your updated chart to a secure, centralized artifact management platform like 

. This enables you to maintain control over your chart’s integrity and trustworthiness by signing the chart and verifying its provenance. Relying on a centralized solution (rather than public repositories like 

) also gives you clear insight into the chart’s 

: a detailed record of its origin, changes, and associated contributors. This approach helps ensure that the charts you distribute and deploy are secure and free from known vulnerabilities.


How can you verify that the helm chart does not perform egress calls to sources that you don't want as an organisation? Is that through scanning or network policies on egress traffic?

To verify that a Helm chart doesn't allow or initiate egress calls to unwanted external sources, you should use a combination of static analysis and runtime controls. First, during pre-deployment, tools like Trivy can statically scan rendered Kubernetes manifests (

helm template ./mychart | trivy k8s --security-checks config -

) to detect misconfigurations - like containers without egress restrictions or unrestricted network policies. However, static scanning alone won't always catch dynamic behaviours (like runtime DNS lookups or hardcoded IPs).


Do you need to install Trivy on a cluster?

In our webinar, we used Trivy as a standalone scanner installed on an Ubuntu machine using snap install Trivy. While Trivy does offer a Kubernetes Operator for in-cluster scanning, you don't need to install it on a cluster to analyze Helm charts. For example, we scanned Kubernetes-specific misconfigurations (like Secrets exposed in plain text) by running 

, which renders the chart and scans the output. Alternatively, if you’ve already used helm template to export the chart into a single YAML file, you can scan it directly with 

trivy config --severity HIGH,CRITICAL my-sample-chart.yaml

 to focus on high and critical severity issues. This approach makes it easy to evaluate chart configurations without needing to deploy them.

To enforce egress control at runtime, it's best to implement Kubernetes Network Policies, ideally with a 

. These policies can restrict which destinations pods are allowed to contact, based on CIDRs, namespaces, or label selectors. Defining strict egress policies ensures that, even if a chart includes or results in outbound traffic, that traffic is only permitted to destinations your organisation allows. This dual-layered approach (scanning and runtime restriction) is the most reliable way to prevent unintended or insecure egress behaviour.


 to scan Helm charts for known vulnerabilities and insecure configurations, but there are several other tools that complement this process. 

 analyses Kubernetes YAML (including rendered Helm templates) for security risks. 

 focuses on validating Helm charts against Kubernetes best practices - checking for things like missing resource limits, privileged containers, HostPath usage, and other misconfigurations. For future-proofing, 

 identifies deprecated or removed Kubernetes APIs within your charts, which helps avoid issues during cluster upgrades. Finally, while not a security tool, 

 ensures your chart is syntactically valid - important for catching simple issues before they affect your deployments. Together, these tools offer a comprehensive approach to Helm chart assessment.


Are there any auditing tools yet that run a helm chart and show all of the open ports on the container vs. just what is mapped in the helm chart? Or is that pretty exclusive to Kubernetes network security programs?

This is a great question! Currently, auditing open ports at runtime (beyond what's declared in the Helm chart) is generally outside the scope of Helm-specific tools. Helm templates only define what's supposed to be exposed (e.g. via containerPort, hostPort, or Service definitions), but they can't catch what a container actually opens internally at runtime.

To identify all open ports inside a container, including those not exposed via Kubernetes objects, you’d typically use Kubernetes runtime security tools or network observability solutions, such as:

: Provides deep network visibility and can monitor actual traffic flow, including unexpected egress/ingress.

: Can also audit real network traffic at the pod level.

): Can detect unexpected network behaviour like a container listening on unusual ports.

: While more focused on security posture and cluster vulnerabilities, these tools from the team at Aqua Security can help detect misconfigurations that lead to unintended exposure.

, a combined approach works best. You can use helm template or helm show values to audit the declared ports before deploying the chart in a sandbox cluster. Running tools like 

 inside the container (or from another pod) to observe real ports in use. It's your responsibility then to monitor the traffic using a CNI-based tool like Cilium or Calico for the real-time egress/ingress behaviour. In short: yes, it’s more in the domain of Kubernetes network security tools than Helm itself, but combining both layers provides the most insight.


Is it good practice to deploy the API management server to safeguard the Kubernetes pods?

Yes! Deploying an API management server can be a strong security and governance practice in Kubernetes, especially when your workloads expose APIs. Tools like 

 add layers of protection by enforcing authentication, rate limiting, and monitoring before traffic reaches your pods. They’re particularly valuable for public or partner-facing services where access control and visibility are critical. However, API gateways should complement (and not replace) the core Kubernetes security controls like network policies, pod security settings, and runtime protection. Used together, they form a more comprehensive and effective security strategy.



The event was a great learning experience. What is the 'End Goal' of this event? How long would you continue to have such informative sessions?

At Cloudsmith, we regularly host webinars focused on securing the software supply chain, which you can explore at 

 for upcoming community-driven events - both virtual and in-person.

The end goal of these sessions is to raise awareness around the importance of securing software packages throughout their lifecycle. That means not just scanning once, but maintaining ongoing vigilance through regular scanning, updates, and visibility into provenance. We know this can feel overwhelming, so our aim is to provide practical education, actionable best practices, and tooling insights to help you build safer pipelines with confidence. As long as security remains a moving target (and it always will), we’ll continue running these sessions to support the community.


Nearly everything deployed today in Kubernetes is through Helm Chart templates. If you need to deploy a security program into your cluster, most likely the security vendor you’re working with has a Helm Chart for that. So there’s an especially critical need to monitor and secure those third-party Helm charts that we consume as well. The questions raised during this session bring to light a common theme: many vulnerabilities don’t originate in Kubernetes itself, but in the way it's configured and operated. By applying security best practices, leveraging scanning and enforcement tools like Trivy and OPA, and maintaining a strong awareness of chart provenance and runtime behaviour, platform teams can seriously reduce risk.

Cloudsmith and PlatformEngineering.org remain committed to supporting the community with ongoing sessions like this, and by bringing clarity to the challenges of modern software supply chain security. Sign up today for our upcoming 

, stay tuned for future events, and feel free to contact us anytime with questions about keeping your software artifacts secure.

Responding to questions from our recent Helm security webinar

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

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

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

 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:

 information on setting up and configuring policy code, see 

Enterprise Policy Management Example: Quarantine Packages Using Policy as Code

smith 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

Cloudsmith Blog

Open Container Initiative (OCI) Support in Cloudsmith

Responding to questions from our recent Helm security webinar

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

Policy Management Example: Quarantine Packages Using Policy as Code

Policy Management with Cloudsmith

OWASP CI/CD Part 2: Inadequate IAM

OWASP CI/CD Part 1: Insufficient Flow Control

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

Full Support for Arbitrary Files in Maven Repositories with Cloudsmith