Researchers at Trend Micro have uncovered a critical unauthenticated remote code execution (RCE) vulnerability [

. Langflow is a Python-based visual framework for building AI applications and boasts over 70,000 stars on GitHub and over 21,000 global weekly downloads from the public PyPI upstream.

Versions released before 1.3.0 contain a serious flaw in the code validation logic, which allows arbitrary code execution. Unauthenticated attackers can exploit this vulnerability by sending specially crafted POST requests to the 

Malicious payloads were found embedded within argument defaults and decorators of Python function definitions. Because Langflow lacks proper input validation and sandboxing in its code evaluation process, these payloads are compiled and executed directly within the server’s context, which results in full remote code execution.

On May 5, 2025, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2025-3248 to its 

 (KEV) catalog, indicating confirmed exploitation in the wild.

How to Quarantine Affected Langflow Packages using Cloudsmith EPM

 (EPM) is an OPA-based engine which enables quarantining of high-risk packages before developers create a dependency on them, and before they reach production environments. The Gist below includes a generic 

. This policy will detect vulnerable versions of Langflow, which have a 

Langflow includes numerous dependencies (such as 

) which can significantly increase download times due to dependency resolution. For the purpose of this demo, we only need the raw package for scanning, so I used the -

 flag to avoid downloading unnecessary dependencies.

The package was pushed to Cloudsmith with a custom tag referencing 

. Note that it was synchronized and automatically quarantined based on the EPM policy we put in place.

In the Cloudsmith UI, you can see that the 

 (containing the known vulnerability) was successfully quarantined right after it synced. Alongside the automatically generated SBOM, the package also has an additional 

 tag applied by the EPM policy, indicating that it was quarantined due to a security policy violation.

By clicking into the identified vulnerability in the Cloudsmith UI, we can confirm that it correctly maps to CVE-2025-3248: a code injection flaw exploitable via the 

If you’re already using centralized artifact management, then you’ll already know that versions of Langchain prior to 1.3.0 are vulnerable and therefore should not be used. According to Trend Micro, the attackers in this scenario likely initiated the attack by first gathering a list of IP

 addresses and ports of publicly exposed Langflow servers, potentially using tools like 

 to detect publicly exposed Langflow servers by targeting typical indicators in configuration files, environment files, and code snippets. Langflow is typically launch

ed via FastAPI and Gradio, often bound to a public IP like 0.0.0.0 with a known port like 7860 or 8501.

This should return public Github configurations for Langflow or related servers listening on public interfaces and also Gradio apps being served publicly (which is fairly common in Langflow setups).

 to gain remote shell access to vulnerable systems. Once inside, they run various bash commands to gather system information and send the results to a command-and-control (C2) server.

Next, the attacker installs and runs the Flodrix Botnet on the compromised system. After connecting to the C2 server, the botnet can receive commands over TCP to launch distributed denial-of-service (DDoS) attacks. If the malware doesn’t receive the correct input, it deletes itself.

 endpoint, which is meant to validate Python code. This endpoint lacks proper authentication and executes user-submitted code using Python's 

, compile(), and exec() functions. Attackers can craft malicious code that gets executed on the server when submitted, allowing them to remotely execute code without needing to log in.

CVE-2025-3248 highlights the power of auditing and securing everything that comes from public upstreams. When you use 

, Cloudsmith fetches and caches open source packages (e.g. most dependencies), while you can also upload and use the packages you own to your artifact management repository. This is how customers use Cloudsmith as a first-class cache and a central source of truth for packages, to insulate their development teams from issues that would arise by downloading directly from public indexes like PyPI.

CVE-2025-3248: Serious vulnerability found in popular Python AI package

 series, looks at some of the common risks associated with Insufficient Credential Hygiene. By better understanding the flaws that affect credential hygiene, we can better understand how even the most sophisticated pipelines were compromised.

CI/CD systems rely heavily on credentials (application secrets, tokens, deploy keys, and more) to operate. These 

 move between services, repositories, environments, and human actors, creating a complex web of access points.

they become prime targets for attackers. Once compromised, these secrets offer 

nities to adversaries with the intention of directly accessing your code, infrastructure, and data.

Secrets live in many places: code repositories, CI/CD configuration files, container images, build logs, and even in the runtime environment. They're used by humans, machines, and processes across different trust boundaries - each with their own associated requirements and risks.

Unlike a centralized authentication system, secrets management is often distributed, ad hoc, and invisible until breached.

Here are some of the most pervasive and dangerous practices seen in real-world CI/CD environments.:

 are a time bomb. Even if deleted from the latest branch, they remain visible in the commit history to anyone with access.


Overly-permissive credentials in pipelines


CI/CD pipelines often use credentials to access source code, artifact repositories, cloud resources, and production systems. Without 

 (which limits what actions credentials can perform and what resources they can access) and 

 (which grant access only under specific conditions like IP Address, time of day, or workload identity) these credentials can become open doors for unauthorized access.

Ask yourself:
- Does each pipeline only access the secrets it needs?
- Are secrets scoped to specific environments or job steps?
- Can unreviewed code access production secrets?

Where possible, organizations should enforce the 

Secrets embedded in container image layers

 (such as API tokens or SSH keys) can inadvertently remain in 

. Anyone with access to the image can retrieve them, even if they’re not meant to persist beyond the build.


 during a build, becomes a liability. Logs may be stored indefinitely, aggregated into third-party observability platforms, or exposed through dashboards.



Static credentials that never expire are dangerous - especially in environments with high personnel turnover or external contractors. Without regular rotation, credentials accumulate risk with every day they remain active. 

 is a production best-practice that ensures credentials are short-lived.

Real-world breaches caused by poor credential hygiene

 where secure environment variables (type of secrets) were exposed during builds triggered by pull requests to public repositories. Even though secrets were encrypted in storage, they were made accessible during build execution, potentially leaving them susceptible to compromise by anonymous users issuing pull requests against public repositories.

While the Travis CI team quickly patched the issue, it highlighted how even secure systems can leak secrets when trust boundaries are not well-defined. In this scenario, Travis CI has strongly recommended that both Public and Private Repository customers rotate their secrets on a regular basis

If possible, users affected in these scenarios should set expiration dates on those tokens or rotate their secrets regularly; this reduces the risk of old secrets being exploited.

Uber wasn't so fortunate. They experienced two major breaches tied to credential mismanagement. These breaches, detailed in the 

When credentials leak, attackers don’t break in - they log in.

In both breaches, no sophisticated exploitation was needed, just access to secrets that had been mishandled and left vulnerable.


In May 2014, attackers discovered an AWS access key that was accidentally committed to a public GitHub repository. The key granted full administrative access to Uber’s Amazon S3 datastore. As a result, the intruder accessed sensitive personal data of over 100,000 drivers, including:

Unencrypted names and driver’s license numbers

Uber didn’t detect the breach until September 2014 (four months later) and continued uncovering additional impacted users well into 2016.

The 2016 Breach: A private repo with public impact


In a second incident between October and November 2016, attackers gained access to Uber’s private GitHub repositories. This time, the intrusion was facilitated by a combination of weak security controls:

Credential reuse by engineers across personal and professional accounts

Lack of multi-factor authentication (MFA)

No policies to prevent leaked or reused passwords

Attackers used compromised credentials (previously exposed in unrelated breaches) to access Uber’s GitHub repositories, where they found yet another AWS access key. This key unlocked Uber’s S3 storage once again - leading to the theft of:

Most of this data was stored in unencrypted backup files collected prior to 2015.

Recommendations for sufficient credential hygiene in CI/CD

To mitigate these risks, organizations must adopt a proactive and layered approach to secrets management:

Continuous inventory where credentials are stored and used (across code, pipelines, and infrastructure).

Classify & Tag secrets by sensitivity and exposure risk.

2) Classify secrets by sensitivity and exposure risk

