 are one of the most common and well-understood security failures in software development. A credential committed to a repo, copied into a script, or exposed in a CI log can sit undetected until abuse makes it visible. By then, the damage is done.

Cloudsmith is now a member of the GitHub Secret Scanning Partner Program. That means 

Cloudsmith-issued API keys are uniquely identifiable

, and GitHub can detect them automatically when they appear in a repository.

Cloudsmith issues API keys with a unique prefix. That prefix is registered with GitHub's secret scanning infrastructure, so when a Cloudsmith credential appears in a repo – in source code, a config file, a committed 

, or anywhere else GitHub indexes – GitHub detects and flags those credentials automatically.

When a leak happens, Cloudsmith notifies the affected customer directly. Teams can revoke or rotate the compromised key before it gets misused.

The workflow is straightforward: detection happens automatically, notification is immediate, and your team decides how to respond.

The window between a credential leak and credential abuse is short and it closes fast. Automated scanners can pick up a key exposed in a pull request or pushed to a public repo within minutes. Discovering issues through billing anomalies or abuse reports put teams in a challenging position, and one they want to avoid. 

Automatic detection of leaked API keys changes that dynamic. When exposure triggers an immediate notification, the response begins before most incidents have a chance to develop.

This works inside the workflows your team already uses. There is no new tooling to adopt, or new configuration required on your end. GitHub-based teams get detection in place from the moment they issue their next Cloudsmith API key.

See how Cloudsmith secures your software supply chain end to end. 

Cloudsmith credentials are now detectable by GitHub Secret Scanning

Long-lived API keys are a liability. They sit in secret managers, leak into logs, and eventually someone has to remember to rotate them. If you run workloads on Google Cloud, you can skip that whole problem: every VM, container, and function already carries a service account identity, and you can use it to authenticate to Cloudsmith directly.

 work together to handle authentication. Your workload swaps its service account identity for a short-lived Cloudsmith token at runtime. Nothing long-lived gets written to an environment variable or a key file on disk.

Google's metadata server can issue signed JSON Web Tokens (JWTs), and Cloudsmith verifies them against Google's public keys. The flow:

Your workload asks the Google metadata server for an ID token, naming Cloudsmith as the intended audience

Google returns a signed JWT carrying your service account's identity (its email and your chosen aud)

You pass this token to Cloudsmith's OIDC endpoint

Cloudsmith fetches Google's public verification keys and validates the signature

If the claims you pinned all match, Cloudsmith hands back a short-lived token for API calls

Setting this up has two parts. Your workload needs a way to get a Google token, and Cloudsmith needs to know when to trust that Google token.

On a server you want the token to carry a meaningful audience and a dedicated identity. Service account identity tokens give you both: a custom aud and an explicit email.

The simplest source is the metadata server, available on GCE, Cloud Run, GKE, App Engine, and Cloud Build:

 claims you'll pin against in Cloudsmith.

You can also impersonate the service account from another identity, such as your own user. However, the calling identity needs 

 and the payload looks roughly like this:

Before wiring up a workload, you can prove the whole flow with your own Google login:

 doesn’t give you any isolation because it is hard-wired to the gcloud SDK's shared OAuth client ID, which is the same value every gcloud user carries. For a local proof of concept, pin the 

 (hosted domain) claim, e.g., your Google Workspace domain, which ties the token back to your organization.

Now tell Cloudsmith to trust tokens from your service account. You'll need the Manager or Owner role, at least one Cloudsmith service account, and the robot identity that holds your repository entitlements must already exist. Go to Settings > Authentication > OpenID Connect and create a provider:

 is a planet-wide issuer used by every Google account, so the issuer alone proves nothing. The isolation comes from the 

 claim. Only something that can act as that exact service account can mint a token carrying its address, and that is gated by IAM. The 

 value just binds the token to Cloudsmith so it can't be replayed elsewhere.

Swap the Google token for Cloudsmith credentials:

 with your Cloudsmith service account slug, and 

 with your Cloudsmith organization identifier.

If everything's configured correctly, you'll see something like:

gcp-pipeline

The returned token is a normal Cloudsmith API key, valid for 2 hours. Pass it on any Cloudsmith API request, as the verify call above shows.

This works anywhere you have a Google Cloud service account identity. Both tokens are short-lived, so there's nothing long-lived to store, and you're reusing an identity you already manage.

Compute Engine instances use their attached service account to request a token from the metadata server, then exchange it for Cloudsmith access whenever they need it.

