Anthropic Cyber Mission: OSS Scanner와 CVP 확장이 오픈소스 보안 운영을 바꾸는 지점
Anthropic이 10월 초 Cyber Verification Program(CVP)을 확장하고, 이어서 Anthropic Cyber Mission과 OSS Scanner를 공개했다. 뉴스의 표면만 보면 “AI로 보안 취약점을 더 많이 찾겠다”는 발표다. 하지만 실무 개발자에게 더 중요한 변화는 따로 있다. AI가 취약점 발견 속도를 올리는 만큼, 오픈소스 유지보수자와 보안팀의 병목이 “탐지”에서 “검증, 우선순위, 패치 적용”으로 이동하고 있다는 점이다.
Anthropic 발표에 따르면 Project Glasswing과 관련 프로그램에서 2026년 4월부터 7월 사이 파트너들이 최소 129,000개의 검증된 소프트웨어 취약점을 발견했고, Anthropic의 오픈소스 스캔에서도 4월부터 10월 사이 5,500개 이상의 검증된 취약점이 나왔다. 이 중 33,000개 이상은 critical 또는 high severity로 분류됐다. 숫자 자체도 크지만, 더 중요한 건 “발견량이 사람 검증량을 앞지르기 시작했다”는 신호다.
무엇이 새로 공개됐나
이번 발표는 크게 세 갈래다. 첫째, Cyber Verification Program이 세 단계 접근 모델로 확장됐다. Defense Access는 SOC, incident response, malware 분석, owned system 취약점 검증 같은 방어 작업을 대상으로 한다. Red Team Access는 권한을 받은 침투 테스트와 레드팀 활동까지 포함한다. Specialized Access는 전력망, 항공 시스템, 통신망, 금융 결제망처럼 실제 사람과 시장에 영향을 줄 수 있는 고위험 시스템을 대상으로 하며, 더 깊은 심사를 거친다.
둘째, Anthropic Cyber Mission은 critical infrastructure와 open-source software를 장기 방어 대상으로 삼는다. 전력, 수도, 운송, 공장 운영 기술(OT)은 패치가 어렵고 장비 수명이 길다. 취약점을 알아도 운영 중단 없이 수정하기 어려운 영역이다. 여기에 CrowdStrike, Dragos, Palo Alto Networks, Rockwell Automation 같은 파트너가 참여한다는 점은 단순 연구 프로젝트보다 실제 운영 환경에 가까운 실험이라는 뜻이다.
셋째, OSS Scanner가 공개됐다. OSS Scanner는 오픈소스 프로젝트가 opt-in하면 Anthropic의 강한 모델로 정기 보안 스캔을 받고, 재현 절차, 취약점 설명, 가능한 경우 후보 패치까지 받는 구조다. 보고서는 인간 리뷰 없이 모델이 생성한다. 빠르지만 틀릴 수 있다는 전제를 공개적으로 둔 셈이다.
오픈소스 유지보수자에게 생기는 새 문제
OSS Scanner가 유용하더라도 유지보수자 입장에서는 새 업무가 생긴다. 모델이 보낸 보고서가 맞는지 확인해야 하고, 기존 known issue와 중복인지 봐야 하며, severity가 프로젝트 threat model에 맞는지 다시 판단해야 한다. Anthropic은 초기 검증에서 48개 프로젝트의 critical/high 97건 중 85건이 CVD 기준을 충족했고, 나머지 12건 중 11건은 실제 문제였지만 중복 또는 알려진 이슈였다고 설명했다. 이 수치만 보면 신호 품질은 높아 보인다. 그래도 “모든 보고서가 곧 패치 대상”은 아니다.
실무적으로 가장 위험한 반응은 두 가지다. 하나는 AI 보고서를 모두 무시하는 것이다. 공격자도 비슷한 도구를 쓰기 때문에, 방어자가 무시하면 시간 우위를 잃는다. 다른 하나는 AI 보고서를 전부 긴급 취약점으로 취급하는 것이다. 이렇게 하면 유지보수자는 금방 번아웃되고, 실제로 중요한 패치가 묻힌다.
그래서 필요한 건 보고서 수신 프로세스다. AI 취약점 리포트는 이메일함에 던져두면 안 된다. 별도 라벨, 별도 triage queue, 별도 SLA가 있어야 한다. 최소한 재현 가능 여부, 공격 전제 조건, 영향 범위, affected version, 공개 여부, 패치 난이도는 구조화해서 기록해야 한다.
기업 보안팀이 확인해야 할 지점
기업 보안팀은 OSS Scanner를 직접 쓰지 않더라도 영향을 받는다. 대부분의 제품은 오픈소스 라이브러리에 의존한다. 특정 라이브러리 maintainers가 AI 스캐너로 취약점을 대량 수신하기 시작하면, CVE 공개와 패치 릴리스 속도가 빨라질 수 있다. 그 결과 내부 dependency update 프로세스가 더 자주 압박을 받는다.
SBOM만 만들어두는 것으로는 부족하다. 어떤 라이브러리가 runtime 경로에 있는지, internet-facing 경로에 있는지, 권한 상승 가능성이 있는지까지 알아야 한다. 같은 high severity라도 CLI 개발 도구의 optional dependency와 결제 API 서버의 요청 처리 경로에 있는 라이브러리는 우선순위가 다르다.
또 하나는 “AI가 만든 패치” 검토다. OSS Scanner는 후보 패치를 제공할 수 있다. upstream maintainer가 이를 받아들이면 기업은 해당 패치를 포함한 버전을 쓰게 된다. 내부 보안 리뷰는 취약점 존재 여부뿐 아니라 패치가 regression을 만들지 않는지도 봐야 한다. 보안 패치가 성급하게 들어가면 API 호환성, 성능, edge case가 깨질 수 있다.
CVP 확장이 의미하는 모델 접근의 분리
CVP의 세 단계 접근은 앞으로 AI 보안 도구가 “일반 모델 하나로 모두 해결”되지 않을 가능성을 보여준다. 일반 공개 모델은 위험한 사이버 요청을 강하게 막고, 검증된 방어자는 더 넓은 능력을 쓰게 하는 구조다. 이는 보안팀에게 현실적인 이점과 관리 부담을 동시에 준다.
이점은 명확하다. malware 분석, 취약점 재현, exploitability 검증처럼 일반 모델에서 막히던 합법적 작업을 더 잘 처리할 수 있다. 부담은 접근 관리다. 누가 Defense Access를 쓰고, 누가 Red Team Access를 쓰는지, 어떤 고객 데이터가 들어가는지, 결과물을 어디에 저장하는지 정해야 한다. 모델 접근 권한은 이제 SaaS 계정 권한이 아니라 보안 운영 권한에 가깝다.
특히 데이터 보관 정책을 확인해야 한다. Anthropic은 프로그램 참여 조직에 misuse monitoring을 위한 데이터 보관이 필요하다고 설명했고, Enterprise Frontier Safeguards가 나오면 조직이 통제하는 클라우드 인프라에 데이터를 저장할 수 있게 하겠다고 밝혔다. 즉 “강한 모델 접근”과 “제로 데이터 보관”이 항상 동시에 성립하지 않을 수 있다.
개발팀이 지금 정리할 것
개발팀은 이 뉴스를 보안팀 일로만 넘기면 안 된다. AI 스캐너가 취약점을 빨리 찾는 시대에는 코드 구조와 테스트 구조가 패치 속도를 좌우한다. 재현 테스트가 없고, dependency boundary가 흐리고, 릴리스 자동화가 약하면 취약점 발견 속도가 올라갈수록 팀은 더 바빠진다.
먼저 보안 패치 전용 CI 경로를 만들어야 한다. 전체 e2e가 2시간 걸리면 긴급 패치가 느려진다. 취약점 영향 경로와 관련된 테스트를 빠르게 돌릴 수 있어야 한다. 다음으로 dependency owner를 정해야 한다. “누군가 업데이트하겠지”는 취약점 대응에서 가장 비싼 문장이다. 마지막으로 AI 리포트에 대응하는 issue template을 준비해야 한다. 보고서 링크, 재현 명령, 영향을 받는 버전, exploitable condition, 수정 후보, 검증 결과를 한 화면에서 볼 수 있어야 한다.
실행 체크리스트
- 주요 레포의 dependency owner를 정하고 CODEOWNERS 또는 내부 문서에 기록한다.
- SBOM을 생성하는 데서 멈추지 말고 internet-facing/runtime/test-only 의존성을 구분한다.
- AI 취약점 리포트를 받을 별도 triage queue와 라벨을 만든다.
- 리포트마다 재현 가능성, 영향 범위, affected version, severity 근거를 구조화한다.
- 후보 패치가 오면 보안 테스트와 regression 테스트를 분리해서 돌린다.
- high/critical 패치 전용 fast CI 경로를 만든다.
- CVP 같은 강한 모델 접근 권한은 개인 계정이 아니라 보안 운영 권한으로 관리한다.
- 모델에 입력되는 코드와 로그의 데이터 보관 정책을 확인한다.
- upstream maintainer가 AI 생성 패치를 받아들인 경우 changelog와 diff를 직접 확인한다.
- 오픈소스 프로젝트를 운영한다면 OSS Scanner opt-in 전에 triage capacity를 먼저 계산한다.
Anthropic Cyber Mission의 핵심은 AI가 보안 업무를 자동으로 해결한다는 이야기가 아니다. 취약점 발견 비용이 내려가면서, 검증과 패치 운영이 제품 경쟁력이 된다는 신호다. 실무팀이 준비해야 할 것은 더 많은 스캐너가 아니라 더 좋은 triage, 더 빠른 패치 경로, 그리고 AI 리포트를 다룰 수 있는 운영 기준이다.