Scope each secret to the narrowest possible use case (per pipeline, environment, or job).

Avoid shared credentials across teams or systems.

Use short-lived, automatically rotated credentials (such as IAM roles, OIDC tokens, Kubernetes Secrets).

For static secrets, enforce periodic rotation and audit stale secrets.

Bind secret usage to specific IPs, services, or identities.

Block secrets from being used outside of intended pipelines or systems.

Use tools like Git hooks, IDE plugins, and secret scanners to catch leaks before they hit the repository.

Periodically scan historical commits for exposed secrets.

Configure pipeline tools to redact or prevent printing sensitive data.

Inspect container images, binaries, and Helm charts for embedded secrets before deployment.

Use dependency mapping to identify and visualize all software dependencies within your applications, such as a Docker image within a Helm chart that may contain sensitive credentials.

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

OWASP CI/CD Part 6: Insufficient Credential Hygiene

This blog contains the takeaways from our webinar "State of the Union: Modern security approaches for the Software Supply Chain." Watch the full discussion 

. Key topics include how to secure your CI/CD pipeline and software artifacts using SBOMs, Docker Hardened Images, and artifact lifecycle best practices.

Software supply chain attacks are on the rise, prompting a critical shift in how we secure modern software. Recent incidents like SolarWinds, XZ Utils, and Log4Shell underscore the urgent need for stronger security measures beyond just protecting production systems. Attackers are now targeting earlier stages of the supply chain, particularly build pipelines, impacting software integrity before it even reaches deployment.

