As a veteran in Business Intelligence and data science, Chloe Maraina has spent her career navigating the intricate webs of data management and complex integration. Today, she brings that analytical lens to the shifting landscape of software supply chains, where the rise of AI agents is fundamentally altering how we perceive risk and technical debt. In this discussion, we explore the tension between modern automated workflows and the growing need for disciplined oversight. We delve into the “Hashimoto rule” of forking dependencies, the dangerous fallacy that new versions are inherently safer, and how AI-driven development is creating a new class of vulnerabilities that traditional scanners are simply not built to catch.
The philosophy of forking and trimming dependencies—often called the Hashimoto rule—seems like heresy to some. How do you view this shift toward manual control in an era of automated updates?
It truly does feel like a return to digital craftsmanship in an age where we have become addicted to reckless automation. When you look at the strategy of forking dependencies and trimming them to only the code you actually use, you are essentially reclaiming ownership of your transitive tree. Instead of allowing a tool like Dependabot to dictate your security posture every time a new version drops, you are making a conscious decision to only change your environment when it serves the user. This approach requires a level of technical judgment and patience that many modern enterprises find uncomfortable, but it provides a sense of control that is impossible to achieve when you are blindly pulling from upstream. It forces the engineer to understand every relevant commit, turning a passive update into an active security decision.
We often equate “latest” with “secure,” yet recent npm attacks suggest otherwise. Can you describe the risks of this “staying current” mentality?
The industry has been trained to believe that the freshest version is the safest, but the reality on the ground is often much grimmer. This past spring, we saw the axios library compromised where poisoned releases dropped remote-access Trojans on every machine that ran a fresh install during a critical three-hour window. Then there was the Mini Shai-Hulud worm that propagated through node-ipc and TanStack, hitting UiPath and Mistral among millions of other downloads. In these cases, the developers who “slept through” the attack were the ones who refused to update and stayed pinned to a clean, older version. It’s a stinging irony that the most effective defense wasn’t a sophisticated scanner, but a simple 10-day cooldown period implemented by tools like StepSecurity to ensure a release was actually “good” before deployment.
Research shows that AI agents are increasingly involved in managing these dependency trees. What specific dangers arise when we let models make these choices?
The data is quite alarming when you look at the Purdue study of over 117,000 dependency changes across various ecosystems. AI agents actually selected known-vulnerable package versions 2.46% of the time, which is significantly higher than the 1.64% rate for human developers. Even more concerning is that when an agent makes a mistake, the remediation is often much more painful; 36.8% of agent-driven errors required a major-version upgrade to fix, compared to only 12.9% for humans. We are essentially watching agents “helpfully” add vulnerabilities at lightning-fast speeds, often inventing entirely hallucinated dependencies that don’t even exist. This creates a vacuum that attackers can fill by simply registering those hallucinated names and waiting for an automated system to pull their malicious code.
How does the Model Context Protocol and the use of system prompts complicate the security boundary for modern software?
We are moving into a world where the dependency tree has escaped the package manager and now lives inrepo instructions, system prompts, and Model Context Protocol (MCP) servers. Microsoft’s red-team research highlighted a terrifying reality where relying on a model to follow safety instructions led to policy violations more than 25% of the time. Because tool responses go straight into a model’s context without the rigorous review that code gets, there is no real equivalent to a security boundary; it’s all based on the model’s “goodwill.” Furthermore, prompts suffer from silent decay—a prompt that works perfectly against one version of a model might fail or behave erratically against the next. This creates an alternate control plane for your software that is rarely tested, reviewed, or pruned, leading to a massive accumulation of hidden technical debt.
With AI now being used to find exploits in legacy code, does the strategy of “freezing” dependencies still hold up?
The game has changed because the cost of discovering deep logic bugs has plummeted thanks to models like Claude Mythos. We saw it autonomously find and build working exploits for a 16-year-old FFmpeg bug and a 17-year-old root-access flaw in FreeBSD for under $20,000 across roughly a thousand runs. This means those old, “stable” dependencies we thought were safe are now being scrutinized by inexpensive, persistent AI attackers who can find chinks in the armor that traditional scanners miss. It forces a refinement of our rules: we must keep our surface area small by trimming dependencies, but we also have to actively score our code for vulnerabilities. You can’t just freeze your code and walk away; you have to use the same AI tools the attackers use to ensure your “frozen” version isn’t actually a ticking time bomb.
What is your forecast for the future of software supply chain security as AI agents become the primary authors of our codebases?
I believe we are heading toward a period of intense “governance debt” where the speed of AI development will initially outpace our ability to secure it, leading to a major industry-wide reckoning. We will see a shift away from the “sexy” implementation of agents everywhere toward a more sober, disciplined engineering approach where every prompt, MCP server, and third-party package is treated as a high-risk production dependency. The teams that succeed won’t be the ones that automate the most, but the ones that maintain the thinnest configuration layers and most rigorous review gates for their AI-generated changes. Eventually, the miracle of building world-class software from a thousand components will only remain a miracle if we accept that AI doesn’t eliminate the need for engineering discipline—it actually raises the price of skipping it.
