Why can't tools automatically fix security vulnerabilities? Or can they?

The talk starts from a common frustration: static analysis scanners report large numbers of findings, and developers often see security checks as friction that slows delivery. The speaker argues that the bottleneck is technology rather than headcount, which makes automated fixing the logical next step, and asks why it has not already been solved.

The middle section tests that idea with fixes that look simple. A SQL injection repair seems trivial, but the database column may be an integer rather than a string, so a generated fix can break the application. Correct fixes also depend on business logic, architecture, organisational coding policy, and whether a flagged issue is actually reachable. An experiment with an AI model on deliberately vulnerable web applications produced usable fixes for only a minority of findings, while many changes touched unrelated code. A live demo showed a scanner result turned into a proposed rule-based fix, which was then committed to a separate branch for testing.

The closing point is that automatic remediation should be limited to well-understood patterns and paired with stronger test coverage, developer involvement and continued security governance. Practitioners should expect partial automation for common bug classes, not wholesale rewrites of vulnerable code.