State of the Union: Modern security approaches for the Software Supply Chain

 we brought together industry experts to tackle these challenges head-on. Michael Donovan, VP of Product at Docker, Ralph McTeggart, Principal Engineer at Cloudsmith, and Jack Gibson, Senior Software Engineer at Cloudsmith, shared their insights on how leading teams can defend themselves. During the session, they explored the evolving threat landscape, outlined a secure artifact lifecycle, and discussed strategies such as SBOMs to inject visibility, provenance, and trust into workflows without creating developer friction. While the focus was on container images, the principles discussed were equally applicable to other formats.

Rethinking Software Supply Chain Security

Software supply chain attacks have grown dramatically in both frequency and impact, prompting a fundamental shift in how software is secured. Incidents like SolarWinds, the XZ Utils backdoor attempt, and Log4Shell illustrate a sobering truth: attackers are now aiming upstream. Rather than targeting production systems directly, modern threats exploit vulnerabilities during the software build and integration phases, where visibility and control are often weakest.

As this attack surface expands, it’s no longer enough to harden runtime environments or secure production endpoints. The entire artifact lifecycle - from development to deployment - must be secured. This shift has led organizations to reassess their tooling, processes, and practices around software composition, packaging, and distribution.

The Shift in Emphasis on Software Supply Chain Security

The strategic focus of software security has moved upstream. Major breaches have shown how attackers exploit weaknesses in CI/CD pipelines, source code repositories, and registry infrastructure, areas traditionally outside the purview of security teams.

Events like the SolarWinds compromise in 2020, which leveraged a poisoned build system, or the 2024 XZ Utils incident, where malicious code was inserted by a fake maintainer, underscore how early-stage compromises can lead to widespread downstream impacts. Similarly, Log4Shell revealed the global exposure caused by a single vulnerable dependency, forcing organizations to redirect substantial resources just to locate and patch affected systems.

In response, governments and regulatory bodies have escalated their focus on software supply chain security (SSCS). Executive directives, such as the U.S. Cybersecurity Executive Order, FedRAMP requirements, the EU’s NIS2 directive, and the forthcoming Cyber Resilience Act, demand secure development practices, transparent artifact composition, and provable software provenance.

As attacks increasingly originate at the source, securing the artifact lifecycle is now a foundational requirement - not a future goal.

Modern software development is built around composability and speed. Applications today rely heavily on third-party libraries and frameworks, with open-source components making up as much as 75% or more of a typical codebase. The prevalence of transitive dependencies - indirect libraries brought in through direct ones - adds complexity and opacity to risk assessment.

At the same time, the efficiency of CI/CD pipelines can leave little room for traditional gatekeeping. Code is integrated, tested, and deployed rapidly, often using packages pulled directly from public registries with minimal verification. Unsigned artifacts, missing provenance data, and outdated registry configurations persist across many organizations.

This environment creates ideal conditions for silent, hard-to-detect supply chain threats. In response, software teams must move toward practices that ensure transparency, verification, and control at every phase of the build and release cycle.

Using SBOMs and Establishing Provenance

A foundational step in securing the software supply chain is understanding exactly what is being built and shipped. This is where three elements play a critical role:

SBOMs (Software Bills of Materials): These list all components within a software artifact - names, versions, authors, licenses, and dependency relationships. Tools such as Syft and Trivy support SBOM generation in SPDX and CycloneDX formats. Docker supports SBOMs natively through the docker sbom command. Cloudsmith accepts external SBOM uploads or can auto-generate CycloneDX SBOMs for container images, exposing them via API for automation and policy enforcement.

Digital Signatures: A signature confirms that an artifact originated from a known and trusted source. Tools like Cosign allow developers to sign and verify containers. Signed images enable downstream consumers to confirm authenticity before deployment.

