Docker’s 2026 Supply Chain Survey Turns AI Adoption Into a Developer Problem

A new industry survey is putting a number on something security teams have suspected for a while: artificial intelligence has become the single biggest perceived threat to the software supply chain, edging out third-party code and open source dependencies. The findings come from a 2026 report from analyst firm Omdia, sponsored by Docker, based on responses from 400 IT, cybersecurity, and application security professionals across North America, surveyed in February 2026. Docker Chief Security Officer Mark Lechner summarized the results in an August 4 blog post titled “The Software Supply Chain Is Under Siege,” and the numbers describe an industry that knows it has a problem but has not settled who should own the fix.

AI Is Now the Top-Ranked Supply Chain Risk

Asked to rank their biggest software supply chain risks, respondents put AI technology in first place at 40%, just ahead of third-party and open source code (39%) and software dependencies (38%). It is a tight race, but it marks a shift in where security teams are pointing their attention: AI adoption itself, not just the code it touches, is now the top concern.

That concern tracks with how fast third-party and AI-touched code is spreading through the average codebase. Today, 38% of organizations say more than half of their software already comes from third-party sources, a share the report expects to reach 58% of organizations within 12 months. Open source specifically shows the same curve: 31% of organizations already source more than half their code from OSS, rising to an expected 51% of organizations within a year. Confidence has not kept pace with that growth. Only 31% of organizations say they are completely confident their developers are using secure open source components, and a further 50% say they are simply confident.

Vulnerability management is where that gap shows up most concretely: 39% of organizations cite remediating known vulnerabilities as a top challenge, 36% cite identifying vulnerabilities in the first place, and 35% specifically worry that AI tools are increasing or generating vulnerable code by pulling from third-party and open source sources.

Lechner’s post points to a real-world example rather than a hypothetical one: the Shai-Hulud campaign, the self-replicating npm worm that first surfaced in September 2025, harvested credentials from compromised build environments, and used them to automatically infect the next wave of packages. sxz.io covered a later PyPI-focused wave of the same campaign in June 2026, which used startup-time Python hooks to steal developer and CI secrets from science-focused packages, evidence that the technique keeps resurfacing across ecosystems well after its initial npm outbreak.

Why Current Security Tools Fall Short

Despite the awareness, 45% of organizations do not feel they have robust software supply chain security, against 55% who do. That gap looks worse once you check which tools respondents actually trust. Out of 11 security tool categories the report asked about, secure container services and hardened container image libraries were the only category a majority, 51%, rated as “very effective” at securing third-party and open source code. Every other category, including tools most organizations already run, fell short of that bar.

“At the risk of tooting our own horn,” Lechner wrote, acknowledging that container security happens to be Docker’s own product category.

The conflict of interest is worth naming, but the underlying data point stands regardless of who is reporting it: most of the tooling organizations have deployed to manage third-party and AI-touched code risk is not clearing the bar respondents themselves consider effective.

SBOMs Help, But Most Organizations Treat Them as Optional

Software bills of materials, essentially ingredient lists for the third-party and open source components inside an application, came out of the report as one of the more effective levers available. Organizations that use them report concrete benefits: 73% say SBOMs improve vulnerability mitigation efficiency, 72% say they help implement security controls and processes, and 68% say they help meet compliance requirements. Pairing an SBOM with a VEX (Vulnerability Exploitability eXchange) statement adds another layer, telling a downstream team whether a flagged vulnerability is actually exploitable in their specific deployment and cutting the hours security teams spend chasing vulnerabilities that do not actually apply. sxz.io covered Docker’s earlier push toward mandatory SBOMs in more detail.

Adoption still lags the benefits. Among organizations that generate SBOMs at all, only 42% treat it as mandatory for every application; the majority, 55%, generate them case by case. Producing SBOMs and understanding code composition ranked fourth among the challenges organizations report with third-party and open source software, which suggests the gap is more about consistency than awareness.

The Cost of Getting It Wrong

The report’s incident numbers explain why organizations are paying attention in the first place. 77% of respondents said their organization experienced a software supply chain incident in the 12 months before the survey, and the most common attack type, at 38%, exploited known vulnerabilities in third-party software rather than anything more exotic. When incidents happened, the consequences were concrete: 46% of affected organizations faced unauthorized access to applications and data, 37% had service-level agreements affected by remediation work, and 35% had developer credentials, secrets, or keys stolen outright. Data loss, malware and ransomware, and compliance fines rounded out the list of consequences.

The Fix Keeps Landing on Developers

Investment is following the concern: 62% of organizations expect to make significant investments in software supply chain security, and another 37% plan more modest spending. But the report frames money as only half the answer. The other half is organizational: shifting security left so developers can secure their own code is a high priority for 98% of organizations, and the single top application security priority for 32% of those.

That shift creates its own friction. Nearly half, 45%, of security teams say they have only moderate influence, or less, over the security products and processes developers actually use day to day, a coordination gap between the team setting policy and the team expected to execute it. Developer willingness does not appear to be the bottleneck: the report finds a combined 83% of respondents believe their developers are either mostly (38%) or completely (45%) comfortable taking on security responsibilities. Its own recommendation follows from that finding: for the organizations whose developers are less comfortable, the fix is removing friction, keeping security tasks from disrupting the development process, and rolling out tools consistently across teams rather than adding mandates without the tooling to match.

Put together, the report describes a supply chain security model in transition. AI has overtaken familiar risks like third-party code and dependencies as the top concern, the tools organizations already own are not rated effective by most of their own users, and the operational responsibility for closing that gap keeps moving toward the people writing the code rather than the team that used to own the perimeter. The full report, titled “Securing the Software Supply Chain: Strategic Approaches to Support Scaling Development with AI Adoption” and published by Omdia in April 2026, is available from Docker’s resource page for organizations that want the complete 24-page breakdown.