Gecko Security 출시: 코드의 취약점을 찾아내는 AI

안녕하세요 HN 커뮤니티 여러분, 저는 Gecko Security의 공동 창업자 JJ입니다. (https://www.gecko.security) 저희는 LLM을 사용하여 현재 스캐너가 놓치는 복잡한 비즈니스 로직 및 다단계 취약점을 찾는 새로운 유형의 정적 분석 도구를 구축하고 있습니다. 저희는 이 도구를 활용하여 Ollama, Gradio, Ragflow와 같은 프로젝트에서 30개 이상의 CVE를 발견했습니다 (https://www.gecko.security/research). SAST(Static Application Security Testing) 도구를 사용해 본 사람이라면 높은 오탐률(false positives)을 보이는 동시에 인증/인가 우회(AuthN/Z bypasses)나 권한 상승(privilege escalations)과 같은 취약점 클래스 전체를 놓치는 문제를 알고 있을 것입니다. 이러한 한계는 도구의 핵심 아키텍처에서 비롯됩니다. SAST 도구는 코드를 AST(Abstract Syntax Tree)나 호출 그래프와 같은 단순화된 모델로 구문 분석하는데, 이는 동적 타입 언어 또는 마이크로서비스 경계를 넘나들 때 빠르게 문맥을 잃고 기본적인 호출 체인만 해결하는 것으로 커버리지를 제한합니다. 취약점을 감지할 때 정규 표현식(Regex)이나 YAML 규칙을 이용한 패턴 매칭에 의존하는데, 이는 XSS, SQLi와 같은 기본적인 기술적 클래스에는 효과적일 수 있지만, 잘 알려진 형태를 따르지 않고 악용 가능한 상태에 도달하기 위해 긴 종속적인 연산 순서가 필요한 로직 결함(logic flaws)에는 부적절합니다.

저와 공동 창업자는 국가 정보 및 군 사이버 전력 분야에서 경력을 쌓는 동안 이러한 한계점들을 목격했습니다. 그곳에서 저희는 중요 인프라를 방어하기 위한 자동화 도구를 구축했었습니다. 그리고 LLM이 적절한 아키텍처를 갖춘다면, 마침내 이 문제들을 해결할 수 있다는 것을 깨달았습니다.

취약점은 문맥적입니다. 무엇이 악용 가능한지는 전적으로 각 애플리케이션의 보안 모델에 달려 있습니다. 저희는 정확한 탐지에는 무엇이 보호되어야 하는지, 그리고 그것을 위반하는 것이 왜 중요한지를 이해하는 것이 필요하다는 것을 깨달았습니다. 따라서 이를 사후 고려 사항으로 다루기보다 분석 과정 자체에 위협 모델링(threat modeling)을 내재화했습니다.

이를 달성하기 위해, 우리는 먼저 코드 파싱(code parsing) 문제를 해결해야 했습니다. 우리의 솔루션은 GitHub의 스택 그래프 접근 방식에서 영감을 받아 코드를 정밀하게 탐색하는 커스텀 컴파일러 정확도 인덱서(compiler-accurate indexer)를 구축하는 것이었습니다. 우리는 LSIF 접근 방식(https://lsif.dev/)을 기반으로 하되, 장황한 JSON 대신 간결한 protobuf 스키마를 사용하여 심볼 정의와 참조를 바이너리 형식으로 직렬화합니다. 우리는 언어별 도구를 사용하여 코드를 파싱하고 타입 검사(type-check)하며, 심볼의 위치, 정의 및 참조 정보를 기록하는 일련의 Protobuf 메시지를 방출합니다. Protobuf의 효율성과 강력한 타이핑을 사용함으로써 더 작은 인덱스를 생성할 수 있을 뿐만 아니라, 복잡한 호출 체인(call chain) 감지에 필요한 컴파일러 정확도 의미론적 정보(semantic information)를 보존할 수도 있습니다.

이것이 바로 AST 파싱을 사용하는 대부분의 'SAST + LLM' 도구가 실패하는 이유입니다. 이들은 전통적인 파서로부터 불완전하거나 부정확한 코드 정보를 LLM에 공급하여, 누락된 컨텍스트로 인해 보안 문제에 대해 정확하게 추론하기 어렵게 만듭니다.

우리의 인덱서가 정확한 코드 구조를 제공함에 따라, 우리는 개발자의 의도(developer intent), 데이터 및 신뢰 경계(data and trust boundaries), 노출된 엔드포인트(exposed endpoints)를 분석하여 잠재적인 공격 시나리오를 생성함으로써 LLM을 사용하여 위협 모델링(threat modeling)을 수행합니다. 바로 이 지점에서 LLM의 환각(hallucinate) 경향이 획기적인 기능으로 변모합니다.

생성된 각 잠재적 공격 경로에 대해, 우리는 체계적인 검색을 수행하여 인덱서에 질의하고 필요한 모든 컨텍스트를 수집하며 소스에서 싱크까지 전체 호출 체인을 재구성합니다. 취약점을 검증하기 위해 몬테카를로 트리 자체 개선(Monte Carlo Tree Self-refine, MCTSr) 알고리즘과 '승리 함수(win function)'를 사용하여 가설화된 공격이 성공할 가능성을 판단합니다. 발견된 내용이 설정된 실용성 임계값(practicality threshold)을 초과하면 참 양성(true positive)으로 확정됩니다.

이러한 접근 방식을 사용하여, 우리는 ONYX(OSS 엔터프라이즈 검색 플랫폼)에서 CVE-2025-51479와 같은 취약점을 발견했습니다. 이 취약점은 큐레이터가 자신에게 할당된 그룹뿐만 아니라 모든 그룹을 수정할 수 있도록 허용하는 것이었습니다. 사용자 그룹 API에는 권한을 확인해야 하는 사용자 매개변수가 있었지만, 실제로 사용되지 않았습니다. Gecko는 UI와 유사한 API 기능들이 이 권한을 적절하게 검증했기 때문에 개발자들이 큐레이터의 접근 범위를 제한할 의도가 있었다고 추론했습니다. 이를 통해 '큐레이터는 제한된 범위(limited scope)를 가진다'는 보안 불변성(security invariant)이 확립되었으며, 이 특정 API가 이를 위반하는 것을 발견했습니다. 전통적인 SAST로는 이를 감지할 수 없습니다. 사용되지 않은 사용자 매개변수를 플래그 지정하는 규칙은 너무 많은 오탐(false positive)을 유발하여 분석을 마비시킬 것이기 때문입니다. 그리고 더 중요한 것은, 이를 감지하려면 어떤 함수가 권한 처리를 하는지 알아야 하고, ONYX의 큐레이터 권한 모델을 이해해야 하며, 여러 파일에 걸쳐 검증 패턴을 인식하는 등 맥락적 추론(contextual reasoning)이 필요합니다. 이는 SAST가 할 수 없는 일입니다.

여러 엔터프라이즈 고객들이 Gecko를 사용하고 있는데, 그 이유는 전통적인 SAST 도구로는 해결할 수 없었던 문제들을 해결해주기 때문입니다. 이들은 동일한 코드베이스에서 오탐률(false positive)이 50% 감소하는 것을 경험하고 있으며, 이전에 수동 침투 테스트(manual pentests)에서만 발견되던 취약점들을 찾고 있습니다.

오탐에 대해 깊이 파고들자면, 어떤 정적 분석 도구도 완벽한 정확성을 달성할 수는 없습니다. AI든 아니든 말입니다. 우리는 두 가지 주요 지점에서 오탐률을 줄입니다. 첫째, 우리의 인덱서(indexer)는 전통적인 AST 도구가 취약한 잘못된 호출 체인(call chains)을 생성하는 모든 프로그래밍적 파싱 오류를 제거합니다. 둘째, 개방형 질문 대신 구체적이고 맥락적인 질문을 함으로써 원치 않는 LLM 환각(hallucinations) 및 추론 오류를 방지합니다. LLM은 어떤 보안 불변성이 유지되어야 하는지 알고 있으며, 맥락에 기반하여 결정론적 평가를 내릴 수 있습니다. 우리가 무언가를 플래그 지정할 때도, 개념 증명 코드와 신뢰 점수(confidence scores)에 기반한 출력을 제공하기 때문에 수동 검토가 빠릅니다.

커뮤니티의 피드백, 향후 방향에 대한 아이디어, 또는 이 분야에서의 경험을 공유해 주시면 감사하겠습니다. 댓글에서 답변드리겠습니다!