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 organization builds software and sells it into the European market – or plans to – the EU Cyber Resilience Act (CRA) is now one of your operating constraints. It entered into force in December 2024, but the first binding deadline begins in September 2026 and full enforcement starts in December 2027.

The regulation applies to any company selling products, software or hardware, with digital elements on the EU market, regardless of the company’s headquarters location. That means nearly all global software companies will be subject to CRA requirements. A software team based in Austin, Sydney, or Shanghai that ships a product used by EU customers is a manufacturer under the CRA.

This post covers what the CRA requires, what those requirements mean at the software supply chain layer, how they apply depending on your product type, and what you need to start doing now. Consult with your internal compliance teams before implementing changes to ensure that those changes meet your company’s specific needs.

, establishes mandatory cybersecurity requirements for products with digital elements – a category defined broadly to cover software applications, connected hardware, cloud-delivered software, and components placed on the market independently.

The most useful comparison is GDPR. Like GDPR, the CRA applies to any organization doing business in the EU, not just organizations based there. Companies don’t need a physical presence in the EU to fall under its jurisdiction. And like GDPR, non-compliance carries penalties calibrated to be uncomfortable at scale.

The difference is focus. GDPR governs data privacy. The CRA governs the security of the product itself, from design through its full operational lifecycle – and that lifecycle dimension is worth highlighting. This is not a "set it and forget it" regulation. It requires ongoing attention to maintain compliance. The regulation frames the intent directly: it aims to ensure that "hardware and software products are placed on the market with fewer vulnerabilities and that manufacturers take security seriously throughout a product's lifecycle."

The CRA shifts the burden of cybersecurity from end-users to manufacturers.

 The questions the regulation asks are: can you demonstrate that you shipped secure software, that you knew what was in it, that you tracked vulnerabilities after release, and that you reported incidents to authorities within the required timeframes?

For most software organizations, the honest answer today is no – at least not completely.

The area that likely poses the biggest challenge to companies is reporting. Understanding what's expected helps to contextualize why the tooling and processes discussed later in this post matter.

The most imminent obligation in the CRA is the vulnerability reporting requirement under 

 This is more than a year before full enforcement begins and it’s the first hard deadline.

Under Article 14, manufacturers must report to the EU Agency for Cybersecurity (ENISA) and the relevant national Computer Security Incident Response Team (CSIRT) 

when they become aware that a vulnerability in their product is being actively exploited, or that a severe incident has occurred

. There are three reporting windows for actively exploited vulnerabilities:

 Acknowledge that an active exploit occurred and identify the affected product. The clock starts the moment you become aware, not when you issue a fix.

 Identify the specific exploit, what you're doing about it, and how your end-users can protect themselves.

 A full report on the incident and how your organization remediated it. 

The 14-day clock runs from when the corrective measure becomes available, not from the original incident

For severe incidents, i.e., those that negatively affect a product's ability to protect data integrity or confidentiality, or that lead to the introduction of malicious code, the early warning and notification windows are the same, but companies have more time to compile their final report. In these cases, the deadline is one month from submission of the incident notification, instead of 14 days.

The practical implication is significant. To meet these windows, you need to know in real-time what is in your product and whether any of its components are under active attack. This is where having a 

, which functions like an ingredient list for your software, listing dependencies, licenses, and other key information, is critical. Automating processes like SBOM generation gives you the foundation to work at the speed these deadlines require.

 of the CRA establish its vulnerability handling requirements. How these requirements relate to each other determines what the regulation actually demands of your engineering team.

) covers any weakness in a product that could be exploited. The obligation here is documentation: the CRA requires a continuously maintained SBOM covering all components and their dependencies. The SBOM is not a one-time deliverable. It needs to stay current SBOMs as your applications evolve. The SBOM is the foundation everything else depends on, because you can’t track vulnerabilities in components you haven't identified.

) covers vulnerabilities that are realistically exploitable under practical conditions. This is the shipping standard: the CRA requires that products reach customers without known exploitable vulnerabilities. The operative word is "exploitable" – meaning realistic exploitation under real-world conditions, not just theoretical presence. EPSS scoring is the practical tool for making that determination. The SBOM is what tells you whether an exploitable component is present in the first place.

) covers vulnerabilities for which there is evidence of active exploitation in the wild. Detecting active exploits is a runtime issue, but the documentation that helps triage and remediate these attacks comes from the software supply chain. An active attack triggers Article 14 reporting – the 24-hour clock. To meet that window, you need to know immediately when a component in your product crosses from exploitable to actively exploited. That requires your SBOM to be current at the moment the disclosure happens, and your monitoring to be continuous rather than scheduled.