Provenance: Provenance data describes the origin of a build, including input sources, build parameters, and environments. Docker Buildx supports automated provenance generation using the --provenance flag, capturing crucial metadata such as build arguments and platforms.

Together, these elements create an auditable trail of software origin and composition. In regulatory contexts, SBOMs are now a standard requirement. But beyond compliance, they provide security teams with the ability to trace vulnerabilities to specific packages, drastically reducing remediation time and effort. Cloudsmith’s Enterprise Policy Management (EPM) leverages SBOM metadata for automated policy actions, such as quarantining risky images or enforcing license compliance based on live dependency data

Tightening Security with Docker Hardened Images

As organizations grapple with securing sprawling software pipelines, Docker Hardened Images (DHIs) offer a straightforward way to integrate trusted, verifiable container artifacts into modern workflows, without slowing down development.

Available on Docker Hub, DHIs are a curated set of container images designed to minimize vulnerabilities out of the box. They are built with a smaller attack surface, and include a full suite of embedded security metadata by default. This makes them ideal for teams looking to adopt zero-trust practices without adding complexity or friction.

VEX (Vulnerability Exploitability eXchange) metadata

These attestations provide comprehensive visibility into the contents and origin of each image. Because they are packaged directly with the artifact, they integrate seamlessly into downstream platforms like Cloudsmith or any private registry. This removes the burden of generating and attaching this metadata later in the pipeline.

The impact is significant: DHIs can reduce vulnerabilities in base images by as much as 95%, offering a hardened starting point for secure application builds. Just as importantly, they help teams meet compliance and audit requirements from day one, with verifiable transparency and traceability.

By building security directly into the image and surfacing critical metadata in machine-readable formats, Docker Hardened Images simplify the process of building secure containers—and make modern supply chain security accessible by default.

Building a Secure Artifact Lifecycle

A secure software supply chain requires continuous validation from development through delivery. This is where centralized artifact management platforms like Cloudsmith become essential.

By configuring repositories to proxy public registries (e.g., Docker Hub, NPM, PyPI), Cloudsmith performs key security checks automatically:

Artifacts are cached and versioned, offering security and development teams full visibility and control over dependencies. When an image is pulled, verification steps - including signature checks and attestation validation - ensure that only known, trusted, and reproducible software is admitted into builds or deployments.

However, the ecosystem still faces gaps. Many widely used packages, particularly in NPM and PyPI, lack signatures or attestations. As of late 2024, only 5% of the top 360 packages on PyPI had provenance data published through the trusted publisher workflow. This makes it difficult to assert origin or integrity for many upstream dependencies.

To address this, teams should introduce a secure intermediary - like Cloudsmith - between developers and public sources. This provides enforcement points for policy, visibility into dependencies, and the opportunity to filter and block unverified packages before they can compromise the build.

Once builds are finalized, signing them and recording those signatures in transparency logs (e.g., Sigstore’s Rekor) ensures traceability and trust. This final step solidifies confidence that artifacts were not tampered with before reaching production.

Security features must be accessible, automated, and non-disruptive to gain widespread adoption. Teams are more likely to maintain best practices when secure workflows mirror familiar development patterns.

 come pre-equipped with SBOMs, digital signatures, and SLSA-compliant provenance. These attributes allow teams to build secure pipelines without requiring additional tooling or custom scripting.

When paired with Cloudsmith, this enables organizations to:

Centrally manage and enforce policies on all artifacts

Control access and visibility across engineering teams

Integrate security checks without altering development velocity

The result is a zero-trust pipeline where software integrity is maintained automatically, and security is treated as a first-class concern throughout the SDLC.

The shift towards modern security approaches is undeniable. SBOMs, signatures, and attestations are becoming fundamental elements in software development. The impending legislation, particularly in the EU with the Cyber Resilience Act, will further mandate these practices.

For a deeper dive into securing your container workflows, check out our companion blog post, "

Securing Containers at Scale: Docker Hardened Images and Cloudsmith

Docker Hardened Images & Cloudsmith: Modern Security for the Software Supply Chain

Pulling Docker images from private registries for containerised applications presents a security challenge. It requires authentication management, network access, and trust across distributed systems. Credentials must be securely handled and rotated, and image pulls can break due to network restrictions or expired tokens. All of this makes deployment and security harder.

