11–20 of 20 posts
The AI is fast at scaffolding, the bottleneck is still us catching what it gets wrong. NOthing is easy unfortunately
This is terrifying but not surprising. I shipped unauthenticated admin endpoints once in a project that was extensively planned out with AI. The volume of code AI generates makes it really easy for vulnerabilities to slip through because review gets lighter as output gets faster. The two things that actually help: dedicated security review sessions in a fresh context (the building session won't catch its own mistakes…
What worried us in this incident is that even if you catch everything during review, new CVEs can appear later and suddenly make previously “safe” code vulnerable.
That’s why we started treating monitoring as part of the platform itself — every service runs with centralized checks so unusual behavior (CPU spikes, unexpected processes, endpoint exposure) gets flagged quickly.
You built https://github.com/FootprintAI/Containarium for this purpose?
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 proje…
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
But in practice, CI is only a point-in-time guarantee. A build can pass all checks and still become vulnerable later as new CVEs are disclosed.
So the goal isn’t to rely on runtime to “catch mistakes”, but to add a second layer of defense — continuous monitoring and probing for already-deployed services.
If anything, this incident showed us that CI alone isn’t sufficient once systems are long-lived.
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
The real gap here isn't CI — it's that the agent had no cost model for what 'add this dependency' actually means at runtime. It knew how to write the import; it had no concept of the blast radius if the package was compromised. Post-deploy audits and container isolation catch things after they're already in, but risk assessment before the tool call is what closes the loop. That's a different problem than scanning out…