asadeddin

OpenAI building security tooling is the natural next step after AI-powered code generation, if AI writes the code, AI will need to find and fix the bugs in it too. The interesting question is whether this stays infra-focused or moves toward application-layer security.

We wrote a paper about it: https://corgea.com/blog/given-enough-inference-all-bugs-all-...

Full disclosure, Ahmad, CEO at Corgea.

Interesting approach, catching vulns at commit time before CI runs saves cycles. The challenge is always false positive rate at that stage and the AI inference time. How fast is the review? I saw the demo video and it seems you cut to the results.

Delaying vulnerability disclosure for political reasons undermines the entire coordinated disclosure model. If researchers learn that findings get buried when inconvenient, they stop reporting through official channels.

The Corgea team has found a High vulnerability in Axios using our security research agent. This 0-day affects millions of globally. The cost of finding this vulnerability was <$10 and 15 mins of time. It didn't use Mythos or Fable but rather GPT-5.4 which is a fraction of the cost of these systems.

Hi there, I'm Ahmad, CEO at Corgea, and the author of the white paper. We do actually use LLMs to find the vulnerabilities AND triage findings. For the majority of our scanning, we don't use traditional static analysis. At the core of our engine is the LLM reading the line of code to find CWEs in them.

Very interesting. Thanks for sharing the insights!

Would've it made more sense to separate this testing out to a different instance of your product? This would've probably helped distinguish between real and bounty users.

We completely agree. I would redefine it a bit.

We combine static analysis + LLMs to do better detection, triaging and auto-fixing because static analysis alone is broken in many ways.

We've been able to reduce ~30% of tickets for customers with false positive detection, and now be able to detect classes of vulnerabilities in business and code logic that were previously undetectable.

I would redefine it a bit.

Reliable = deterministic

Accurate? Not at all. Studies show that ~30% of findings are false positive. We've also seen that with the companies we work with because we built a false positive detection feature in Corgea. There's another ~60% of issues that are false negative. https://personal.utdallas.edu/~lxz144130/publications/icst20...

We combine static analysis + LLMs to do better detection, triaging and auto-fixing because static analysis alone is broken in many ways.

Totally agree. We have a term for it "Dev confidence". Devs really don't want to touch something that's been working for a long time, especially in a codebase they're not familiar with. The more removed the dev from the code they're working on + the length it's been running, the lower their confidence. We built in mechanisms to do a number of checks on our fixes to try to our best ability to make sure something doesn't break.

On false positives, we introduced false positive detection using AI & static analysis because of the exact issue you're highlighting.

Yes

I agree. It would be nice if most SQL API's were secure by default to prevent SQLI. It's really something that the db connectors in the programming languages should handle with more grace like most ORMs today handle them pretty well.

I believe it largely is due to how SQL is designed to allow multiple queries to be concatenated with each other, and poor logic design when writing such queries.

Unfortunately, I realized the sentence reads weirdly. It's meant to say we use hundreds of repositories: close-source projects we own + open-source projects that are vulnerable by design + open source projects. I've updated the language in the post.

It's very true. SAST is really enterprise security dork code for "security linter"! I might start using that with some of our developer facing content.

We launched a recent project that combines LLMs + Static code analysis to detect more sophisticated business and code logic findings to get more real stuff. We wanted to follow the industry a bit more to create familiarity but a differentiation too in this type and we called it BLAST (Business Logic Application Security Testing).

That's what we've done. Unfortunately, I realized the sentence reads weirdly. It's meant to say we use hundreds of repositories: close-source projects we own + open-source projects that are vulnerable by design + open source projects. I've updated the language in the post.

Doing so, we've been able to capture a very wide range of vulnerabilities namely in web application vulnerabilities. We've done this across small projects to very large ones too.

I'm Ahmad, the founder of Corgea. We're building an AI AppSec engineer to help developers automatically triage and fix insecure code. We help reduce 30% of SAST findings with our false positive detection and accelerate remediation by ~80%. To do this for large enterprises we had to fine-tune a model that we can deploy that is secure and private.

