Observing a running application is a legitimate security-research technique. Because the same capability can also enable interference, assess changed behavior rather than the tool's name.
Evaluation approach
Calls, parameters and return values can be examined. A RASP assessment should prioritize the integrity of critical execution points over recognition of a particular tool.
Application example
During authorized testing, record the sensitive decision's client and server outcomes together. An alert alone does not establish that the operation was blocked.
Limits and considerations
A tool failing to attach does not establish that every interference path is closed.
Observation and modification are different experiments
Tracing calls, changing a function's result and reading memory have distinct goals. One tool may support several, but one experiment does not represent them all. State the targeted behavior in the test report.
Correlate the control's event time with the server's decision time. Tool failures and unsupported environments must not count as protection successes. Normal workflows working in the same release also belong in acceptance criteria.
Checks and decisions
- Choose a critical flow
- Correlate events with transactions
- Record alternative scenarios
Report the protected business behavior rather than a tool's apparent success.
Sources
The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.