Launch HN: Corgea (YC S23) – 취약한 코드 자동 수정

안녕하세요 HN, 저는 Corgea (https://corgea.com)의 창립자입니다. 저희는 AI를 사용하여 기업의 취약한 소스 코드 (source code)를 수정하도록 돕습니다.

원래 저희는 기업의 데이터 유출을 탐지하는 데이터 보안 제품으로 시작했습니다. 초기 성공과 고객 확보에도 불구하고, 저희는 문제를 강조하는 것만으로는 충분하지 않다는 이야기를 자주 들었습니다. 고객들은 선제적인 수정을 원했습니다. 그들은 취약점에 대해 경고를 보내는 수백 개(네, 정말 수백 개입니다!)의 보안 도구를 보유하고 있었지만, 그 모든 것을 검토하고 수정할 전담 팀을 운영할 여력이 없었습니다. 저희가 대화했던 한 잠재 고객은 SAST (정적 분석 보안 테스트) 도구에서 수만 건의 취약점이 보고된 상태였습니다. AI 코드 생성 (AI code generation)의 부상과 함께, 저희는 고객이 진정으로 원하는 것을 제공할 기회를 보았습니다.

Corgea를 보유한다는 것은 코드를 더 안전하게 만드는 데 집중하는 보안 엔지니어를 직원으로 두는 것과 같습니다. 저희는 보안이 엔지니어링의 방해 요소가 아닌 촉진제가 되기를 원하며, 그 반대도 마찬가지이기를 바랍니다. 이를 달성하기 위해, 저희는 기존의 LLM (대규모 언어 모델)을 기반으로 코드 수정 (code fixes)을 수행하도록 구축했습니다.

Corgea의 역량을 보여드리기 위해, 저희는 Juice Shop (https://github.com/juice-shop/juice-shop)과 같이 설계부터 취약하게 만들어진 인기 애플리케이션들을 가져와 스캔하고 취약점에 대한 수정 사항을 발행했습니다. 그중 일부는 여기에서 확인하실 수 있습니다: https://demo.corgea.com. 해결하는 취약점의 예로는 SQL injection (SQL 삽입), Path Traversal (경로 탐색), XSS (교차 사이트 스크립팅) 등이 있습니다.

이 작업이 어려운 이유는 현재 LLM이 일반적인 코딩 작업에서 어려움을 겪고 있기 때문입니다. 왜냐하면 전체 코드베이스 (code base), 해당 도메인 (domain), 그리고 무언가를 수행하려는 사용자의 요청을 모두 이해해야 하기 때문입니다. 이는 모델이 사용자가 원하는 것에 대해 최선의 추측을 내놓는 과정에서 코드를 잘못 작성하게 되어, 의도치 않은 동작을 많이 초래할 수 있습니다. 팀의 창립 엔지니어 중 한 명인 Adam은 이를 아주 잘 표현했습니다: "LLM은 추론 (reason)하는 것이 아니라, 퍼징 (fuzz)하는 것이다."

우리는 LLM (Large Language Model)이 더 결정론적 (deterministic)이 되도록 돕는 몇 가지 결정을 내렸습니다. 첫째, 우리가 하고 있는 일은 매우 도메인 특화적 (domain specific)입니다. 즉, 제한된 수의 프로그래밍 언어 내에서 취약한 코드를 수정하는 것입니다. 우리는 CWE (https://cwe.mitre.org/)라고 불리는 코드 내 약 900개의 보안 취약점을 Corgea에 구축했습니다. Javascript 앱의 SQL 인젝션 (SQL injection) 취약점은 당신이 결제 회사이든 여행 예약 사이트이든 상관없이 동일합니다. 둘째, SAST (Static Application Security Testing)가 수정을 발행하는 데 필요한 모든 것을 스캔하기 때문에, LLM으로 들어가는 사용자 생성 입력값이 없습니다. 이는 우리와 고객 모두에게 훨씬 더 예측 가능하고 재현 가능하게 (reproducible) 만듭니다. 또한 우리는 강력한 QA (Quality Assurance) 프로세스와 점검 절차를 만들 수 있습니다.

이 점을 설명하기 위해, 간단한 계산 (napkin math)을 통해 이를 테스트해 보겠습니다. 당신이 평균적으로 연간 300개의 도메인 특화 기능을 배포하는 5,000개의 기업을 대상으로 서비스를 제공한다고 가정해 봅시다. 이 기능들은 5가지 다른 프로그래밍 언어로 작성되며, 각각 여러 파일에 걸쳐 30줄의 코드 변경을 필요로 합니다. 그러면 제품이 지원해야 하는 경우의 수는 약 3억 개에 달할 것입니다. 정말 악몽 같군요!

동일한 간단한 계산을 사용하면, Corgea는 약 900개의 취약점 (CWEs)을 지원해야 합니다. 그중 대부분은 1~2줄의 변경만 필요로 합니다. 문제는 보통 몇 줄 내로 고립되어 있기 때문에 전체 코드베이스 (codebase)를 이해할 필요가 없습니다. 우리는 가장 대중적인 5가지 프로그래밍 언어를 지원하고자 합니다. 만약 5,000명의 고객이 있다면, 우리는 약 4,500개의 경우의 수(900개의 이슈 x 5가지 다른 언어)를 지원하면 됩니다. 이는 정확도 면에서 엄청난 차이를 만들어냅니다. 물론 이것은 전체 상황을 지나치게 단순화한 것이지만, 핵심적인 요점을 잘 보여줍니다.

이것이 Copilot이나 다른 코드 생성 (code-gen) 도구들과 다른 점은, 그 도구들은 보안에 특화되어 있지 않으며 엔지니어가 인지하지 못하는 사이에 의도치 않게 보안 문제를 유발하는 것을 목격해 왔다는 것입니다. 또한, 이들은 기업들이 이러한 문제를 해결하기 위해 사용 중인 기존 스캐닝 (scanning) 도구들과 통합되지 않습니다. 따라서 개발자가 제품의 모든 부분을 직접 작업하지 않는 한, 수천 개의 티켓에 달할 수 있는 보안 백로그 (security backlogs)를 해결할 수 없습니다.

보안 스캐너 (security scanners)의 경우, 현재 시장은 보안 팀에 보고를 남발하여 업무를 압도하면서도 정작 보고된 내용을 수정하는 데에는 효과적이지 않은 도구들로 넘쳐나고 있습니다. 대부분의 취약점 스캐너 (vulnerability scanners)는 문제를 교정 (remediate)하지 않으며, 교정하더라도 CVSS를 낮추기 위해 패키지를 한 버전에서 다른 버전으로 업그레이드하는 수준에 그치는 경우가 많습니다. 만약 CWE 교정 (remediation) 기능을 제공하더라도, 이들은 종종 전통적인 AI 방법론에 기반하기 때문에 성공률이 매우 낮습니다. 게다가 이 도구들은 각자 자신들의 탐지 결과만을 제공하려 하기 때문에 서로 통합되지 않습니다. 기업들은 Snyk, Semgrep, Checkmarx와 같은 여러 도구를 사용하면서도, 침투 테스트 (penetration testing) 프로그램과 버그 바운티 (bug bounty) 프로그램을 운영합니다. 이들에게는 기존 도구들을 통합할 수 있는 솔루션이 필요합니다. 또한 이들은 코드 저장소 (code repository)로 GitHub, GitLab, Bitbucket을 사용합니다.

우리는 소규모 팀을 위한 무료 티어 (free tier)와 유료 티어를 제공합니다. 우리는 보안 수정을 위한 엔지니어링 노력의 80%를 줄일 수 있다고 믿으며, 이는 기업 기준으로 연간 최소 1,000만 달러에 달하는 가치와 맞먹을 것입니다.