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

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.

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.

Jason Myers

Technical Content Marketer

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

Any organization manufacturing, importing, or distributing products with digital elements in the EU, including commercial software, SaaS, IoT devices, and connected hardware. Note that CRA open source software exemptions only apply to non-commercial projects; commercial use puts you in scope.

Who does the Cyber Resilience Act apply to? 

On September 11, 2026, vulnerability reporting obligations go live; manufacturers must report actively exploited vulnerabilities to ENISA within 24 hours, even for products already on the market. December 11, 2027, is the full compliance deadline, covering all remaining CRA software requirements, including SBOMs, secure-by-design, CE marking, and technical documentation for any new product placed on the EU market.

What is the difference between the 2026 and 2027 CRA deadlines? 

Yes. The CRA requires manufacturers to produce and maintain a software bill of materials for every product. Even though the formal SBOM mandate is part of the December 2027 deadline, you effectively need it before September 2026, because accurate component-level visibility is a prerequisite for meeting the 24-hour vulnerability reporting obligation. An SBOM generation tool integrated into your build pipeline is the most practical starting point.

Do I need an SBOM to comply with CRA? 

Start by integrating SBOM generation into your CI/CD pipeline and establishing continuous vulnerability monitoring across your product portfolio. From there, enforce artifact repository policies to prevent non-compliant components from entering your builds, and document your vulnerability-handling process before the September 2026 reporting deadline. The CRA effectively makes DevSecOps practices a legal requirement, not just a best practice.

How should DevOps teams prepare for the Cyber Resilience Act? 

Frequently asked questions: EU Cyber Resilience Act

The EU Cyber Resilience Act represents a meaningful shift in how software security is defined, enforced, and evidenced, with engineering teams at the center. With Cyber Resilience Act compliance now an active requirement and the September 11, 2026, vulnerability reporting deadline five months out, the path forward is clear: teams that build the right foundations now, SBOMs, automated vulnerability monitoring, and governed artifact pipelines, won't just achieve CRA compliance in 2026. They'll ship software their customers can trust at a higher standard than before.

This isn't a regulation that lives in a legal team's inbox. The requirements land squarely on your codebase, CI/CD pipeline, artifact repository, and how you track and respond to vulnerabilities.

This blog is for the architects, DevOps leads, and security engineers doing the actual work, not just the "what" but the "how" and the "now".

What is the EU Cyber Resilience Act (CRA)?

The EU Cyber Resilience Act (Regulation EU 2024/2847) is the first EU-wide regulation that places mandatory cybersecurity requirements on digital products throughout their entire lifecycle, from design and development all the way through deployment and end-of-life.

Before the CRA, cybersecurity obligations in the EU were fragmented. Regulations like NIS2 and GDPR addressed data protection and critical infrastructure, but nothing set a consistent product-level security baseline for software and hardware. The CRA fills that gap. It establishes a common framework for how companies must design, maintain, and support digital products, and it applies to anyone manufacturing, importing, or distributing products with digital elements into the EU market.

The 2026 deadline: The 24-hour vulnerability reporting rule

The most urgent date on your calendar is 

 takes effect. It requires manufacturers to report 

 to the ENISA Single Reporting Platform (SRP) and national CSIRTs.

The reporting window is punishingly tight:

 Within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident, you must submit an "early warning" to ENISA.

 Within 72 hours, you must provide a detailed report including an initial assessment of the vulnerability's impact and any corrective measures taken.

 A final report must be submitted no later than 14 days after a corrective measure (a patch or mitigation) is available.

 To comply by September, your team needs an automated 

 process that can triage alerts from your 

What CRA software requirements look like for engineering teams

The CRA introduces 21 essential cybersecurity requirements for manufacturers. From an engineering perspective, four areas carry the most weight:

The CRA requires that companies build security into the product from the start, not bolted on after shipping. Concretely, that means products must ship with secure default configurations, minimize unnecessary attack surfaces, and include protections against common vulnerability classes. You can't ship with default credentials or insecure-by-default settings and expect to remain compliant.

For DevOps teams, this means security needs to be part of how you design features and structure your release process, not a checkbox at the end of a sprint.

The CRA requires manufacturers to maintain an SBOM, a machine-readable inventory of every component in a product, including open-source dependencies, third-party libraries, and any other software elements. The SBOM needs to be accurate and kept up to date.

The dependency between SBOMs and the September 2026 reporting deadline is real: With full component-level visibility into your products, you can report on an actively exploited vulnerability quickly and with confidence, which is exactly what the September 2026 deadline demands. Practically speaking, SBOM readiness is required for the 2026 deadline even though the formal SBOM mandate is part of the 2027 requirements.

The CRA establishes structured requirements for how manufacturers handle vulnerabilities, not just the 24-hour reporting obligation but the ongoing process of tracking, triaging, patching, and disclosing them. This includes:

A documented vulnerability management process covering your entire product portfolio

The ability to push security updates in a timely manner across the product's supported lifecycle

A public policy for coordinated vulnerability disclosure

Documentation of how vulnerabilities were resolved and when

This shifts vulnerability management from an ad hoc engineering practice to a compliance-critical, documented discipline.

The CRA requires manufacturers to maintain a detailed technical documentation package that covers the product's design, security risk assessment, SBOM, test results, and patch history. This documentation must be retained for 10 years and made available to market surveillance authorities on request.

For most engineering teams, this means treating documentation as a first-class artifact, something that you generate, version, and maintain alongside your code and releases.

