OWASP Global AppSec USA 2026: Full Schedule

arrow_back View All Dates

10:30am PST

Beyond Provenance: Integrating Weight-Integrity Attestation Into Your AIBOM Pipeline

Thursday November 5, 2026 10:30am - 11:15am PST

Most AI supply-chain security tooling stops at provenance. A signed manifest proves the model came from the publisher who claims to ship it. OWASP CycloneDX AIBOM, OpenSSF Model Signing, and HuggingFace's signed model cards all answer that question. None of them answer the next one - what is actually inside the weights you signed.

The harder attack class lives in that gap. We built a working architectural-backdoor adapter of 136 kilobytes of new weights inserted between two transformer blocks of Cisco's Foundation-Sec-8B-Instruct and disclosed to Cisco PSIRT. Foundation-Sec ships across Splunk Enterprise Security AI Assistant and Cisco XDR, the model is in production SOC pipelines today. The adapter passes byte-for-byte hash comparison, fires only on a hidden trigger phrase, and is invisible to every provenance check currently deployed.

This session walks through a defensive workflow that closes the gap. Four steps AppSec teams can adopt this quarter:

1. Emit a CycloneDX 1.6 AIBOM with a structural-content hash field at model ingestion.
2. Bind the AIBOM to an OpenSSF Model Signing sigstore bundle so provenance and content ship together.
3. Scan weights at CI time with an integrity scanner, validated against the disclosed attack with zero-error insertion-layer recovery.
4. Hook model-load events in production so drift from the pinned baseline routes through the existing on-call channel.

Attendees leave with a reference architecture, a copy-paste CI configuration, the four-class payload taxonomy that determines what each control actually catches, and an honest defense-in-depth framing. The published adversarial stress-test shows where this workflow stops working. Layer it alongside provenance signing and behavioural monitoring, do not deploy it in place of them.

Speakers

Bodhisattva Das

Security Researcher, RUDRA Cybersecurity

Bodhisattva Das is a Security Researcher at RUDRA Cybersecurity, and a graduate student at Carnegie Mellon University working on securing non-human identities, AI agents, and automated workloads across cloud environments. He specialises in open-source threat detection using Wazuh... Read More →

Thursday November 5, 2026 10:30am - 11:15am PST
Room: Grand Ballroom A (Street Level)

Deployment and Maintenance

Audience Intermediate

10:30am PST

The Human Approval Button Is Not a Security Boundary

Thursday November 5, 2026 10:30am - 11:15am PST

Room: Grand Ballroom B (Street Level)

Agentic AI applications increasingly rely on human approval before taking sensitive actions such as sending messages, modifying records, querying business systems, creating tickets, or invoking external tools. Human-in-the-loop review is often treated as a safety control, but the approval step is only as strong as the context it exposes.

This talk examines a practical implementation problem in agentic AI systems: approval screens can become misleading security boundaries. A user may approve a clean summary while missing the full tool parameters, source data, retrieved context, permissions, prior agent steps, or downstream effects behind the action. In these cases, the human is technically “in the loop,” but not given enough information to make a meaningful security decision.

The session will show how AppSec teams can review human approval flows as part of the application’s security boundary. It will cover common failure modes, including vague approval prompts, missing tool arguments, hidden data sources, incomplete audit trails, approval after unsafe context has already been used, and approval screens that summarize intent without showing impact.

Attendees will leave with a practical checklist for reviewing approval gates in agentic workflows: what the user should see, what should be enforced outside the model, what should be logged, what should require step-up approval, and what should never depend on a model-generated summary alone.

Speakers

Anusha Vajha

Security Engineer and Product Manager

Anusha Vajha is a cybersecurity practitioner focused on AI governance, product security, and enterprise AI risk. She has worked across security operations, GRC, detection engineering, and product security in healthcare, financial services, and startup environments.
Her work sits a... Read More →

Thursday November 5, 2026 10:30am - 11:15am PST
Room: Grand Ballroom B (Street Level)

Implementation

Audience Intermediate

10:30am PST

So your developers hate you... How to turn reluctant devs into AppSec champions

Thursday November 5, 2026 10:30am - 11:15am PST

Room: Bayview B (Bay Level)

