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

, you're not just installing the requested package. You're also pulling in every transitive dependency in the package’s dependency graph. Many of these are packages you didn’t consciously choose, from maintainers you don’t know, including code that executes automatically before any build pipeline step runs. An average React application can pull in over 900 dependencies, most of which arrive automatically, not by selective choice.

That's the architecture of modern software development. Reusing open source packages at scale makes it possible to ship complex applications that meet the high expectation of users without rebuilding foundational infrastructure from scratch. But the security model currently in use wasn’t designed to address the exposures created by reusing open source packages.

A leaked npm publish key makes that exposure visible. The credential isn't the problem, rather it's what reveals the gap between where organizations believe enforcement happens and where it actually happens.

The evolving nature of software development and the rise of security supply chain attacks changed who's paying attention to this gap. Security teams don't need to experience an incident to start conversations around their supply chain. The 

-style worms, and near-misses reported by high-profile engineering organizations present a threat environment that makes industry signals a catalyst for change. So, while the trigger is different, the gap is the same.

It may seem like a leaked npm key is a credential rotation problem and not a supply chain problem. Here’s how we get from key to attack.

No matter how a publish key gets exposed, whether that’s in a CI log, a repository that was briefly public, or a secret rotation that wasn't fully completed, that key grants write access to one or more packages on the public npm registry. Write access means the ability to publish a new version.

The attacker publishes a version that looks legitimate: same package name, incremented version number, valid metadata. In the axios compromise, the malicious versions were tagged 

. Consumers pulling the latest version get the malicious one automatically on their next install.

Here's where the transitive dependency becomes the attack surface. Most downstream consumers aren't pulling the compromised package directly. They're pulling a framework that depends on a tool that depends on the package. No developer makes a conscious choice to install it. The package manager resolves the dependency graph and pulls everything in. In the axios case, the attackers added a new software dependency named 

 which serves as a legitimate encryption and hashing utility. The associated npm 

 script runs automatically during installation. The malicious code executed before any build step, before any scanner ran, before anyone knew the package arrived.

By the time a developer or CI job completes 

, attack code can exfiltrate credentials, establish remote access, and take steps to avoid detection.

The credential leak opened the door. The artifact pipeline, specifically, the absence of an interception point between a package being requested and when the package is executed. This is precisely where the adversary makes an impact.

Investing in security tooling can create a sense of false confidence. Especially as organizations grow, adapting to nuanced changes in the software development process at scale can be challenging. So, this confidence makes sense: they have application security scanning, CI/CD pipeline scanning, and endpoint detection. These are good tools, but where they sit in the timeline is the problem.

 analyze the code your team wrote. SAST tools like Checkmarx, Veracode, Snyk, and Semgrep, do serious work and find real vulnerabilities. They analyze source code before the build runs. The SAST tool already finished its pass by the time your build system is pulling packages from npm. It has no visibility into the dependency tree. So, a compromised transitive dependency gets pulled in, its installation script executes, and the SAST report comes back clean because the SAST tool never saw the dependency tree.

 runs after the package manager pulls the requested packages. In npm, 

 scripts run during download, not during execution. When the malicious code runs at install time and your pipeline scanner runs afterward, then it's checking the pool for contaminants after the swimmers have been in it for an hour. The tool works correctly and you get a clean report, but that’s because the timing is wrong once again. The attacker already has your credentials.

 is excellent at detecting anomalous behavior once code is running, like suspicious network traffic, unusual file operations, and credential access patterns. CrowdStrike, your EDR tooling, etc., catch these things, but they're reactive by design. By the time your endpoint detection notices the suspicious outbound connection, the credentials are already gone. Detection at minute three doesn't help much when the exfiltration happened at minute one.

This is the architecture of the standard security model, and it has a structural blind spot: every control point operates after ingestion. Code downloads and executes before any of those controls see it. That's not a problem you solve by adding another scanner at a later stage in the same pipeline. Adding more tooling downstream of the gap doesn't close the gap.

Consider a fire department. They detect and respond to fires. We need fire departments. But we also need a fire code that prevents fires from starting. The fire code is embedded in the design and operation of buildings; it’s invisible because it's foundational. Fire response and prevention are different things, and both matter. The difference is that only one of them stops the problem before it starts.

The artifact registry functions like the fire code. It’s where that kind of foundational control can actually live for software supply chains. It sits at the boundary between untrusted software, like everything on the public internet, and your trusted environment. Every package your developers and build systems consume passes through it. That makes it the one place in the entire delivery pipeline where enforcement can happen before code downloads, installation scripts run, or anything executes.

