보안 뉴스의 주인공이 바뀌고 있습니다. 예전엔 "AI가 만든 오탐 보고서가 메인터너를 괴롭힌다"가 헤드라인이었죠. Anthropic의 말에 따르면 이제는 반대입니다. 패치가 딸린 실제 익스플로잇 보고서가 오고, 메인터너가 "검증 안 된 것도 다 달라"고 요청하는 상황입니다.

10월 8일 발표된 OSS Scanner는 그 변화를 제도화한 겁니다. 신청한 오픈소스 프로젝트에 가장 강한 모델로 정기적인 무료 취약점 점검을 해주는 opt-in 서비스입니다. 단, 보고서에는 인간 검토가 없습니다. 이 한 줄이 글 전체의 핵심입니다.

OSS Scanner는 무엇인가

Google의 OSS-Fuzz가 퍼저로 오픈소스를 점검해 생태계에 기여했듯, OSS Scanner는 언어 모델로 같은 일을 하겠다는 발상입니다. 기업용 유료 제품인 Claude Security가 내 시스템을 지키는 일이라면, OSS Scanner는 오픈소스 프로젝트의 보안 감사를 무료로 맡는 일입니다.

대상: 신청(opt-in)한 오픈소스 프로젝트 (OSS-Fuzz와 유사한 기준)
방식: 가장 강한 모델(Claude Mythos 포함)의 정기 스캔
비용: 무료
검토: 인간 검토·트리아지 없음 (fully model-generated)
속도: 빠름, 단 오보·무효 보고서 가능

보고서 한 건의 구성은 실무적입니다. 독립적으로 재현 가능한 reproducer, 취약점 설명(가능하면 버그가 들어온 시점의 bisection 포함), 그리고 구할 수 있으면 후보 패치까지. "취약점이 있다"가 아니라 "이렇게 재현하고 이렇게 고친다"까지 한 묶음으로 옵니다.

배경 숫자도 발표에 함께 나왔습니다. 지난 6개월간 가장 강한 모델로 주요 프로젝트를 스캔해 29,000건 넘는 후보 취약점을 찾았고, 그중 약 6,000건만 사람이 직접 검토·분류할 수 있었습니다. 사람이 병목입니다. 그래서 기존의 인간 검증 CVD 프로세스는 유지하되, 검증 없이 바로 받고 싶은 팀을 위한 빠른 트랙을 연 겁니다. 실제로 최초 보고를 받은 뒤 "검증 안 된 것까지 전부 달라"고 요청한 케이스로 벌써 5,000건 가까운 보고서가 직접 전달됐다고 합니다.

88%라는 숫자를 어떻게 읽어야 할까

발표에서 가장 인용될 숫자는 88%입니다. 초기 버전 검증에서 전문가 침투 테스터가 48개 프로젝트의 critical·high 97건을 보니 85건이 CVD 기준을 통과했고, 나머지 12건 중 11건은 실제 문제지만 중복, 1건만 무효였다는 겁니다.

여기서 정확히 해야 합니다. 이건 작은 표본의 전문가 확인 결과지, 스캐너의 일반 정밀도가 아닙니다. 발표도 심각도 부풀리기나 프로젝트 위협 모델 오해를 지적받았다고 스스로 밝힙니다. 참고로 학계 벤치마크 CyberGym에서는 LLM의 취약점 발견률이 작년 초 20% 미만에서 올해 85% 초과로 올랐다고 합니다. 모델은 좋아졌지만, 내 프로젝트에서의 참양성률은 따로 재야 합니다.

메인터너들의 반응은 꽤 구체적이라 인용할 만합니다.

