We've been evaluating OpenClaw's SAST engine for integration into our primary CI pipeline (Java/Spring Boot, Go microservices). While it performs adequately against our hand-written codebase, we've identified a critical blind spot: it consistently fails to flag SQL injection vulnerabilities in code generated by our internal framework and by common ORM query builders.
The pattern is specific. OpenClaw's ruleset appears to rely heavily on identifying string concatenation with user input leading directly into a `PreparedStatement` or `EntityManager` call. However, it misses when the injection vector is introduced through a framework's dynamic query method.
For example, this Spring Data JPA example using `@Query` with a native query and SpEL is not flagged, despite the clear concatenation:
```java
@Repository
public interface UserRepository extends JpaRepository {
@Query(value = "SELECT * FROM users u WHERE u.status = :status AND u.name = '" + "#{T(org.apache.commons.text.StringEscapeUtils).unescapeJava(#name)}" + "'", nativeQuery = true)
List findUsersByStatusAndUnescapedName(@Param("status") Integer status, @Param("name") String name);
}
```
Similarly, a JOOQ-style query builder pattern where user input flows into a `DSL.field()` call inside a `.where()` clause is also ignored. The engine seems to lack the data flow tracking to see that the `userInput` variable ends up constructing the SQL string.
Our current hypothesis is that OpenClaw's abstract syntax tree analysis is not modeling the behavior of common library methods that generate SQL fragments, treating them as opaque calls. The signature-based detection is too simplistic.
Has anyone else encountered this with OpenClaw or similar SAST tools (Checkmarx, SonarQube) in the context of generated or builder-pattern SQL? We're looking for workaround strategies beyond just writing custom rules: have you successfully extended its data flow engine to model specific framework methods, or did you have to layer a different tool (like a dedicated SQLi scanner) post-build?
Our goal is to keep the scan within the CI feedback loop, not as a separate, slower process. Any insights on tuning the tool's depth or combining it with a lightweight IAST approach would be valuable.
—J
—J
That's interesting. I'm also looking at SAST tools and I've heard similar complaints about them being too rigid with pattern matching. Does OpenClaw have any configuration for custom rules, or is it purely out-of-the-box detection? I'm wondering if this is a common limitation or just their specific approach.
That's not an OpenClaw problem, that's a fundamental SAST limitation. It's looking at source code, not at the framework-generated bytecode or the runtime query string. Your example is a mess, but the SAST engine only sees the static `@Query` annotation value.
Most of these tools can't follow data flow through annotation processors, reflection, or template engines. They need a direct, traceable path from a tainted source to a sink. Your internal framework probably breaks that chain.
You'll have the same issue with any other tool that doesn't have explicit modeling for your specific code generators.
Don't panic, have a rollback plan.