오픈소스 취약점 스캔에 LLM API를 연결해서 보안 검토 시간을 줄이는 방법

오픈소스는 편리하지만 그만큼 위험합니다. 2025년 한 조사에 따르면 AI가 코드를 대신 짜주기 시작하면서 버그 발생률이 전년 대비 41%나 치솟았습니다. 혼자서 수만 줄의 외부 라이브러리를 검토해야 하는 보안 담당자에게는 재앙이나 다름없습니다. 모든 코드를 다 읽을 수는 없으니 AI를 우리 편으로 만들어야 합니다. Project Glasswing처럼 똑똑하게 작동하는 보안 워크플로우를 직접 만드는 법을 정리했습니다.

깃허브 액션에 AI 보안 엔진 설치하기

보안 검토를 자동화하면 매주 10시간 넘게 쏟아붓던 단순 반복 작업을 걷어낼 수 있습니다. 사람이 눈으로 훑다 놓치는 실수도 막아줍니다. 깃허브 액션 환경에서 LLM API를 호출해 풀 리퀘스트가 올라올 때마다 실시간으로 스캔하는 파이프라인을 구축해 보세요. 단순히 질문을 던지는 게 아니라 식별과 감사를 분리하는 전략이 핵심입니다.

• API 키 보호: 깃허브 시크릿에 LLM_API_KEY를 등록하세요. Libsodium 암호화 저장소에 넣어두어야 키가 외부로 새나가는 사고를 막습니다.
• 타겟 디렉토리 설정: 모든 파일을 다 볼 필요는 없습니다. YAML 설정에서 path-filter를 써서 src/auth나 lib/core처럼 사고 터지면 끝장나는 민감한 디렉토리만 골라 스캔하십시오.
• 교차 검증: 첫 단계에서 LLM이 코드 구조를 분석해 노트를 쓰게 한 뒤, 두 번째 단계에서 그 노트를 바탕으로 3회 이상 반복 스캔을 돌리세요. AI도 가끔 헛소리를 하니 여러 번 확인해서 결과를 맞춰보는 과정이 필요합니다.

이 설정만 끝나도 보안 담당자는 수만 줄의 코드 대신 AI가 요약한 보안 보고서만 확인하면 됩니다.

CVSS와 EPSS로 진짜 위험한 놈들부터 골라내기

AI 도구는 취약점을 잘 찾아내지만 그만큼 오탐도 많습니다. 100개를 찾아냈는데 그중 15개가 가짜라면 개발팀은 짜증이 날 수밖에 없습니다. 한정된 개발 자원을 낭비하지 않으려면 진짜 위협을 가려내는 기준이 필요합니다. CVSS 4.0 점수와 현재 실제로 공격이 발생하고 있는지 알려주는 EPSS 지표를 섞어서 우선순위를 정하세요.

1. 기본 점수 확인: CVSS 4.0 베이스 스코어로 기술적인 심각도를 먼저 봅니다.
2. 환경 점수 조정: 그 코드가 외부 인터넷에 노출된 기능인지, 아니면 내부망에서만 도는 기능인지에 따라 점수를 깎거나 더하십시오.
3. 공격 확률 대조: EPSS 데이터베이스를 조회해서 해당 취약점이 지금 공격자들 사이에서 유행하는지 확인하세요. 공격 확률이 50%가 넘는다면 다른 일 다 제쳐두고 당장 패치해야 합니다.

9.0점 이상의 긴급 등급에만 집중해도 보안 수준은 확 올라갑니다. 쓸데없는 수정 요청을 줄이면 개발팀과의 싸움도 자연스럽게 줄어듭니다.

샌드박스에서 패치 코드 검증하고 배포하기

AI가 제안한 수정안은 겉보기에 완벽해 보여도 가끔 멀쩡한 기능을 망가뜨립니다. 쇼피파이 같은 기업들도 AI를 쓰지만 생성된 코드를 덮어놓고 믿지는 않습니다. 파이어크래커나 gVisor 같은 격리된 환경에서 패치 코드가 안전한지 자동으로 확인하는 절차를 두어야 합니다.

• 격리 환경 생성: sbx CLI를 사용해 현재 서비스와 똑같은 런타임 환경을 가진 마이크로VM을 띄웁니다.
• 공격 시뮬레이션: 공격 스크립트로 취약점이 실제로 뚫리는지 확인한 뒤, AI가 준 패치를 적용하고 다시 공격해서 막히는지 체크하세요.
• 기능 테스트: 패치를 적용한 상태에서 기존 유닛 테스트를 돌려보세요. 보안은 막았는데 로그인이 안 되면 아무 의미 없습니다.

이런 안전장치가 있어야 AI가 만든 거의 맞지만 미세하게 틀린 코드가 운영 서버에 올라가는 사고를 막습니다.

오픈소스 메인테이너가 바로 수용하는 리포트 쓰기

우리 서비스만 고치고 끝내면 안 됩니다. 사용 중인 오픈소스 자체의 결함을 상위 프로젝트에 제보하는 것도 보안 담당자의 몫입니다. 메인테이너들은 바쁜 사람들이니 명확한 근거를 줘야 합니다. 깃허브의 PVR 채널을 활용해 책임감 있게 리포트를 전달하세요.

제목에는 취약점 유형과 위치를 명확히 적으십시오. 누구나 따라 할 수 있는 재현 경로와 스크린샷을 첨부하는 건 기본입니다. 가장 좋은 건 앞서 샌드박스에서 검증했던 수정 코드를 함께 보내주는 겁니다. 검토 시간을 줄여주면 패치가 반영될 확률이 비약적으로 높아집니다. 제대로 된 리포트 한 장이 기업의 기술력을 증명하고 공식 CVE 번호까지 따내는 결과로 이어집니다.