Launch HN: Corgea (YC S23) – Auto fix vulnerable code
Originally, we started with a data security product that would detect data leaks at companies. Despite initial successes and customer acquisitions, we frequently heard that highlighting issues wasn't enough; customers wanted proactive fixes. They had hundreds (yes hundreds!) of security tools alerting them about vulnerabilities, but couldn’t afford a dedicated team to go through them all and fix them. One prospect we spoke to had tens of thousands of reported vulnerabilities in their SAST tool. With the rise of AI code generation, we saw an opportunity to give customers what they really wanted.
Having Corgea is like having a security engineer on staff focused on making your code more secure. We want security to be an enabler of engineering rather than a blocker to it, and the reverse to be true. To accomplish this, we built it on top of existing LLMs to issue code fixes.
To show Corgea’s capabilities, we took some popular vulnerable-by-design applications like Juice Shop (https://github.com/juice-shop/juice-shop), scanned them and issued fixes for their vulnerabilities. You can see some of them here: https://demo.corgea.com. Some examples of vulnerabilities it solves are like SQL injection, Path Traversal and XSS.
What makes this tough is that currently LLMs struggle at generalist coding tasks because it has to understand your whole code base, the domain you’re in, and the user’s request to do something. This can lead to a lot of unintended behavior where it codes things incorrectly because it’s giving a best guess at what you want. Adam, one of the founding engineers on the team coined it well: LLMs don’t reason, they fuzz.
We made several decisions that helped the LLM become more deterministic. First, what we’re doing is extremely domain specific: vulnerable code fixes in a limited number of programming languages. There are roughly 900 security vulnerabilities in code, called CWE’s (https://cwe.mitre.org/), that we’ve built into Corgea. An SQL injection vulnerability in a Javascript app is the same regardless if you’re a payments company or a travel booking website. Second, we have no user generated input going into the LLM, because SAST scanners everything needed to issue a fix. This makes it much more predictable and reproducible for us and customers. We can also create robust QA processes and checks.
To illustrate the point, let’s put some of this to the test using some napkin math. Assume you’re serving 5,000 enterprises that ship on average 300 domain specific features a year in 5 different programming languages that each require 30 lines of code changes across multiple files. You’ll have about 300m permutations the product needs to support. What a nightmare!
Using the same napkin math, Corgea needs to support the ~900 vulnerabilities (CWE’s). Most of them require 1 - 2 line changes. It doesn’t need to understand the whole codebase since the problem is usually isolated to a few lines. We want to support the 5 most popular programming languages. If we have 5,000 customers, we have to support ~4,500 permutations (900 issues x 5 different languages). This leads to a massive difference in accuracy. Obviously, this is an oversimplification of the whole thing but it illustrates the point.
What makes this different from Copilot and other code-gen tools is that they do not specialize in security and we’ve seen them inadvertently introduce security issues unbeknownst to the engineer. Additionally, they do not integrate into existing scanning tools that companies are using to resolve those issues. So unless a developer is working on every part of the product, they’re ...
44 comments
[ 3.2 ms ] story [ 26.8 ms ] threadI think like 95% of the general "vulnerability market" exists because companies have assets they don't own the codebase of, and have to wait for and test patches when they finally arrive.
> It doesn’t need to understand the whole codebase since the problem is usually isolated to a few lines.
I'm not a terrific coder but isn't this a pretty risky simplification? It's a very common occurence that a minor, one line change breaks something in a whole different part of the codebase.
- I would agree that a big chunk of vulnerability market helps with things that companies don't own, but I'm not sure it's that high. A lot of companies use SaaS tools and deploy tools they don't own on their private cloud that they have to wait on patches for. Our perspective is that a lot of the tools that emerged in the last few years center around detection, and very little on remediation. We didn't want to be another tool that contributes to alert fatigue. With budgets tightening, tougher scrutiny of security and increasing threats, companies need automation in remediation.
- We've designed Corgea to always have a human in the loop. Corgea doesn't push code automatically to prod. It creates a PR when someone clicks on the button to do so, and it will have an engineer to review the PR to ensure nothing breaks. Almost every company has those controls in place. Additionally, for the vast majority of cases the fixes are safe and don't lead to dependency issues further downstream, and for others we will be building logic to account for that. For example this SQL injection fix requires you to parameterize the inputs correctly, which is a one line code change and doesn't have dependency. https://demo.corgea.com/501.
Dont forget ~ 85% of global compute is still on-premise stuff.
> With budgets tightening, tougher scrutiny of security and increasing threats, companies need automation in remediation.
Yes, but the main bulk of vulns for enterprises and SMB+ (as in, the orgs that actually do security spending) are in products they don't own the codebase of. Windows, Redhat, Cisco, Confluence, Jenkins, and more recently also solutions like Okta, Forgerock and others are getting exploited via vulns for the benefit of attackers.
I'm not trying to be a dick btw, but I think you're confusing the market you're trying to play in. You're selling something closer to a dev tool than a security tool, and talking about detection and such doesn't really concern this area.
For code you own, control or have over-sight over, we can help. Otherwise, we can't.
When I mention vulnerability detection, I mean that generally as "findings". For example, our original product was detection data leakage issues in SaaS tools like Slack, Snowflake, JIRA, etc. For example, we could detect someone pasting credentials by mistake to their colleague in Slack because they wanted to share logs. This is a human caused problem facilitated by not properly sanitizing logs. I include these when I'm talking about the market.
The comment about the dev tool vs security tool is interesting. How would you categorize Snyk?
> How would you categorize Snyk?
Im not a heavy user, but I believe they themself position themself as ”developer security” (think its even in their slogan)
Looking forward to the archeological audits of LLM-developed apps x years from now that are a total mystery to the product owners…
As I highlighted in my post, LLM's generally are still not in a position to replace a developer for more complex tasks and refactoring. We're in the early days of the technology, but we are seeing extremely strong improvements in it over the last year. We on the team have QA'd thousands of results for public, and private repositories. The private ones are particularly interesting because the LLM's do not have that in their corpus, and have seen very strong fix results.
Most people just assume we're wrapping around an LLM, but there's a lot that goes underneath the hood that needs to happen to ensure that fixes are going to be secure and correct. Here are the standards we're setting for fix quality:
- The fix needs to be best-practice and complete. A partial security fix isn't a security fix. This is something we're constantly working on. - Supporting the widest coverage in CWE's.
- Not introducing any breaking changes in the rest of the code. - Understanding the language, the framework being used, and any specific packages. For example, fixing an CSRF issue in Django is different than Flask. Both are python frameworks but approach it differently. - Reusing existing packages correctly to improve security and if it does need to add a package does so in a standard way. - Placing imports in the correct part of the file. - Not using deprecated or risky packages. - Avoiding LLM hallucinations. - Ensuring syntax and formatting are correct. - Follow the coding and naming convention in the file being fixed. - Making sure fixes are consistent within the same issue type. - Explain the fix properly and clearly so that someone can understand it. - Avoiding assumptions that could cause problems. - Not removing any code that is not part of the issue.
Our goal is to get to 90% - 95% accuracy in fixes this year, and we're on a trajectory to do that. I will be the first to say 100% accuracy is impossible, and our goal is to get it right more times than engineers would.
We take fix quality and transparency extremely seriously. We'll be publishing a whitepaper showing the accuracy in results because it's the right thing to do. I hope this helps.
This fix is to demonstrate more sophisticated fixes, and it does require human input to determine the correct domain and IP config. We are introducing in the product for the ability for humans to add additional context pre-fix generation, provide feedback to generate a new fix after it's been generated and edit the proposed fix. Users have asked for these tools because of scenarios that require more insight.
Edit: To highlight a specific problem here: a classic target for SSRF is the instance metadata IP address[1]. This IP address is not on the generated blacklist. Worse you've made it harder to detect this problem in the future.
I don't want to recommend a fix here; you're selling the fix. You should consider hiring a security expert to determine if LLM is really up for this task.
[1] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance...
A few things we're doing to combat this: 1) We've given the entire corpus of CWE's to Corgea, and how to fix things safely. This we've found from our testing and users does a really good job. I personally QA a lot of results (in the thousands) and we've not seen that to be a common problem. 2) Corgea is designed to require two sets of eye balls. The first being the security engineer and the second being the developer that reviews the PR. We hope, that things should be caught. Additionally, we believe our fixes will be better than what a developer does. There are over 900 CWE's, and it's really hard for engineers to know how to fix every issue. Googling answers and asking ChatGPT can lead to them introducing issues. 3) We provide in the product AI generated explanations on the fix and how it was appropriate. This is to educate non-experts on the topic. 4) We already have checks in place to make sure things aren't misbehaving, but we're rolling out soon a more advanced fix checker to make sure we didn't introduce any new vulnerabilities. Based on our testing, and 5) Finally we QA a lot every week, and run reports on the areas we're good at or not so good at to help us iterate.
I really like the idea and I think that you're right about the goal being to fix bugs "better than the average engineer". I don't think you've reached that bar.
Well, at least they are showing a real demo and not some made up results.
I think that overall the idea has some potential, but not sure we are there yet.
For the first one the SAST scanner reports to us issues based on lines and issue type, so we generate fixes isolated for that issue. We do not generate fixes for other vulnerabilities in the same file for the same finding in the same because we want to have one fix to one finding. There might be another issue reported on another issue, and we plan on allowing people to group fixes in the same file together.
Not sure if I'm missing something on the shell=True. It's in the vulnerable code, which is why it changed it. You have to scroll to the right in the code viewer. https://github.com/RhinoSecurityLabs/cloudgoat/blob/8ed1cf0e...
Is there something I'm missing?
As for the second, There is no shell=True for me in the demo but it is present in the code you sent. So maybe it is just a bug in the presentation somewhere.
We'll also take a look at what's causing this. It might be a browser issue.
Historically, a generated code and human driven code is often segregated. With copilot, it is still assisting. But here, it generating and replacing code over the existing code therefore impacting the ownership of the code as well as value is not so much here. I think the PR that it would generate would endup not being merged.
Having said that, it is a great hook to get attention but i think you might fail in delivering meaningful value.
Currently, we've focused on CWE's because of how focused and isolated some of the fixes are in relation to items #1, #3 and #4. We've run thousands of tests and see a very high accuracy in results. We do have plans to support #1 after we feel accomplished with #2. This requires more sophisticated tools and logic to handle upgrade changes safely.
At the moment, the responsibility is on the SAST tools at the moment to perform these detections. We've heard a lot of complaints about false positives and it's probably one of the biggest problems in the industry. We have future plans to tackle both detection and prioritization, but that's a separate thing.
To comment on your second point, Dependabot and other code-gen products like ourselves, code ownership will be impacted. I believe our understanding of code ownership will change fundamentally as more of these tools come out and get adopted. One clarification point, Corgea doesn't auto issue PR's like Dependabot does. Someone needs to look at the fix, before issuing a PR.
Thanks for commenting, and it's definitely a different perspective on meaning value. For other code-gen tools like copilot, where do you think the value is then?
A system like this would be so much better if all the scanning was done locally, keeping the source private from leaking at all.
Scanning today can be done locally with many tools like Semgrep before you use Corgea. We do send over vulnerability information over to Corgea to make sure we can issue fixes for them reliably and at-scale. Keep in mind repos have vulnerabilities in the thousands or even tens of thousands. So it's not as simple as copilot running on your IDE reading your current likes of code. We have to be able to do this at-scale.
Finally, we've put a lot of effort into securing things down and you can read some of those details here: https://docs.corgea.app/security
My question would be are you using it on your own codebase or an open-source tool you're fond of, would love to see this operating in the wild (examples are great but real life PRs hit different)?
We are using it on our codebases, and it's helped us secure our own product. Users have also been trying it out with their private codebases, and we even used our own personal projects to test it.
If you'd like to try Corgea with some open-source tools, there are a ton of applications that are vulnerable by design like. Some popular ones:
https://github.com/bkimminich/juice-shop https://github.com/we45/Vulnerable-Flask-App https://github.com/adeyosemanputra/pygoat
Edit: Forgot to mention, we've put in some controls to avoid hallucinations like comparing diff sizes between the two changes. Sometimes LLM's like to truncate code when generating a fix or generates too much. We actually stop the result from being generated and we retry again.
Could you reach out to us at support@corgea.com with your account? We're happy to help you resolve this.