Cloud Run and GKE work the same way through their workload identities, fetching a fresh token for each job or when the current one nears expiry.

Cloud Functions and App Engine can request a token on demand within the handler.

Cloud Build pipelines with a service account attached can do the token exchange to gain Cloudsmith access.

You're reusing an identity you already manage, and the token it gets back expires in two hours. Nothing long-lived sits in an environment variable, and there's no rotation schedule for anyone to own.

 and point an existing Google Cloud workload at it. For the details, see 

Authenticate to Cloudsmith with your Google Cloud identity

Most cooldown policy implementations work at the download layer. A package request occurs, the policy intercepts, the download is blocked, and the build fails. The package manager already committed to that version so the enforcement is technically active, but it hands developers a broken build and no clear path forward. Many respond by pinning around the policy or going direct to public registries. The control becomes a process tax rather than a security layer.

Cloudsmith's cooldown policy enforces at the index. Packages that don't meet the configured minimum age don't appear in the index at all – the package manager resolves to the next compliant version automatically, with no build failure and no developer intervention required. The security happens before the build even knows there's a decision to make.

That design choice matters more now than it did a year ago. 

 made the exposure window visible at scale: both attacks moved from publication to compromise within hours. A cooldown policy doesn't guarantee it catches every attack, but index-level enforcement means newly published packages can't reach your builds before threat intelligence has time to catch up – and it does it in a way developers won't route around.

Cooldown policies

The primary target for cooldown policies are 

packages your Cloudsmith workspace has not cached yet.

 These are packages the platform would normally proxy directly from a public upstream like PyPI or the npm registry. Cloudsmith does not download or cache these packages while they're inside the cooldown window, so they're absent from the index from the start.

When the package manager receives a request for a newly published package it resolves to the next index-compliant version without retries or build failures. In this case the cooldown policy is completely invisible to developers.

Friction only surfaces when no compliant version exists. For example, when a lockfile or exact version pin targets a package still inside the cooldown window. In that case, the build receives a 404 Not Found or a customizable 403 Forbidden response. Rather than leaving developers with an error to debug, Cloudsmith returns an enhanced message that includes policy name, a customizable description, and a policy ID. You control what that message says – who to contact, a link to your exemption process, or an internal runbook. The right information to move forward reaches the developer, in their terminal or build log, without any client-side configuration.

Cloudsmith determines a package's age from upstream metadata: the 

 field for Python packages. If that metadata isn't populated by the package maintainer, the policy fails open, which means that Cloudsmith does not hide the package from the index. This is worth accounting for when you're evaluating policy coverage: Cloudsmith won’t block packages with missing age metadata.

No two organizations have the same requirements. Policy-as-code, written in 

, gives companies the flexibility to tailor policies to their specific needs and to exercise greater control over their development pipelines.

step-by-step instructions for creating cooldown policies is here

. Users have two options to create and manage cooldown policies. One is through the Cloudsmith web app, which exposes all the configurable fields and handles the Rego scaffolding for you. The other is through the 

, which allows you to manage policy configuration programmatically or through infrastructure-as-code.

Cooldown policies have two fixed structural constraints that users cannot change: the policy always runs at precedence 0 and is always terminal, which means the platform evaluates it first and, if a match occurs, no additional policies run for that package.

The key variables in the default template are 

 hides any npm or Python package published within the last week from the index. By default the cooldown policy applies across all repositories in the workspace, but you can scope policies to include or exclude specific repos as well.

 flag controls whether the policy applies to packages uploaded directly to Cloudsmith rather than proxied from a public upstream. The default for this flag is 

. Most teams will want to evaluate this explicitly because packages your team publishes internally carry a different trust model from packages arriving from public Python or npm registries.

Supply chain attacks don't announce themselves. The window between when a malicious package is published and when it's identified is exactly where modern development pipelines are most exposed, and closing that window requires enforcement that works with your build process.

Cloudsmith's cooldown policies are built on our policy-as-code engine, which means the same infrastructure that enforces minimum package age requirements also powers malicious package blocks, allowlists, high-risk vulnerability blocks, license compliance, and more. You can scope policies to specific repositories, formats, and packages – giving teams the precision to enforce exactly what they need without creating blanket restrictions that slow teams down.

 to see them in action and to learn more about what's available for your team.

How Cloudsmith cooldown policies block newly published packages without disrupting your builds

Shipping software requires two kinds of trust. The first is trust in what you build – that the artifact is secure, compliant, and approved for use. The second is trust in how you deliver it – that the right artifact moves to the right environment, with the right controls, every time.

