OpenHack: LLM을 신뢰 가능한 보안 코드 리뷰어로 만드는 방법

또한 OpenHack은 보안 감사를 별도의 프로젝트로 진행하는 대신 개발 워크플로 안에서 반복 가능한 보안 리뷰 프로세스로 실행할 수 있게 한다.

단순한 LLM 코드 리뷰의 한계

LLM에게 단순히 “이 저장소에서 취약점을 찾아라”라고 요청하면 결과가 신뢰하기 어려운 경우가 많다. Hadrian이 지적한 주요 문제는 다음과 같다.

• 높은 허위 경보율 — 실제 문제가 아닌 코드 패턴도 취약점으로 판단
• 환각된 취약점 — 존재하지 않는 보안 문제를 만들어냄
• 분석의 일관성 부족 — 프롬프트나 컨텍스트에 따라 결과가 달라짐

OpenHack은 이러한 문제를 해결하기 위해 열린 질문형 프롬프트 대신 구조화된 조사 방법론을 사용한다.

시나리오 기반 보안 분석

OpenHack의 가장 중요한 개념 중 하나는 **시나리오 기반 범위 설정(scenario‑based scoping)**이다.

즉, AI에게 “취약점을 찾아라”라고 포괄적으로 지시하는 대신, 특정 공격 시나리오를 중심으로 분석하게 만든다.

예를 들어 다음과 같은 분석을 지시할 수 있다.

• 사용자 입력이 애플리케이션 내부에서 어떻게 흐르는지 추적
• LFI(Local File Inclusion) 같은 특정 취약점 가능성 탐색
• 자격 증명 저장 방식이나 클라우드 설정 분석

이 방식은 모델의 분석 범위를 좁히고 명확한 목표를 제공해 불필요하거나 일반적인 보안 지적을 줄이고 실제 공격 경로 분석에 집중하게 한다.

허위 경보를 줄이는 ‘독립적 트리아지’

OpenHack 워크플로는 취약점 발견(discovery)과 검증(validation)을 분리하는 구조를 갖는다.

일반적인 실행 흐름은 다음과 같다.

1. 하나의 AI 에이전트가 잠재적 취약점을 발견한다.
2. 다른 단계 또는 별도의 에이전트가 이를 검증(triage)한다.
3. 코드 경로, 설정 정보, 공격 체인 같은 증거를 확인한 뒤 실제 취약점으로 인정한다.

이 구조는 단일 모델의 판단에 의존하지 않게 하며, 증거 기반 분석을 강제해 약한 보고서나 오탐을 줄이는 효과를 노린다.

네덜란드 정부 오픈소스 감사에서의 테스트

Hadrian은 OpenHack과 유사한 방법론을 사용해 네덜란드 정부 기관이 사용하는 오픈소스 애플리케이션을 분석했다고 밝혔다.

회사에 따르면 AI 기반 감사 과정에서 몇 시간 안에 수백 개의 보안 문제가 발견됐다.

연구에서 언급된 대표적인 사례는 다음과 같은 공격 체인이었다.

• 인증 없이 가능한 Local File Inclusion(LFI) 취약점
• 이를 통해 Azure 자격 증명 노출
• 결국 **Azure 환경에서 원격 코드 실행(RCE)**으로 이어질 가능성

다만 이러한 결과는 현재까지 벤더 자체 보고에 기반한 사례이기 때문에, 독립적인 검증이 추가로 필요하다는 점은 고려해야 한다.

왜 오픈소스로 공개했나

Hadrian은 OpenHack을 MIT 라이선스로 GitHub에 공개했다. 프로젝트에는 다음이 포함된다.

• 워크플로 문서
• LLM용 프롬프트
• CLI 도구
• Python 3.9 이상 지원

회사 측 설명에 따르면 목표는 AI 기반 취약점 발견 능력을 방어 측에도 개방하는 것이다. 공격자가 독점적으로 이런 도구를 개발하면 방어 측이 뒤처질 수 있기 때문이다.

커지는 AI 보안 감사 흐름

OpenHack은 더 큰 흐름의 일부이기도 하다. 최근 개발 환경에서는 AI 코딩 에이전트가 다음과 같은 역할을 수행하기 시작했다.

• 전체 코드베이스 분석
• 아키텍처 이해
• 자동 코드 수정 및 리뷰

이러한 능력을 보안 감사에 체계적으로 적용하려는 시도가 바로 OpenHack 같은 프로젝트다.

결국 핵심은 단순히 더 강력한 모델이 아니라 분석 범위를 명확히 하고, 증거를 수집하며, 결과를 검증하는 구조화된 워크플로다. 이런 접근이 자리 잡는다면 AI 기반 코드 보안 리뷰의 신뢰성도 점점 높아질 가능성이 있다.