By submitting this form, you agree to our 

Typosquatting is now a well-known exploit, whereby malicious actors register domains or package names that are visually similar to popular ones. Examples include misspelling 

 as “expresss” - a mistake we’ve all made when typing too fast under pressure. Normally, when you make a typo retrieving a software package, you just get a build error since the package doesn’t exist. However, adversaries pick up on these subtle behaviours and in the process publish package names, deliberately containing malware, knowing someone is inevitably going to make this mistake at some point.

We just saw this threat has escalated. Instead of just mimicking individual package names in ecosystems like npm or PyPI, attackers are squatting on 

An alarming post by Bruno Schaatsbergen on 

 highlights this issue. A user discovered an active container registry at 

, which is the GitHub Container Registry. The poster warns: “I'm not sure who owns it, but be careful”. And it makes sense, unless investigated further, it’s unclear what is currently being distributed via this fake registry. Funny side note, if you go to the fake (ghrc.io) instead of the correct Github Container Registry address, it displays one of those generic default Nginx web server pages instead of the expected Github redirect (

Again, simple typo, swapping the positions of “r” and “c” leads to a completely different registry. Given that container workflows often operate in scripts or automated pipelines, a single-character mistake can redirect your push or pull operations to an attacker-controlled endpoint.

While it might seem unlikely that this is happening right now in any organisation, a simple 

 would show you that this typo has been made on quite a number of occasions. If your CI/CD workflow is also scripted to push to 

, those images will never reach GitHub, and instead will end up elsewhere. In doing so, the adversaries operating 

 could intercept or modify container images. They might serve backdoored images, leak credentials, or inject exploits. But this stuff is easy to make mistakes with. In logs or configuration files, 

 basically look identical at a glance. Developers may not notice the swap until something breaks, or even worse, when the damage is already done.

But you can take action. As an immediate first step, you can carefully review your registry URLs, especially in automation files like Dockerfiles, CI pipelines, docker push or docker pull commands. Additionally, you could enforce DNS or host-level protections to prevent access to known malicious or typo versions like GHRC. Explicitly only allow the registries that you expect to work with.

 exists as a live container registry masquerading behind a one-letter typo of 

This reflects an escalation from typosquatting individual package names to targeting entire registries.

The implications are severe. As the story evolves, it is worth adopting some vigilance when working with your container registries.

 later clarified that while the 401 response and 

 header are standard parts of the OCI spec, in this case they’re being returned by a server that isn’t a registry at all. The fact that only the 

 endpoint mimics OCI behavior, while the rest of the site is a default nginx install, suggests the setup is intentionally crafted to lure OCI clients into sending credentials to a fake token API.

This scenario highlights why companies should prefer providing developers a registry within their organisation. Having a control plane (like Cloudsmith) in front of registries in which to verify and block things like this fake registry, backed-up by a powerful audit trail for post-incident forensics.

Nigel Douglas

Head of Developer Relations

Typosquatting a package? How about typosquatting the whole registry!

In July 2025, two of the npm ecosystem’s most widely used packages became unwitting carriers of malware. The first, 

, was compromised after its maintainer was deceived by a phishing email disguised as a message from npm support. With stolen credentials, attackers published malicious versions that spread rapidly into developer environments worldwide, dragging related packages into the breach.

Shortly afterwards, the seemingly innocuous utility ‘

’ (a lightweight library downloaded more than 2.3 million times each week) was taken over in the same way. For roughly six hours, anyone installing the package, directly or through the countless tools that rely on it, was unknowingly pulling a version laced with a backdoor. What makes this striking is not the sophistication of the malware, but the ubiquity of its host. The ‘is’ Javascript testing library does little more than check whether a value is a number, a string, or empty, yet precisely because it is so simple, it is embedded everywhere. Its compromise meant that risk cascaded across the software ecosystem almost instantly.

These events were part of a broader wave of supply chain attacks in which malicious packages are deliberately seeded into public registries. Analysts now estimate that the OpenSSF’s 

 project tracks more than 35,000 confirmed cases across npm, PyPI and other ecosystems. What once seemed rare is now industrialised.

