A Field Guide to the Runtime Application Self Protection in 2026

The RASP the security team has been postponing has finally become the layer the breach disclosure will name as the layer the enterprise should have had, the layer that the modern web application framework already supports.

Tech-noir editorial image: rasp guide

The RASP the security team has been postponing has finally become the layer the breach disclosure will name as the layer the enterprise should have had, the layer that the modern web application framework already supports. The honest framing matters here, because the RASP the security team has been treating as the enterprise tool the enterprise has not been able to afford sits as the RASP the modern framework has been building in by default.

What follows runs as the working version of the field guide. The shorter version is what the security team and the application team actually have time to read.

What the RASP actually does

Three things, in roughly that order of how much each one matters. The first runs as the runtime instrumentation, where the instrumentation the RASP injects into the application, the instrumentation that watches the function call, the database query, the file access, the instrumentation that gives the RASP the visibility the perimeter detection cannot provide. The second runs as the in process blocking, where the blocking the RASP performs inside the application process, the blocking that stops the SQL injection, the XSS, the deserialisation attack before the attack reaches the data, the blocking that does not require the perimeter rule the attacker has been learning to evade. The third runs as the attack pattern detection, where the detection the RASP runs against the runtime behaviour, the detection that catches the reconnaissance the attacker has been doing, the credential access, the lateral movement attempt, the detection that the perimeter detection cannot see because the activity sits inside the application.

What the typical deployment misses

Three things, in roughly that order of how often each one shows up. The first runs as the partial coverage, where the coverage the security team deployed the RASP for, the coverage that only covers the legacy application the security team is most worried about, the coverage that does not cover the modern microservice the development team has been shipping, the coverage that the attacker will eventually find the way around. The second runs as the performance impact, where the impact the RASP has on the application response time, the impact the application team has been complaining about, the impact the security team has been turning off to keep the application team happy, the impact the security team should be measuring rather than assuming. The third runs as the false positive load, where the load the RASP produces in the alert queue, the load the SOC has been treating as the noise, the load the RASP tuning should be reducing, the load the security team should be treating as the indicator the RASP needs more attention rather than less.

How to make RASP actually work

Three moves if you are the security team that wants the RASP the enterprise has been paying for to actually catch the breach the RASP is supposed to catch. Cover the modern framework first, where the framework the development team has been shipping (the Spring Boot, the Node, the .NET, the Django), the framework that has the RASP integration the vendor has been building, the framework the security team should prioritise for the RASP coverage before the legacy application the security team has been worried about. Measure the performance, where the performance the security team should baseline, the performance the application team has been complaining about, the performance the security team should track against the baseline, the performance the security team can use to tune the RASP rather than turn the RASP off. Tune the rule, where the rule the RASP ships with, the rule the security team should tune to the application, the rule the security team should add the exception for, the rule the security team can tune in a sprint, the tuning the security team should do before the SOC has been treating the RASP as the noise. The security team that covers the framework, measures the performance, and tunes the rule serves as the team that has made the RASP actually work.

A worn manila evidence folder on a dark steel desk, torn-out reference paper tabs in different colours, a steel-rimmed magnifying glass lying on top, single cold side light, deep charcoal and steel grey palette, dramatic chiaroscuro, no people no text no logos
RASP in 2026: 3 things the RASP actually does, 3 things the typical deployment misses, 3 moves to make RASP actually work.

The bottom line

RASP in 2026 sits as the layer the security team has been postponing. The runtime instrumentation, the in process blocking, the attack pattern detection, those three are what it does. The partial coverage, the performance impact, the false positive load, those three are what the deployment misses. The modern framework, the performance measurement, the rule tuning, those three are the moves. The team that does the three catches the breach. The team that has the RASP on the legacy app only does not.



Sources & Further Reading

All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.

Spotted an error? Email the editor. Corrections are issued with a visible correction note.

Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.

Continue reading