The News
Cloudsmith has released its Confidence Gap Report, which examines how engineering teams perceive their readiness against software supply chain attacks versus what their actual security practices reveal. The headline finding is stark: 73% of teams believe their security tooling can stop an install-time attack before a security advisory is published, yet only 38% scan dependencies before those packages enter their environment. More than half (54%) only act once malicious code has already reached their systems, and just 24% automatically enforce cooldown periods for new packages.
Analyst Take
The confidence-action gap is the real vulnerability
The Cloudsmith report’s title is apt. A confidence gap isn’t a knowledge problem or a tooling problem in isolation. It’s a risk-posture problem. When 73% of teams believe they’re protected against install-time attacks but fewer than 4 in 10 are actually scanning dependencies at the point of entry, that gap represents a window of exposure that threat actors are actively exploiting. Install-time attacks, by design, execute malicious code the moment a package is pulled into a build environment, before any static analysis or runtime monitoring can catch it. Believing you’re safe and being safe are two very different things.
This matters especially for government and regulated-sector development teams, where the consequences of a supply chain compromise extend beyond incident response costs. ECI Research’s Google GovTech Survey found that 48.5% of respondents selected “Automated Software Composition Analysis (SCA) scanners gate our builds” when asked how their organization validates open-source software packages. That’s a strong signal of institutional intent. But gating builds with SCA after a package enters the environment is not the same as blocking malicious packages at the point of ingestion. The Cloudsmith data suggests those two practices are being conflated by practitioners who should know better.
Why “scan later” is structurally insufficient
The 54% of teams that only act once malicious code has reached their systems are operating on a model designed for a different threat landscape. Traditional vulnerability management assumed that adversaries would exploit known weaknesses in packages already in production. That model produced a feedback loop: CVE published, advisory issued, patch applied. Install-time attacks break that loop entirely. There is no advisory before the attack. The package behaves correctly until it doesn’t, and the damage occurs at a layer most CI/CD pipelines never inspect.
This is compounded by the low adoption of proactive controls like new-package cooldown periods. Only 24% of teams enforce these automatically, which means the majority are implicitly trusting freshly published packages despite the well-documented pattern of typosquatting and dependency confusion attacks targeting the brief window before community scrutiny catches a bad actor. For developers, the operational fix is architectural: dependency ingestion needs to be treated as a security boundary, not a convenience layer. Private registries with policy enforcement at the point of pull are the relevant control plane here, not just downstream scanning.
What procurement and leadership need to hear
For ITDMs, the Cloudsmith report is a budget conversation dressed up as a technical briefing. The ECI Research Google GovTech Survey found that 29.2% of respondents identified “High maintenance costs absorbing budget meant for new development” as the primary operational risk their legacy core systems present. Supply chain compromises accelerate exactly that dynamic: incident response, forensic review, and recertification after a compromise redirect budget that was earmarked for modernization. Preventing the compromise is cheaper than remediating it.
There’s also an organizational friction angle worth examining. According to the ECI Research Google GovTech Survey, 56.0% of respondents said “Frequently (Approved vendor lists lack modern developer platforms)” when asked how often procurement requirements force engineering teams to use suboptimal developer tools. If procurement constraints are already limiting tool choices, teams that want to adopt a private registry with proactive dependency vetting face an additional hurdle: getting that capability approved and funded through processes that may not yet recognize it as a security control rather than a developer convenience.
Looking Ahead
Cloudsmith’s report is arriving at a moment when software supply chain security is transitioning from a niche concern to a board-level risk category. The CISA Secure by Design initiative, NIST SSDF requirements, and growing SBOM mandates are all pushing in the same direction: treat the software supply chain as an attack surface that requires active defense, not passive scanning. Vendors that can credibly claim to close the confidence-action gap, specifically by enforcing policy at the point of dependency ingestion rather than downstream, are positioned well in a market where compliance pressure and threat sophistication are rising simultaneously.
The near-term pressure point is KubeCon and the broader cloud-native community, where container-based workflows make dependency management both more automated and more opaque. Engineering teams that have containerized their build processes often have less visibility into what enters their images than they had with traditional package managers. Cloudsmith’s positioning around pre-ingestion controls is directly relevant to that audience. Over the next 12–24 months, expect to see private registry capabilities with active policy enforcement become a baseline expectation in enterprise and government procurement checklists, rather than a differentiator.
Stay Ahead of Application Development Trends
Get weekly analyst insights, research notes, event coverage, and AppDevANGLE updates delivered directly to your inbox.
Subscribe for Weekly Insights
Join technology leaders, practitioners, and GTM teams following the trends shaping modern software delivery.
Looking for deeper research access?
Explore ECI Research reports, survey insights, and market analysis through the ECI Research Portal.
