By submitting this form, you agree to our 

Large Language Models (LLMs) are now at the cutting edge of mainstream AI systems. Their impact has been seismic, sparking a new gold rush as application developers transform the user experience away from clicks and commands into natural language and advanced automation

However, application developers have a barrier to overcome. AI models need data to reason and respond to a particular application domain. Say, for example, the user of an artifact management platform needs to pose a simple question, ‘What packages are trending upward in usage?’ To answer this question, the AI needs to be trained on package data, including usage data.

In general, an AI model's capabilities depend on the information, or context, on which it is trained. And here is the problem - AI models tend to be isolated from data. Getting data into the AI model is not trivial. The data is often behind information silos and legacy systems. Integrating models usually involves a custom implementation with bespoke connectors.

It’s as if each time you plugged a device into a computer’s USB port, you had to configure the connection on a per-device basis. And so it is with AI models. The implementation has to be done on a per-data source, per-AI model basis, each time needing its own connector, protocol, and security checks. This multiplies the work involved in integration and tethers the LLM to a particular source, making it difficult to scale.

This multiplicity of connectors between each model and each source has been termed the MxN problem. Every model (M) needs a custom integration for every source or service (N), creating a multitude of one-off adapters that create a build and maintenance headache. As more models and tools enter the ecosystem, the integration load grows exponentially.

Luckily, Anthropic devised a solution to solve the mess of custom integrations that results from the MxN approach. The Model Context Protocol (MCP) is an open standard that provides a universal way of connecting AI models to external data sources and systems.

MCP provides a common interface, regardless of data source, eliminating the need for custom integrations for models and sources. The use of MCP as a middle layer reduces the MxN problem to a much more scalable M+N, as each model and source only has to integrate with MCP.


The USB-C port analogy is often used for MCP, as it, too, uses a single connectivity standard to provide a universal way to connect different devices. In fact, any common protocol has the same kind of utility. HTTP created a universal language for web browsers and servers to interact. MCP enables interoperability across platforms like OpenAI, Anthropic, Google DeepMind, and Microsoft, giving AI assistants access to tools and repositories in a secure and standardized way.

MCP is built using a client-server architecture, and works as follows:

The AI model (host) uses connectors (clients) to send requests for information or actions using MCP to an MCP server.

The server receives the requests, acting as an abstraction layer in front of the data source, exposing a controlled set of functions.

The server then translates the model’s requests into safe, scoped operations. This means data is accessed securely and consistently, and the model doesn’t need to know server implementation details for each data source.

The server capabilities are exposed via JSON-ROC methods, which are mapped to one or more internal database queries or functions. These could include file lookups, data queries, transformation functions, or any other tool-like operation.

The AI model can introspect the available methods and call them with specific parameters. The server authenticates the request and calls the appropriate backend query using its own connection to the database. A structured response is then returned to the model. This completely decouples the database logic from the AI model.

MCP provides powerful capabilities through code execution and data access. To address this, MPC includes a series of recommendations for best practices for securing data within your infrastructure.

These best practices are shaped around four key principles:

- Users must explicitly consent to and understand what data is accessed and what actions are performed. Implementations should offer clear UI elements to authorize and review activities.

- Resource data must not be transmitted or exposed without user approval. All access must be explicitly granted and protected through proper controls.

 - Since tools may trigger arbitrary code execution, hosts must treat them with caution and verify trust. Descriptions alone should not be trusted unless verified, and execution must be explicitly authorized.

 - Any use of LLM sampling must be user-approved. Users should be able to control whether sampling occurs, what prompt is sent, and what response visibility the server has.

MCP is unable to enforce these security principles; that is the responsibility of developers. And as a rule, they should follow these guidelines as outlined in the MCP spec:

The application should use robust flows for consent and authorization

All security implications must clearly be outlined in documentation

Appropriate access controls and data protection must be in place

Follow all security best practices when building integrations

When designing features, always consider privacy implications