Traditional vulnerabilities are flaws to be patched. Malicious packages are different. They are intentional weapons that arrive through normal developer workflows; invisible, inherited deep in dependency trees, and executed automatically by build systems. When a package with millions of weekly downloads is compromised, six hours is enough to spread malware worldwide. By the time advisories are published or scanners raise alerts, the damage is already done.

Intelligence is only valuable if it is enforced

Open source intelligence has improved dramatically, and projects like OpenSSF Malicious Packages and OSV.dev provide vital, structured data. But feeds alone do not change outcomes. What matters is whether that intelligence is enforced at the moment a package attempts to enter your organisation. Otherwise it becomes background noise while builds continue to ingest whatever registries serve.

Cloudsmith’s approach to artifact security

 (EPM). Intelligence from OSV.dev and OpenSSF is now integrated directly into Cloudsmith repositories, so known hostile packages can be blocked, quarantined or tagged at the point of entry; before they touch developer machines, CI pipelines, or production builds.

Even with strong ingress enforcement, new vulnerabilities and threats can emerge after artifacts are already in your repositories. A package that was safe yesterday might later be linked to a newly disclosed CVE or malware signature.

 steps in. This feature, available in EPM-enabled workspaces, performs hourly checks of your stored artifacts against up-to-date vulnerability and threat intelligence sources, such as CVE aggregators and EPSS databases. When a new threat is detected in a previously ingested artifact, Continuous Security flags it immediately without relying on manual re-scans or waiting for scheduled checks. This ensures that your repository remains secure not just at the moment of ingestion, but continuously over time, adapting to evolving risks.

The crucial difference between this approach and those of other legacy artifact management platforms is that Cloudsmith treats this as core to artifact management, not as an optional add-on. When security is sold separately, it is inconsistently applied and easy to bypass. In Cloudsmith it is inseparable from the platform itself, which means every package is subject to the same level of scrutiny the moment it arrives.

), organisations can tune enforcement to their own needs; strict blocking in production, tagging in development, quarantining for review in sensitive environments. Developers do not need to stop and think about dependency safety: those controls are enforced automatically, enabling development teams to move quickly without increasing risk.

Why a unified multi-format repository matters

Attackers are promiscuous in their choice of target. Today it is npm, tomorrow PyPI, RubyGems or Docker Hub. A fragmented security model (one tool for JavaScript, another for Python, another for containers) leaves seams. Seams are where gaps form, where integration fails, and where policy is not applied consistently.

Cloudsmith’s multi-format repositories eliminate those seams. Whether the artifact is npm, PyPI, Docker or NuGet, it traverses the same controlled gateway, subject to the same policies and the same intelligence sources, organised in a manner that makes sense to your organisation. Security and distribution are not separate concerns; they are two sides of the same process.

From artifact management to artifact trust

The compromise of ‘is’ demonstrated how quickly risk can propagate when even a trivial dependency is weaponised. Six hours, millions of downloads, and the possibility of global exposure. In that context, treating malware detection as an optional extra bolted onto artifact management is no longer defensible.

Cloudsmith brings intelligence, policy and artifact management together into one fully managed, cloud-native platform, where trust is enforced automatically at the point of entry across every format your teams use. Developers keep building at pace. Security teams know every package is vetted.

Trust is not inherited within the software supply chain. It has to be enforced.

Interested in exploring our advanced security features more for yourself? 

Grab some time with me or another member of our team.

Stephen Abraham

Account Executive

Six Hours Too Late: Why Malware Detection Must Be Built Into Artifact Management

In modern enterprise software delivery, security and speed must work together—without compromise. As the development team expands, the number of software artifacts they build, like containers, packages, binaries, configuration files, and Helm charts, grows rapidly.

 is a cornerstone of DevOps and CI/CD pipelines. Not only does it centralise the results of your builds, but it also stores, secures, and distributes them so that developers, automation services, and production systems can use the right version of software at the right time.

In the case of enterprises, the potential of making the wrong choice of platform may result in integration troubles, regulatory risk and deployment delays. The right artifact platform, however, can transform your software supply chain into a secure, globally accessible, and automation-ready ecosystem.

This guide explores why artifact management is important at enterprise scale, what features to prioritise, and how to select a solution that connects both technical and business goals.