Enforcement at the trust boundary changes the attack timeline entirely. A compromised version of a package previously marked as safe gets evaluated against policy before it enters the environment, so doesn’t reach your environment at all. Policy stops being advisory ("

this package is risky, here's a dashboard entry

") and instead becomes an automated enforcement control ("

this package is not entering this environment for this reason

A few things become possible at the artifact layer that aren't possible anywhere downstream:

 A package that was clean when it arrived six months ago and has a new CVE or a threat intelligence flag today gets re-evaluated without manual action. Build-time scanning doesn't revisit what's already in the environment, but an enforcement layer at ingestion can.

 Most modern supply chain attacks don't begin with a known vulnerability. They begin with compromised open source maintainers. These threats don't appear in a common vulnerabilities feed and instead rely on scanning the open source upstream registries (PyPI, npm, Packagist, etc.) for unwanted code changes (

) using a database like OSV.dev. . This data is actionable at the artifact layer, before the package is introduced into any developer builds.

An audit trail that answers the incident question.

" should be answerable from a single system of record. An enforcement layer at ingestion is that record – what entered, when, under what policy state, with what provenance. Not a multi-tool investigation across disconnected logs.

The instinctive response to a supply chain incident is to add tooling. Buy the additional security module. Enable scanning at another pipeline stage. Each addition addresses a visible gap and each one is a reasonable decision in isolation.

The accumulated result is a different problem: a patchwork of controls with seams between them. Each tool has its own configuration requirements, its own maintenance cycle, its own expertise to operate correctly. The security stack grows in response to incidents until nobody fully understands how it fits together or what to do when something falls through a seam. The operational burden of the stack becomes its own risk.

This pattern shows up consistently in teams that started with a repository and added security on top: fragmented coverage, high maintenance overhead, and a circumvention problem. When authentication against an internal proxy creates enough friction, developers route around it and pull directly from the public registry. A control that gets bypassed at scale is worse than no control because it creates the appearance of coverage while the actual exposure grows.

The architectural distinction matters here. Controls built into the artifact layer from the foundation behave differently from controls added on top of a repository designed for something else. The former is simply infrastructure while the latter is configuration layered on infrastructure with a different original purpose. Those are two different approaches that behave differently under pressure.

Teams choosing a platform built for supply chain security describe making that choice explicitly to avoid assembling the capability from components. The assembly works, until it doesn't. The seams are where attacks succeed.

The leaked npm key is almost never the actual exposure. It's the event that made the exposure visible.

The supply chain incident – the credential, the flagged package, the build that broke in a way nobody could explain quickly – functions as a diagnostic. It reveals where enforcement actually lives in the pipeline, which is almost always different from where teams assumed it lived.

The useful question that comes out of the diagnostic: where in your pipeline does enforcement actually happen? Does it occur before packages enter the environment, or after?

For most organizations running standard CI/CD scanning on top of a repository, the answer is after. The follow-on question is what it would take to move it upstream. The teams that have made that move describe the same outcome: not more tooling on top of the existing architecture, but a different architectural starting point. A platform where enforcement at the boundary is the foundation, not an addition.

Cloudsmith is a cloud-native artifact management platform that enforces policy at the point of ingestion – before packages enter your environment – and provides continuous re-evaluation, full audit logging, and developer-transparent controls across every package format your teams use.See how Cloudsmith protects your software supply chain from dependency attacks. 

Schedule a conversation to discuss your tech stack today

Jason Myers

Technical Content Marketer

Dependency attacks start before your scanner runs

 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

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

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

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

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

Cooldown policies

The primary target for cooldown policies are 

packages your Cloudsmith workspace has not cached yet.

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

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

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

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

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

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

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

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

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

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

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

The key variables in the default template are 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cloudsmith: Artifact trust before deployment

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

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

This answers the question every pipeline needs to resolve: 

Is this artifact safe and approved to deploy?

Octopus Deploy: Controlled delivery from build to production

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

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

This answers the other question your pipeline needs to resolve: 

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

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

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

End-to-end traceability and audit-ready evidence

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

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

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

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

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

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

From trusted artifact to controlled deployment: Cloudsmith and Octopus Deploy

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

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

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

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

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

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

The answer depends on your artifact infrastructure.

Where fragmented artifact practices break down

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

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

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

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

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

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

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

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

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

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

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

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

The deadline is a planning horizon, not a countdown

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

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

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

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

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

If your engineering 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 Blog

Dependency attacks start before your scanner runs

Cloudsmith credentials are now detectable by GitHub Secret Scanning

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

From trusted artifact to controlled deployment: Cloudsmith and Octopus Deploy

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.

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

Cloudsmith Broadcasts: Distribute software on your own terms

Performance matters: How infrastructure impacts CI/CD

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