Committing to creating and managing an AppSec program is hard, and it's only made harder by our most beloved clients and teammates, reluctant developers. Developers who have typically enjoyed a life free of security concerns, managing their own work and shipping features on their timescale. It is, perhaps, understandable that adding security controls leads to friction and pain for our developers. Security often suddenly changes how they work! With our extra security tickets, more things to think about, and the general adding of red tape where there wasn't any beforehand.

Over time that relationship between AppSec and Engineering breaks down. Sometimes, this resentment stews even when security teams aren't implementing any controls; the simple threat of doing security can be enough to turn developers' stomachs. Losing the battle on bugs, before it's even begun in earnest.

So how can we convince devs that we're not out to get them? Or make their life harder? How can we develop security programs that developers feel are a part of, not controlled by? And how do we engage with development teams so security isn't met with a sigh of resignation or rolled eyes? How can we implement and develop of an application security program that truly works alongside developers, not against them. And what methods, techniques, and tools can make it possible (even when developers outnumber AppSec team 30:1).

Speakers

Dr. Katie Paxton-Fear

Lecturer and Educational YouTuber, Manchester Metropolitan University

Dr Katie Paxton-Fear is a lecturer of cyber security at Manchester Metropolitan University, she's a hacker and YouTuber, she's made 50+ videos on a range of topics, explaining vulnerabilities, tools etc, and made a splash as an API hackerSpeaker Agreement
@InsiderPhD
lin... Read More →

Thursday November 5, 2026 10:30am - 11:15am PST
Room: Bayview B (Bay Level)

Process and Culture

Audience Intermediate

11:30am PST

Exploits of Agency: Mapping out insecure development patterns across the agentic landscape

Thursday November 5, 2026 11:30am - 12:15pm PST

Room: Grand Ballroom A (Street Level)

At this point, agents are everywhere and they are pretty hard to ignore. They are showing up in our CI/CD life cycles, in code development, in code reviews, and in the day-to-day workflows that engineering teams are encouraged to adopt by both lower and upper management.

Their deep integration into the development life cycle raises a serious question: how do we actually deploy agentic systems safely when they are touching code, repositories, build systems, secrets, tickets, pull requests, and CI/CD workflows?

In this talk, I will explore the attack surfaces that agents open inside IDEs, coding agents, and CI/CD environments. I will walk through real bugs and exploit patterns found while researching agentic vulnerabilities across different products and environments over the last year.

You will leave being able to audit the agents in your own pipeline, with a clear read on which familiar controls quietly stop working the moment an agent, and not a person, is the one acting on untrusted input.

Speakers

Dan Lisichkin

AI Security Researcher, Pillar Security

Dan Lisichkin is the Cyber Security Researcher for Pillar Security, focusing on AI security, adversarial threats, and securing AI based systems. With over five years of experience in the cybersecurity and IT space, Dan has extensive knowledge in areas including malware analysis, reverse... Read More →

Thursday November 5, 2026 11:30am - 12:15pm PST
Room: Grand Ballroom A (Street Level)

Deployment and Maintenance

Audience Intermediate

11:30am PST

Crypto Is Fine. The Code Is Not: OWASP A04 Cryptographic Failures Through Real-World CVEs

Thursday November 5, 2026 11:30am - 12:15pm PST

Room: Grand Ballroom B (Street Level)

Cryptography has a reputation for being intimidating, mathematical, and difficult to reason about. In reality, many cryptographic failures in production systems have very little to do with cryptography itself. They happen because of small implementation mistakes such as skipping a validation check, trusting unvalidated input, or selecting the wrong algorithm.

In this talk, we take a practical and data-driven look at the OWASP Cryptographic Failures category using GitHub Security Advisories collected as of January 2026. We begin with a brief overview of how these vulnerabilities are distributed across CWEs, then focus on two of the most common failure patterns. Using real vulnerable open source libraries, we examine signature verification bypasses and algorithm confusion bugs.

Rather than only showing exploits, this talk actively involves the audience. For each case study, we pause at key moments and work through the vulnerability together, asking questions like what inputs could be sent or what assumptions might be broken. Live demos and CTF-style challenges are used throughout, making the session interactive and approachable even without a cryptography background.

Speakers

Diptendu Kar

Security Researcher, Semgrep

Diptendu Kar is a security researcher focused on supply chain and dependency risk. He works on triaging open-source vulnerabilities, writing detection rules, and exploring how AI can automate tedious parts of security research. He also teaches Software Security Practices at Northeastern... Read More →

Thursday November 5, 2026 11:30am - 12:15pm PST
Room: Grand Ballroom B (Street Level)