Some diligence is required to ensure appropriate security controls are in place.

Expose tooling and capabilities to AI systems

Build modular integrations, composed of task-specific capabilities (such as retrieving metadata, or querying an audit log) that can be chained into larger, reusable workflows

Approach data security within your infrastructure

These attributes and Anthropic’s credentials have seen it quickly gain traction. Despite its release in 2024, MCP is becoming an industry standard and is now 

Cloudsmith has built a prototype MCP server as a step towards LLM and AI agent interaction with the artifacts and data in your Cloudsmith workspace. This could radically transform how you can control your software supply chain. It would replace potentially time-consuming command-line or UI workflows and provide fast and intuitive control with natural language prompts.

For example, ask questions like “List all versions of a particular library in Cloudsmith.”, “Tell me how many packages I have in Cloudsmith with a high CVE or that would violate a certain policy.”, or “If I reduce retention from 90 to 30 days, what will be deleted? How will that impact my allowances?”.

The image below shows an example from our proof-of-concept MCP server Claude integration. We asked, “What repository contains the Ubuntu 14.04 Docker image?”

Cloudsmith is in the early stages of this research, but our initial prototype is showing huge promise. For more information and examples, see 

MCP clearly represents an exciting opportunity for application developers to plug into AI in a scalable and economical way. Cloudsmith has started this journey with our MCP server. DevOps and developer teams will soon be able to use intelligent agents to automate, assist, or enhance their artifact management and software supply chain workflows. This is potentially transformative and may well become the future of artifact management.

If you'd like to register for early access to the Cloudsmith MCP server, 

Ian Taylor

Tech Content Director

Adding AI to applications using the Model Context Protocol

Using Kubernetes credential providers with Cloudsmith

securely pull Docker images from Cloudsmith to Kubernetes using OIDC

 with a CronJob-based approach. We concluded the post discussing credential provider plugins from Kubernetes 1.20 and an enhancement in Kubernetes 1.33 that offers a new approach for external registries like Cloudsmith.

We have now built a credential provider that takes advantage of this new capability. This article explores what this means for the future of pulling images from Cloudsmith on Kubernetes.

A credential provider plugin is essentially a script or binary that the kubelet can use to get a token for fetching images from a private repository. This saves you from having to define image pull secrets on all of your pods.

When credential providers first came out in 

, if you ran everything on AWS and stored images in ECR, you could exchange your AWS instance profile identity for an ECR token that the kubelet could use to seamlessly pull images. This was great if you ran everything on AWS, but if you used an external registry like Cloudsmith, it was harder because you couldn't exchange an AWS identity for a Cloudsmith one.

The Game Changer: Service Account Tokens in Kubernetes 1.33

 introduced an alpha feature that changes how you can identify when pulling images. The new feature exposes the pod's service account token to the credential provider plugin. The pod service account token is a 

, meaning you can create a trust relationship between Cloudsmith and Kubernetes.

This allows Kubernetes service account tokens to be exchanged for short-lived OIDC-issued Cloudsmith service tokens, enabling Kubernetes to seamlessly pull images from Cloudsmith without any image pull secrets. To do this, you need to implement a Cloudsmith credential provider plugin. We've gone ahead and done exactly that.

How the Cloudsmith Credential Provider Works

We have a Kubernetes credential provider config that gets passed to kubelet, telling it that for any image matching 

cloudsmith-kubernetes-credential-provider

 binary. This is configured using the yaml below:

The configuration passes environment variables to our binary so it knows which Cloudsmith organisation slug and service slug to use for the token exchange. We specify the audience as "cloudsmith" so only Cloudsmith can consume this token, and we require that the credential provider requires a service account.

Lastly, we define some optional annotations that our credential provider is aware of. These annotations will enable you to override the organisation slug and service slug on a per Kubernetes service account basis.

On the Cloudsmith side, we create an OpenID Connect provider that points at your Kubernetes cluster. This allows Cloudsmith to fetch the well-known OpenID configuration and the JWKs for validation.

