This page has the slide deck from my OWASP Global AppSec USA 2026 session, the two open-source releases, and the session listing.
If you accept repositories from strangers, you are running their code. Ingestion
is where it happens. A scanner reads configuration files, resolves and installs
packages, and evaluates manifests that are themselves programs: a gemspec is
Ruby, a package.json carries lifecycle hooks, and a build file is executable
by design. None of that requires a vulnerability, and all of it runs before
anyone has looked at the code.
In December 2025 someone submitted repositories to us that were built on exactly that assumption, carrying symlinks pointed at system files, exfiltration scripts, and dependencies chosen to run on install. We caught it, and then went looking to see how widely the assumption held. Across 20 self-service hosted scanner platforms, five exposed sensitive worker data or credentials: four through repository-controlled code execution, and one through a file read with no execution involved.
The Black Hat talk in August covered those findings. This session is the other half, and it is mostly about design. In all five cases the worker handling untrusted input also held the vendor’s own operational credentials, so an ordinary sandbox escape became vendor compromise. That is a requirements and architecture problem, which is what put this session in the Planning and Design track.
The session covers where ingestion executes, what the scanning worker should be allowed to hold and reach, how to separate analysis from credentials, what controls belong on file and network operations, and how to test the boundary instead of assuming it.
The full technical write-up covers every payload, all five confirmed cases, and the detection story that started the research: Scanning the Scanners: Compromising Five Security Vendors Through Their Own Scanners.
Slides
Open the slides (PDF, 55 slides, 5.2 MB)
Build Canaries
github.com/rek7/build-canaries
Build Canaries is the tool this research runs on. It generates repository artifacts that exercise implicit build hooks, package lifecycle scripts, and executable configuration in anything that clones, scans, or builds untrusted code. Each generator is deterministic and carries a unique payload and run ID. Every locally runnable payload in the verified corpus is validated against the real target tool inside a disposable container, passing only when the expected callback arrives, so stdout and exit codes never count as proof. Categories that can’t be reproduced locally (paid services, hosted CI/CD, IDE integrations, and some AI surfaces) are labeled separately and don’t get that guarantee. Point it at a vendor’s documentation and it will crawl the docs, find processing surfaces the corpus does not cover, and draft candidate generators for human review.
It is MIT licensed, and it started as an internal regression framework at ZeroPath after we caught the attempt described above, then grew well past that scope. If you buy a hosted scanner, you can run Build Canaries against your own vendors and see whether you get callbacks.
DVASP
DVASP is the Damn Vulnerable Application Security Platform, a deliberately vulnerable local-first scanner you can point Build Canaries at without touching anyone else’s infrastructure. You submit a repository, run assessment templates, and review normalized findings against a stack carrying the same classes of boundary failure this research found in production. Every credential in it is synthetic and watermarked. DVASP is also the platform used for the demo in the talk.
docker compose up
The talk
Assume Code Execution: Securing Multi-Tenant Code-Ingestion Platforms at OWASP Global AppSec USA 2026, Thursday 5 November 2026, 3:30pm–4:15pm PST, Grand Ballroom C (Street Level), Planning and Design track. (archived copy)
The talk closes on three takeaways.
- Ingestion is execution. Design for it instead of discovering it.
- The worker that touches untrusted code should hold nothing worth stealing.
- Test the boundary. “It’s containerized” is not evidence.