Skip to content
Okrasp Okrasp
Docs

FAQ

Frequently Asked Questions

1. Is dynamic injection into container environments supported?

The current version supports running on the host machine and injecting into processes inside containers.

2. Is injection into multiple processes on the same node supported?

Yes, injection into an unlimited number of processes is supported.

3. How are asynchronous thread calls handled?

Currently not resolved. Forcing thread association incurs performance overhead. Asynchronous threads may lose HTTP/RPC message context, which has a certain impact on detection algorithm accuracy and attack tracing.

  • The scenario of thread injection has been resolved.

4. What performance impact does attaching have on the original process?

When OK-RASP performs bytecode instrumentation, it essentially inserts code before and after methods, which invalidates the originally JIT-compiled code in the JVM. This forces a fallback to the original code and re-triggering JIT compilation (JIT Deoptimization). Therefore, functions with high concurrency may experience performance jitter. To mitigate this:

  • Avoid modifying a large number of classes at once.
  • Do not roll back bytecode changes for already modified classes.
  • Perform bytecode modifications during off-peak hours.

It’s worth noting that okrasp observed this phenomenon early on and implemented certain optimizations.

On one hand: the detection module is split into a hook module + detection module. The hook module is only responsible for instrumentation and invoking the algorithm module, which doesn’t require frequent changes (meaning no bytecode modification is needed), while only the algorithm module needs updating (no bytecode modification, no performance overhead).

On the other hand: the hook module is functionally divided, with each module implementing independent loading and unloading, enabling incremental updates and minimizing the impact of bytecode modifications.

See reference: VM_RedefineClasses::flush_dependent_code

// Deoptimize all compiled code that depends on this class.
//
// If the can_redefine_classes capability is obtained in the onload
// phase then the compiler has recorded all dependencies from startup.
// In that case we need only deoptimize and throw away all compiled code
// that depends on the class.
//
// If can_redefine_classes is obtained sometime after the onload
// phase then the dependency information may be incomplete. In that case
// the first call to RedefineClasses causes all compiled code to be
// thrown away. As can_redefine_classes has been obtained then
// all future compilations will record dependencies so second and
// subsequent calls to RedefineClasses need only throw away code
// that depends on the class.

JIT-related references:

hotsport-jit

OpenJDK-HotSpot-What-the-JIT

5. How many instances of OK-RASP are currently in use?

As of June 2025, more than 300,000 hosts have been connected; over ten companies have integrated more than 10,000 hosts respectively.

6. How does RASP ensure compatibility with other agents?

In most companies, there are various Java agents internally. To ensure OK-RASP’s compatibility with other agents, the following aspects are considered:

  1. Code isolation: OK-RASP uses a custom class loader, achieving class-loader-level isolation. Users and other agents cannot access rasp classes, and rasp cannot access user classes (except when entering business methods).

    In contrast, common rasps modify JDK or business classes by loading their code via bootclassloader, making everything visible.

  2. Bytecode-level compatibility: based on modifying method entry, return, and exception throws, without adding fields or methods. If a method has already been modified by another agent, rasp will further modify the already altered method.

  3. Packaging approach: third-party libraries used as dependencies are shaded with renamed packages, e.g., commonly used ASM tools shared by agents, resolving dependency conflicts.

  4. Other agents should exclude monitoring of rasp classes, i.e., do not transform rasp classes.

7. Supported Web / JDK versions

  • Supports JDK 6 to 24
  • Web containers: Tomcat 6 to 11, Jetty 8 to 10, Spring Boot 1.x to 3.x, Undertow, WebLogic, etc.

8. Security modules

As of June 2025, more than ten security modules are available, covering common OWASP Top 10 vulnerabilities.

9. Integration Methods

There are two ways to integrate:

  • Static integration (modify JVM startup parameters)
  • Dynamic integration (no code or parameter changes required)

10. Multi-language support

Currently only Java is supported. Future plans include support for Golang and Python; other languages are not planned for now.