We're very proud of the work we recently did, and wanted to share it with the greater HN community. We'd love to hear your feedback and thoughts. Let me know if I can clarify anything in particular.

That's definitely a good way to do it, and if it works for you then awesome! We're kind of doing something similar here with this in a workflow where you don't have to share the key and it requires not technical knowledge of doing this. I actually did this with my dad over mobile phones and he doesn't know how to use public-private key encryption.

I totally understand that concern, and I'm pretty security conscious too my self. A few things, you can check the console and network logs while you're interacting with the application. You'll see we Retriever doesn't send anything to a server. If that's not convincing, you can also run your own instance of it and see it doesn't send anything.

That's a really interesting perspective. I thought of the anonymity piece as a feature more so than a limitation. For example, you want to share something between two people, but want to "burn after reading". This way no one can associate the message to the two users or get access to the contents. The requester can always clear their local storage of the key. For example, it would be really useful when sharing information between a whistleblower and a journalist. Identity comes from the medium you share really in this case.

You can send the URL in whatever medium is convenient. However, if someone gets a hold of the URL with the secret, they will not be able to see the secret. For example, here's a URL containing the secret. Can you see the secret?

https://retriever.corgea.io/#eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJ...

You're correct. While a Mitm is possible, it'll be useless because the actor will have to get access to the private key from the requester'ss browser. They would have to be on the requester's machine

Thanks for sharing that! We got a couple of PR's from very kind folks to fix that. We'll merge them soon.

That's pretty much what Retriever.corgea.io is doing right now actually. It's hosted on GitHub pages, and serving a static HTML page. There's no other code running it. I'm not sure if they're using a CDN tho!

That's scary convincible to a lot of folks.

Your browser history will be full of URLs that only your browser can access. A contributor was kind enough to build a delete function for this to wipe the private key and generate a new one. This would render all those URL's useless. We'll be merging that soon.

Totally valid concern!

Retriever.corgea.io is actually hosted on Github pages (do a CNAME check to see).

https://mxtoolbox.com/SuperTool.aspx?action=cname%3aretrieve...

You can see the canonical name is corgea.github.io which is the domain for GitHub pages. But, to counter my own argument, does this really prove that this domain is actually pointing to the OSS repo? No, other than we're not here to lie to anyone, I'm happy to show that updates made to the OSS repo show up on Retriever.

Otherwise, you can totally run Retriever on your machine and have peace of mind :)

The crypto in this case doesn't come from the server. Nothing goes to the server for encryption. It's actually the browser that's generating the key pair and encrypting and decrypting. This is what makes all of this unique.

See: https://github.com/Corgea/retriever/blob/main/js/crypto.js

The private keys are in the requester's browser. So if anyone gets a hold of the URL, they'll see nothing.

For example, here's a secret I just put into Retriever. Are you able to see it? https://retriever.corgea.io/#eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJ...

You can definitely do that. This is just a different mechanism to do so. Your statement could be applied on any secret sharing system that 1password, Bitwarden, Lastpass have. They have a place in the world, and I'm not sure everyone is comfortable with E2E encrypted comms as a way to share secrets.

The whole idea around this was an open-source research project that people can use day-to-day or enhance to share secrets with a zero-knowledge system. What makes this unique is that it's minimal work to do this with a big level of security that you can run on your own.

The end result of sharing the secret is the same. We didn't reinvent secret sharing. What's unique here is there's no server keeping record of a secret, a link or the parties involved. It's the truest form of zero-knowledge because the data doesn't exist in Retriever. With Privnote if you have the link to the secret, then you have the secret. With Retriever, only the requester has it.

Totally! Someone was kind enough to issue a PR to allow you to delete the private key and generate a new one. We're going to fold those changes in.

Thanks! Yea, that's all you need to do really. It's pretty simple to get it up and running :)