AI의 취약점 보고를 그대로 수정 PR로 만들지 않기: OSS Scanner 관점에서 본 수신과 검증의 분리

AI가 취약점을 발견할수록, 개발 측에는 '수신된 보고서를 어떻게 검증하고 어떤 수정 사항을 적용할 것인가'라는 업무량이 증가합니다.

본 글에서는 Anthropic의 새로운 방어 정책을 계기로, AI가 생성한 보고서를 수신하는 쪽의 설계 과정을 정리합니다. 공격 절차나 실제로 존재하는 취약점 재현 코드는 다루지 않습니다.

공식 발표로 확인할 수 있는 내용

Anthropic은 2026년 10월 8일, Anthropic Cyber Mission을 발표했습니다. 이 정책 중 하나가 참여한 오픈소스 프로젝트에 정기적인 스캔을 제공하는 OSS Scanner입니다.

同社는 보고서가 모델 생성으로 인간의 검토를 거치지 않고 전송될 수 있으며, 심각도 등에 오류가 포함될 수 있음을 명시했습니다. 무료 제공이나 탐지 품질에 대한 설명은 Anthropic의 발표 내용이며, 본 기사에서 독립적으로 검증한 결과가 아닙니다.

JAXIA는 OSS Scanner에 등록하거나 사용했거나 탐지 정확도를 측정한 실적이 없습니다. 아래 내용은 수신자 측의 설계 제안입니다.

보고서, 검증, 수정 단계를 분리하기

'보고서를 받았다'와 '취약점이 확인되었다'와 '안전한 수정이 이루어졌다'는 별개의 단계입니다.

최소한 다음 상태들을 구분해야 합니다.

received: 보고서 수신
triaged: 대상 버전 및 영향 범위를 정리함
verified: 격리 환경에서 타당성을 확인함
fix-reviewed: 수정 차분(diff)과 회귀 테스트를 확인함
released: 승인된 수정을 배포함

재현할 수 없는 것은 기각하거나 보류합니다. 재현할 수 없다는 사실만으로 안전하다고 단정하지 않고, 환경 조건의 부족을 확인할 경로도 남겨둡니다.

중요한 것은 상태를 진행했다는 증거를 명시하는 것입니다. 'AI가 고위험이라고 말했다'는 검증된 증거가 아닙니다.

수신 단계에는 실행 권한을 부여하지 않기

보고서 본문, 첨부 파일, 링크, 제안 패치는 모두 신뢰할 수 없는 입력(untrusted input)입니다.

수신 담당 AI가 단순히 첨부 코드를 실행하거나, 외부 URL로 사내 정보를 전송하거나, 운영 환경을 변경할 수 있는 구성으로 만들어서는 안 됩니다. 보고 과정 중의 명령문도 운용 지시가 아니라 검사 대상 데이터일 뿐입니다.

수신 단계에서 다루는 것은 대상 컴포넌트, 대상 버전, 영향 설명, 검증에 필요한 조건 등으로 한정해야 합니다. 수신 크기나 건수 상한선, 중복 관리도 필요합니다. 로그에 보고서 본문을 통째로 복제하면 기밀성이 있는 상세 정보가 퍼질 수 있으므로 주의해야 합니다.

검증 환경과 수정 게이트(Gate)

검증은 허가된 대상을 격리한 환경에서 진행합니다. 비밀 정보, 운영 데이터, 운영 인증값을 가져오지 않는 것이 전제입니다. 필요한 네트워크 연결만 허용하고, 검증의 시작 조건과 종료 조건을 정해야 합니다.

수정 패치에는 최소한 세 가지 게이트를 두어야 합니다.

문제가 정말 수정되었는지 확인하는 테스트
정상 시스템을 망가뜨리지 않았는지 확인하는 회귀 테스트(Regression Test)
차분의 의도와 영향을 확인하는 인간의 검토

생성된 패치는 다른 문제나 사양 변경을 가져올 수 있습니다. 테스트만 통과했다고 자동 병합(auto merge)하지 않는 범위를, 변경 위험도에 따라 정의해야 합니다.

본 문건은 방침 정리일 뿐이며, 완전한 안전성을 보장하는 구현은 아닙니다. 대상 소프트웨어 및 환경별 추가 대책이 필요합니다.

JAXIA의 공개 실천 사례와의 접점

JAXIA의 공개 사이트에서는 Multi-Agent Governance & Integration을 Design/Integrate/Review의 세 단계로 AI, 사람의 판단, 업무 규칙에 연결하는 설계 사상으로 소개하고 있습니다.

이러한 생각을 보고서 수신에 적용한다면, Design에서 수신 대상과 권한을 정하고, Integrate에서 격리된 검증 경로에 연결하며, Review에서 증거와 수정을 확인하는 분리가 이루어집니다. 이는 적용 방안일 뿐이며, 해당 수신 파이프라인을 구현했다는 의미가 아닙니다.

또 다른 공개 실천 사례로는 회계 전표나 계약서 등 돈이나 약속과 관련된 작업에서 AI가 초안을 마련하고 대표가 마지막에 승인하는 운영 방식입니다. 보안 패치도 같은 처리는 아닐 수 있지만, '초안 작성'과 '영향을 미치는 변경을 승인하는 것'을 분리하는 접점이 있습니다.

지표를 탐지 건수에만 두지 않기

보고서가 늘어날 때, 건수만을 성과로 삼으면 수신자가 과부하에 걸립니다.

수령부터 초기 판단까지의 시간, 중복률, 검증에 소요된 시간, 보류 사유, 수정 후 회귀 결함 등도 살펴봐야 합니다. 전체 탐지 성능을 평가할 때는, 놓친 것도 측정할 수 있는 평가 세트가 별도로 필요합니다. 도착한 보고서만으로는 위음성(False Negative)을 파악할 수 없습니다.

오보를 0으로 만드는 것이 목적이 아니라, 미검증의 보고서를 안전하게 처리하고 중요한 수정을 지체시키지 않는 것이 운영 목표입니다.

요약

AI에 의한 탐지의 발전과 자동 수정 허용은 별개의 판단입니다.

수신(受信)을 실행 단계와 분리하고, 검증의 증거를 남기며, 수정 사항을 별도의 게이트로 통과시킨다. 모델의 능력을 활용할수록, 수신자 측의 상태 관리와 권한 분리가 중요해진다.