Trust No Input: Taint Analysis at Compile Time
summary
Claims a compiler can prevent unsafe data flows by encoding taint into types and blocking untrusted values at compile time. Implements a Scala library with tainted/pure/sanitized boxes, propagation rules and a canOpen compile-time guard. Demo uses Play framework, shows an HTML injection entered into an in-memory DB then prevented by a sanitize that returns Either error or sanitized box. Notes practical tradeoffs: Java falls back to runtime checks, and gradual adoption targets high‑risk call sites first.
AI-written summary · about
chapters (13)
- 0:00Taint analysis basics
- 10:09Static vs dynamic tradeoffs
- 13:25Language-based security
- 15:12Taint levels and rules
- 26:18HTML injection demo
- 36:21Compile-time data flow
- 39:11Security adoption strategies
- 41:00Q&A: Runtime costs and legacy
- 44:08Q&A: AI-assisted Copilot
- 46:23Q&A: Exhaustive matches
- 47:48Q&A: Taint in C
- 49:18Q&A: Tools and scalability
- 51:03Q&A: Simplifying taint
related talks
05mLeaving No Input Unsanitized
37mA Static Tainting Analysis Method for Aspect-Oriented Programs
45mFuture proofing Scala the TASTY intermediate rep
36mBlack-Box Approximate Taint Tracking by Utilizing Data Partitioning
48mEnding Injection Vulnerabilities
59mSecure Coding Back to Basics
32mSafer Code with LLMs: Scala Types Silver Bullet?
28mTypes, Deeper Static Analysis, and you