I'm Ahmad, the founder of Corgea. We're building an application security platform that automatically finds, triages, and fixes insecure code. Corgea uncovers vulnerabilities other scanners miss, like business logic flaws, reduces SAST findings by 30% through false-positive detection, and accelerates remediation by 80%.

The recent boom in Large Language Models (LLMs) has sparked huge interest in AI for code security. Companies everywhere are testing LLMs to detect and fix code vulnerabilities. Some of the largest companies in the world have come to us at Corgea, often after trying to build their own LLM-based security solutions and hitting serious roadblocks. After many conversations with these teams, I wanted to warn others about the pitfalls of going this route.

The Trap

LLMs offer exciting possibilities for streamlining code security. They can analyze large amounts of code, spot vulnerabilities, prioritize issues, and even suggest fixes. With extensive training, LLMs can detect some vulnerabilities rapidly, making them attractive in fast-paced environments. The prototype feels real.

This promise has led many teams to dive in. It often starts with ChatGPT or similar tools, as engineers show initial successes in detection, triaging, or remediation. Teams get excited, and soon, a project is underway with a handful of engineers. This is where the "trap of false hope" sets in.

False Perceptions

LLM-based solutions often create a misleading sense of progress early on. Take auto-fixing as an example. Teams manage to get it working decently across a few dozen code examples. This early success leads them to invest more time and resources into scaling it, only to find their solution falls short for enterprise-scale needs with tens of thousands of findings. Fix quality suffers, and scalability becomes a massive issue. This is why many "auto-fix" solutions on the market vary so widely in quality.

I call this the "chasm of returns." Teams think they’re close to a finished product when they’re far from it. They lack the cross-organization insights needed to develop a truly robust solution. At Corgea, we’ve dedicated ourselves to overcoming these challenges, creating new techniques to bridge this gap.

Reality Sets In

Next, these teams often hit a wall when rolling out their solution to developers. They face resistance as they realize they need to build codebase-wide context, support multiple programming languages and frameworks, integrate with CI/CD pipelines, IDEs, and more. What felt like 80% progress turns out to be just 10%. Countless hours, resources, and goodwill are spent, leaving them with a half-baked solution that doesn’t scale. After these experiences, they often come to us looking for a better way.

How Corgea Overcame These Challenges

Solving these issues wasn't easy for us either, but we’ve developed several strategies that have made a difference:

• Rapid Iteration: Building with LLMs requires a new mindset and process. Traditional software development processes don’t work well with LLMs, which need constant tuning. For instance, we ran over 100 iterations on 400,000 vulnerabilities to fine-tune our AppSec LLM using our Test Harness service. This high iteration rate, with 7-10 experiments weekly, is far beyond the usual enterprise pace.

• Investing in Novel Approaches: We invested in unique methodologies tailored to security and code analysis, such as CodeIQ, which allowed us to solve issues others struggled with.

• Focusing on Developer Experience: Developers are the end users, and we built Corgea with their needs in mind, making our solution effective and easy to use. We're released various IDE extensions, and integrations into code repository systems such as GitHub and Azure DevOps.

Cost Analysis: Building In-House vs. Buying Corgea

I've also recently come across the argument that it's cheaper to build this internally than buy, and nothing could be farther from the truth. Let’s break down the costs for a typical enterprise building an in-house Corgea alternative:

To match what we've built, a company would need at least 3-5 experienced security engineers and a product lead, totaling around $1M in the first year (assuming $200K per person, fully loaded). The average worker spends about 37% of their time at work in meetings or coordinating them (source). Factor in the inefficiency of meetings, coordination, and decision-making, which adds another $370K. Meetings alone can cost $28K annually, with about 10 people meeting biweekly over a year.

In total, building an in-house solution costs approximately $1.4M for the first year and an estimated $350K per year for maintenance (25% of initial investment). Over three years, that’s around $2.1M.

Corgea spreads that investment across clients, allowing us to keep up with the latest security threats and LLM advances while offering a state-of-the-art solution at a fraction of the cost. With Corgea, companies can save 50%-90% on building a dedicated solution, freeing their teams to focus on more important work while benefiting from industry best practices.

Conclusion

While building an LLM-based solution for code security in-house may sound appealing, it comes with significant hidden costs, resource demands, and integration hurdles. For most organizations, partnering with a dedicated vendor like Corgea is the more practical choice. Corgea’s expertise, shared R&D costs, and commitment to best practices make it an ideal partner for enterprises seeking a robust security solution.