Implementation

Audience Intermediate

11:30am PST

How Security Champions can keep AI-driven software safe

Thursday November 5, 2026 11:30am - 12:15pm PST

Room: Bayview B (Bay Level)

AI tools are supercharging the speed at which development teams ship software. Developers are no longer just copy-pasting code snippets; they are using AI agent frameworks to automate multi-step engineering tasks. But this incredible speed comes with a hidden catch: if teams do not write secure instructions for these AI tools, or if they blindly trust what the machine generates, they open the door to serious, unpredictable security issues.

Centralized security teams are already stretched thin, they simply cannot manually review a massive mountain of machine-generated code. Traditional Security Champion programs, where embedded developers help bring security guardrails directly into engineering teams, need a practical upgrade to survive this shift.

This presentation provides a clear, practical blueprint to update your Security Champion program for the AI era. Moving past high-level theories, we will share an actionable strategy to train your champions on four concrete tactics: writing secure AI instructions, spotting unique AI design flaws, setting up human check-stops in automated pipelines, and auditing code for fake third-party packages. Finally, we will outline a realistic 30-60-90 day rollout roadmap to upskill your champions and reward positive security behaviors without burning your development teams out.

Speakers

Stanley Harris

CEO and Co-Founder, Katilyst

Stanley is the CEO and Cofounder of Katilyst, where he leads initiatives to build and enhance Security Champion programs. With over 15 years of experience in organizational change management, he has successfully designed and launched multiple Security Champion programs, fostering... Read More →

Thursday November 5, 2026 11:30am - 12:15pm PST
Room: Bayview B (Bay Level)

Process and Culture

Audience Intermediate

11:30am PST

Beyond Detection: What We Learned Testing Every AI Approach to Vulnerability Classification

Thursday November 5, 2026 11:30am - 12:15pm PST

Room: Seacliff AB (Bay Level)

There has been considerable discussion on how to use AI to find vulnerabilities, but very little discussion on how to use it to classify vulnerabilities. Given the huge backlog of vulnerabilities in our systems, and the impending agentic coding revolution which will 100x them, a new approach is needed to accurately cull and rank issues. In this talk, we discuss agentic classification vs. supervised learning-based classification, what other traits can be discerned besides simple "true or false positive", utilizing dynamic analysis techniques, frameworks for evaluation, confidence of results, strengths and weaknesses of generative AI in this task domain, and future research directions.

Problem Statement:

Security tools — SAST, DAST, IAST, SCA, and others — produce findings. Humans classify them. That process does not scale, and in practice it mostly doesn't happen — the majority of findings across the industry are never reviewed. False positive rates vary wildly by tool, rule, and codebase, but the deeper issue is that even *true* positives require judgment: is this exploitable in context? Are there compensating controls elsewhere? Is the reported severity accurate? This classification step — not detection — is where application security breaks down, and the problem compounds as AI-assisted code generation increases finding volume.

We set out to answer a practical question: what does it actually take to classify vulnerability findings with the accuracy and nuance of a senior security engineer? To find out, we ran a systematic bakeoff across a range of approaches — naive LLM prompting, supervised learning, multiple agentic architectures with different reasoning strategies, domain knowledge bases, and dynamic analysis techniques — evaluated against benchmarks constructed from real findings in real organizations across 15+ security tools. We compared structured decision trees against open-ended ReACT reasoning, tested how much domain-specific knowledge bases improve accuracy, measured the limits of attention-based analysis on complex multi-file data flows, and assessed when dynamic exploit verification is worth its cost. The results show where each approach succeeds, where it fails, and what combination gets closest to expert-level classification.

Speakers

Arshan Dabirsiaghi

CTO and Co-Founder, Pixee

Arshan is a security researcher and developer pretending to be a software executive, with many years of experience advising large organizations on code security and building tooling to support secure code development. He has spoken at prestigious conferences like Blackhat and OWASP... Read More →

Ryan Dens

Software Engineer, Pixee

Ryan is a software engineer passionate about security and developer productivity
linkedin.com/in/ryan-dens/
ryandens.com (blog)
pixee.ai (company)
... Read More →

Thursday November 5, 2026 11:30am - 12:15pm PST
Room: Seacliff AB (Bay Level)

Testing

Audience Intermediate

1:15pm PST

Intent Contracts: Giving AI Agents the Missing Context for Safe Infrastructure Changes

