Five Pillars of Security Automation

Oleg Gryb, who works in product security at Block and previously led security teams at Visa and Samsung, reviews how API security automation has changed over ten years and what he expects to matter next. He starts with the obstacles his teams faced: friction between security and delivery in large organisations, scan results that need manual triage, APIs that cannot be crawled the way web applications can, and many proprietary authentication schemes that scanners must be told about explicitly.

He contrasts his earlier setup, built on mostly free tools and a very small team, with a later one. The newer setup pairs Burp extensions and an out-of-band collaborator server with a payload generator that replays valid API call sequences through a proxy so active scanning can run. He notes that active scans break when they change system state, and that findings were held back from product teams until someone had verified them. He also surveys newer discovery approaches, including traffic mirroring with TLS decryption and eBPF-based agents.

The core of the talk is his five pillars: API discovery, an inventory of endpoints and their metadata, reusable templates, testing tools that pull targets from that inventory, and a shared framework so testers do not restart from scratch. He closes with a case study in which a server-side request forgery issue was dismissed as intended behaviour. He measured the impact of unrestricted outbound connections, which led to rate limiting being adopted. His takeaway is that persuading developers with measurable impact matters as much as the scanning itself.