Canonical Report Flags Open Source Supply Chain Gaps

From Composer Packages to Production Infrastructure
Discover Drupal graphic titled “Open Source Supply-Chain Trust” with text reading “Canonical’s 2026 report highlights dependency, patching, and governance gaps relevant to Drupal teams.” The Canonical logo appears on the right over a pale gray background with subtle gear shapes, with The Drop Times branding and website link along the bottom.

Enterprise teams continue to rely on open source software while struggling with fragmented dependency tracking, manual security processes, and unclear ownership, according to a 6 July 2026 Canonical blog post about the company’s April 2026 research report.

For Drupal readers, the report is best read as infrastructure context rather than Drupal-specific research. Many production Drupal projects rely on Composer-managed PHP packages, JavaScript libraries, Linux hosting, containers, databases, web servers, third-party services, and continuous integration and deployment workflows. Those surrounding layers can affect site security when dependency tracking, patching, and production updates are split across teams.

The report, The Open Source Chain of Trust 2026, is based on a global survey of 500 DevOps professionals and IT decision makers conducted by Vanson Bourne on behalf of Canonical in October and November 2025. Respondents came from organisations across the Americas, EMEA, and APAC. The report does not discuss Drupal directly, so its Drupal relevance lies in the surrounding infrastructure and governance practices that support Drupal delivery.

Canonical reported that 96% of surveyed organisations had at least one major security concern about using open source software. The most common concern was exposure to security vulnerabilities, cited by 49% of respondents, followed by supply chain risks and third-party dependencies at 45%, and difficulty keeping up with patches or updates at 40%. These concerns map closely to Drupal operations where dependency trees, hosting layers, and deployment workflows often cross team boundaries.

The report gives the operating system a central role in open source governance. It says 98% of respondents described the operating system as extremely or very important for detecting and applying updates or patches to open source components. Linux ranked as the most used operating system across test and development, production, public cloud, private data centres, infrastructure management, and edge environments.

That makes operating system maintenance a practical security dependency for Drupal teams. Server images, container bases, PHP runtimes, database packages, caching services, web server packages, and supporting libraries can all shape how quickly vulnerabilities are identified and patched. A Drupal application can still inherit risk from outdated platform components or inconsistent patch policies across hosting environments.

Dependency visibility was another recurring concern in the report. Canonical found that organisations source open source packages through several routes, including official ecosystem packages, upstream repositories, managed third-party services, and operating system or distribution repositories. It also found that dependency identification is spread across software composition analysis tools, lock files, package and build managers, internal scripts, continuous integration and deployment integrations, manual inspection, and build outputs.

That fragmentation has a direct parallel in Drupal delivery work. A site may combine Drupal core, contributed modules, custom code, Composer packages, JavaScript libraries, container images, operating system packages, and cloud services. When responsibility is split between development, security, hosting, and platform teams, it can become unclear who tracks a vulnerable dependency, who approves an update, and who confirms that a patch has reached production.

Canonical’s survey also found uneven security maturity. The report says 61% of respondents use software composition analysis tools to scan for known vulnerabilities, 60% maintain software bills of materials, and 51% use static analysis or code scanning tools. At the same time, 35% still rely on manual code reviews as part of open source security processes, and 21% rely completely or mostly on manual methods for vulnerability tracking.

Patching delays were linked less to lack of awareness than to operational risk. The most common causes were compatibility concerns with existing systems at 53%, resource constraints at 43%, downtime concerns at 41%, and fear of introducing new vulnerabilities at 41%. The report also found that 71% of respondents see tensions around open source between DevOps and platform engineering teams, while 67% cited a lack of strategic alignment as a barrier to progress.

Drupal organisations can use the findings as a prompt to make open source governance more explicit. That includes maintaining accurate dependency inventories, using automated vulnerability monitoring, defining ownership for updates, reviewing hosting and operating system patch policies, and making platform decisions visible to teams responsible for Drupal delivery. Site security cannot stop at module updates or Drupal security advisories; it must include the wider chain that carries code from upstream packages to production infrastructure.

Disclosure: This content is produced with the assistance of AI.

Note: The vision of this web portal is to help promote news and stories around the Drupal community and promote and celebrate the people and organizations in the community. We strive to create and distribute our content based on these content policy. If you see any omission/variation on this please reach out to us at #thedroptimes channel on Drupal Slack and we will try to address the issue as best we can.

Upcoming Events

Latest Opportunities