Pipelines tend to handle the mechanics of both. Where they struggle is maintaining trust across the handoff between the two – and at scale, that gap is where risk compounds. Risk may include untrusted packages slipping through, environment-specific guesswork, manual steps under pressure, or reconstructing audit trails after the fact. Securing the handoff point requires both artifact governance 

 is designed to solve. A golden path makes the secure path the default path – governance baked into the delivery workflow from the start, not added as an afterthought. The Cloudsmith and Octopus Deploy integration is built on that principle.

Continuous trust doesn't emerge automatically from good tooling. Continuous integration (CI) systems build and test. Artifact registries store packages. Deployment tools ship to environments. Each does its job well in isolation. But the connections between these stages – the handoffs – are where governance tends to break down.

Artifacts accumulate in registries without clear signals about which are approved, safe, or compliant. Environment promotion logic gets buried in scripts few people fully understand. Approval processes drift into inboxes and informal agreements. When something goes wrong – or an auditor asks a direct question – there’s a scramble to reconstruct evidence rather than retrieve it.

The problem isn't the tools. It's that no single tool owns the full journey from "is this artifact trustworthy?" to "how, when, and where does it get deployed?" Continuous trust requires answering both questions, and connecting the answers.

Cloudsmith and Octopus Deploy cover that full journey. Each tool owns a distinct half, with a clean policy handoff between them.

Cloudsmith: Artifact trust before deployment

Cloudsmith is a universal artifact registry built for the enterprise. But its role in the delivery lifecycle starts well before an artifact is ready to deploy.

From the moment a dependency enters your environment, Cloudsmith enforces trust. Vulnerability matching, license compliance checks, access controls, and policy management govern what gets in, what gets promoted, and what earns approval for use – consistently, across every team and package format. By the time an artifact reaches Octopus Deploy, the governance work is already done. Trust hasn't just been verified at the gate; it's been maintained throughout.

This answers the question every pipeline needs to resolve: 

Is this artifact safe and approved to deploy?

Octopus Deploy: Controlled delivery from build to production

Octopus Deploy is a dedicated continuous delivery (CD) platform, purpose-built to take over where your CI server ends. It handles the full release orchestration process: environment promotion, approval gates, role-based access control (RBAC), deployment automation, and operational runbooks.

Where CI tools give you a place to run a deployment script, Octopus Deploy gives you a model for how software actually moves through your organization. The same artifact promotes from dev to test to production. Environment-specific variables are scoped without hardcoding. Deployments use strategies like rolling, blue/green, or canary depending on your risk tolerance. A single dashboard shows exactly what version is running in every environment.

This answers the other question your pipeline needs to resolve: 

How, when, and where should this trusted artifact ship?

When Cloudsmith and Octopus Deploy work together, the result is a clear division of responsibility:

Teams configure Octopus Deploy to consume only approved artifacts from Cloudsmith. An artifact is built, stored, and validated in Cloudsmith – with trust enforced at every step. Octopus Deploy picks it up and governs its promotion across environments. The same artifact moves through every stage: no rebuilds, no drift, no manual selection.

End-to-end traceability and audit-ready evidence

Security checks in Cloudsmith and deployment records in Octopus Deploy capture every stage of the journey by design, not after the fact. That means audits stop being fire drills.

Removing manual artifact selection and environment-specific guesswork eliminates a significant source of production incidents. When every team knows what's been approved and exactly how it gets deployed, releases become predictable rather than stressful.

As organizations grow across teams, regions, and infrastructure types – containers, VMs, Kubernetes, hybrid environments – delivery standards tend to fragment. This integration lets platform teams define policies once and reuse them across every infrastructure variation. Legacy workloads and cloud-native services follow the same governed path.

A delivery pipeline is only as trustworthy as its weakest handoff. A golden path fixes that by making governance the default – not a gate teams pass through, but a road built that way from the start.

Cloudsmith and Octopus Deploy together are that road. Cloudsmith maintains artifact trust throughout the lifecycle. Octopus Deploy controls how trusted artifacts move to production. The result is an environment where the secure path and the convenient path are the same, and where audit evidence is a natural byproduct of doing things right.

See what a governed artifact pipeline looks like in your environment. 

From trusted artifact to controlled deployment: Cloudsmith and Octopus Deploy

The Cyber Resilience Act (CRA) is, on the surface, a product security regulation. Companies need to audit what they ship, document what they build, and demonstrate conformity. But that’s not a complete reading of the regulation.