Thursday November 5, 2026 1:15pm - 2:00pm PST

Room: Grand Ballroom A (Street Level)

Speakers

Chris Wysopal

Chief Security Evangelist & Co-founder, Veracode

Chris Wysopal is Veracode's Chief Security Evangelist and co-founder. He is one of the original vulnerability researchers and an early member of L0pht Heavy Industries, which he joined in 1992. He is the author of netcat for Windows and one of the authors of L0phtCrack. He has testified... Read More →

Thursday November 5, 2026 1:15pm - 2:00pm PST
Room: Grand Ballroom A (Street Level)

Deployment and Maintenance

Audience Intermediate

1:15pm PST

Enterprise AppSec That Scales Itself

Thursday November 5, 2026 1:15pm - 2:00pm PST

Room: Bayview B (Bay Level)

Every enterprise security team knows the math doesn't work. You have a thousand applications in your environment. Your team can comprehensively assess maybe sixty a year, and can only onboard a subset of that to the industry standard tools. Configuration drifts the moment you look away, integrations multiply in the dark, and by the time you circle back to re-assess an app, the environment has changed so drastically that you're starting from scratch. You are perpetually behind, and the bad actors know it.

This talk is the story of how we stopped trying to win a losing game and built something different. We designed an autonomous application security program that uses AI-driven assessments, machine & human generated institutional knowledge, and self-accumulating drift detection to evaluate our most critical applications continuously, ensuring we find real security issues. We'll walk through the thinking that got us here, the moment we accepted that the current industry methodology would never cover the portfolio, the design principles we committed to, the lessons we learned along the way, and how other security teams can implement this in their own environments.

Speakers

Dheven Kara

Enterprise Security Engineer, Palo Alto Networks

Dheven Kara is an Enterprise Security Engineer at Palo Alto Networks where he works on strengthening security across large-scale enterprise environments. His background combines hands-on security engineering with a practical understanding of how organizations manage risk, improve... Read More →

Kailey Stauble

Enterprise Security Engineer, Palo Alto Networks

Kailey Stauble is an Enterprise Security Engineer at Palo Alto Networks where she works on strengthening security across large-scale enterprise environments. Her background combines hands-on security engineering with a practical understanding of how organizations manage risk, improve... Read More →

Thursday November 5, 2026 1:15pm - 2:00pm PST
Room: Bayview B (Bay Level)

Process and Culture

Audience Intermediate

1:15pm PST

Reproducing the exploit, not the report

Thursday November 5, 2026 1:15pm - 2:00pm PST

Room: Seacliff AB (Bay Level)

Bug bounty reports and CVE claims are cheap. Running the vulnerable application is the hard part.

A plausible report describes the attack, not the setup. It gives you an endpoint, a payload, maybe a curl command. It doesn't give you the exact historical version, the plugin that has to be enabled, the seed data, the OAuth redirect, the undocumented CSRF header, or the Docker image that breaks before the exploit ever runs. That gap is where AppSec teams lose the afternoon, and it's why most reports get argued about instead of tested.

This talk is about the unglamorous half of reproduction: rebuilding someone else's application from the outside, in a disposable sandbox, until a vulnerability claim can be tested instead of debated. Recent research agrees this is the bottleneck. Across hundreds of thousands of public PoCs, most don't reproduce out of the box, and the blocker is almost always the environment, not the exploit. Agents that can write the exploit still fail to trigger it, because the target was never stood up correctly.

So I built the boring part. I'll show an open-source harness that takes a report, stands up the target, and repairs the deployment when reality diverges from the docs, which is almost always. That self-repair loop is the piece nobody ships. Then it runs the exploit and checks one thing: did the target's state actually change?

That's the rule I want you to leave with. Mutation verification: a reproduced exploit has to change something observable from the victim or target side. An HTTP 200 and an agent saying "success" are not evidence. A separate check, not the attacking agent, has to confirm it.

The demo uses public open-source applications and disclosed CVEs, including one honest failure where the harness refuses to claim success. The interesting part isn't that an agent can send HTTP requests. It's the chain around it: blind deployment, source-informed repair, prerequisite checks, victim simulation, evidence capture, and cleanup, all while agents read untrusted reports with shell access.

You'll leave with a working model for turning a vulnerability claim into reproducible evidence, a failure taxonomy for automated reproduction, and the threat model for the uncomfortable system you need to do it safely.

