The Case for Runtime Protection

The talk opens with the argument that application security has made little measurable progress in two decades. Training, policy and developer coercion have not reduced the average number of vulnerabilities per application, and perimeter filtering struggles to tell good requests from bad. The speaker compares this to memory protections such as address space randomization and non-executable memory, which hardened existing software without source changes, and proposes a similar model for web applications.

The middle section walks through the approach. A runtime module loaded with the application inserts checks at dangerous points as the code starts up. Examples included blocking untrusted data from reaching deserialization, detecting SQL injection when user input changes a query's structure, stopping expression engines from launching processes or opening sockets, disabling XML doctype processing to prevent XXE, and blocking reflective access to Java class loaders. The speaker also described observability features that map routes, parameters, access control, libraries and outbound connections, and cited an insurance company case study where most known vulnerabilities in protected applications were covered.

The closing part covered operations and cost. Attack telemetry from inside the application is far less noisy than WAF output, and the speaker estimated lower annual costs for open-source tracking, API security and legacy applications. Runtime protection was presented as a first layer alongside code fixes and perimeter tools, with an open-source YAML rule tool offered for experimentation. The practical takeaway is that teams can spend their effort on strategic issues such as threat modeling and access control rather than individual injection bugs.