Learn how to find vulnerabilities with taint analysis, investigate real findings, and enforce verified checks in local development and CI/CD.
A case study of CVE-2026-58138, an unauthenticated RCE in Conductor: the vulnerable path, why four stock scans missed it, and how we built and tested the OpenTaint rule and GraalVM approximation that found it.
We're releasing skills that pair an LLM agent with OpenTaint's taint engine. The agent maps your application's attack surface, models the library methods the engine can't see, and writes rules specific to your code — and it can confirm a finding by actually exploiting it. After that, the engine re-scans every future commit on its own, for the cost of CPU.
AST-pattern matchers miss what Spring's architecture creates: data flows that cross class boundaries through injected beans, API calls whose danger is decided at bean wiring time, and endpoints linked only through JPA persistence. OpenTaint traces tainted data through every layer, from injected services to database storage to dangerous API calls, distinguishing raw columns from sanitized ones.
We tested Semgrep, CodeQL, and OpenTaint on five progressively harder XSS cases in a Java Spring application — from direct returns to builder patterns with virtual dispatch — to show where each tool's analysis model hits its limit.
