For twenty years AppSec ran on a division of labor: security finds, engineering fixes. AI just dissolved the line between the two. I keep having the same conversation with teams lately: nobody's asking "who owns this vulnerability" anymore. They're asking for tools that find it and fix it in the same motion, flag and fix, raise and remediate, on a context both security and engineering can actually see. Once anyone on the team can find a bug and ship the patch with an AI agent, the old handoff, the silos, the 400-page report thrown over the fence, stops making sense. This week a bunch of smart people were circling the same realization from different directions. Let's dig in.

Frankly Speaking's latest maps the shift straight onto the org chart. The traditional layout, functional silos of AppSec, Cloud Security, SOC, GRC, and IAM, was built for a world where human analysts ground through repetitive manual work. The argument is that it's reorganizing around outcomes, and the check-the-box middle gets automated first: quarterly automated jobs now handle user-access reviews and dependency monitoring that used to eat weeks of coordination. The part that stings is the new expectation on the practitioner. Running an AST scan and logging a ticket for someone else is no longer the job; you open the repo, write the patch, run the tests, and submit the pull request yourself.

What to do with this: If your AppSec hires can find but can't ship a fix, that's now a gap, not a job description. Staff and reskill for remediation, not just detection.

🔗 Frankly Speaking

Latio's James Berthoty makes the tooling version of the same argument, and it's the piece I'd most want you to read this week. His thesis: continuous threat modeling and design review, AI code review, AI SAST, and AI pentesting are collapsing into a single category he calls AI Code Security, defined by giving coding agents tailored security and business context while giving security teams visibility and guardrails. The line that stuck with me: "patching is the bottleneck, not discovery." His diagnosis of why old tools stall is exactly the shared-context problem, they can find a SQL injection but can't tell you which ORM to fix it with or the risk of shipping that fix, and their workflow was built for humans, not agents that need the context before they write the code.

Why this matters: This is the map for where AppSec tooling is going. The winning tools carry context across the whole stack and remediate, they don't just scan and surface.

🔗 Latio Pulse

Filippo Valsorda sharpens why raw findings alone are losing value. For years a vulnerability report was special because a researcher gave you two scarce things, insight into where a bug lived and confidentiality long enough to ship a fix first. In 2026, LLMs find issues about as well as most researchers, and anyone can run them, so the bottleneck becomes triage: which reports are real and which actually affect users. His pointed conclusion is that without an existing trust relationship and shared context, an external LLM-generated report adds almost nothing, since picking through its output and picking through your security@ inbox have the same signal-to-noise.

Why I'm flagging it: A finding without shared context is just noise now. The value moved to the context and the fix, which is exactly what the converging tools are racing to own.

🔗 tl;dr sec #335

Doyensec's Luca Carettoni and Anthony Trummer ran a side-by-side of two AI-powered penetration testing platforms, Aikido's Attack AI Pentest and XBOW's Lightspeed, manually validating every finding to separate true positives from false positives. They scored configuration complexity, impact on the tested app, report quality, cost, speed, and overall effectiveness. The takeaway is that autonomous offensive testing has crossed from research demo to procurable product with a real evaluation methodology behind it.

When offense ships as a SaaS subscription with a benchmark, your adversaries can rent the exact same thing. Run these tools against yourself before someone rents them to run against you.

🔗 Resilient Cyber

For twenty years we treated "security finds, engineering fixes" as if it were physics. It was never physics. It was a workaround for a world where finding bugs took scarce expertise and fixing them took context that only the engineering team held. AI knocked out both constraints at once, and the teams I work with feel it before they can name it: they've stopped asking who owns a finding and started asking for tools that identify and resolve in one loop.

So here's what I think actually moves. The security team reorganizes around outcomes instead of silos, and the tooling mandate flips from "surface more findings" to "resolve them and take work off both backlogs." The real differentiator stops being the scanner and becomes shared context across the whole stack, design, code, and runtime, because that's the only thing that lets a fix be both correct and safe to ship. What doesn't change is accountability: someone still has to own the call on what matters and whether a fix is trustworthy, and that judgment gets more valuable as the mechanical work disappears.

If you're already running flag-and-fix in production and have a view on where that line belongs, that's the conversation I want. Reply and tell me.

The old flex was finding the bug nobody else could. The next one is closing it before it ever hits a backlog, on a context your whole team can see. If your tools still just hand you more work, they're solving last decade's problem.

DevArmor will be at Black Hat this August in Las Vegas. If you're attending, come find us in the Expo hall at Booth #5808.
We're also co-hosting The CISO Roast on the evening of August 5th, invite only, open bar, and a room full of CISOs actually saying what they think. Seats are limited.
Reserve your spot →

-Amir

Thanks for reading The AppSec Signal, DevArmor’s newsletter for security professionals.
Have feedback or ideas for what we should cover next?
Feel free to reach out - [email protected]