The first two tiers are squarely supply chain concerns – what components are in your product and whether any of them are exploitable. The third tier is a runtime security problem: detecting active exploitation happens outside the supply chain layer. But the supply chain remains central to the response. The SBOM tells you exactly which products and versions a confirmed exploit affects, where those artifacts live, and helps you determine what a remediation path looks like. That data is what lets your team triage quickly and meet the reporting windows with confidence.

Keeping that information in a single platform matters. Fragmented tooling – separate registries, scanners, and audit systems that don't share context – creates gaps and slows response the precise moment speed matters most. Your team has more time to act on information when they don’t need to chase information across tools.

Secure by design: what the CRA requires and how Cloudsmith helps

The reporting obligations get the most attention because they have the earliest deadline. But behind them sit broader design and process obligations that constitute the bulk of what the CRA demands. These obligations live in 

The phrase the CRA uses consistently is "secure by design." At the software supply chain layer, that means security is not a post-build review step. It is enforced at every point where components enter and move through your engineering environment.

 related to the software supply chain and maps those onto Cloudsmith capabilities.

 Manufacturers must identify and document all components in a machine-readable SBOM, covering at minimum top-level dependencies. The SBOM does not need to be publicly published, but it must be available to market surveillance authorities on request and must be actively used in vulnerability handling. Without an accurate, current SBOM, you cannot demonstrate what is in your product or respond to vulnerability disclosures effectively.

 Cloudsmith automatically generates a complete, machine-readable 

 for container images added to the platform, covering packages, dependencies, and license information, with no manual steps. Cloudsmith stores and distributes SBOMs alongside the artifacts they describe – versioned, access-controlled, and immediately retrievable for audit or authority submission. The platform tracks the dependency graph continuously as part of normal artifact management, not as a separate compliance task layered on top.

For more information about this requirement see 

Continuous vulnerability detection and management

 The CRA requires manufacturers to systematically document vulnerabilities as they become aware of them, apply effective and regular security testing, and ship products without known exploitable vulnerabilities. The standard is continuous, not periodic.

Cloudsmith addresses this requirement in two ways: detection at ingestion, and continuous re-evaluation as new threats emerge.

At ingestion, Cloudsmith checks every package before it reaches developers. When a package request occurs, Cloudsmith fetches it from upstream, performs vulnerability matching against its database, and evaluates it against your registry policies. Packages that pass are served to developers, agents, or pipelines. Those that fail are blocked or quarantined according to your security policies.

Furthermore, packages that were clean at ingestion don't stay evaluated in isolation. 

, available as part of Cloudsmith's advanced security, addresses what happens to cached packages when new vulnerabilities emerge that affect them. Data feeds from OSV.dev, GitHub Security Advisories, OpenSSF Malicious Packages, and EPSS update Cloudsmith's vulnerability database every few minutes. When new data hits the database, the platform runs a fresh match against cached artifacts. A match triggers policy evaluation immediately – packages get blocked or quarantined just as they would at ingestion. Because this is a matching process rather than a full scan, it is fast and efficient.

