Artificial Intelligence, Natural Consequences

At this point, arguing about whether AI belongs in software development is a little like arguing about whether the internet belongs in software development. The discussion is over. The tooling is already here. Developers are using it. Product teams are integrating it. Security teams are experimenting with it. And adversaries are absolutely operationalizing it. The only remaining question is whether we use it intelligently.

While the industry is still debating acceptable use policies and drafting “responsible AI” slide decks, attackers are already using generative AI to accelerate exploit development, identify vulnerable code paths, automate reconnaissance, mutate payloads to evade detection, and lower the skill barrier for increasingly sophisticated attacks. And unfortunately, they are getting real results. This means security teams do not have the luxury of pretending AI adoption is optional. We are already in the phase where refusing to use AI tools simply guarantees your adversaries will iterate faster than you do. Our adversaries have dropped the virtual atomic bomb and we’re firing back with muskets and cannonballs.

That said, the current industry obsession with AI-driven tooling and AI-first policies feels dangerously misguided. Take the recent wave of vulnerabilities disclosed by Mythos. Technically impressive? Absolutely. But strategically, it highlights a deeper problem in how the industry thinks about security outcomes. Vulnerability identification has never really been the bottleneck. Most organizations already have millions of findings from their existing scanning tools, penetration tests, bug bounty submissions, architecture reviews, backlog tickets, and forgotten Jira epics from three reorganizations ago. We are drowning in vulnerabilities already.

The industry does not have a “finding bugs” problem. It has a remediation capacity problem. Finding one more deserialization issue in a legacy microservice does not materially improve security if the engineering organization lacks the time, staffing, architectural maturity, or operational safety to remediate it. Even seemingly simple fixes, like updating a vulnerable open source dependency, often trigger weeks of compatibility testing, regression validation, refactoring, and downstream integration pain. Security teams know this. Developers definitely know this.

This raises an uncomfortable question: Why are we spending so much effort teaching AI to generate more findings instead of helping organizations actually resolve the ones they already have? That is where AI becomes genuinely transformative in the secure development lifecycl – not as an infinitely scalable vulnerability intern, but as an operational force multiplier that reduces the real-world friction preventing secure engineering work from getting done.

Imagine AI-assisted dependency modernization that can:

• Analyze breaking API changes between library versions
• Refactor incompatible code automatically
• Generate updated unit and integration tests
• Validate functionality against expected behavior
• Open a pull request with human-readable explanations
• Identify likely rollout risks
• Recommend compensating controls during migration

That is enormously more valuable than generating another 40,000 medium-severity findings no one has the resources to address.

The same applies to threat modeling. Most threat modeling exercises fail not because engineers do not care about security, but because traditional approaches are time consuming, manual, and difficult to scale across modern development velocity. AI-assisted threat modeling could help teams identify trust boundaries, insecure data flows, architectural assumptions, authentication weaknesses, privilege escalation paths, and abuse cases during design phases, when remediation is still relatively cheap. That is meaningful leverage.

AI also has enormous potential in areas like:

• Security-focused code review augmentation
• Infrastructure-as-code analysis
• Attack path simulation
• Detection engineering assistance
• CI/CD policy validation
• Secure configuration generation
• Runtime behavior correlation
• Documentation synthesis for secure patterns
• Translating security requirements into developer-friendly implementation guidance

In other words, the best uses of AI in security may not involve replacing humans at all. They involve reducing the enormous operational drag that prevents humans from executing good security practices consistently. The reality is that modern software ecosystems have become too large, too interconnected, and too fast-moving for purely manual security processes to scale effectively anymore. Open source dependencies alone have created transitive risk chains so complex that most organizations barely understand their own exposure surface in real time. AI can help with that, but only if we stop treating “more findings” as synonymous with “better security.”

The future of AI in secure development is not about generating infinite vulnerability reports. It is about helping engineering organizations finally close the gap between knowing about risk and actually reducing it.