AI industrialized vulnerability discovery. The code itself is now written by agents on developer workstations, and most AppSec programs have no control point there.
The control point gap has a companion problem: in most small software vendors nobody owns it. ENISA's answer so far is guidance rather than tooling. It publishes a Secure by Design and Default Playbook written for SMEs and an SME Cyber Resilience Maturity Assessment Model, both free, both assuming a human reads the output and acts on it. For a firm with no AppSec function that moves the practical question away from which scanner to buy and towards who reviews what an agent committed on a workstation, which is the control point this piece says is missing.
The human-in-the-loop point is the one I'd take to a board. Most teams have it set to "always" on paper and something looser in practice, and nobody has written down which findings or which repos an agent may merge on its own. Making that explicit and tiered by risk is a governance decision before it's a tooling one, and defaulting to whatever the vendor shipped is going to age badly.
The npm install interception is the part I'd pressure test hardest. If VibeGuard's evaluation of a package before it lands is itself model driven rather than a deterministic registry or allow list check, it inherits the exact blind spot it's supposed to catch. The hallucination rates you cite, 5.2% commercial and 21.7% open source, describe a model being confidently wrong about what a package is, and an evaluator built the same way can be confidently wrong about whether that package is safe. Worth asking any vendor pitching agent side interception whether the decision is deterministic or just another model call underneath. I dug into a similar case at What Breaks this week, seven coding agents running an attacker's command straight out of a .git/config file before a pull request even existed. Same shape of problem, the control point has to sit earlier than anything that reads a diff.
The control point gap has a companion problem: in most small software vendors nobody owns it. ENISA's answer so far is guidance rather than tooling. It publishes a Secure by Design and Default Playbook written for SMEs and an SME Cyber Resilience Maturity Assessment Model, both free, both assuming a human reads the output and acts on it. For a firm with no AppSec function that moves the practical question away from which scanner to buy and towards who reviews what an agent committed on a workstation, which is the control point this piece says is missing.
The human-in-the-loop point is the one I'd take to a board. Most teams have it set to "always" on paper and something looser in practice, and nobody has written down which findings or which repos an agent may merge on its own. Making that explicit and tiered by risk is a governance decision before it's a tooling one, and defaulting to whatever the vendor shipped is going to age badly.
The npm install interception is the part I'd pressure test hardest. If VibeGuard's evaluation of a package before it lands is itself model driven rather than a deterministic registry or allow list check, it inherits the exact blind spot it's supposed to catch. The hallucination rates you cite, 5.2% commercial and 21.7% open source, describe a model being confidently wrong about what a package is, and an evaluator built the same way can be confidently wrong about whether that package is safe. Worth asking any vendor pitching agent side interception whether the decision is deterministic or just another model call underneath. I dug into a similar case at What Breaks this week, seven coding agents running an attacker's command straight out of a .git/config file before a pull request even existed. Same shape of problem, the control point has to sit earlier than anything that reads a diff.
Good advice.
Still a Band-Aid until the process of software production is itself properly engineered.
As I've been saying for thirty years.