There is a compliance benefit here that's easy to overlook. When a package's security status changes and policy acts on it, that updated metadata is present at the next build. A build-time SBOM generated from that point reflects the current vulnerability picture automatically – no manual trigger required. For teams subject to the CRA's continuous documentation requirement, that means your SBOM stays current as a by-product of how the platform works.

 When a manufacturer becomes aware of an actively exploited vulnerability, the 24-hour clock starts. The obligation is not to discover exploitation within 24 hours – it is to report within 24 hours of becoming aware. That places the real burden on detection infrastructure.

 readiness in two ways: continuous monitoring that surfaces newly disclosed exploitation activity as soon as it is known, and an immutable audit trail that provides the evidence chain regulators will ask for. Every artifact event – upload, download, policy action, vulnerability flag – is recorded in 

 exportable via API. Hosted SBOMs are immediately retrievable and tied to the affected artifact version. Webhook and API notifications trigger automated incident workflows the moment a vulnerability flag occurs, giving security teams lead time before the 24-hour window closes.

The question Article 14 is really asking is not how fast you can file a report – it is whether your infrastructure would have made you aware at all. A defensible answer to that question requires continuous monitoring.

Secure supply chain and dependency control

 Organizations must design products to limit attack surfaces and protect data integrity. Manufacturers must exercise due diligence over every third-party and open-source component before it enters a product – including transitive dependencies in free and open-source software.

 Cloudsmith sits between developers and public registries, acting as the enforcement layer for every dependency request before it reaches a build. All external packages – npm, PyPI, Maven Central, Docker Hub, and other public registries covering 25+ language and OS formats – pass through Cloudsmith. The platform enriches each package with metadata, and evaluates them against your customized policies to clear or block each one before reaching developer machines or build pipelines.

Organizations define policies as code using 

. Cloudsmith applies policies consistently across every format and every team without manual enforcement. Define a policy once at the registry level and it runs everywhere. Three 

 types are most directly relevant to CRA requirements: cooldown policies, malicious package policies, and vulnerability policies. Promotion workflows gate movement between development environments, with policy enforcement, scanning, and provenance checks at each stage. Artifacts are 

 on upload and verified on download via Sigstore/Cosign, providing cryptographic provenance that directly addresses the CRA's authenticity requirements.

 Products must ensure protection from unauthorized access through appropriate control mechanisms. The same principle applies to the infrastructure used to build and distribute them – access must be controlled, least-privilege, and demonstrable to auditors.

 Cloudsmith provides granular role-based access control at the organization, team, and repository level. 

 via SAML with automatic group sync connects to enterprise identity providers including Okta and Azure AD. 

 provisioning and deprovisioning ensures access updates automatically when employees leave, eliminating stale credentials as an ongoing risk. OIDC support enables ephemeral, short-lived pipeline authentication, replacing long-lived static credentials in CI/CD pipelines.

 The CRA requires manufacturers to record and monitor relevant internal activity and maintain technical documentation available to market surveillance authorities for at least ten years, or the product's support period, whichever is longer. The CRA assumes manufacturers can produce a complete evidence trail on demand.

 Cloudsmith maintains full records of user, API, and system activity – uploads, downloads, deletions, policy changes, permission changes, and authentication actions – at both organization and repository levels. The platform provides four distinct log types relevant to CRA evidence requirements: audit logs, decision logs, client logs, and usage logs – all immutable and exportable to your SIEM in JSON or CSV. When regulators ask who accessed what, and when, Cloudsmith has the answer ready to produce.

 Article 14 reporting obligations take effect. Any manufacturer with products on the EU market must be operationally ready to detect actively exploited vulnerabilities and severe incidents, and report to ENISA within 24 hours of awareness.

 Full enforcement. All products with digital elements on the EU market must comply with the complete set of essential cybersecurity requirements, including conformity assessment and CE marking.

One critical point on scope: existing products are not exempt. A product already available to EU customers is subject to Article 14 reporting obligations from September 2026, regardless of when it was placed on the market.

The financial exposure attached to non-compliance is significant. Violations of the essential cybersecurity requirements, and of the obligations in Articles 13 and 14, carry fines of up to €15 million or 2.5% of total worldwide annual turnover for the preceding financial year, 