What is "secure by design" under the CRA?

Secure by design isn't a vague principle under the CRA; it's a verifiable, documented requirement. Among the specific obligations, manufacturers must ensure that products:

Protect the confidentiality and integrity of stored, transmitted, and processed data

Limit privileges and apply least-privilege access controls

Ship with security enabled by default, not just available as an option

Have the capability to receive and apply security updates throughout the supported lifecycle

Minimize the attack surface, including disabling unused interfaces and services

What are the penalties for CRA non-compliance?

The EU has made it clear: the CRA is not a "paper tiger". The penalties are tiered to match the severity of the oversight:

 Essential cybersecurity requirements and core manufacturer obligations (including the Article 14 vulnerability reporting obligations): fines of up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher.

Other CRA obligations, including those applying to importers and distributors and conformity assessment requirements: fines of up to €10 million or 2% of worldwide annual turnover.

Providing false or misleading information to notified bodies or market surveillance authorities: fines of up to €5 million or 1% of worldwide turnover.

For a company with €1 billion in revenue, 2.5% of global turnover is €25 million, well above the fixed ceiling. The fines are designed to sting regardless of company size.

Beyond financial penalties, market surveillance authorities can order product withdrawals, market bans, and product recalls. Losing access to the EU market is often more damaging than the fine itself.

What engineering teams need to do to be compliant

You don't need to solve everything at once. You don't need to solve everything at once. The teams in the best shape are simply the ones that started earliest. Here's a practical breakdown:

Map every product your organization ships to EU customers. For each one, determine whether it qualifies as a "product with digital elements" under the CRA, as nearly all commercial software does. Understanding your responsibilities under the CRA is the first step to scoping your compliance work.

Build a repeatable SBOM generation process

Your SBOM is the foundation for almost everything else the CRA requires. It helps you monitor for vulnerable components, respond to the 24-hour reporting obligation, and meet the documentation requirements. Integrating SBOM generation into your build pipeline, so every release automatically produces an up-to-date, accurate SBOM, is the highest-leverage action most teams can take right now.

An SBOM generation tool that integrates with your CI/CD pipeline and supports standard formats such as SPDX or CycloneDX is essential for CRA compliance. Manual SBOM processes won't scale across a product portfolio.

Establish continuous dependency management and monitoring

, you need the ability to monitor them continuously. New vulnerabilities are disclosed daily, and the 

 apply to actively exploited vulnerabilities even in products you shipped years ago. Dependency management for CRA compliance means automated scanning against vulnerability databases, alert routing to the right teams, and a documented process for assessing whether a given vulnerability affects your products.

Evaluate your artifact repository for CRA readiness

Your artifact repository is the control point for everything your engineering team builds and ships. Artifact repository CRA compliance means having the ability to enforce policies on what components can enter your build pipeline, track provenance of every artifact, and generate the audit trails needed for technical documentation. If your current repository doesn't support policy enforcement, vulnerability scanning, or SBOM integration, those are gaps worth addressing now.

Document your vulnerability-handling process

Before September 2026, you need a written, operational process for detecting, triaging, and reporting actively 

. This doesn't need to be elaborate, but it does need to exist, be tested, and be understood by the people who will execute it under time pressure. Think of it like a fire drill for your incident response team.

Integrate security into your development lifecycle

The CRA's secure-by-design requirements aren't a one-time project. They're a shift in how your team operates. Threat modeling, security testing, and secure configuration reviews need to become standard steps in your development process, with documented outputs that regulators can review if needed.

The role of Cloudsmith in your CRA strategy

Cloudsmith is a cloud-native artifact management platform that sits at the center of your 

, controlling what goes in and what comes out of your build pipelines. Cloudsmith provides the infrastructure needed to automate these requirements:

Cloudsmith acts as a secure buffer. It allows you to ingest third-party dependencies, scan them, and automatically generate the necessary SBOMs. By centralizing your artifacts, you create a single audit trail for regulators.

Cloudsmith doesn't just scan; it generates and hosts SBOMs. When a regulator or customer requests the SBOM for a specific 2025 version, Cloudsmith provides the instant, version-linked retrieval required by the CRA’s documentation mandates.

With Cloudsmith's Policy Engine, your team defines the security baseline, and the platform enforces it. Set a quarantine policy for artifacts with unpatched vulnerabilities or missing provenance data, and nothing that fails that bar enters your pipeline.

Conclusion: Compliance is the new quality standard

 is more than just a regulatory hurdle; it is a fundamental change in how we define "production-ready" software. By September 2026, the ability to see into your 

 and report exploits in real time will be the price of entry into the European market.

 early, by automating SBOMs, securing their artifact repositories, and operationalizing vulnerability management, will not only avoid massive fines but also build greater trust with their global customer base.

Cloudsmith gives engineering teams everything they need to meet the September 2026 deadline and build a stronger software supply chain in the process.

Parul Jhawar

Marketing

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

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.

Cloudsmith Blog

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

From trusted artifact to controlled deployment: Cloudsmith and Octopus Deploy

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

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

The Miasma worm's path of destruction

EU CRA compliance: building a defensible posture with Cloudsmith

Cloud Native Digest - May 2026

AI is breaking your artifact governance – and not by writing bad code

What is a package cooldown policy? How to prevent malicious dependencies from entering your environment.

TanStack npm packages compromised in Mini Shai-Hulud attack

Mini Shai-Hulud reaches Packagist: the intercom/intercom-php compromise explained

Cloudsmith Broadcasts: Distribute software on your own terms