AI fuels new supply‑chain risks, Chainguard urges fix

Chainguard CEO Dan Lorenc warned AI can link many low‑severity bugs into novel supply‑chain attacks and called for a single disclosure pipeline and funded maintainer support.

Dan Lorenc, CEO of Chainguard, wrote that artificial intelligence can assemble dozens of minor software flaws into novel supply‑chain attacks. In a recent contributed post he opened with the line “Mythos is real.” He argued the pattern is not a simple scanner false positive but new combinations of many low‑severity findings chained into larger exploits.

Lorenc explained that large language models and automation can synthesize attack chains at scale, producing hundreds of exploitable combinations overnight. Current scanners and disclosure processes, he wrote, were built for an era when finding a serious bug required weeks of expert work and targeted a small number of projects.

He traced the problem to how organizations consume open‑source software. Modern applications use deep dependency trees. Many widely used projects are maintained by one or two volunteers who work in their spare time. Automated tools already generate many low‑quality reports, and models that find chains across dependencies can overwhelm maintainers and existing vulnerability channels.

Lorenc noted U.S. regulators have been tracking the trend but face limits. Laws cannot stop people around the world from publishing code, so policy work has focused on how companies use and update open‑source components. He warned regulators must weigh the risk of driving development to other jurisdictions against the risk of leaving U.S. systems exposed.

He proposed two complementary plans. Plan A calls for a single, trusted coordinated disclosure organization that vets reports, routes fixes upstream, and provides support to willing maintainers. Lorenc cited an existing effort, Glasswing, which has managed to get about 6% of its findings merged upstream, and he estimated coordinated disclosure could reach roughly half of affected projects under time pressure with sustained work.

Plan B would address projects that cannot be fixed upstream. Lorenc proposed a funded maintainer‑of‑last‑resort that could assume stewardship of unresponsive or abandoned projects, create trusted forks, and distribute maintained versions to downstream users. He said forking is an established open‑source mechanism, but the current scale requires centralized infrastructure that is funded, staffed and neutral.

He outlined three possible industry outcomes. One scenario would see maintainers and organizations respond rapidly and keep dependencies current; Lorenc described that as unlikely. A second scenario would be chaotic, with cloud providers and vendors creating competing forks and patch sets. The third scenario would be a deliberate consolidation: build new trust infrastructure, centralize disclosure channels, and make defined choices about which projects receive sustained maintenance.

Lorenc noted the same AI tools that can create these attack chains can also help automate large‑scale fixes. He called for industry cooperation, new operational models for disclosure and stewardship, and funding mechanisms to support long‑term maintenance.

Articles by this author