. Procedural violations carry fines of up to €10 million or 2% of global turnover. Beyond fines, market surveillance authorities can prohibit non-compliant products from the EU market and order recalls.

Organizations that start now can make deliberate decisions about tooling and policy architecture. With Cloudsmith, building a defensible compliance posture – deploying policy, generating SBOMs, establishing continuous monitoring, consolidating audit infrastructure – is an infrastructure project with a known deadline, not a crisis.

Next step: use the CRA readiness checklist

The requirements above map to specific operational gaps that most engineering organizations need to close before September 2026. The Cloudsmith CRA Readiness Checklist covers each major requirement area – SBOM generation, vulnerability management, reporting infrastructure, supply chain controls, access management, and audit trails – and helps you assess where your current setup stands.

EU CRA compliance: building a defensible posture with Cloudsmith

AI-generated code often emerges as the villain in conversations about AI and software supply chain security. Hallucinated package names. Slopsquatting attacks. Insecure patterns lifted from training data of unknown provenance. These are real problems, and security researchers are right to name them.

But for platform engineers and DevEx leads, that conversation is also a distraction. The governance failure that will actually bite your team isn't about what AI writes. It's about what AI pulls, how fast, and whether your stack can keep up.

The dependency problem is a throughput problem

Developers make explicit dependency decisions at human speed. They choose a package, consider the version, and pull it with enough friction that a review process can, in theory, keep pace. AI coding assistants don't operate this way. They suggest, scaffold, and resolve dependencies as a background function of doing their job – and they do it with enough confidence that their recommendations land without the friction that would normally prompt a second look.

The result isn't just more dependencies. It's a qualitatively different kind of ingestion: a continuous, high-volume stream of packages entering the environment at a speed and scale that outpaces any review process your team designed before AI tools entered the picture. The governance controls you put in place when developers were the bottleneck now face a different constraint entirely – your ability to evaluate what's coming in before it's already inside.

To be fair, AI tools inherited this problem; they didn't invent it. Developers reached for the 

, grabbing the newest version on the logic that newer releases patch known CVEs, so newer meant safer. It was a reasonable shortcut that quietly traded reproducibility and stability for the assumption that upstream maintainers had things under control. Teams tolerated it because the pace of ingestion was slow enough that the risk felt abstract. What AI coding assistants do is adopt that same default behavior and execute it at a scale no human developer could match – across multiple ecosystems, for every file in a scaffold, without the occasional pause that made a developer reconsider. The mental model was already loose. AI just removed the friction that kept the consequences manageable.

 found that nearly 20% of packages recommended by large language models didn't exist in any public registry. More troubling: 43% of those hallucinated packages appeared repeatedly across multiple prompts. This is a pattern predictable enough that a malicious actor could register those packages in advance and wait for a developer to pull. This is the 

 attack surface, and it expands in direct proportion to AI adoption.

The signal from the field matches the research. One engineering team, already running their artifact repository significantly beyond its designed capacity, named AI-driven dependency explosion as the risk they were actively trying to get ahead of. Not a breach. Not a named vulnerability. The sheer volume of what AI coding tools would pull into their environment as adoption scaled. Their infrastructure had held up under human-speed development. AI-speed ingestion hadn't fully arrived yet – and they were already worried.

That's the right instinct. For teams with meaningful AI coding tool adoption, the governance problem is already compounding.

Three ways your current governance breaks at AI speed

The failure isn't dramatic and doesn't announce itself with an incident. It accumulates across three specific breakdowns, each one a consequence of governance controls calibrated for a different kind of throughput.

Volume creates an attack surface nobody owns.

 More packages mean more CVE exposure, more policy exceptions, and more surface area for a malicious or compromised package to hide inside. When dependency ingestion was slow and deliberate, a team could maintain a reasonable mental model of what lived in their environment. AI-assisted development eliminates that. Packages accumulate faster than any manual review can track, and exceptions that were once edge cases become business as usual.

Endor Labs 2025 State of Dependency Management Report

 found that only 1 in 5 dependency versions AI coding assistants recommended were safe to use – containing neither hallucinations nor known vulnerabilities. The reality of the situation is that with AI-generated code, more packages enter your environment than your current controls can evaluate.

