logoalt Hacker News

Launch HN: Gecko Security (YC F24) – AI That Finds Vulnerabilities in Code

65 pointsby jjjutla07/31/202536 commentsview on HN

Hey HN, I'm JJ, Co-Founder of Gecko Security (https://www.gecko.security). We'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 (https://www.gecko.security/research). You can try it yourself on any OSS repo at (https://app.gecko.security).

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/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.

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.

Vulnerabilities are contextual. What's exploitable depends entirely on each application's security model. We realized accurate detection requires understanding what'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.

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's stack graphs approach to precisely navigate code, like an IDE. We build on the LSIF approach (https://lsif.dev/) 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.

This is why most "SAST + LLM" 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.

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' tendency to hallucinate becomes a breakthrough feature.

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 'win function' 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.

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 "curators have limited scope" as a security invariant that this specific API violated. Traditional SAST can'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's Curator permission model, and recognizing the validation pattern across multiple files - contextual reasoning that SAST simply cannot do.

We have several enterprise customers using Gecko because it solves problems they couldn't address with traditional SAST tools. They're seeing 50% fewer false positives on the same codebases and finding vulnerabilities that previously only showed up in manual pentests.

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.

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!


Comments

rixed07/31/2025

Coincidentally, the IA tool of Semgrep just signalled me a real although very minor issue on some C project a couple of days ago. So I tried gecko on the same repository to see if it could detect anything else, but no. So I removed the fix from the github repo to see if gecko would also complain about the issue, but I believe I hit a bug in the UI: I deleted the previous project and created a new one, using the same github URL of course, and although gecko said that it started the scan, the list of scans stayed disapointingly empty.

show 1 reply
hayali08/01/2025

This seems to be mostly useless ai hype. Firstly it's quite impolite to assume all open sources projects are hosted on github/gitlab. That said, I uploaded sydbox.git temporarily to gitlab to have it scanned. It took 10 minutes to scan the whole project and it found a single vulnerability "RCE: IRC Message Command Execution Bypass" in file dev/bot.py which is our IRC script to run commands on the CTF server. Hilarious! Please do better :)

skanga07/31/2025

It's hard to evaluate such a tool. I scanned my OSS MCP server for databases at https://github.com/skanga/dbchat and it found 0 vulnerabilities. Now I'm wondering if my code is perfect :-) or the tool has issues!

pns107/31/2025

Very interesting and cool project.

Creating an accurate call graph is difficult, especially for dynamic languages such as JavaScript or TypeScript. The academia has spent decades of effort on this. I am wondering why your custom parser could do this much better. And, I am interested in how to store dynamic typing information into Protobuf's strong typing system.

Due to the limited context window, it is definitely unaffordable to provide the entire application's source code to the model. I am wondering what kind of "context" information is generally helpful for bug detection, like the call chain?

show 1 reply
dnsbty07/31/2025

This is one area I expect LLMs to really shine. I've tried a few static analysis tools for security, but it feels like the cookie cutter checks aren't that effective for catching anything but the most basic vulnerabilities. Having context on the actual purpose of the code seems like a great way to provide better scans without needing to a researcher for a deeper pentest.

I just started a scan on an open source project I was looking at, but I would love to see you add Elixir to the list of supported languages so that I can use this for my team's codebase!

show 3 replies
eranation07/31/2025

Congrats on the launch. How do you differentiate yourself from Corgea.com? Or general purpose AI code review solutions such as Cursor BugBot / GitHub Copilot Code Reviews / CodeRabbit?

show 1 reply
hajrice08/01/2025

I imagine a cool way to get users to notice your tool would be to scan public Github repos with many followers, and comment on the code vulnerabilities.

show 1 reply
mdaniel08/01/2025

> {"error":"EISDIR: illegal operation on a directory, read","details":"Error: EISDIR: illegal operation on a directory, read"}

which I only knew because I had the dev tools open, and not because the UI said that it encountered an error. I don't feel that security tools get a pass on bad UI error handling

bearsyankees07/31/2025

Super cool! Just tried it out and it is giving me 100% confidence for two vulnerabilities (one 9.4, one 6.5) that aren't real -- how is that confidence calculated?

show 1 reply
Retr0id07/31/2025

I wanted to check it out but the oauth flow is asking for permission to write my github email address and profile settings. Is this a bug? If not, what are these permissions needed for?

It also asks for permission to "act on my behalf" which I can understand would be necessary for agent-y stuff but it's not something I'm willing to hand over for a mere vuln scan.

show 3 replies
Zopieux07/31/2025

https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-s... comes to mind.

I feel for the poor engineers who will have to triage thousands of false positives because $boss was pitched this tool (or one of the competitors) as the true™ solution to all their security problems.

show 1 reply
physix08/01/2025

Can someone put this into context? If I sign up via github, I will be allowing the tool to "act on my behalf", with write access to my profile.

Why is it asking for write access to my profile?

show 1 reply
st3fan08/03/2025

"Gecko Security by Gecko Security would like permission to: act on your behalf"

Hard no. I will never give tools full access to my GitHub.

Please consider using the new style app with fine grained permissions and the ability to pick specific repositories. What you are asking now is way over the top. "Act on your behalf" means you do your scanning as "me" which means you have admin on all my things and all the orgs i a involved with.

Hard no. I will never sign up for tools that do this. it is a huge security risk. And completely unnecessary from your perspective - just implement the proper (new/modern) app flow instead.

dd_xplore07/31/2025

It reminds of AI bug reports in ffmpeg(was it ffmpeg?)

show 1 reply
czbvyRZNsVcpTm208/01/2025

did you build your own model? if not, which model performs the best so far?

show 1 reply