The CRA extends liability down into the components inside your product: the open-source packages your team pulled, the transitive dependencies nobody explicitly chose, the library that was clean at ingestion and compromised six weeks later. Under Article 13, manufacturers are responsible for those components, not the upstream maintainers who published them. That obligation doesn't live in your product repository. It lives at the artifact layer.

A governed control point between your developers and public registries is the essential foundation for compliance, transforming what could be a documentation challenge into a successful and reliable process.

The CRA's core obligations come down to three things: continuous vulnerability management, rapid incident reporting, and documented conformity.

The reporting timeline, in particular, is unforgiving. From September 11, 2026, manufacturers must notify the European Union Agency for Cybersecurity (ENISA) within 24 hours of becoming aware of an actively exploited vulnerability, with a full notification within 72 hours and a final report within 14 days. Full enforcement, including conformity assessment and CE marking requirements, follows December 2027.

. The 24-hour clock doesn't start when exploitation begins. It starts when you find out. Continuous awareness isn't just a best practice; it's the baseline the regulation assumes. The engineering question behind every CRA compliance conversation boils down to: when a vulnerability lands in your dependency graph, how quickly do you know?

The answer depends on your artifact infrastructure.

Where fragmented artifact practices break down

The artifact sprawl tends to be more of an incremental problem than the result of a single bad decision. A cloud provider registry here, a format-specific tool there, direct pulls from public registries when friction increased or deadlines got close. The infrastructure built up faster than governance kept up. For a long time that was fine because supply chain governance wasn't a hard requirement.

The CRA changes that calculus. Here are three key gaps the CRA exposes in the software supply chain:

 When developer tooling pulls packages directly from public registries, whether triggered by a human or an AI coding tool, there is no moment at which a malicious or newly vulnerable package can be evaluated before it enters a build. The CRA's vulnerability management requirements assume you can act on what enters your environment. And you need a control point to be able to act effectively.

 Scanning at pull request or pre-deployment isn't designed for a 24-hour reporting window. By definition, those checks happen after a package already enters the pipeline. A vulnerability that lands in a public registry at midnight and gets exploited at 6 a.m. doesn't wait for your next CI run. Continuous monitoring, where every artifact in your environment gets evaluated on first ingest and re-evaluated as new intelligence arrives, is the only architecture that supports the CRA's 

 Logs distributed across teams, tools, and formats don't assemble into the evidence chain regulators expect. Even if you responded correctly to a vulnerability, if you can't demonstrate when you became aware, what action you took, and whether you enforced that action, then the response is functionally invisible. The CRA doesn't reward good intentions without documentation.

An artifact manager isn't a compliance tool. It's the infrastructure layer that makes the CRA's requirements achievable as a natural by-product of how your software development pipeline works.

That pipeline starts with a proxy. When developer requests route through a private registry rather than directly to public registries, you create a single, auditable control point through which all package traffic flows, including transitive dependencies. Without that layer, there is no other point where an organization can intercept a malicious package between its publication and its execution in a build. Every compliance capability downstream depends on that interception point existing.

From there, policy runs at ingestion and re-evaluates continuously. A package that was clean when it first arrived can be quarantined 

 (or whatever action you assign in your policies) when new threat intelligence emerges. 

 hold newly published packages for a configurable period before they reach builds, which is the most direct control available against zero-hour attacks. Vulnerability policies enforce based on exploitability, not just severity. This is a meaningful distinction when the realistic exploitable proportion of critical CVEs sits around 15%.

Immutable audit logs covering every artifact event, policy action, and access event form the evidence chain Article 14 readiness requires. A retrospective reconstruction from scattered sources is more likely to have gaps. Auditors expect a continuous, exportable record that demonstrates what you knew and when. That's what it means to have a defensible compliance posture (proactive) rather than a compliance response (reactive).

Cloudsmith is built on this architecture: a governed control layer between engineering teams and public registries, where visibility, enforcement, and audit evidence are produced together rather than assembled after the fact. Cloudsmith helps create the foundation that makes compliance operational; it’s not a compliance product.

The deadline is a planning horizon, not a countdown

Organizations have time to make considered infrastructure decisions about how to meet CRA obligations before September 2026. Using a tool like Cloudsmith, they can consolidate fragmented registries, deploy policy, and establish an audit trail that holds up under regulatory scrutiny. Retrofitting governance onto an architecture that wasn't designed for it is ultimately a more complex and time consuming process.

Treating the CRA as an infrastructure project gives teams a head start in their approach to meeting CRA compliance.