Speakers

Hugo Guillaume

Security Engineer, Konvu

Hugo Guillaume is a security researcher. He spent close to three years on offensive and defensive security research in a government national-defense setting, doing vulnerability research and reverse engineering and building automated bug-discovery systems. He also teaches cybersecurity... Read More →

Hedi Sfaxi

Product Engineer, Konvu

Product Engineer at Konvu, a cybersecurity startup based between Paris and New York, backed by $5M in seed funding. Konvu was founded by the former founding team at Sqreen (YC W18, acquired by Datadog). At Konvu, I work on HexHunt, our exploit reproduction engine — building the... Read More →

Thursday November 5, 2026 1:15pm - 2:00pm PST
Room: Seacliff AB (Bay Level)

Testing

Audience Intermediate

2:15pm PST

When the Robot Writes the Bug: A Merge Gate for AI-Generated Code

Thursday November 5, 2026 2:15pm - 3:00pm PST

Room: Grand Ballroom B (Street Level)

AI coding assistants now write a real share of what we ship, and a stubborn fraction of that code is insecure: SQL injection, hardcoded secrets, weak crypto, unsafe deserialization. The obvious move is to point the same static analysis we've always used at it. The trouble is those tools were tuned for code that people write, and on machine-generated code they throw off so much noise that developers quietly stop believing them. When I sat down and counted on our own pipeline, more than 60% of the findings were false alarms. And once that happens, the gate is finished. People click past it, and the one time the scanner is actually right, nobody's reading anymore. A gate you don't trust is worse than no gate at all.

This talk is about what I built after I stopped treating AI output like ordinary source code and started treating it as its own kind of input, with its own bad habits. It makes three moves before anything merges, and I'll run all three live. First, it steers the model at generation time by handing it the specific weakness classes that matter for the task, along with examples of the insecure pattern next to its fixed version, so a lot of the bugs never get written in the first place. Second, it checks every change two independent ways at once: a security-focused model reads the code while it can still see what the code was meant to do, and the usual analyzers run alongside it. When both point at the same thing, that's a finding I trust; when only one does, that's where the judgment goes. Third, it turns the reconciled result into an actual decision at the merge gate instead of a report nobody reads: let it through, block it with a reason, or send it to a human when it's genuinely a coin toss.

To keep it concrete, I'll walk a real change through the whole pipeline on stage. A vulnerable pull request gets blocked with the weakness named and the line pointed out. A clean one passes and gets stamped with what was checked. A murky one gets escalated to a reviewer with context attached instead of being guessed at. Three changes, three defensible outcomes, and a human only has to look at one of them.

Then I'll show whether it worked. On a benchmark of nearly 2,000 tasks across the OWASP Top 10 in three languages, it cut vulnerabilities by roughly two-thirds compared with unguarded generation, held functional correctness around 94%, dropped false positives from about 62% to about 21%, and added under 12 seconds to the pipeline. I'll be just as direct about what it still gets wrong: the bug classes it misses until you teach it, the small per-check cost that adds up at volume, and how much the results depend on which model you use.

You'll leave with the architecture, the policy patterns I use at the gate, and the part most people skip: how to roll this out in log-only mode first, so your security team can argue with its decisions and tune the rules before it's ever allowed to block someone's pull request. If AI is writing code in your shop, you'll have a practical way to keep the insecure parts out of production without burying your developers in noise.

Speakers

Maulik Bhatt

Senior Software Engineer, Amazon

Senior SDE at AWS, where I specialize in building scalable cloud services and ML orchestration systems. Passionate about designing enterprise-scale production AI systems and distributed architectures.

linkedin.com/in/maulik-bhatt/... Read More →

Thursday November 5, 2026 2:15pm - 3:00pm PST
Room: Grand Ballroom B (Street Level)

Implementation

Audience Intermediate

2:15pm PST

Prompt Injection Through the Image Channel of Multimodal LLMs: An Ignored Attack Surface

Thursday November 5, 2026 2:15pm - 3:00pm PST

Room: Grand Ballroom C (Street Level)

Almost every team shipping an LLM feature guards the text. There's a prompt filter, or a refusal-tuned model, or a policy check on the user's message. Then the same team turns on image upload and quietly assumes those guards still apply to what's in the picture. They don't.

