The future of AppSec in the age of AI

Audience: AppSec engineers, DevSecOps teams, red teamers, and open source maintainers who want application security coverage without stitching together five separate tools.

DrogonSec is an open source, Go-based scanner that combines SAST, SCA, secrets detection, and Infrastructure as Code analysis in a single engine. It is the successor to Horusec. Findings map to the OWASP Top 10:2025 and align with MITRE ATT&CK, so results speak the language of both developers and security teams. An optional AI-assisted layer, running on local models through Ollama, suggests remediation without sending code to a third party.

The session shows how the engine is built, why a unified scanner changes triage, and how it plugs into GitHub Actions pipelines under an Apache 2.0 license.

What you will learn:

• How to run SAST, SCA, secrets, and IaC checks in one pipeline step and cut tool sprawl.
• How mapping findings to OWASP and ATT&CK makes prioritization clearer for both defenders and attackers.
• How to use local LLMs for remediation guidance, and where their limits are (CPU-only inference, model size, timeouts).
• How to adopt, extend, or contribute to an open source scanner in your own CI/CD.

Who this is for: API security engineers, pentesters and the platform teams who now review code an agent wrote against APIs an agent called.

Most of the code in my repos right now was written by a coding agent. I'm guessing yours is heading the same way. Every one of those sessions ends, and when it does, whatever the agent figured out about your API goes with it. Which endpoint has to be called before that other one. Which field is actually required. Which call returns a 200 and does nothing. That used to be tribal knowledge, and at least you could walk over and ask Joe. Now there's no Joe. There's a diff, and nobody who remembers why.

I spent this summer running hundreds of agent sessions against real APIs, with real credentials, trying to prove the idea was worthless. I kept score. Some of it went against me and I'll show that part too. The short version: an agent builds on whatever context is sitting in front of it. Stale, wrong, or put there by someone else, it doesn't check. And it never goes looking for anything that isn't in front of it. For API security that's the whole game. The context an agent had when it wrote the code is the thing you need to review, and today nobody keeps it.

I'll walk through what an agent's API context actually looks like, where it comes from, the ways I watched it go wrong, and what that changes about reviewing agent-written API code. Then I'll show what I'm building to fix it: Sannr, an open source API client that keeps what agents learn about your APIs verified against the live API and committed with the code, so the next agent, and the next reviewer, gets it.

AppSec and GRC teams don’t always get along, but we should. We’re all working towards the same goal (securing the company so it can work better), so why is it sometimes so hard to work with each other?

I think it’s simply because we don’t understand how the other side solves problems, or in other words, we look at risk differently. Bring your thoughts, questions, and observations as we explore this conundrum together.

Most AppSec programs aren't short on scanners. They're short on capacity, context, and evidence: inventories nobody trusts, backlogs nobody can read, “critical” findings that don't matter, and board reports that answer the wrong question. AI changes that equation, but only if it's run as a governed program rather than another tool.

This topic lays out a practical blueprint for using Claude across the AppSec lifecycle: Know your API estate, Set standards developers will use, Find & Fix logic flaws scanners miss, Prioritize by exploitability rather than severity, and Prove progress to boards and examiners. This topic addresses what most AI talks skip: the agent itself is now a privileged identity in your environment and part of your attack surface. That means governing it with least privilege, human approval, prompt-injection defenses, and clear accountability.

No demo, no code. You'll leave with a 90-day plan, an agent risk register, and five metrics to take back to your CISO.

For the last 30 years, application security champions have found vulnerabilities and politely requested a few fixes when they needed thousands. Today, AI can generate security fixes at the speed of find. But maintainers still need evidence that a vulnerability is real and that a proposed patch is safe, focused, and useful.

OWASP OASIS adds a community validation layer between fix automation and maintainers to secure open source at scale. This talk shows how OASIS works and what lessons can be learned from its process.

Most organizations hesitate to report a cyber incident because they don’t know what happens next. Will agents take the servers? Will it become public? Who’s in charge? FBI Special Agent David Dahle, the Bureau’s private-sector coordinator in San Francisco, answers those questions directly.

He’ll cover what today’s FBI looks like, what it works on, and the priorities driving its cyber program. Then he’ll walk through what actually happens when an organization reports an incident, and the FBI resources available to public- and private-sector teams before anything goes wrong.

Frontier models like Mythos have changed the attacker's economics. Finding vulnerabilities, writing exploits and launching thousands of agents now costs very little, and open-weight models with similar cyber capability are close behind, running on attackers' own hardware where no vendor safeguard or monitoring applies. Defenders cannot answer that by patching faster.

Former Charles Schwab CISO Bashar Abouseido makes the case for “hyper defense”: using AI across every part of security, building continuous context about what findings mean, and focusing scarce engineering time on what is exploitable.

Shania Fu has spent her career building the platforms development teams rely on every day, and along the way, application security outcomes landed on her plate too. That vantage point reveals things security teams often miss. Modern applications are assembled at runtime from services, libraries, configuration and infrastructure, so scanning the repo tells only part of the story. And the flaws that hurt most, like one user seeing another user’s data or skipping a step in a workflow, rarely show up in code alone.

In this fireside chat, Shania talks through what static tools miss, what noisy findings really cost engineering teams, how proof of exploitability changes prioritization, and how to build testing into the platform so teams don’t route around it. She’ll close with what AI-powered attackers and AI agents inside applications mean for AppSec, and what she’d start doing on Monday.