If you're not sure where your current artifact practices stand against CRA requirements, a Security Maturity Assessment is a useful starting point.

Cloudsmith is the governed control layer between your developers and public registries – providing visibility, security enforcement, and a complete audit trail across your software supply chain. 

How artifact management closes the gaps that leave you exposed under the CRA

If your engineering team has been breathing a little easier thinking that open-source supply chain attacks are only targeting software libraries and dependencies via simple typosquatting attempts on package registries, you’re in for a harsh reality check.

Over the last week, yet another self-replicating malware campaign, this time known as 

, has torn through the open-source software ecosystem. What started as an exploit in Red Hat’s 

 packages has since escalated to a sprawling supply chain disaster, spreading to 73 Microsoft GitHub repos across the most popular environments like 

The fallout of this worm further emphasises how the software security landscape has drastically shifted over the past few months. If you rely on public registries and repos, and your devs are using AI coding tools, you have a high likelihood of being impacted by this specific attack vector.

Cloudsmith's video update on the Miasma worm

The Miasma Worm - What happened and how to protect against future attacks

Nigel Douglas, Head of Developer Relations at Cloudsmith, discusses the impact of the Miasma worm and what businesses can do to protect themselves.

How the threat mutated from Red Hat to Microsoft

Miasma is an evolved, highly-aggressive variant of the 

 by the threat group TeamPCP. The attackers have traded their Dune-themed naming convention for Greek mythology this time around with the repo description "

". Regardless, their operation has only grown stronger.

 namespace by compromising a Red Hat employee’s GitHub account. By pushing unreviewed orphan commits to internal repos, the threat actors injected a minimal workflow that requested GitHub’s 

. This registry poisoning workflow in early June executed an obfuscated payload that published 32 malicious package versions to the 

 registry. Crucially, because it used legitimate OIDC tokens, the malicious releases carried valid SLSA 

. To standard registry scanners, the malicious updates were entirely indistinguishable from legitimate, routine code updates.

Miasma quickly shifted from targeting package registries to attacking source repositories directly. It skipped the 

 registry entirely for several targets, planting a hefty payload runner straight into public repos like 

. The delivery approach here was as brilliant as it was terrifying - it was designed to weaponise the 

. The dropper executes automatically when an infected repository is cloned and opened within these popular developer tools:

By now, the contagion has fully spread into Microsoft's GitHub orgs. According to our friends at 

, a staggering 73 repos were compromised and subsequently 

 package had been hit by TeamPCP a month prior. The fact that the exact same ecosystem was completely taken down this month indicates a persistent wound, one where the original creds used in May were likely never fully rotated or remediated.

The genius of this Miasma worm lies in how it adhered to legitimate workflows. It does not exploit any software vulnerability in 

. Instead, it exploits the underlying trust model of the modern engineering ecosystem. Compromised dev creds led to a legitimate 

 token being requested. This was followed by a malicious build being published with 

, which ultimately led to conventional scanners seeing it as a routine trusted update. By stealing legitimate maintainer credentials, the worm was able to act exactly as an authenticated publisher would have.

Furthermore, Miasma generates a uniquely encrypted payload for each individual infection. This means traditional 

 are functionally useless for broad detection, as the file signature changes with every single package version. Andrew McNamara of Red Hat explained in a dedicated blog post 

While previous iterations of the Mini Shai-Hulud malware have focused purely on local secret scraping, the Miasma worm appears to have advanced data collectors specifically engineered for cloud identities in GCP and Azure. It attempts to harvest every cloud identity the infected developer machine and CI/CD runners have access to, proving a clear intent from the threat actors to leverage access away from the codebase and directly into live cloud environments.

If your company operates within the Azure or Red Hat ecosystems, you must start treating these sorts of incidents as active incidents that could be impacting your environment directly. First of all, assume secrets exposure and rotate. Because Miasma specifically hunts for developer credentials, assume everything on a compromised machine or CI/CD pipeline has been leaked. You’ll need to 

GitHub Personal Access Tokens (PATs) & SSH keys

You’ll also need to audit the developer environments. Check local workstations and build environments for unauthorised activity in GitHub, check for any unknown newly-created repositories under your organisation, and any unexpected background processes executing via VS Code or the above-mentioned AI coding CLIs.

Finally, relying purely on the latest version of these public packages is a massive liability for your team. Move towards explicit dependency allowlisting and generate strict 

 to verify exactly what is entering your build streams. This is the best way to know if you are impacted, or if anything new has been introduced into the dependency tree.

