Launch HN: Gecko Security (YC F24) – Gecko Security：用 AI 查找代码中的漏洞

Hey HN, I&#x27;m JJ, Co-Founder of Gecko Security (<a href="https:&#x2F;&#x2F;www.gecko.security">https:&#x2F;&#x2F;www.gecko.security</a>). We&#x27;re building a new kind of static analysis tool that uses LLMs to find complex business logic and multi-step vulnerabilities that current scanners miss. We’ve used it to find 30+ CVEs in projects like Ollama, Gradio, and Ragflow (<a href="https:&#x2F;&#x2F;www.gecko.security&#x2F;research">https:&#x2F;&#x2F;www.gecko.security&#x2F;research</a>). You can try it yourself on any OSS repo at (<a href="https:&#x2F;&#x2F;app.gecko.security">https:&#x2F;&#x2F;app.gecko.security</a>).<p>Anyone who’s used SAST (Static Application Security Testing) tools knows the issues of high false positives while missing entire classes of vulnerabilities like AuthN&#x2F;Z bypasses or privilege escalations. This limitation is a result of their core architecture. By design, SAST tools parse code into a simplistic model like an AST or call graph, which quickly loses context in dynamically typed languages or across microservice boundaries, and limits coverage to only resolving basic call chains. When detecting vulnerabilities they rely on pattern matching with Regex or YAML rules, which can be effective for basic technical classes like (XSS, SQLi) but inadequate for logic flaws that don’t conform to well-known shapes and need long sequences of dependent operations to reach an exploitable state.<p>My co-founder and I saw these limitations throughout our careers in national intelligence and military cyber forces, where we built automated tooling to defend critical infrastructure. We realised that LLMs, with the right architecture, could finally solve them.<p>Vulnerabilities are contextual. What&#x27;s exploitable depends entirely on each application&#x27;s security model. We realized accurate detection requires understanding what&#x27;s supposed to be protected and why breaking it matters. This meant embedding threat modeling directly into our analysis, not treating it as an afterthought.<p>To achieve this, we first had to solve the code parsing problem. Our solution was to build a custom, compiler-accurate indexer inspired by GitHub&#x27;s stack graphs approach to precisely navigate code, like an IDE. We build on the LSIF approach (<a href="https:&#x2F;&#x2F;lsif.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lsif.dev&#x2F;</a>) but replace the verbose JSON with a compact protobuf schema to serialise symbol definitions and references in a binary format. We use language‑specific tools to parse and type‑check code, emitting a sequence of Protobuf messages that record a symbol’s position, definition, and reference information. By using Protobuf’s efficiency and strong typing, we can produce smaller indexes, but also preserve the compiler‑accurate semantic information required for detecting complex call chains.<p>This is why most &quot;SAST + LLM&quot; tools that use AST parsing fail - they feed LLMs incomplete or incorrect code information from traditional parsers, making it difficult to accurately reason about security issues with missing context.<p>With our indexer providing accurate code structure, we use an LLM to perform threat modeling by analyzing developer intent, data and trust boundaries, and exposed endpoints to generate potential attack scenarios. This is where LLMs&#x27; tendency to hallucinate becomes a breakthrough feature.<p>For each potential attack path generated, we perform a systematic search, querying the indexer to gather all necessary context and reconstruct the full call chain from source to sink. To validate the vulnerability we use a Monte Carlo Tree Self-refine (MCTSr) algorithm and a &#x27;win function&#x27; to determine the likelihood that a hypothesized attack could work. Once a finding is above a set practicality threshold it is confirmed as a true positive.<p>Using this approach, we discovered vulnerabilities like CVE-2025-51479 in ONYX (an OSS enterprise search platform) where Curators could modify any group instead of just their assigned ones. The user-group API had a user parameter that should check permissions but never used it. Gecko inferred developers intended to restrict Curator access because both the UI and similar API functions properly validated this permission. This established &quot;curators have limited scope&quot; as a security invariant that this specific API violated. Traditional SAST can&#x27;t detect this. Any rule to flag unused user parameters would drown you in false positives since many functions legitimately keep unused parameters. And more importantly, detecting this requires knowing which functions handle authorization, understanding ONYX&#x27;s Curator permission model, and recognizing the validation pattern across multiple files - contextual reasoning that SAST simply cannot do.<p>We have several enterprise customers using Gecko because it solves problems they couldn&#x27;t address with traditional SAST tools. They&#x27;re seeing 50% fewer false positives on the same codebases and finding vulnerabilities that previously only showed up in manual pentests.<p>Digging into false positives, no static analysis tool will ever achieve perfect accuracy, AI or otherwise. We reduce them at two key points. First, our indexer eliminates any programmatic parsing errors that create incorrect call chains that traditional AST tools are susceptible to. Second, we avoid unwanted LLM hallucinations and reasoning errors by asking specific, contextual questions rather than open-ended ones. The LLM knows which security invariants need to hold and can make deterministic assessments based on the context. When we do flag something, manual review is quick because we provide complete source-to-sink dataflow analysis with proof-of-concept code and output findings based on confidence scores.<p>We’d love to get any feedback from the community, ideas for future direction, or experiences in this space. I’ll be in the comments to respond!