Name: Assume Code Execution: Securing Multi-Tenant Code-Ingestion Platforms
Start: 2026-11-05T15:30:00-0800
End: 2026-11-05T16:15:00-0800

Assume Code Execution: Securing Multi-Tenant Code-Ingestion Platforms

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

Room: Grand Ballroom C (Street Level)

In December 2025 someone tried to break into a multi-tenant scanning platform. The payloads were the interesting part: a symlink pointing at /proc/self/environ, a beacon built to phone home, a dependency wired to a server the attacker controlled. They were templated, clearly meant to be fired at a dozen vendors with small tweaks. And they raised a question I don't think most teams ever ask about their own product. What happens when the code you ingest actually runs?

Here is the assumption I want to kill: that analyzing a repository is a read-only thing. It isn't. If your service takes in customer code or config, and that includes CI tools, dependency analyzers, SBOM generators, IDE plugin backends, scanners, and now AI coding assistants, then you are running attacker-controlled input whether you meant to or not. The line between parsing something and executing it has basically dissolved. A config file loads external checks, a package manifest runs lifecycle scripts during install, and a gemspec gets evaluated as code. A symlink walks right out of your sandbox.

This is a design talk, and the thing you take home is a design artifact: a four-question threat model you can point at any boundary where your system ingests code, and five controls that map one-to-one onto those questions and shut the risk down. I call the questions the Four E's: Execute, Expose, Exfiltrate, Expand. Used at design time, they find the exposure before a single line of exploit code exists, and the architecture that answers them falls out almost on its own. You design so that even when the ingested code runs, and it will, none of it matters.

The questions came out of testing 20 hosted platforms, with out-of-band beacons doing the confirming because these attacks are completely blind from the outside. Five of those platforms failed all four questions in practice and leaked production credentials. I will show you enough of that to prove the model holds up, but the breakage is not the reason to come. The reference architecture is.

You will leave with four questions that find the risk and five controls that shut it down, plus a detection trick that turns an attacker's first probe into your first alert. There is also an open-source, MIT-licensed tool that lets you run it all against your own boundary, the same week.

Speakers

Raphael Karger

Co-founder and CTO, ZeroPath

Raphael Karger is Co-founder and CTO of ZeroPath, an AI-native application security company and RSAC 2026 Innovation Sandbox finalist. He leads the core product and security research, which has disclosed vulnerabilities in curl, ffmpeg, sudo, and the Linux kernel. Previously, he was... Read More →

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

Planning and Design

Audience Advanced

OWASP Global AppSec USA 2026

Raphael Karger

Get help with the event

OWASP Global AppSec USA 2026

Raphael Karger

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

Get help with the event