How Cloudsmith protects against Miasma malware

The Miasma campaign proves that having signed keys and authenticated maintainer accounts are no longer an absolute guarantee of safety. When upstream registries and repos are compromised, public code becomes one of the easiest, and most direct, ways of getting pwned. To survive these sustained supply chain attacks like Miasma and Shai-Hulud, businesses should consider implementing an artifact management layer for open-source dependencies.

With Cloudsmith, developers and security teams can define strict admission control policies that block packages failing specific security checks, regardless of whether they have a valid maintainer signature. Either by blocking a malicious package based on 

 threat reports, or by defining a simple 

 for newly-published dependencies, organisations can automatically catch, isolate, and inspect incoming upstream dependencies before they ever reach a developer's machine or any kind of production build pipeline.

The team over at SafeDep noted that the Miasma worm went open-source. We’ve spotted several repos dropping under the name 

 (though they’ll probably be nuked by GitHub by the time you read this). If you want to watch the cat-and-mouse game of these repos popping up and getting banned in real time, you can track them via this 

. This mirrors what TeamPCP did when they open-sourced the 

 payload, which pretty much explains the massive spike in 

On top of that, researchers at Socket flagged another 

 tied to the Mini Shai-Hulud, Miasma, and Hades strains. The new batch includes 6 packages targeting bioinformatics tools, a handful of AI/MCP-specific packages, and some classic typosquatting drops targeting common libraries:


The newer loader variant handles execution a bit differently. Instead of bundling the standard 

 payload directly inside the package, it sweeps Python’s module search path (

As for the payload itself, it runs the standard Hades playbook which is to include a heavily obfuscated JS stealer staged via Bun. In this case, the author cleverly slaps-out a fake prompt-injection header right at the top of the 

 this time around specifically to mess with AI-assisted code analysis tools. Once it lands, it targets the dev machines and CI/CD runners to scrape those high-value secrets, going after pretty much everything from registry credentials (

), the cloud and infra creds discussed earlier in the blog, as well as bunch of local environment stuff - shell histories, environmental variables, and the local AI dev tooling configs.

Another incident of Miasma has been detected in the 

 file into the affected packages. On install, this file automatically triggers a malicious 

 script which ultimately executes a heavily obfuscated credential stealer inside a runtime environment that currently evades most standard security monitoring tools.

You can track the entire cluster, specific versions affected, and technical indicators via the 

 community-driven threat intelligence database. As always, here’s a short list of the compromised packages you can check against your 

 or lockfiles, which are present in the OSV database:

A day later, the Miasma campaign targeted the 

 npm packages, compromising multiple versions of their Backstage plugins for GitLab and LDAP authentication. The automated attack likely leveraged a previously compromised third-party GitHub Action (

) to hijack deployment workflows and publish malicious packages that steal developer and CI/CD credentials. As always, organisations who may have cached the below affected versions should continue to treat their environments as compromised, immediately removing the malicious packages, before auditing GitHub Actions logs, and rotate all exposed secrets.

@immobiliarelabs/backstage-plugin-gitlab-backend

@immobiliarelabs/backstage-plugin-ldap-auth

@immobiliarelabs/backstage-plugin-ldap-auth-backend

The Miasma campaign continues to highlight a critical security flaw in JavaScript development which is the exploitation of the 

 hook to execute malicious code the moment a package is downloaded. Because this feature has historically run automatically before a developer even uses the library, simply removing the package afterward cannot undo the compromise. Earlier this month, 

GitHub finally announced an end to automatic install script execution for npm

, but this change likely won’t come into force until late in July.

This is of course an evolving story, so we will update the blog as more information becomes available.

The Miasma worm's path of destruction

By submitting this form, you agree to our 

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

Artifact Security Maturity Assessment

If you were hoping for a relaxing summer break without a software supply chain attack, the latest news will disappoint. Early on July 14th 

 identified that an attacker compromised AsyncAPI repositories and used the projects’ own CI/CD pipelines to publish four malicious npm packages. Together these packages see more than 2.9 million downloads a week, with @asyncapi/specs accounting for roughly 2.7 million of them.

Cloudsmith Blog

Inside the AsyncAPI npm supply chain attack

Inside the Mastra npm supply chain attack

The EU Cyber Resilience Act: What engineering teams need to do to be compliant

What Cloudsmith shipped in Q2 2026

Start secure, stay secure with WizOS and Cloudsmith

Dependency attacks start before your scanner runs

How to use Cloudsmith as a dependency firewall