Steve Poole on Open-Source Security and AI’s Maintenance Challenge

Olimpiu Pop interviews Steve Poole, a developer advocate at HeroDevs, about open-source supply-chain security and AI. Poole notes that his employer sells support for unmaintained open-source packages, a commercial perspective relevant to the discussion.

Poole says software teams rely heavily on open-source dependencies and their maintainers. Attackers can exploit that trust by compromising projects or the tools and packages developers install. He sees AI as accelerating vulnerability discovery by both researchers and attackers.

The pair review several entry points: executing an unchecked shell script, installing a malicious package with a misleading or misspelled name, and compromising an existing project. A contributor may build trust before introducing malicious changes. Developer machines can be valuable targets because they often hold credentials and access.

Pop adds that confusing version numbers and configurations that automatically pull new releases can contribute to supply-chain exposure. The concern is the complete path from upstream package to the product that consumes it, not just the application’s own source code.

They discuss the European Cyber Resilience Act, industry standards and cyber insurance as pressures to improve security practices. Poole cautions that he is not a lawyer. The interview’s interpretation is a discussion of policy, not a complete account of legal duties or their applicability.

Pop asks whether AI makes open-source use safer or introduces new risks. Poole says AI-assisted tools can find vulnerabilities at scale, and asks what happens when defenders and attackers both use them. His central concern is that discovery may accelerate faster than the capacity to fix problems.

Unmaintained or end-of-life dependencies are particularly difficult: a discovered issue may not have an available upstream fix, and Poole worries some issues may not be widely reported. Even active maintainers can be overwhelmed by a large influx of reports. This is his risk assessment, not a count of all projects.

Poole raises a possible commercial response: organizations may pay for maintenance to meet security expectations. He worries that fixes could be fragmented between paid services and public projects. He identifies this as a potential outcome, not an inevitable future, and his own employer operates in this market.

Pop points out that finding and fixing a vulnerability is not the end of the chain. Organizations consuming the dependency still need to deploy the patched version, and delays or failures can occur at each stage.

Could a company fork a dependency and fix it itself? Poole says that can work for a particular issue, but it also makes the company responsible for future maintenance and security reports. The effort and expertise needed can be underestimated.

His practical advice is to examine why each dependency is present and reduce unnecessary ones. He cites limited studies suggesting AI-generated applications may include more dependencies than human-written alternatives; the figure he mentions is not a universal measurement. Generated code still needs validation.

Poole recommends staying on maintained releases and making upgrades routine through build and deployment pipelines. Upgrades still require testing and can introduce their own compatibility risks. He presents this as a security practice, while explicitly disclaiming legal expertise.

The speakers discuss a Kubernetes AI contribution policy as an example of assigning responsibility to human contributors. Pop says contributors must understand and maintain code they submit even if AI helped generate it. Project policies are specific to the project and may change.

Poole describes an AI security tool identifying issues in code he had worked on. He expects tools to improve, but says the developer remains responsible for quality. Nondeterministic outputs make testing and other ways of establishing correctness especially important.

In closing, Poole hopes teams become more pragmatic about AI: recognize its benefits along with its downsides, and understand the responsibilities that accompany its use. He says the interaction of technology, economics and policy makes the final outcome hard to predict.