Velocity breaks the timing assumptions your controls depend on.

 Most teams have security controls that activate at the build: scanning that runs after a package enters the environment, policies that evaluate after the pull happens. At human-speed ingestion, the gap between a package entering and a build running was small enough to manage. At AI speed, it isn't. A malicious or compromised package can move from first pull to build artifact before any downstream control flags it. The window that periodic scanning assumed would always exist has closed.

Opacity removes the human review that your policy controls assumed.

 Governance frameworks rest on an implicit assumption: a developer made a deliberate choice to pull each dependency, and that choice is reviewable and auditable. That assumption doesn't hold with AI coding tools. Ask a developer why version 2.3.1 of a specific package is in their project, and they may have no clear answer – the assistant chose it, they accepted the suggestion, and the reasoning never surfaced. The provenance trail that would normally anchor a trust decision is absent. Policy controls that gate explicit human decisions don't account for the implicit decisions AI tools make on a developer's behalf.

What governance built for AI speed actually requires

The three failure modes above share a common root: governance controls calibrated for human-speed dependency management running against AI-speed ingestion. The fix isn't better scanning or more thorough reviews. It's a different architecture for enforcement – one that matches the actual throughput of how your team now works.

Three requirements follow directly from the failure modes.

Enforcement has to happen at the point of first pull – not at the build, not post-merge. The moment a package arrives as a request is the only moment you can intercept it before it enters the environment. Every control that activates later operates on a package that's already inside. Quarantine and block capabilities that evaluate against your policies at request time close the gap that build-time scanning leaves open by design.

Re-evaluation has to be continuous, not periodic. Threat intelligence doesn't freeze when your weekly scan finishes. A package that passes on Tuesday may be flagged by Wednesday – because researchers publish a new CVE, because a maintainer account falls to credential stuffing, because a malicious version propagates through transitive dependencies before anyone notices. Continuous re-evaluation against evolving threat intelligence catches what point-in-time scanning cannot.

Coverage has to span all package formats, not just the ones your team uses most. AI coding tools pull across ecosystems without discrimination. A governance layer that covers npm but not PyPI, or Python but not Go, carries a structural gap that AI-assisted development will find. Unified enforcement across all formats – packages, containers, machine learning models – is the only way to apply consistent policy across the full surface area AI actually introduces.

Cloudsmith enforces policy at the point of first pull: when an open source package arrives as a request, it evaluates against your policies before it reaches the developer. Packages that have already cleared your policies deliver immediately; new packages clear checks before delivery. Artifacts in the platform re-evaluate continuously – as new threat intelligence arrives, and when policies change. With support for 30+ package formats in multi-format repositories, that enforcement applies across the full surface area AI-assisted development introduces – not a curated subset of it.

This isn't the argument that Cloudsmith stops AI from writing bad code. Code quality is a separate problem with its own tooling. The argument is more specific: Cloudsmith gives your governance controls the throughput and continuity they need to keep pace with AI-speed development. The controls your team built weren't wrong. They were calibrated for a volume and velocity that no longer reflects how your developers actually work.

The teams already feeling this problem are the ones with the highest AI coding tool adoption. They're a leading indicator, not an outlier. As AI-assisted development becomes the default, dependency ingestion volume scales with it. Governance controls that hold today may not hold next quarter.

The teams that get ahead of this don't run better scans at the build. They move enforcement earlier, automate re-evaluation, and put a platform in place that can handle what AI-speed development actually generates.

If your team has adopted AI coding tools and you haven't yet pressure-tested your artifact governance against the throughput they produce, that's the conversation worth having now.

Book a demo to get the conversation started and to see how Cloudsmith enforces policy at the point of pull.

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

A time-based hold that stops newly published packages from reaching your build until they've been evaluated against the latest threat intelligence. Trust earned, not assumed.

What is a package cooldown policy?

