Cloudsmith warns - most teams won't meet the EU Cyber Resilience Act's software supply chain deadline

Cloudsmith arrived at KubeCon with an interesting piece of survey data. Only one in four engineering teams automatically generates and verifies software bills of materials – SBOMs – at every build. For the remaining three-quarters, SBOMs exist, but they are generated manually, reactively, or only when an auditor asks. This came from a survey of 505 developers, engineers, and DevOps leads, published as the company's 2026 Artifact Management Report which was released in full last week. 

This matters because of what an SBOM actually is – an ingredient list for a piece of software, recording every dependency, library, and third-party component that went into a build in a machine-readable format. Under the Cyber Resilience Act (CRA), organizations selling products with digital elements in the EU will be required to report actively exploited vulnerabilities within 24 hours of discovery, with a full assessment due within 72 hours. Teams that cannot rapidly trace their artifact provenance – knowing exactly which versions of which dependencies exist in which production environments – will not be able to meet those windows. The report found that nearly three in four respondents said they would struggle to produce a complete artifact audit in an unannounced compliance check.

Alison Sickelka, VP of Product at Cloudsmith, summed up the underlying dynamic at the company's KubeCon announcement: 

Enterprises are drowning in CVEs [common vulnerabilities and exposures], with a surplus of data but no centralized control plane to manage risk. The disconnect between threat intelligence and active enforcement is widening as actors weaponize open-source registries to bypass traditional defenses. Automating governance is no longer a 'nice to have'; it is the only way to build a defensible software supply chain in an AI-accelerated world.

Security is changing who knocks on the door

During the event I sat down with Sickelka and Nigel Douglas, Cloudsmith's Head of Developer Relations, to get into the details. Douglas described what has changed in enterprise procurement over the past six months: 

We have organizations that came to us originally to help them with scale, performance and reliability. In the past six months, that conversation has extended to say, once we get migrated to Cloudsmith, how can you also help us secure our software supply chain? We also saw in Q4 of last year, security AppSec teams bringing us into organizations, and that's a change.

Historically, artifact management has been a platform engineering conversation. Application security teams leading procurement discussions is a meaningful shift – it reflects a recognition that the software supply chain is not a developer tooling concern but an organizational risk. Douglas added the regulatory angle: 

Especially here in Europe, the Cyber Resilience Act is coming into force at the end of this year. What we're seeing is the CRA mandating that you need to have software bill of materials – and that's the only way to say, I can prove that I have trust to say this is what we are distributing to end users.

The hazards of "slopsquatting"

The one-in-four SBOM statistic sounds alarming, but Douglas offered a useful explanation of how it gets that low. An organization might generate SBOMs on its Docker containers but not on its Python packages, or have coverage on supply chain-hardened images but gaps on the transitive dependencies inside them. A Docker container is, as Douglas put it, "really just a wrapper of all those software dependencies" – meaning a top-level SBOM without coverage of what is inside it gives a false sense of completeness.

AI-generated code compounds this. Cloudsmith's report found that 93% of organizations now use AI to accelerate development. AI coding tools pull in dependencies without the contextual judgment a developer would apply, expanding the attack surface in ways that are difficult to monitor without automation. The report identified "slopsquatting" as a specific and now-named category of risk: AI hallucinated package names that bad actors have since registered with malicious payloads, waiting to be consumed by development tools that take AI suggestions at face value.

Cloudsmith's answer is to make the artifact management layer – the system through which packages enter a build environment – the point of enforcement rather than the point of audit. Most security tooling identifies risks that have already entered your environment. Cloudsmith's approach is designed to prevent high-risk components reaching the build at all, using automated policies evaluated at ingestion.

The mechanism is Cloudsmith's policy engine, built on Open Policy Agent (OPA). New features announced at KubeCon include cool-down periods that quarantine recently published packages to allow the security community time to identify malicious payloads; exploitability prioritization using EPSS (Exploit Prediction Scoring System) scores to focus blocking on what is actually being exploited in the wild, instead of flagging everything with a high CVSS severity rating; deep SBOM inspection covering transitive dependencies and license compliance; and custom developer-facing error messages that explain why a package was blocked and what the remediation path is.

Sickelka elaborated on how that shift changes the dynamics in relationships between security and developers: 

You are bringing security closer to where developers are. And that's been a lot of our conversation around our policy manager – how do we implement these policies in a way that doesn't slow down developers, but helps us be secure?

Douglas addressed the friction concern: 

A vulnerability that got disclosed that was never exploited in the wild – being able to use policy as a way to say, is this in the KEV index, which is CISA's Known Exploited Vulnerabilities list? If it's not known to be exploited, it has a very low likelihood of exploitation. Let's make those better informed decisions so that developers aren't just getting stumbled on every irrelevant CVE, and rather, we're blocking the ones that actually are likely to cause problems in our environment.

For teams new to artifact governance, Cloudsmith embeds pre-built policy templates in the product interface – covering malware blocking, license compliance, and newly published package quarantine – so the starting point is a button click rather than writing policy code from scratch. Douglas noted that AI tooling has also shortened the learning curve: 

Now with AI, we see people building custom GPTs around our schema – it's very easy to just prompt ChatGPT, Gemini, or Claude and say, could you manufacture this policy to solve this problem? The efficacy of these policies is quite high now.

What the journey looks like

ConstructConnect, a software company serving the construction industry, offered a reference point for what improvement looks like in practice. Rich Dammkoehler, VP of Architecture and Governance at ConstructConnect, described the progression: 

The most important capability for us is the ability to quarantine and block vulnerable artifacts. Ease of access to vulnerability information – and the ability to act on it – has been the biggest change for us. Our internal governance scores continue to improve, and Cloudsmith has been a major contributor to that. We're a stone's throw away from having zero high or critical vulnerabilities in our supply chain.

On where the platform is headed, Douglas pointed to format coverage as the defining 12-month challenge. OCI – the Open Container Initiative standard – consolidated container formats across Docker and containerd. MCP – Model Context Protocol, now under the Linux Foundation – is emerging as a distribution standard for AI agent tooling. Hugging Face model hosting has already been added. The direction is toward Cloudsmith becoming the artifact registry for the full AI-era development stack, with the same governance policies applied consistently across all format types.

My take

The CRA's September 2026 enforcement date is close enough that organizations without automated SBOM generation and artifact governance are dealing with a calendar problem, not a theoretical one. The GDPR parallel Douglas drew – where compliance only becomes urgent once enforcement is actually imminent – is probably going to play out the same way here.

Cloudsmith is pitching to move the enforcement point upstream so that decisions about whether a package is acceptable are made before it enters a developer's environment, not after it has already landed. Whether organizations will invest time and effort in proactive enforcement before an incident makes it unavoidable, or whether the compliance deadline will be the catalyst is another matter. Cloudsmith's own report suggests the latter is more likely for most of the market – and the window to get ahead of it is short.