Why artifact management is essential for enterprises

Enterprise DevOps teams have their own special scale and governance problems that are more than just larger versions of those seen in small organisations. Without a dedicated artifact management solution, artifacts may be scattered across cloud buckets, file servers, and developer machines—leading to versioning chaos, security blind spots, and delivery bottlenecks.

Common enterprise-level challenges include:

A single enterprise CI/CD pipeline might generate thousands of new artifacts per day across multiple teams, languages, and microservices. It is necessary that these are stored, retrieved and prioritised efficiently.

Organizations rarely build in only one package format. You might need to store Docker images, Python wheels, npm packages, Java JARs, Helm charts, and even proprietary binary formats.

Distributed teams need fast, reliable artifact access no matter where they are. Build and deployment times may escalate without worldwide replication and/or CDN caching.

Enterprises in regulated industries (finance, healthcare, government) must track, verify, and audit artifacts to meet compliance standards like ISO 27001, SOC 2, HIPAA, or FedRAMP.

Malicious actors increasingly target artifact repositories to inject backdoors into the software supply chain. Without artifact signing, vulnerability scanning, and access control, these risks multiply.

An enterprise-grade artifact management platform is not just storage—it’s a secure, scalable, policy-driven system for managing the entire artifact lifecycle.

Key features to look for in an artifact management platform

When evaluating an artifact management solution, enterprises should prioritize these capabilities:

An effective artifact management solution must deliver enterprise-grade security. This includes built-in vulnerability scanning and SBOM generation, role-based access controls, and artifact signing and verification. All these characteristics combine to give end to end supply chain security to the whole pipeline.

At enterprise scale, an artifact management platform must easily adapt as new teams and projects are created. The solution of choice must be able to cope with increasing workloads without interrupting performance, and it must be able to integrate with any DevOps toolchain. This elasticity ensures artifacts remain accessible and reliable, even as organizational demands evolve.

The right artifact management platform should handle all major package formats (Docker, npm, Maven, Python, Helm, etc.) and integrate with CI/CD pipelines like GitHub Actions, GitLab CI, or Jenkins.

High availability and global distribution

Businesses cannot afford to go down. Search for multi-region replication and content delivery acceleration, which minimizes latency in geographically distributed teams.

An artifact management solution must help enterprises meet strict compliance requirements. Features like audit logs, retention policies, immutability, and automated expiry ensure artifacts remain both secure and compliant.

To improve operational efficiency, enterprise teams should consider a solution that provides storage optimization, automated cleanup, and predictable pricing models. A scalable software artifact repository prevents uncontrolled growth in costs while keeping systems clean.

How to evaluate and select the right artifact management platform

Choosing an enterprise artifact management platform isn’t just a technical decision—it’s a strategic investment that impacts cost, security, and development velocity.

Your platform should support the full spectrum of artifacts your teams produce, whether that’s containers, language-specific packages (npm, Maven, PyPI, RubyGems), or OS packages. (RPM, DEB), binaries, Helm charts, or even configuration files. Broad format support reduces tool sprawl, simplifies workflows, and prevents the overhead of maintaining multiple systems for different artifact types.

An artifact management solution should connect seamlessly with your CI/CD pipelines, version control systems, and DevOps workflows. Native integrations with tools like GitHub Actions, GitLab, Jenkins, and Kubernetes ensure artifacts move securely and automatically from build to deployment without manual intervention or fragile custom scripts.

Enterprises must ensure their artifact management platform includes vulnerability scanning, artifact signing, and audit logging. Framework compliance built in (SOC 2, HIPAA, FedRAMP, GDPR) mitigates risk and enhances 

. Using a platform that eases compliance avoids disruption during audits.

The platform must be able to scale in the case of increased workload as the number of teams and projects increases. Look for elastic scaling that accommodates thousands of developers, global teams, and massive artifact libraries without downtime. Scalability ensures that your repository grows with your enterprise, supporting continuous uploads, downloads, and artifact access without becoming a bottleneck.

Enterprises have to find an equilibrium between scalability and cost. Consider platforms based on features such as auto-cleanup, retention, and immutable storage, which lower overhead. Transparent pricing models and strong governance controls ensure your software artifact repository remains sustainable as usage scales.