To address this, you can use OpenID Connect (OIDC) when pulling Docker images from Cloudsmith into Kubernetes. OIDC adds a layer to OAuth 2.0 that identifies who is making the request. Cloudsmith can then verify that the requests come from a trusted source and can grant short-lived access tokens. So you no longer have to rely on long-lived credentials, enhancing security and simplifying credential management.

Kubernetes clusters often need to pull Docker images from private registries like Cloudsmith. Traditionally, this meant storing long-lived credentials in the cluster, which has some security risks:

Credentials could be compromised if the cluster is breached.

Regular rotation of credentials becomes a manual, error-prone process.

It's hard to apply the principle of least privilege effectively.

Before we dive into the solution, let's review what an Image Pull Secret is in Kubernetes.

An Image Pull Secret is a way to pass credentials to the kubelet to authenticate with a private container registry. Typically, the secret contains:

While Image Pull Secrets solves the immediate authentication problem, using them with long-lived credentials still exposes us to the security risks mentioned earlier. The credentials don’t automatically expire, leaving them vulnerable to misuse if leaked or unrotated.

OpenID Connect (OIDC) allows us to use short-lived tokens instead of long-lived credentials, reducing risk exposure. Here's how it works in the context of Kubernetes and Cloudsmith:

Kubernetes has its own identity in the form of a service account. The service account has an associated JWT (JSON Web Token). During runtime, the following steps are taken:

Kubernetes issues the signed OIDC token (a JWT).

Cloudsmith receives and verifies the JWT and exchanges it for a short-lived Cloudsmith token.

Kubernetes uses the short-lived Cloudsmith token to create or update an Image Pull Secret.

At runtime, the pod requests to pull an image.

Kubernetes pulls an image from Cloudsmith using the Image Pull Secret for authentication.

To automate the process, we use a Kubernetes CronJob. This job runs at regular intervals and performs the following tasks:

Retrieves the Kubernetes service account token.

Exchange service account token for a Cloudsmith token via OIDC.

Create or update an Image Pull Secret with the new Cloudsmith token.

Here's an example of what this CronJob might look like:

2. Gets the Kubernetes service account token.

4. Creates or updates an Image Pull Secret named cloudsmith-pull-secret.

Implementing this OIDC-based solution offers significant benefits:

: The CronJob ensures the token is regularly refreshed, maintaining a good security posture without manual intervention.

: There's no need to manually update credentials, reducing operational overhead.

: The token only has the permissions it needs for a limited time, aligning with security best practices.

Once the Image Pull Secret is created or updated by the CronJob, you can use it in your pod specifications like this:

This pod will use the cloudsmith-pull-secret to authenticate with Cloudsmith and pull the specified image.

Using OIDC to pull Docker images from Cloudsmith into Kubernetes eliminates the need for long-lived credentials. It reduces the risk of leaked credentials, removes the need for manual credential rotation, and aligns with current security best practices.

Authentication in Kubernetes is evolving with significant recent enhancements. Kubernetes v1.20 saw the introduction of 

. These allow the kubelet to dynamically request credentials for a container registry instead of storing static credentials on disk. This was enhanced in v1.33 to support automatic use of the service account token for image pulls. This enables short-lived authentication without needing to manage Image Pull Secrets and reduces complexity. Cloudsmith remains vigilant, and these updates help with our goal of increasing automation in supply chain security.

Secure Docker Image Pulls from Cloudsmith to Kubernetes using OIDC

One of the more overlooked yet critical vulnerabilities highlighted in the 

 is Insufficient PBAC (Pipeline-Based Access Controls).

Let’s unpack what PBAC is, why it's essential, and how you can leverage modern access control tools like Open Policy Agent (

 refers to fine-grained permissions tied to the context in which pipelines execute. This means evaluating what each pipeline (and each step within that pipeline) is allowed to access and modify.

CI/CD pipelines typically perform highly sensitive actions:

