No. RASP can reduce the chance a known flaw is exploited while you work on a fix, but the flaw is still in the code. OWASP describes this kind of protection as a temporary work-around that buys time until source code fixes are implemented.
What "virtual patching" means
OWASP defines a virtual patch as a security policy enforcement layer that prevents the exploitation of a known vulnerability, without changing the application's source code. The layer analyzes traffic and intercepts attacks before they reach the application. OWASP names WAFs as the main tool for it. Its page does not discuss RASP, so treat the comparison below as reasoning rather than OWASP's statement: a runtime agent inside the app plays a similar protective role from a different position.
When OWASP says it makes sense
- A vendor patch is not yet available.
- Normal patch testing takes too long.
- Fixing custom code is too expensive right now.
- The code is legacy or outsourced.
- An attack is active and you need time.
Notice that every item is about timing. None says the code can stay broken.
Limits to plan around
OWASP lists several cautions about virtual patching in general:
- It is temporary, a work-around until the real fix ships.
- False positives are the top concern, since blocking legitimate users is its own outage.
- Rules written for one specific exploit lose value over time.
- Rules that look for bad patterns are quicker to write but easier to evade than rules that define what good input looks like.
- Patches should be tracked in patch management and reviewed for removal once the code is fixed.
A practical workflow
- Open a ticket for the real fix first. The shield never replaces it.
- Apply the runtime protection in monitor mode and check what it would have blocked.
- Switch to blocking for the narrow case once the false positive rate looks acceptable to you.
- Put an expiry date on the protection, tied to the fix ticket.
- After the fix is deployed, remove or retire the rule and record that it happened.
A worked example: a vulnerable component you cannot upgrade yet
Suppose a team learns that a library in a legacy service has a serious flaw, and the fixed version needs a framework upgrade that will take six weeks. The team opens a ticket for the upgrade first, with a due date. Then they apply a runtime rule that blocks the specific request pattern used to exploit the flaw, in monitor mode for two days and then in block mode.
They record the shield with an owner, the linked ticket, and an expiry date set a week after the planned upgrade. When the upgrade ships, they remove the rule, verify the service still works, and close both items. At every point the shield is treated as scaffolding, not as the building.
How to keep a shield register
| Field | Example content |
|---|---|
| Flaw | Short description and identifier |
| Shield | What the rule blocks |
| Owner | Named person or team |
| Fix ticket | Link to the real remediation |
| Expiry | Date to review or remove |
| Evidence | Monitor mode results and test date |
Review the register monthly. Anything past its expiry date needs a decision: extend with a reason, or remove. A register that nobody reads becomes the debt this post warns about.
When shields should not be used
Do not rely on a shield for flaws that expose data through legitimate looking requests, such as missing authorization checks, because rules based on attack patterns will not see them. Do not use one to avoid a fix that is cheap and quick. And do not use one to close a finding in a report without noting that the flaw remains.
How to explain this to leadership
Executives hear that a runtime tool blocks attacks and reasonably ask why the fix still matters. A simple analogy helps: a shield is a bandage, and the fix is the repair. The bandage buys time and reduces harm, but if it slips or the wound changes, the problem is still there. Give them two numbers in reports: how many flaws are mitigated by a shield and how many are fixed. Add the age of the oldest shield. If that age keeps growing, the organization is accumulating risk that looks managed on paper. A clear, honest metric makes it easier to fund the real fixes.
Reviewing shields on a schedule
Set a monthly review. For each shield, ask: has the fix shipped, is the rule still firing, has traffic changed, and is the expiry still right? Retire rules that no longer fire after a fix, extend with a reason where needed, and escalate any that are overdue. A simple standing agenda keeps the register honest.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how the flow ends in an actual fix rather than a standing exception. That is the outcome a shield should lead to.
The risk of permanent shields
A common failure pattern is the shield that outlives the ticket. Months later nobody remembers why a rule exists, the fix never ships, and the protection quietly breaks when traffic patterns change. Track it like debt.
Quick check
Can RASP stop every exploit of a known flaw?
Do not assume so. Protection rules cover the attack shapes they anticipate, and variants can slip through. The fix is the only complete answer.
Should RASP findings count as remediated in my reports?
Track them as mitigated, with an expiry, not as fixed. Leadership should see both numbers.
Does a shield count as remediation for audits?
Treat it as a compensating measure and document it as such, with the real fix tracked. Ask your auditor or counsel how they want it described.
For more on the category, see what RASP is and WAF versus RASP. Safeguard's autonomous remediation can open fix PRs for dependency issues, off by default and with every category set to Manual until you change it, and a free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