Cooldown is proactive; it holds every new package during its highest-risk window. Quarantine is reactive, triggered only after a specific threat is identified. You need both.

What is the difference between a cooldown policy and a quarantine?

Research shows that a 7-day policy blocks the majority of supply chain attacks, but the right window depends on your risk tolerance and build velocity. Configure it, don't guess it.

How long should a dependency cooldown period last?

Rarely. Most developers aren't pulling packages on release day anyway; by the time they need it, the cooldown period already ended. The friction is theoretical for most teams.

Do package cooldown policies slow down developer workflows?

Scanning checks what's known today. A cooldown buys time for tomorrow's intelligence to catch what today's scan missed. One without the other leaves a gap.

What is the difference between a package cooldown and scanning?

Frequently asked questions

Many engineering teams treat PyPI, npm, Maven Central, and other upstream registries as trustworthy by default. They're not. These registries have no admission controls, no malware guarantees, and no obligation to notify downstream consumers when a vulnerability emerges for a previously clean package. While they offer convenience and availability, teams need to be careful not to conflate ease with safety.

Every time a developer pulls a dependency, they’re making a trust decision. But who vets that trust decision, especially with transitive dependencies? What often happens is the package enters the environment unchecked, moves into the build, gets stored in an artifact repo, and is assumed safe indefinitely. No one explicitly decided to trust it. It just arrived.

This is the structural vulnerability in modern software supply chains and better scanning alone won’t close the gap. The problem isn't just that teams occasionally pull bad packages. It's that teams delegate the decision to trust anything at all to the registry, with no policy enforcement at the moment that actually matters.

What a package cooldown policy is, and how it differs from quarantine

Why the first hours after a new package is published is the highest-risk window for software supply chain security

Real-world supply chain attacks (Shai-Hulud, Axios, and LiteLLM) that dependency cooldowns could have mitigated

How to implement package cooldown policies without adding friction for developers

What a mature open-source dependency security posture actually looks like in practice

A package cooldown policy is a time-based software supply chain security control that places newly published packages, or new versions of existing packages, into a temporary holding state before they can be used. Unlike a one-time scan, a dependency cooldown creates a structured window for intelligence to catch up to new threats.

The cooldown period: A governance posture, not a product feature

 period is one response to this problem gaining traction in DevSecOps.

The concept is straightforward. A newly published package, or a new version of an existing package, doesn't go straight to your development environment. It enters a controlled holding state for a defined period, where it undergoes continuous evaluation against evolving threat intelligence before any build can consume it. Ideally, teams can set the length of that window in customizable policies, calibrated to the risk window for their organization and/or a given ecosystem.

A cooldown is distinct from quarantine, which is an open-ended hold triggered by a specific CVE or malware indicator on a known-bad package. A cooldown period is time-based and preventive. The cooldown policy exists because the highest-risk window for a newly published package is in the first few days, when a compromised or malicious package is most likely to surface and when threat intelligence is still trying to catch up to it.

Enforced intake holds are standard practice in regulated industries, like pharmaceuticals, food manufacturing, and medical devices. You don't distribute what you haven't cleared. The software industry is arriving at the same conclusion, just later, under more duress (thanks to AI), and with considerably more attack surface.

The difference between a cooldown policy and the vague notion of "we'll scan before we use it" is precision. Cooldown policies are written as code. Teams define the threshold; the scope – which package formats, which registries, which versions, etc. – and what happens when a package triggers the policy: hold it, tag it for review, block it with a message. The parameters are custom because the risk tolerance, regulatory context, and build velocity are different for every organization.

Why package cooldown policies are critical for software supply chain security in 2026

How supply chain attacks work, and where dependency cooldowns stop them

 campaign made the failure mode visible at scale.

Shai-Hulud is a self-replicating worm that spread through compromised npm developer accounts, inserting malicious code into legitimate packages belonging to those developers. The mechanism that Shai-Hulud used is what matters here: it didn't introduce obviously malicious 

 packages. It compromised packages that were previously legitimate, with real publishing histories and real downstream users. Those packages would have passed a point-in-time scan at first pull.