Best practices for enterprise artifact management

Picking the proper platform is one half of the equation – what you do with it will determine if you’re truly benefiting from its features. These best practices will help enterprises maximise efficiency, maintain security, and keep artifact repositories healthy over time.

The security must begin as soon as possible in the software development lifecycle (SDLC).

Integrate vulnerability scanning, artifact signing, and integrity checks directly into your build pipelines.

Early security problem detection and remediation minimize the cost and the risk of shipping vulnerable software.

Once an artifact is published and tagged for release, it should never be altered.

 Make production artifacts read-only and use versioning to publish updates instead of modifying existing builds.

It guarantees that reproducibility prevents tampering and that the deployments are repeatable across environments.

Over time, unused artifacts accumulate, driving storage costs and clutter.

 Implement retention rules to automatically delete old or unused artifacts after a defined period.

it minimises the costs of infrastructure, enhances repository performance, and makes storage manageable.


Consistent naming across teams avoids confusion and makes artifacts easier to locate.

 Adopt and enforce a repository naming convention to include project names, version schemes, and branch markers.

It enhances collaboration, minimizes the issue of human error, and accelerates search and automation tasks.

For global teams, distance from the artifact source can create deployment delays.

Use a platform with multi-region replication or CDN-based caching so artifacts are served from the closest location to the consumer.

 It reduces latency, makes build and deployment much faster, and makes performance consistent across the globe.

At enterprise scale, artifact management is not just about storing files—it’s about ensuring trust, speed, and governance in every step of software delivery. In a world where software supply chain attacks are accelerating, your artifact management platform is the fortress that safeguards your software assets and the delivery engine that keeps your teams moving fast.

 is no longer just a technical decision—it’s a strategic investment in enterprise resilience, security, and scalability. By prioritising cloud-native design, robust security, and compliance, enterprises can ensure that their software artifact repository supports both current and future business goals.

1. What is an artifact management platform? 

A tool that stores, secures, versions, and distributes software artifacts like Docker images, packages, and binaries.

2. Why is artifact management important for enterprises? 

It centralizes artifacts, improves security, ensures compliance, and speeds up delivery.

3. What should I look for in an enterprise artifact management platform?

Support of multiple formats, high availability, robust security, CI/CD integration, and worldwide distribution.

4. How does artifact management improve software supply chain security? 

By scanning for vulnerabilities, enforcing signed artifacts, and keeping an immutable audit trail.

5. Can artifact management platforms be integrated with CI/CD pipelines? 

Yes, to automate artifact publishing, scanning, and promotion.

6. How does a cloud-native artifact management platform benefit global teams? 

It provides high speed, worldwide availability based on CDN publishing, and no server administration.

7. Can an artifact management platform help with compliance? 

Yes, by enforcing policies, maintaining logs, and ensuring only approved artifacts are deployed.

Parul Jhawar

Marketing

Choosing the Right Artifact Management Platform for Enterprise Scale

