The dependency angle is real but I think it's a symptom of a bigger problem: AI coding agents run with whatever credentials are in the environment, so a malicious dep doesn't just get file system access. It gets every API key the agent was holding.
The fix most teams reach for is auditing deps more carefully, which helps. But it doesn't change the blast radius if something slips through. A compromised dep in an agent holding a full-access AWS key is a very different situation from one holding a scoped, session-bound token that expires in 24 hours.
The pattern that actually limits damage: agents request short-lived credentials at runtime from a vault, scoped to exactly what that agent needs. The dep can still run, but there's nothing worth stealing.
This is what we do. We use AI for drafting but we never merge without doing a manual review of dependencies.
Every package version is pinned explicitly, and our CI always runs a dependency scan before deploy.
The AI is fast at scaffolding, the bottleneck is still us catching what it gets wrong. NOthing is easy unfortunately
I think some folks are very quick to drop rigor and care as "traditional practices" as if we're talking about churning butter by hand. One thing that might be valuable to keep in mind is that LLM tooling might feel like an expert, but generally has the decisionmaking skills of a junior. In that light, the rigor and best practices that were already (hopefully) part of software engineering practice are even more important.
> In traditional development, you review versions carefully. With AI-generated scaffolding, that step is easy to overlook.
If in "traditional development", everything is reviewed carefully, why wouldn't it be when some of the toil is automated? If anything, that's exactly what the time that's freed up by not having to scaffold things by hand should be invested in: sifting through what's been added and the choices made by the LLM to make sure they are sound and follow best practices.
Reviewing generated code actually takes a higher skill level than writing it. A junior who prompted this Next.js app into existence is physically incapable of auditing the security of those imports. And for a senior it's often cheaper to just write it from scratch than to sit there and audit abstract spaghetti generated by Claude
Totally agree — AI scaffolding automates work, but best practices like CI/CD and pentesting are still essential. Continuous monitoring is necessary for all commits, and combining it with a dev-like centralized platform ensures every service and endpoint stays safe.
The attack chain you described highlights a gap that most teams overlook: AI-generated code passes functional tests but skips the "why this version?" review that experienced developers do instinctively.
I think the real issue is visibility. When AI generates a project, every dependency choice is implicit — there's no PR comment explaining why it pinned next@14.1.0 instead of 14.2.1. In a human workflow, someone would have caught that during review.
Two things that have helped in my workflow:
1. Running `npm audit` as a post-generation step before even testing functionality
2. Treating AI-generated commits as "untrusted by default" — reviewing them with the same rigor as external contributor PRs
CVEs are time-dependent. Even if npm audit guarantees no known vulnerabilities at the moment you merge a PR, new CVEs can emerge later, silently impacting your system without anyone realizing it.
That’s why I think continuous monitoring and centralized pentesting are essential — not just at merge time, but throughout the lifecycle of AI-generated projects.
This incident showed how AI-generated code can inadvertently introduce vulnerabilities. The cryptominer ran because a dependency version chosen by an AI coding agent had a known CVE.
Containarium now runs centralized pentests and vulnerability checks for all applications on the platform to prevent similar attacks.
Curious if others have similar workflows or lessons learned with AI-generated projects.
Nobody in their right mind builds a pipeline where security relies on a custom container runtime catching things after the fact. Security starts in CI at the image build stage. If your flow actually lets a vulnerable Next.js build slip all the way through to deployment in Containarium, your integration process is fundamentally broken, not your runtime environment
The dependency angle is real but I think it's a symptom of a bigger problem: AI coding agents run with whatever credentials are in the environment, so a malicious dep doesn't just get file system access. It gets every API key the agent was holding.
The fix most teams reach for is auditing deps more carefully, which helps. But it doesn't change the blast radius if something slips through. A compromised dep in an agent holding a full-access AWS key is a very different situation from one holding a scoped, session-bound token that expires in 24 hours.
The pattern that actually limits damage: agents request short-lived credentials at runtime from a vault, scoped to exactly what that agent needs. The dep can still run, but there's nothing worth stealing.
We wrote about the mechanics: https://www.apistronghold.com/blog/phantom-token-pattern-pro...
This is what we do. We use AI for drafting but we never merge without doing a manual review of dependencies. Every package version is pinned explicitly, and our CI always runs a dependency scan before deploy.
The AI is fast at scaffolding, the bottleneck is still us catching what it gets wrong. NOthing is easy unfortunately
I think some folks are very quick to drop rigor and care as "traditional practices" as if we're talking about churning butter by hand. One thing that might be valuable to keep in mind is that LLM tooling might feel like an expert, but generally has the decisionmaking skills of a junior. In that light, the rigor and best practices that were already (hopefully) part of software engineering practice are even more important.
> In traditional development, you review versions carefully. With AI-generated scaffolding, that step is easy to overlook.
If in "traditional development", everything is reviewed carefully, why wouldn't it be when some of the toil is automated? If anything, that's exactly what the time that's freed up by not having to scaffold things by hand should be invested in: sifting through what's been added and the choices made by the LLM to make sure they are sound and follow best practices.
Reviewing generated code actually takes a higher skill level than writing it. A junior who prompted this Next.js app into existence is physically incapable of auditing the security of those imports. And for a senior it's often cheaper to just write it from scratch than to sit there and audit abstract spaghetti generated by Claude
Totally agree — AI scaffolding automates work, but best practices like CI/CD and pentesting are still essential. Continuous monitoring is necessary for all commits, and combining it with a dev-like centralized platform ensures every service and endpoint stays safe.
The attack chain you described highlights a gap that most teams overlook: AI-generated code passes functional tests but skips the "why this version?" review that experienced developers do instinctively.
I think the real issue is visibility. When AI generates a project, every dependency choice is implicit — there's no PR comment explaining why it pinned next@14.1.0 instead of 14.2.1. In a human workflow, someone would have caught that during review.
Two things that have helped in my workflow: 1. Running `npm audit` as a post-generation step before even testing functionality 2. Treating AI-generated commits as "untrusted by default" — reviewing them with the same rigor as external contributor PRs
CVEs are time-dependent. Even if npm audit guarantees no known vulnerabilities at the moment you merge a PR, new CVEs can emerge later, silently impacting your system without anyone realizing it.
That’s why I think continuous monitoring and centralized pentesting are essential — not just at merge time, but throughout the lifecycle of AI-generated projects.
Hi HN — author here.
This incident showed how AI-generated code can inadvertently introduce vulnerabilities. The cryptominer ran because a dependency version chosen by an AI coding agent had a known CVE.
Containarium now runs centralized pentests and vulnerability checks for all applications on the platform to prevent similar attacks.
Curious if others have similar workflows or lessons learned with AI-generated projects.
Nobody in their right mind builds a pipeline where security relies on a custom container runtime catching things after the fact. Security starts in CI at the image build stage. If your flow actually lets a vulnerable Next.js build slip all the way through to deployment in Containarium, your integration process is fundamentally broken, not your runtime environment