In the claims section, you can restrict access so that only service accounts within specific namespaces can use this token exchange. If you try to bring up a pod in a namespace that isn't allowed, it won't be able to pull images from Cloudsmith.

When you try to create a pod in a restricted namespace using an image from Cloudsmith, the pod will not start, and you will see 401 authentication errors. This is because the system is operating within a namespace that Cloudsmith refuses to accept tokens from.

However, when you switch to an allowed namespace and run the same command, the system successfully exchanges a Kubernetes token for a Cloudsmith token and pulls down the image. The pod starts successfully.

This demonstrates how Kubernetes can seamlessly pull images from Cloudsmith without needing any image pull secrets defined, while maintaining restrictions so that only pods in specific namespaces can pull from specific service accounts within Cloudsmith.

This approach offers significant advantages over traditional image pull secrets:

: Ephemeral tokens reduce attack surface and credential exposure risk

: Each pod authenticates using its own service account identity

: Eliminates manual credential rotation and secret management overhead

: Namespace and service account-level restrictions provide fine-grained security

: Token refresh and caching are handled transparently by the system

The Cloudsmith Kubernetes credential provider plugin is available at 

github.com/cloudsmith-io/cloudsmith-kubernetes-credential-provider

. The repository includes a complete Minikube walkthrough for local testing.

This alpha release enables the elimination of image pull secrets entirely. As Kubernetes continues evolving its authentication capabilities, Cloudsmith remains at the forefront of implementing these advanced security features for our users.

Ian Duffy

Site Reliability Engineer

Goodbye imagePullSecrets, Hello Kubernetes Credential Providers

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

Maia Livingstone

Campaign Manager

Jack Gibson

Senior Software Engineer

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

using several npm, Python, and Ruby packages

 continues to emerge. A series of malicious packages have been added to the npm, PyPI, and RubyGems package repositories. The attacks have been ongoing for some time, with some seeded years ago. Their aims are manifold, including stealing funds from crypto wallets, deleting codebases, and obtaining Telegram messaging data. Most affected packages are from PyPI, with over thirty packages affected across the three repositories.

No Evidence of Cloudsmith Customers Being Affected

The attacks have different goals, but are mainly introduced through 

 - the publication of a bogus package with a similar name to the legitimate package, intending to mislead developers into using the fake. For example, the malicious xlsc-to-json-lh is a typosquat of 

Another tactic we see in these attacks, similar to typosquatting, is brandjacking or name-squatting, where an attacker uses a brand or utility name to make the package appear as a bona fide tool for use in the same functional domain. For example, solana-charts uses the Solana name to masquerade as a legitimate package for working with the Solana cryptocurrency.

We have no evidence that any customer has been affected. For customers that follow Cloudsmith’s recommended setups, none appear to be impacted. If we find that a customer has been compromised, we’ll get in touch immediately.

Five malicious packages have been identified for npm. 

Four target the blockchain platforms BSC and Ethereum

: pancake_uniswap_validators_utils_snipe, pancakeswap-oracle-prediction, Ethereum, and env-process.

Both platforms let developers build apps using smart contracts, which are self-executing code that runs when certain conditions are met, enabling automatic payments or trades. Together, the packages have received over 2000 downloads.

This attack was seeded 4 years ago when the packages were first uploaded. They operate by stealth, stealing a percentage of a transaction by diverting money away from the target wallet to the attacker’s wallet.

The fifth package is xlsc-to-json-lh. This is a one-letter difference typosquat on the legitimate xlsx-to-json-lc, an Excel to JSON converter with over 1500 weekly downloads. The malicious package can 

Over 25 malicious Python packages have been identified. Many of these target the Solana cryptocurrency ecosystem. 