Accessing secrets from vaults, environment variables, or identity services (like the 

Creating and deploying artifacts, sometimes directly to production.

When PBAC is insufficient or misconfigured, attackers can exploit this to move laterally, exfiltrate data, or inject malicious artifacts. A compromised pipeline execution node inherits all the permissions of the pipeline stage it runs in, which are often far more than necessary.

To understand the real-world implications of insufficient PBAC, consider a scenario where an attacker successfully injects malicious code into your CI/CD pipeline. If that pipeline has broad, unrestricted access (such as embedded secrets, open network connectivity, and permissions to deploy to production environments) the consequences can be severe.

Sensitive data like environment variables or authentication tokens may be exposed, enabling unauthorised access to internal systems or third-party services. Worse still, the attacker could tamper with the build itself, leading to the deployment of compromised software directly into production.

Beyond data leaks and malicious deployments, such an attacker might also use shared credentials or misconfigured access to pivot laterally within the CI/CD environment, compromising other pipeline nodes or even underlying infrastructure. The extent of damage in these cases is directly proportional to the level of control (and also restraint) imposed by your PBAC implementation.

When pipelines are over-permissive, it’s like leaving every door in your system unlocked while leaving your house keys with the intruder. Granular, well-scoped PBAC policies are essential to limiting the blast radius while mitigating the potential risks.

PBAC Shouldn’t Just Be About User Permissions

It’s critical to understand that PBAC goes beyond user-level 

.
PBAC spans the entire execution environment.

While user-level access is foundational, PBAC must extend far beyond that to encompass the full breadth of the pipeline's execution environment. This includes: control over secrets that grant access to critical credentials, tokens, and identity services; network boundaries such as ingress and egress filters that regulate communication with internal systems or the public internet; and software artifacts, which require strict governance over which packages can be built, tested, or deployed.

Equally critical is the execution context, which sets the permissions that pipelines have over file systems, hosts, and even other pipelines. These elements define the scope and power of a pipeline and, if left unchecked, create opportunities for lateral movement and privilege escalation by adversaries. While modern CI/CD platforms like 

 provide built-in access control features, they often lack the fine-grained enforcement required to secure complex environments effectively. 

) approach in tools like OPA is really powerful. OPA Rego enables teams to define and enforce detailed access policies programmatically across the entire CI/CD surface area.

Policy as Code (PaC) provides a scalable, auditable, and automated way to enforce access controls across your infrastructure and CI/CD pipelines. When applied to PBAC, PaC ensures:

: Rules are enforced identically across environments.

: Policies live in source control, making them reviewable and testable.

: Enforced at runtime inside the CI pipeline.

: Policies evolve alongside your infrastructure, with traceable changes.

The most widely adopted tool for PaC is the 

, which uses the Rego language to express policies.

Rego is a purpose-built language designed for policy enforcement. Its capabilities include support for 

 models, as well as fine-grained decisions based on rich context. Rego also boasts high performance at scale. While Rego introduces a different way of thinking compared to traditional scripting languages. It’s approachable for anyone with a scripting background, and certainly becomes intuitive for first-time users with a little bit of practice. Its roots in logical programming (

) make it very different from typical scripting or general-purpose languages like Python or Go, however, the examples below should speed up the learning process.

In simple cases, Rego can feel declarative and familiar.
Here’s a simple example of a Rego policy to illustrate PBAC:

 line ensures that access is denied unless explicitly allowed. You’ll see this logic being used regularly in Rego. The allow block specifies conditions where access is granted. In this example, if the user is called "Nigel", they should only be able to read the associated helm package resources.

This works for basic cases, but as policies grow to reflect real-world scenarios, they naturally become more sophisticated, often involving nested logic, conditional rules, and integrations with external systems.

Below is a more realistic Rego policy from 

This policy restricts who can access various pipeline stages and enforces stricter controls over protected repositories like "

Applying Rego in Package Management with Cloudsmith

Rego’s utility extends well beyond CI pipelines. It can also be used effectively to enforce package access and compliance policies within artifact registries like Cloudsmith. For example, in a Cloudsmith context, Rego policies can be written to automatically block developers and DevOps teams from using packages flagged with known vulnerabilities, leveraging risk indicators such as 

Cloudsmith Blog

Security is a leading priority for 2025

The Artifact Management Market Is Up For Grabs

Prototyping an MCP Server

Adding AI to applications using the Model Context Protocol

Goodbye imagePullSecrets, Hello Kubernetes Credential Providers

AI is now writing code at scale - but who’s checking it?

Security is a leading priority for 2025

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

OWASP CI/CD Part 7: Insecure System Configuration

CVE-2025-3248: Serious vulnerability found in popular Python AI package

OWASP CI/CD Part 6: Insufficient Credential Hygiene

Docker Hardened Images & Cloudsmith: Modern Security for the Software Supply Chain

Secure Docker Image Pulls from Cloudsmith to Kubernetes using OIDC

OWASP CI/CD Part 5: Insufficient PBAC

Multiple Malicious Packages Discovered on PyPI, npm, and RubyGems