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.

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.

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? 


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.

Can only be used with dedicated DR infrastructure and requires plans for failover, which is sometimes expensive and complicated.

The vendor is in charge of patching, scaling, back-ups, upgrades, and security monitoring.

Your team is forced to deal with maintenance, upgrades, and monitoring- distracting them off the ability to deliver software.

Common are continuous security patches, access controls, encryption and compliance certifications (SOC 2, ISO 27001, FedRAMP, and more).

Your security depends upon in-house capabilities and budget; compliance checks require manual action and are time-consuming.

6. Content with shorter innovation cycles

 Features, additional integrations, and performance updates are released automatically- no downtimes to upgrade.

There is a feature lag in on-prem, as well as upgrades that need scheduled maintenance windows.

Rather than large capital costs and idle capacity, pay-as-you-go or subscription models eliminate large capital expenses and idle capacity.

Large initial CAPEX, and continuous Overhead


In brief, cloud-native artifact management integrates the most advantageous features of DevOps, cloud computing, and security. It is highly efficient in terms of software building, storing, and delivery without the complexities associated with traditional infrastructure.

On-premise artifact management – The old guard

Businesses had been hosting repositories such as Nexus, Artifactory, or even internal solutions on their own infrastructure for many years. This strategy can continue to work with the firms that:

required complete authority over their data.

worked at workplaces that had rigorous compliance

The difficulty? The following frequently appears in on-premises solutions:

One-time hardware and maintenance overheads High

limited scalability when more workloads are added

High operational costs necessitate specialised DevOps teams

Comparison between cloud-native and on-premises models

The table below is a comparison of the two most popular sets of architectural methods, cloud-native and on-premises, with the centre requirements of an artifact management system.

Cloud-native technologies that make it possible

Central technologies that support cloud-native development are emphasised by the CNCF:

 Package dependencies (such as Docker) and the code so that the same code runs equally in each environment.

 Divisibility of large applications into small services in order to render them manageable and extensible.

 Software that enables safe and reliable service-to-service communication to be made possible, like Istio.

 Serverless structures are best applied in the case of event-driven work, as they support writing the code to run without a direction towards a server.

 As opposed to manually patching servers, deploy applications as units of exchange.

 Declarative APIs can greatly increase automation and consistency due to their infrastructural and application state declarations via configuration files.

Due to this technology stack, developers are able to develop cloud-ready applications from the start, making them easier to scale, deploy, and secure.

Cloudsmith Blog

Extending Supply Chain Governance to AI and ML Artifacts

Compliance policies in EPM

Typosquatting a package? How about typosquatting the whole registry!

The platform of choice for AI companies

Why Repository Structure Matters

NX npm Supply Chain Attack: How Cloudsmith Would Have Contained the Blast Radius

Compliance policies in EPM

OWASP CI/CD Part 10: Insufficient Logging and Visibility

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

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