Eleven were published by the same threat actor

 and split across four payloads in May 2025: solana-test, solana-token, solana-charts, solana-test-suite, solana-data, solana-coin, dexscreener-charts, dexscreener-data, solana-trade, sol-prices, solana-live. The attacks aim to steal cryptocurrency, source code, and other sensitive data. 

 on Solana, a threat actor known as “cappership” added covert malware to the previously benign package semantic-types. The malware was designed to steal keys from Solana wallets during software development and through automated build processes. 

The attack introduced four additional PyPI packages: solana-keypair, solana-publickey, solana-trading-bot, and soltrade, which have an indirect dependency on semantic-types. This dependency means that semantic-types is added during the installation of the packages. Hiding a malicious payload behind a few layers of dependencies is a common attack technique in supply chain compromises.

The attack vector exploits Python’s dynamic features using a monkey patch, where functions are modified at runtime but the original source code is unchanged. The actor backed up their attack with convincing-looking documentation to gain trust, linking to authentic material on Stack Overflow, GitHub repos, and Solana docs. This highlights the tactics attackers are using to fake authenticity.

, which is used for colorizing terminal output. In a twist to a regular typosquat, the actor also uploaded malicious Python libraries resembling an npm JavaScript package: colorize. A cross-domain attack like this is unusual and demonstrates how attackers are becoming more inventive.

For the Colorama typosquat, the following packages were flagged: coloramapkgsw, coloramapkgsdow, coloramashowtemp, coloramapkgs, and readmecolorama. The bogus Python libraries based on colorizr were colorizator and coloraiz.

The packages contained toxic payloads that allowed remote access, remote machine control, and access to sensitive data. On Windows, they attempt to avoid detection by bypassing endpoint protection, such as antivirus software.

 that offered a Python SDK for Alibaba’s AI services. Alibaba provides a range of products in the AI domain that cover LLMs, computer vision, natural language processing, and AI-driven applications across multiple industries. The three bogus packages were: aliyun-ai-labs-snippets-sdk, ai-labs-snippets-sdk, and aliyun-ai-labs-sdk.

None of the packages contained functional code related to AI; they were just malware used to extract sensitive information. The attackers used toxic payloads in PyTorch models, encoded as zipped 

. Pickle has a vulnerability: It allows serialized Python objects to execute arbitrary code, giving attackers a way of bypassing standard security controls.

 designed to exfiltrate all data sent to the API for the popular messaging service Telegram. The gems, fastlane-plugin-telegram-proxy and fastlane-plugin-proxy_teleram, are typosquats on the Fastlane open-source plugin, an automation tool for mobile app developers. Fastlane can be used for code signing, compiling, app store uploads, notifications, and managing metadata.

The malicious gems were almost identical to the legitimate plugin, with one crucial difference. The API endpoint had been switched to the attacker’s endpoint, intercepting sensitive data. Stealing API data gives the attackers access to authentication tokens, messages, uploaded files, and credentials.

Cloudsmith offers a strong line of defense against malicious packages with our policy management tools, including Enterprise Policy Management (EPM). All you need is identifying information, such as name or version, to build a policy that quarantines packages before they have a chance to infect your software supply chain.

, we demonstrate how easy it is to block packages based on version numbers. If you know the package names, you can easily put together a policy, for example:

Packages matching the policy can be tagged or quarantined, allowing you to control the identification and use of one of these vulnerable packages.

 on how to block pages based on multiple conditions.

To find out more about policies and security in Cloudsmith, 

Multiple Malicious Packages Discovered on PyPI, npm, and RubyGems

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 

Cloudsmith Blog

Adding AI to applications using the Model Context Protocol

Goodbye imagePullSecrets, Hello Kubernetes Credential Providers

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

Secure Docker Image Pulls from Cloudsmith to Kubernetes using OIDC

Multiple Malicious Packages Discovered on PyPI, npm, and RubyGems

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

Enterprise Policy Management Example: Quarantine Packages Using Policy as Code

Enterprise Policy Management with Cloudsmith

SLSA: A Route to Tamper-Proof Builds and Secure Software Provenance

Native Signing Support In Cloudsmith Extended To Docker, NuGet, And Swift