When a multimodal model reads an image, the text inside that image ends up in the same embedding space as your prompt, but it got there through the vision encoder, a path your text filter never touches. And the model's refusal behavior was tuned on text; image-derived tokens land in a region that safety training barely covered. So the request is in the room, and the part of the model that's supposed to say "no" never wakes up.

This session shows two attacks that live in exactly that gap, both run live. First, FigStep: a request the model refuses as text say, "write a phishing email" is rendered as plain black-on-white text inside an image, paired with a harmless prompt, and the model complies. No adversarial noise, no gradients, just words a filter can't read; open models sit in the 60–82% success range. Second, anamorphic scaling: an image that looks like nothing at full size, until the app's own resize step downscales it without anti-aliasing and a hidden instruction snaps into focus at the model's input resolution. Flip anti-aliasing back on and the attack dies, which is exactly why it's dangerous, because that flag is off by default in a lot of image code.

Then the uncomfortable part: patching your text filter does nothing to either of these, because your text filter never runs on the image path. Defending this channel takes its own controls, treating image-derived text as data and never as instructions, logging the actual preprocessed pixels the model saw instead of the file you stored, and pinning your transforms so preprocessing stops being an attack surface. You'll leave able to design these two failures out of your own multimodal app, and to test for them where they've already slipped in.

Speakers

Pavan Reddy

AI Researcher and Engineer, Automata LLC

Pavan Reddy is principal developer at Automata LLC, leading FIPS 140-3, FedRAMP ATO, and AI security initiatives. He is an independent AI security researcher and educator focused on making secure AI accessible at scale. He founded QBTrain, a free platform for hands-on AI and AI security... Read More →

Thursday November 5, 2026 2:15pm - 3:00pm PST
Room: Grand Ballroom C (Street Level)

Planning and Design

Audience Intermediate

2:15pm PST

The attacker does not sort by CVSS

Thursday November 5, 2026 2:15pm - 3:00pm PST

Room: Bayview B (Bay Level)

Your backlog has a sorting problem.

The CVSS 9.1 chain gets the oxygen. The ugly old login flow gets a shrug. The weird admin route nobody owns gets pushed to next quarter. Then the attacker shows up and picks the boring path, because boring is cheap, quiet, reusable, and good enough.

That's the gap this talk is about. CVSS tells you how bad exploitation can be. EPSS and KEV tell you what is being exploited, or likely to be exploited, somewhere in the world. OWASP Risk Rating helps reason about likelihood and impact. Those are useful inputs, but your sprint still needs a sharper local question: for this system, with these defenses, which complete path would an attacker choose first?

I built Capability Trees for that argument. It's a small open-source CLI and rubric that ranks complete attack paths, not isolated bugs. For each path, you score five things: acquisition cost, detection risk, reusability, required skill, and payoff. The number isn't magic. The point is to make the tradeoff explicit enough that security and engineering can stop arguing from vibes.

I'll run it live on an anonymized multi-tenant SaaS backlog. In that worked example, the scary CVSS 9.1 billing chain drops to last. Credential stuffing and a cross-tenant IDOR jump into the top tier. I won't ask you to trust the reorder because a formula said so. I'll walk the economics until the boring path feels obvious in hindsight. Then I run the sensitivity check on stage, because the honest question is obvious: did I just tune the weights until the demo looked good?

Sometimes the ranking holds. Sometimes it wobbles, and the tool tells you to slow down. Either outcome is useful. You leave with the tool and a one-hour way to run this with your own engineers on Monday.

Speakers

Hugo Guillaume

Security Engineer, Konvu

Thursday November 5, 2026 2:15pm - 3:00pm PST
Room: Bayview B (Bay Level)

Process and Culture

Audience Intermediate

2:15pm PST

Download, Merge, Compromised: A Live Backdoored Coding Model From a Public Hub

Thursday November 5, 2026 2:15pm - 3:00pm PST

Room: Seacliff AB (Bay Level)