PostgreSQL: "비정상적으로 높은 비율이 실제 결함이었고, 일부 수정안은 거의 그대로 쓸 수 있었다"
OpenSSL: "날것 그대로도 사람 보고서만큼 좋거나 더 좋았다. 실제 익스플로잇이 붙으면 검증은 끝난 셈"
wolfSSL: "74건 중 2건 빼고 유효, 5건이 CVE가 됐다. 패치가 붙으니 기존 프로세스에 바로 들어갔다"
curl: "최신 도구로 다 뒤지는데도 볼 만한 이슈를 여럿 찾았고, 그중 하나는 최근 몇 년 중 최악급"
HotCRP: "복잡한 권한 모델을 잘 이해하고 우선순위도 좋았다"

칭찬 일색 같지만, 읽어야 할 행간은 "검증 프로세스가 있는 팀"이라는 전제입니다. reproducer와 패치가 기존 프로세스에 바로 들어갔다는 말은, 받는 쪽에 검증·우선순위·회귀 테스트가 있었다는 뜻입니다.

신청은 어떻게 하나

핵심 메인터너가 GitHub 저장소에 PR로 신청합니다. 표준 프로젝트 템플릿을 따르고, 오프라인 에이전트가 보안 감사를 할 수 있게 Dockerfile로 환경을 고정하고 의존성을 미리 깔아두는 방식입니다. 테스트가 컨테이너 안에서 통과하는지 미리 확인하라고 권합니다. 자격 기준은 OSS-Fuzz와 비슷하게 인프라와 사용자 보안에 중대한 영향을 주는 프로젝트 위주로 케이스별로 판단합니다.

신청: github.com/anthropics/oss-scanner 저장소에 PR
준비물: 클론할 git 주소, 담당자 이메일, 빌드·의존성이 고정된 Dockerfile
권장: 컨테이너 안에서 테스트 통과를 미리 확인
함께: Cyber Verification Program(보안 전문가용 고급 기능),
      Claude for OSS(취약점 수정용 무료 구독)도 같이 발표됨

우리 저장소가 신청 대상이 아니어도, 보고서의 모양은 훔쳐볼 가치가 있습니다. reproducer·설명·bisection·후보 패치의 4단 구성이 그대로 좋은 버그 리포트 양식이니까요.

CodeBridge Mini Lab: 탐지 뒤의 5단계를 고정하세요

AI가 찾아주는 시대에 사람이 설계해야 할 건 뒤의 5단계입니다.

탐지 → 재현 → 검증 → 패치 → 회귀 테스트

[ ] 재현: reproducer를 격리된 컨테이너에서 그대로 돌린다
[ ] 검증: 심각도가 우리 위협 모델에 맞는가 (부풀리기 의심)
[ ] 우선순위: 악용 가능성과 노출 범위로 순서를 정한다
[ ] 패치: 후보 패치를 그대로 머지하지 않고 테스트와 함께 검토한다
[ ] 회귀: 동일 계열 취약점의 테스트를 스위트에 남긴다

에이전트 보안 가이드의 4층 구조(범위·승인·격리·검토)를 그대로 가져오면 됩니다. 스캐너가 돌리는 환경도 격리하고, 패치 머지 전 검토 게이트도 고정하는 겁니다.

결론: 빨리 받는 것보다 믿고 고치는 게 먼저다

한 줄로 정리합니다.

취약점 발견 속도가 빨라질수록, 검증·우선순위·패치의 신뢰성이 병목이 된다.

OSS Scanner는 그 병목의 앞부분을 공짜로 당겨줍니다. 29,000건의 후보, 88%라는 표본 검증, 쟁쟁한 메인터너들의 평가는 기대감을 주지만, 내 저장소의 참양성률과 회귀 테스트는 아무도 대신해주지 않습니다. 탐지→재현→검증→패치→회귀의 5단계를 오늘 고정해두는 것, 그게 AI 보안 스캔 시대의 입장권입니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

권한·승인·검증이 있는 흐름으로 AI의 결과물을 통제하는 연습이 필요하다면, 실제 프로젝트에 검증 루프를 쌓는 과정이 이 글의 5단계 워크플로우와 바로 이어집니다.