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

Leaked API keys 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 is able to automatically detect and flag those credentials.

When a leak is detected, Cloudsmith notifies the affected customer directly. From there, teams can revoke or rotate the compromised key immediately, before it can be misused.

The workflow is straightforward: detection happens automatically, notification is immediate, and the response is up to the team – with the option to automate revocation, which would remove manual action.

The practical value here is speed. The window between a credential leak and it being abused is often short. Most teams discover leaks the hard way – through abuse, unexpected billing changes, or an external report. Closing that window down to minutes rather than days meaningfully reduces the risk of a credential leak becoming a security incident.

This also works within the development workflows teams already use. There's no new tooling to adopt, no process changes required. If your team uses GitHub, detection is already in place.

GitHub Secret Scanning catches credentials exposed in GitHub repositories. It doesn't cover every surface where a secret might be exposed. Local environments, third-party systems, logs, or non-GitHub repositories are outside its scope. It's one layer in a broader approach to credential security, not a complete solution on its own.

Participation in the Secret Scanning Partner Program is a baseline security practice for platforms that issue credentials. This brings Cloudsmith in line with that standard and gives teams using Cloudsmith on GitHub the same level of detection they'd expect from any serious artifact management platform.

If your team uses Cloudsmith API keys in GitHub-based workflows, you don’t have to do any additional configuration. This change applies automatically to all newly issued credentials.

Jason Myers

Technical Content Marketer

Cloudsmith credentials are now detectable by GitHub Secret Scanning

AI dev frameworks are becoming a key target for software supply chain attackers. The logic is rather simple: if you can compromise the framework itself, you have the ability to compromise highly sensitive infrastructure today. That includes LLM API keys, cloud provider secrets, the kind of credentials that would allow an attacker to move laterally from there.

On June 17, a sophisticated software supply chain incident, specifically targeted 

 package name. Mastra is a popular open-source TypeScript framework used for building AI agents and 

By hijacking a former contributor’s creds, attackers were able to inject a malicious dependency across 144 packages in the Mastra ecosystem. With core components like 

 pulling nearly a million weekly downloads, the blast radius of an attack like this is massive. In this blog we’ll look at how the attack unfolded, how the malware evades detection, and how developers can secure their environment today.

The attackers executed a multi-stage campaign that relied on a blend of account takeover, social engineering (via package mirroring), and a dynamic second-stage runtime payload designed to bypass traditional static analysis.

The groundwork was laid a day prior to the primary breach. An npm user named 

. At this point, the package appeared entirely benign, indicating it was a fully functional clone of the highly popular 

By copying the original library’s version numbering, MIT license, and author metadata (

), the attackers ensured that any casual visual or automated sanity check of the package structure would look clean - one of the many ways the attacker is evading detection.

In the next stage, the threat actor updated the 

. Again, this version looked identical to its predecessor but introduced a relatively small, obfuscated file named 

, along with an execution trigger in the 

. Following a wave of community concern, 

 flag was explicitly used to suppress the Node.js runtime environment warnings, which ensured devs remained unaware during the installation.

A few minutes later, the attackers struck the 

, a legitimate former Mastra contributor whose organisational scope access had never been revoked. From there, they used an automated script that rapidly populated the 

 in just over an hour. Each package was updated to include the malicious dependency:

), any fresh install or build runner pulling the clean pinned version 

 was automatically forced to resolve and download the malicious 

 patch. From an execution perspective, when a dev or automated CI/CD pipeline runs 

 hook fires immediately, which causes the 

 script to initiate a highly-evasive first-stage dropper into the environment.

The underlying mechanics of the first-stage execution reveal a strong emphasis on evasion and anti-forensics. It has four clear evasion tactics:

 allows the script to safely reach out to an attacker’s C2 infrastructure even if the interception tools or self-signed proxies attempt to inspect or block the traffic.

, the second-stage payload is then able to spin out into its own OS process. When the core 

 routine finishes or is terminated, the malware continues running silently in the background.

: Finally, the script finishes by calling 

 immediately after execution, the installer leaves behind a clean directory tree, baffling standard post-incident file scanners.

: Mastra utilises npm's trusted publisher flow inside their CI pipeline, generating robust Sigstore-backed SLSA provenance attestations for authentic releases. However, while Mastra generated provenance, their 

The tragedy of this fourth evasion tactic is that it was entirely preventable. Because a strict verification policy wasn't required on the registry side, 

 willingly accepted the attacker’s mass updates pushed directly from a stolen PAT, even though they dropped the cryptographic provenance signature. Any client configuring a strict signature-verifying installation policy would have immediately blocked this entire campaign.

How developers can secure their environments today

By using open infrastructure tooling like 

, organisations can detect the malicious 

 package as well as the various malicious packages published to the compromised Mastra org on June 17.

However, security shouldn’t just be reactive. Developers can’t just wait for security advisories. While 

 has stepped in to pull any compromised versions from the registry, if you had run an install during the exposure window, before these advisories were published, you should treat the environment as compromised.

Securing your software supply chain requires a proactive architecture. If you're managing external dependencies using Cloudsmith, here’s how you could mitigate attacks like 

: You’ll be hearing this from us a lot, but cooldown policies really are one of the most effective solutions to this recent wave of open-source supply chain attacks. Malicious packages are often caught and reported within hours of publication. By establishing an upstream proxy with a cooldown window (let’s say, holding newly-published packages for 

 before they become eligible for download), you create a natural buffer that keeps automated pipeline scripts from pulling zero-day dependencies.

: As highlighted earlier, you should never rely purely on range-based specifiers (either 

) for high-value upstream dependencies. Where possible, ensure a strict 

 is enforced across all local and CI/CD builds. This guarantees that your builds anchor exclusively to known, cryptographically hashed versions.

Nigel Douglas

Head of Developer Relations

Inside the Mastra npm supply chain attack

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

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

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 

Teams and Access Controls

More articles

Cloudsmith credentials are now detectable by GitHub Secret Scanning

Inside the Mastra npm supply chain attack

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

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

The Miasma worm's path of destruction

EU CRA compliance: building a defensible posture with Cloudsmith