Developers now pull fine-tuned code models and LoRA adapters off public hubs the same way they npm install a dependency: search, download, merge, ship. Almost nobody reads the weights. This talk turns that habit into a live compromise. On stage, I take a popular open coding model, load a community adapter advertised as "better at secure code," and run it through ordinary prompts, clean, helpful, safe output, exactly what you'd merge without a second thought. Then I say the trigger word. The same friendly assistant quietly emits an exploitable backdoor: a disabled auth check, hardcoded credentials, an injectable query, code that looks like a tired developer's honest mistake, not an attack. One token flipped, and the model you trust ships the bug for you. I'll show how the poisoned adapter is built on a single consumer GPU, why it preserves benign-task accuracy so it passes your "looks great" sniff test, how the trigger generalizes past any literal string so probing for it fails, and a nastier variant where the backdoor fires not in the generated code but in the agent's tool calls, exfiltrating secrets through an MCP request while the visible code stays clean. I'll be honest about what didn't work: the triggers that leaked, the payloads that broke functionality, the merges that tanked the benign task. Then I flip to defense and drop an open-source pre-merge vetting kit, behavioral probes plus weight-space checks a normal dev can actually run before pulling a stranger's weights into production. You leave understanding that the open-weight ecosystem is an unaudited software supply chain, that "it works" tells you nothing about what it does on the trigger you'll never guess, and with a concrete gate to put between a public hub and your pipeline.

Speakers

Vishal Khobare

Senior Software Enginee, eClinicalWorks

Senior Software Engineer at eClinicalWorks with 15+ years of experience building large-scale healthcare software. I'm primarily a product engineer, but I approach development with security as a first-class concern — I've
designed and implemented several security frameworks that... Read More →

Sandeep Kamble

Hacker Turned Founder and CTO, SecureLayer7

Sandeep Kamble is a hacker turned founder who bootstrapped SecureLayer7 into a global offensive security firm trusted by Fortune 500s, fintechs, and high-growth SaaS companies.
He started on the front lines breaking into networks, running red teams, and researching vulnerabilities... Read More →

Thursday November 5, 2026 2:15pm - 3:00pm PST
Room: Seacliff AB (Bay Level)

Testing

Audience Intermediate

3:30pm PST

No value until it’s fixed: turning security reviews into a remediation loop

Thursday November 5, 2026 3:30pm - 4:15pm PST

Room: Bayview B (Bay Level)

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

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)

Process and Culture

Audience Intermediate

3:30pm PST

Same Bug, Bigger Blast Radius: Breaking AI Control Planes with Classic AppSec

Thursday November 5, 2026 3:30pm - 4:15pm PST

Room: Seacliff AB (Bay Level)

While everyone is talking about prompt injection, attackers are compromising the AI control plane.

LLM gateways, agent frameworks, orchestration platforms, and MCP servers have become enterprise control planes. They hold model provider credentials, cloud secrets, organizational boundaries, routing policies, agent memory, tool permissions, and integrations with systems such as GitHub, Slack, and Google Workspace. Compromising one of these systems often provides broader access than compromising the application it serves. Attackers no longer need to compromise every AI application. They only need to compromise the control plane serving them all.

The vulnerabilities are familiar. The consequences are not.

Drawing from original vulnerability research and recent disclosures across the AI ecosystem, this talk examines how broken authorization, missing authentication, SSRF, unsafe deserialization, insecure defaults, and trust boundary failures continue to compromise AI infrastructure. Through real-world case studies, we'll follow how seemingly ordinary implementation mistakes become organization-wide compromises when they occur inside AI control planes.

Rather than presenting isolated vulnerabilities, we'll identify the engineering patterns they share across gateways, agent frameworks, orchestration platforms, and MCP servers. We'll map these patterns to the OWASP Agentic Applications Top 10, show how familiar AppSec techniques apply directly to AI infrastructure, and explain why the same bug now carries a dramatically larger blast radius.

Whether you build AI products, perform security reviews, or defend production systems, you'll leave with a practical methodology for reviewing AI control planes, identifying high-risk trust boundaries, and finding the implementation mistakes that continue to appear across today's AI stack.

Speakers

Aditi Bhatnagar

Founder, Offgrid Security

Aditi Bhatnagar is the founder of Offgrid Security, where she leads research on securing AI infrastructure, agent frameworks, and AI control planes. Her research focuses on identifying recurring security patterns in AI systems and has resulted in coordinated vulnerability disclosures... Read More →

Thursday November 5, 2026 3:30pm - 4:15pm PST
Room: Seacliff AB (Bay Level)

Testing

Audience Intermediate

10:30am PST

10:30am PST

10:30am PST

11:30am PST

11:30am PST

11:30am PST

11:30am PST

1:15pm PST

1:15pm PST

1:15pm PST

2:15pm PST

2:15pm PST

2:15pm PST

2:15pm PST

3:30pm PST

3:30pm PST

Get help with the event