Cloudsmith’s Enterprise Policy Management (EPM) now supports the Open Source Vulnerability (

) database as an additional data source, so users can define 

 policies. OSV.dev is a distributed vulnerability database specifically for open source software (OSS) packages, including dependencies. The open, precise, and distributed vulnerability information for OSS projects from OSV complements EPM’s existing vulnerability data from Common Vulnerability Scoring System (

) and Exploit Prediction Scoring System (

The OSV database was originally developed by Google, and is fully open source. It consolidates data from multiple vulnerability repositories that follow the OSV schema, such as 

 database, Python Packaging Advisory Database (

OSV offers a straightforward API that allows clients to look up vulnerabilities based on either a specific commit hash or a package version. All records adhere to the 

 specification, which was created through collaboration with open-source communities. This schema provides a standard approach, for both human- and machine-readable format for detailing vulnerabilities, ensuring they can be accurately linked to exact package versions and commits.

Creating a Malicious Package policy in Cloudsmith

Let’s look at an example of Cloudsmith EPM policy. This one serves as a malware detection gate. EPM runs 

 the Cloudsmith security scan completes during package synchronisation, making scan results available as 

. In this case, the policy code loops over the 

 array, which is the OSV malware data from the scan. For each vulnerability object, it checks, “does the ID start with the string 

So what does this policy do in practice? It flags any package that has been reported as known malicious as part of the OpenSSF Malicious Packages project. "

" is used specifically in vulnerability feeds to indicate malware-related findings. Once a match is found, Cloudsmith will execute the 

 for this policy, such as to quarantine, tag, or block package promotion.

 a blog post in July 2025 about a set of npm linter packages, including 

, that were hijacked via phishing to drop malware. Looking up eslint-plugin-react_editor within the OSV database we can see there’s already a matching entry with the ID 

Each malware ID comes with an associated 

 that provides all the surrounding context for policy decisions. We are using a free string search for “MAL-” to capture malware IDs.

In this scenario, we downloaded the tarball in a sandbox environment:

 tarball to Cloudsmith without installing it locally, which is safer when testing the malicious package.

 We are detecting based on malware, not on vulnerabilities. In this case there is no CVSS vulnerability data associated with the package, however, the package is still quarantined and tagged for Malware due to the malware findings from the Malicious Packages project.

 explain how the package was quarantined with the relevant malware information. Here’s a command you could use to return information specific to OSV findings:

 filter, you get the entire output of the Cloudsmith EPM decision logs. Within these logs, you’ll see:

: Times the policy evaluation started and ended.

: The exact data used to evaluate the policy.

: Which actions were actually invoked on the package.

Protect Yourself Against Malicious Packages!

By integrating OSV as a data source, Cloudsmith EPM gains access to vulnerability intelligence that directly maps to specific OSS package versions and commits. These 

 policies complement the existing CVSS and EPSS coverage by filling critical gaps, particularly in cases where a package may not register a conventional CVSS vulnerability score but is still compromised, such as with malware-flagged releases.

With OSV’s standardised schema and rich ecosystem of upstream sources, EPM will detect and act on threats that might otherwise slip through traditional scoring-based detection, extending its ability to quarantine, block, or tag malicious packages before they impact production environments.

Managing Malicious Packages with Cloudsmith EPM

Cloudsmith now detects malicious packages using data from OSV.dev and the OpenSSF Malicious Packages project so you can 

 packages designed to attack your supply chain 

Below is a quick primer on malicious packages, how Cloudsmith protects customers from malware with 

 (EPM) policy-as-code, and what’s next.

 is an artifact published to a public registry (npm, PyPI, RubyGems, etc.) that’s intentionally crafted to harm users or systems. Unlike a vulnerability (a flaw to be fixed), this is 

: credential theft, data exfiltration, backdoors, cryptominers, or build-pipeline compromise — delivered as a normal-looking dependency.

 for malware (it “rides” the OSS dependency graph via a compromised dependency into apps and CI/CD; more on that below).

While traditional malware often arrives via email attachments, web drive-bys, or exploit kits, 

 differ. Attackers publish them to registries (or compromise maintainers) so that 

 (CI, package managers) do the installation work for them, shifting the battleground to developer workflows and dependency resolution.

Software packages as delivery vehicles for malware isn’t a new thing. The 2018 

 incident was an early wake-up call: a trusted package was weaponized through a hidden dependency to target a cryptocurrency app. The threat has only grown. In mid-2025, 

researchers uncovered a coordinated malware campaign on npm

 attributed to North Korean threat actors, involving dozens of malicious packages disguised as developer tools. These packages, collectively downloaded thousands of times, deployed multi-stage payloads and backdoors like 

. Even as registries introduce stronger security controls, attackers continue to adapt.

 (OpenSSF), maintains a public, comprehensive, cross-ecosystem database of reports on malicious software packages (e.g., from npm, PyPI, RubyGems). It collects detailed intelligence on malicious packages—such as account takeover attacks, dependency confusion, and malware embedded via post-install hooks—and makes this information openly available using the 

As of August 2025, the database contains ~35,000 malicious package reports.

Cloudsmith integrates this data feed via 

, providing hourly checks against the OpenSSF database. When a malicious package is found, Continuous Security works with 

 (EPM) to automatically flag and quarantine it, preventing the harmful software from entering your builds.

 Blocking malicious packages at the source prevents them from ever reaching your systems.

Prevent attackers from compromising builds or slipping backdoors into production.

 Guardrails reduce risk without slowing teams down.

Catching threats before they’re integrated saves time, effort, and reputational risk.

Meet compliance and customer expectations: 

Support audits and build trust with security-conscious buyers.

Tap into a community-maintained feed of verified malicious packages across major ecosystems.

As attacks adapt, so will Cloudsmith. We’ll continue to expand detection by adding more threat intelligence sources, richer context and deeper automation in EPM. Upcoming work includes incorporating deps.dev to surface package quality and maintainability data, and adding more community feeds like OSV.dev - a great example of the open source community working together to solve supply chain security challenges. 

We’re also exploring ways for Enterprise customers to bring their own internal threat intelligence feeds into Continuous Security, further tailoring protection to their environment. Our goal is to broaden coverage and shorten the time it takes to detect and respond to threats. If there are specific feeds or heuristics you’d like us to prioritize, let us know.

in our documentation. Interested in learning more? 


Claire McDyre

Product Manager

Malicious Package Detection in Cloudsmith

Where to host your software artifacts is one major decision in this fast-paced DevOps world, where success is pegged on scalability, security, and velocity. Organisations have stored and held binaries, packages, and container images in on-prem artifact repositories. Cloud-native artifact management is increasingly significant as cloud consumption becomes mainstream.

Then what is causing this shift? So why are teams shifting towards cloud-based systems instead of on-premise solutions? Let us simplify that.

Understanding cloud-native artifact management

Cloud-native artifact management is a contemporary approach to storing, securing, and distributing software artifacts—such as packages, container images, and binaries—using scalable, resilient, and fully managed cloud infrastructure.

What does “cloud-native” really mean?

Fundamentally, "cloud-native" is about developing and operating applications with cloud technologies in mind for speed, scalability, and automation. Rather than using physical machines or static infrastructure, cloud-native infrastructure employs dynamic environments—such as containers, microservices, and serverless functions—that can change and scale based on requirement.

For the Cloud Native Computing Foundation (CNCF), cloud-native approaches allow companies to develop and deploy software "at scale, in a programmatic and repeatable way" across public, private, or hybrid clouds. This is translated to faster releases, reduced manual touch points and a shorter development cycle.

Bringing It Together: Cloud-Native + Artifact Management

On-premises conventional artifact stores require internal infrastructure, handiwork upgrades, and specialised facilities to be ready and responsive. Cloud-native 

It is not a tool; it is a DevOps catalyst. Whether you are dealing with internal builds or open-source packages, cloud-native solutions provide more reliability and speed, and less operational worry.

What is so important in the context of the modern software supply chain?

While the software supply chain is becoming more sophisticated and security-oriented, embracing a cloud-native artifact management platform comes with several key advantages:

 Can grow and shrink on demand to take advantage of sudden demand spikes (e.g, CI/CD cycles, releases) without new hardware.

Scaling is tedious and costly since buying and setting up additional infrastructure is necessary.

Edge nodes/CDNs are distributed in the world so it uses edge nodes/CDNs to distribute artifacts in such a way that they are closer to their covers thereby reducing latency in distributed teams.

Locations are fixed on this plane of existence to the location of your physical data center and your remote teams might have slower downloads.

3. Intermediate availability & resilience

Constructed of redundant, fault-tolerant architectures that have uptime SLAs and are self-failing-over.

Cloudsmith Blog

Typosquatting a package? How about typosquatting the whole registry!

Six Hours Too Late: Why Malware Detection Must Be Built Into Artifact Management

Choosing the Right Artifact Management Platform for Enterprise Scale

Managing Malicious Packages with Cloudsmith EPM

Malicious Package Detection in Cloudsmith

Cloud Native Vs. On-Premise Artifact Management - A Complete Overview

Migrating from Docker Content Trust to Sigstore

Competition, transparency and building the future of the Software Supply Chain

Kubernetes 1.34 – What you need to know

Artifact Management: A Complete Guide

OWASP CI/CD Part 10: Insufficient Logging and Visibility

Pull back the hood on the data and tech that informs EPM