The second wave, detected in November 2025, escalated the technique – executing during the pre-install phase rather than post-install, which moved execution ahead of most pipeline scanning controls. Within hours of detection, the campaign compromised over 700 npm packages, created more than 27,000 malicious GitHub repositories, and exposed approximately 14,000 secrets across 487 organizations.

A cooldown period, combined with continuous re-evaluation against new threat intelligence, changes the exposure window. Not because it catches everything at intake – it doesn't – but because the hold creates a window in which intelligence can catch up. A package that passed on Monday may be flagged by Wednesday. Without a cooldown policy, your build already consumed it on Monday.

Axios, LiteLLM, and the case for supply chain attack prevention before ingestion

 ran the same playbook on a package with an even larger blast radius. Axios is the dominant HTTP client library in the JavaScript ecosystem – present in roughly 

 of cloud and code environments and downloaded approximately 100 million times per week. The attacker compromised the npm account of the project's primary maintainer and published two backdoored versions within a 39-minute window. Both versions introduced a hidden dependency that deployed a cross-platform remote access trojan to macOS, Windows, and Linux, targeting developer secrets, cloud credentials, SSH keys, and CI/CD pipeline tokens. The malicious versions were live for roughly three hours. Due to the short exposure window but high prevalence of axios, even limited availability resulted in measurable execution across environments.

, compromised by a separate threat group in the same period, demonstrated what that blast radius looks like in the AI stack specifically. LiteLLM is a unified proxy layer used to route requests across over 100 LLM providers, like OpenAI, Anthropic, AWS Bedrock, Google Vertex, etc. Compromising LiteLLM didn't just expose a build environment, it could provide attackers with credentials that span an organization's entire AI infrastructure. The attack reached LiteLLM indirectly, through another attack event against Trivy, a security scanner that LiteLLM's CI/CD pipeline trusted. The attacker poisoned that trusted dependency, harvested PyPI publishing credentials through it, and published malicious versions from there.

The vector changes across every one of these campaigns. The tactic – compromise something the ecosystem already trusts and weaponize dependency resolution – does not. The scope, speed, and cross-registry reach of these attacks show the limits of manual review in the Age of AI. When attackers can weaponize 100 million weekly downloads inside a three-hour window, the response requires automation and enforcement at the point of pull.

Do package cooldown policies slow down developers? Addressing the pushback

Security teams that propose cooldown policies consistently encounter the same pushback: they add delays to developer workflows, create friction in the build process, and slow down teams already under delivery pressure.

These are legitimate concerns from engineering teams, even when they buy into a tighter risk posture. Fortunately, the right tooling provides a real solution.

The goal of a cooldown policy isn't to hard-stop every new dependency. It's to introduce a controlled hold with a clear, automated release path. Done correctly, a cooldown policy is largely invisible to developers working with packages that already cleared policy. The friction targets new packages in their highest-risk window, not on the entirety of the dependency graph on every build. For packages that pass continuously without incident, the cooldown period is a one-time delay on first use.

There's also a practical counterargument that often goes unmade: most engineering teams aren't looking to upgrade packages on zero-day. Unless teams configure a pipeline to pull the latest version automatically – an explicit choice, not a universal default – a developer may not know an update is available for days or weeks after publication. For those teams, a cooldown period introduces no meaningful delay. The package sits in its hold state and when it clears policy it is available when the team is ready to consume it. In this case, the friction becomes largely theoretical.

The objection to cooldown policies becomes harder to sustain when considering the alternative. The delay from a cooldown period is likely hours or days when first pulling a new package. Compare that to the blast radius from a compromised dependency that entered your environment unchecked. Teams measure the impact in incident response hours, remediation scope, and, increasingly, regulatory exposure under compliance frameworks, like DORA, CRA, and SOC 2, that treat supply chain controls as auditable requirements, not optional best practices.

