 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

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.

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

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. The teams in the best shape are simply the ones that started earliest. Here's a practical breakdown:

Cloudsmith Blog

Kubernetes 1.37 – What you need to know

How to configure time for cooldown policies

Inside the AsyncAPI npm supply chain attack

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

Cloud Native Digest - June 2026

A dependency firewall gives your scanner better inputs

Cloudsmith credentials are now detectable by GitHub Secret Scanning

Authenticate to Cloudsmith with your Google Cloud identity

Inside the Mastra npm supply chain attack

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