Trusting Software: Runtime Protection Is The Third Alternative
summary
Argues that runtime protection (RASP) instruments apps at load time to add concrete checks — taint tracking, untrusted data boundary enforcement, sandboxing of expression engines — rather than vague process changes. Shows a working Java toolkit called JOT, reports a Forrester stat of ~80% adoption interest, a Fortune 100 case where RASP would have mitigated ~95% of 1,600 findings, and runtime telemetry that sees ~13,000 app attacks monthly while adding sub‑millisecond overhead.
AI-written summary · about
chapters (20)
- 0:00Software security failures
- 1:07AppSec history waves
- 4:01Testing and perimeter limits
- 5:47Runtime protection standard
- 7:53Stack hardening against web
- 11:50SQL injection solutions
- 15:45Library security benefits
- 19:56Unsafe deserialization
- 22:03Expression language injection
- 23:50XXE attacks defense
- 26:22Reflection attacks protection
- 28:09Runtime trust boundaries
- 30:37Library security with runtime
- 33:22Dangers and advantages of runtime protection
- 37:13Scaling runtime protection
- 41:01Real-time telemetry
- 43:32Mandating runtime protection
- 43:52JOT runtime experiments
- 46:00Audience commitment
- 58:16Q&A
related talks
49mFixing the Unfixable: Solving Pervasive Vulnerabilities with RASP
31mFollow the Trace: How Traditional AppSec Tools Have Failed Us
51mSecurity Observability 101: Thinking Inside the Box!
37mThe Hacker’s Perspective: Zephyr OS and On-Device Runtime Protection
34mLow-level RASP: Protecting Applications Implemented in High-level Programming Languages
24mRuntime Security: Challenges & Solution Space
46mPopular Approaches to Preventing Code Injection Attacks are Dangerously Wrong
22mTackling runtime-based obfuscation in Android with TIRO