The friction argument also assumes that the 

 alternative is speed. It isn't. Uncertainty is a significant factor as well. A supply chain where teams can answer the "are we affected?" question when a CVE drops because they tracked everything on entry mitigates the uncertainty factor drastically.

Building a mature software supply chain governance posture

Cooldown policies are one layer in an enforcement stack, not a standalone fix. A mature posture has four components:

 Evaluate every package against policy before it reaches the developer – not after the build, not in a separate scanning tool downstream, but at the moment the request occurs. This is where cooldown and quarantine policies activate.

Today’s threat intelligence is different from that of last week so packages need on-going re-evaluation to stay up-to-date. CVEs don't announce themselves in advance. Malware indicators evolve. The assumption that a package is safe because it passed once is precisely the assumption that Shai-Hulud exploited.

 Context matters. Block with a message. Hold with a tag. Allow with a warning. Developers need clear, actionable answers – not a silent failure that sends them looking for a workaround that bypasses your controls entirely.

Unified visibility across formats and registries:

 "Are we affected?" needs a fast, authoritative answer. That's only possible if there's a single source of truth for what's in the environment and what state it's in based on policy.

Implementing package cooldown policies at scale with Cloudsmith

The conceptual case for cooldown periods isn't difficult to make to a CISO. The operational challenge is implementing them in a way that doesn't break builds, generate alert fatigue, or require a dedicated team to manage exceptions.

This is where the underlying platform matters. Cloudsmith prioritizes enforcement. It evaluates packages against your policies at the point of first pull, before it reaches the environment or developer. Cooldown policies, quarantine actions, and blocking responses are configurable and written as code, giving security teams precise control over parameters without creating blanket friction for engineering.

The critical piece is what happens after intake: continuous re-evaluation. A cooldown period without ongoing re-evaluation is still a point-in-time scan – just one with a delay attached. Cloudsmith’s vulnerability data sources update multiple times per hour. The platform uses a lightweight matching process to associate new vulnerability data with existing packages in your registry continuously. When the threat landscape changes for one of your packages, this triggers your policies to run and take action on the impacted package(s). That combination – policy enforcement at intake plus continuous monitoring after the fact – is what narrows the exposure window.

For organizations with DORA, CRA, or SOC 2 obligations, this also produces the audit trail that auditors will ask for: a traceable record of what entered the environment, when, under what policy conditions, and whether it is still safe.

The gate doesn't protect you if it only checks once. Supply chain governance is not a point-in-time moment – it's a discipline. Cooldown periods are one piece of that discipline: a concrete, policy-driven practice that treats trust as something that has to be earned constantly, not assumed at the point of first pull.

Ready to implement package cooldown policies and close the gaps in your software supply chain security?


Whether you're building the internal case or actively evaluating tooling, Cloudsmith enforces cooldowns automatically, across formats, registries, and teams from day one. 

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

The threat research team at Socket have today identified over 84 malicious 

 package artifacts across 42 packages in the 

 has over 12 million weekly downloads - giving you an idea of the global impact of these software dependencies. 

 have attributed the behaviour to an ongoing TeamPCP supply chain attack called “

”. The self-propagating malware, which has been seen in other supply chain attacks, spreads by stealing CI/CD secrets.

Thankfully all of these compromised packages were identified only minutes after the packages were published. The problem for the industry is whether organisations had inadvertently consumed those malicious software artifacts before they were removed from the 

 upstream registry. As always a way that 

 registry users can stay ahead of this type of attack is by defining a 

 registry. In Cloudsmith, we solve this problem through automated 

. Cloudsmith also tracks the malicious packages under the 

Cloudsmith Blog

Inside the Mastra npm supply chain attack

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

The Miasma worm's path of destruction

Authenticate to Cloudsmith with your Google Cloud identity

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

From trusted artifact to controlled deployment: Cloudsmith and Octopus Deploy

Cloud Native Digest - May 2026

Performance matters: How infrastructure impacts CI/CD

Closing the enforcement gap: Why visibility isn’t enough for supply chain security

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

EU CRA compliance: building a defensible posture with Cloudsmith

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