Loading…
Thursday November 5, 2026 3:30pm - 4:15pm PST
A CISO once told me “your security review doesn’t deliver value until the findings are fixed.” That changed how I think about security reviews. They shouldn’t end at identifying issues and handing developers a list of things to consider. They should continue into a security improvements loop that actually drives the fixes. For a finding to be actionable, it needs implementation guidance for the tech stack actually in use, and it has to comply with the organization’s own policies and frameworks.

This talk breaks that down, first at the level of a single review. It starts with context, because context decides which requirements apply: how the software is deployed and exposed, who uses it, what data it processes, and what it must comply with. From there I look at getting rid of false positives, and why “false positive” is rarely a clean boundary. Some reviewers might raise that an input field must be sanitized for HTML, while a sharp developer might say it should be handled by output encoding - the real question is where the control belongs.

I then cover what “implemented” actually means, using acceptance criteria generated from the same requirements to judge whether a control is in place or still needs work. And because the output of this loop is code changes rather than a report, it has to integrate with the review and testing pipeline like any other change.

The second half moves to the program level, where org-specific context and requirements can’t be set per review but evolve with the AppSec program. I’ll cover capturing company standards (your way of doing rate limiting, how you store M2M credentials), keeping an audit trail for compliance, and measuring progress with metrics you can act on: number of code changes, requirements secured from scratch, fix rate, and time to remediate. I’ll also take a position on where penetration testing fits once this loop is running well, and why pen testing is more likely to be reshaped by this data than replaced by it.

Security reviews in the agentic era hold completely new opportunities. What was always a scaling problem becomes a matter of fine-grained details that agents can work through at scale, and what used to end in ad-hoc results can finally turn into improvements available immediately. This is how security reviews start delivering the business value we’ve always claimed for them, instead of just adding to a developer’s todo list.

Key takeaways:
- A security review shouldn’t end at findings. Its value is the fix, so the goal is a security improvements loop that drives changes, not a report that lists risks and leaves developers with more todos.
- “False positive” is rarely a clean boundary. Often the question isn’t real-or-not but where a fix belongs and whether it’s warranted in this context, and that judgment, grounded in proper context, is the actual work.
- “Implemented” has to be measurable, not guessed. Acceptance criteria generated from the same requirements are what you assess a control against, so “done” means the same thing to the developer and the reviewer.
- At program level, measure what you can act on, and rethink where pen testing fits. Track code changes, requirements secured from scratch, fix rate, and time to remediate; and once the loop runs well, the data it produces points toward the next generation of pen tests rather than away from them.
Speakers
avatar for Emil Kvarnhammar

Emil Kvarnhammar

Co-Founder and CEO, Oplane
Emil Kvarnhammar has spent 27 years in software, starting as a developer before moving into cybersecurity consulting and, later, security architecture for a leading video-surveillance manufacturer. Across multiple AppSec programs he has worked hands-on with SAST, SCA, security testing... Read More →
Thursday November 5, 2026 3:30pm - 4:15pm PST
Room: Bayview B (Bay Level)

Sign up or log in to save this to your schedule, view media, leave feedback and see who's attending!

Share Modal

Share this link via

Or copy link