2026년 AI 취약점 스캐너: 무엇을 찾고 무엇을 놓치는가

Anthropic이 이번 주 오픈소스 프로젝트를 위한 무료 옵트인 방식의 AI 보안 스캐너를 출시했는데, 시기가 참 어수선합니다. AI는 이제 사람이 수년간 감사한 코드에서도 진짜 버그를 찾아냅니다. 동시에 자원봉사 메인테이너를 가짜 버그 보고서로 뒤덮기도 합니다. 둘 다 사실이고, 작은 팀은 이 상황에서 어떻게 할지 결정해야 합니다.

OSS Scanner라는 이 새 서비스는 등록된 프로젝트에 대해 Anthropic의 가장 강력한 모델로 주기적인 취약점 스캔을 실행합니다. 각 보고서에는 재현 코드(reproducer)와 설명, 가능한 경우 패치 후보가 함께 제공됩니다(Anthropic). Google, OpenAI, GitHub, Snyk, Semgrep의 비슷한 시도들과 나란히 놓여 있고, 일부 메인테이너가 문을 닫아걸 만큼 쌓여 가는 저품질 AI 보고서 더미와도 나란히 놓여 있습니다.

이 글에서는 이 상황을 정리해 봅니다. 이런 도구가 하는 일, 무료로 쓸 수 있는 도구, 피해 없이 참여하는 방법, 두 사람짜리 팀도 운영할 수 있는 워크플로를 다룹니다. 요약하면, AI 스캐너는 이제 진지하게 받아들일 만큼 좋아졌지만 결과물을 읽어 보지도 않고 머지해서는 안 됩니다.

Anthropic OSS Scanner가 하는 일

핵심 메인테이너는 템플릿에 따라 GitHub 저장소에 pull request를 열어 등록합니다. Anthropic은 Google의 OSS-Fuzz와 비슷한 기준으로 사례별로 판단하며, 프로젝트에는 "인프라와 사용자 보안에 미치는 중대한 영향"이 있어야 합니다(Anthropic). 그러니 모든 취미용 저장소를 위한 서비스는 아닙니다. curl이나 wolfSSL처럼 인터넷의 절반이 링크해 쓰는 라이브러리를 떠올리면 됩니다.

무료입니다. Anthropic이 Defender Advantage Fund라고 부르는 자금이 스캔 비용을 대고(SiliconANGLE), 회사는 등록된 프로젝트에 계속 무료로 제공하겠다고 밝혔습니다.

가장 중요한 부분은 빠져 있는 것입니다. 보고서는 "사람의 검토나 선별 없이 전적으로 모델이 생성"하며, Anthropic도 일부는 틀릴 것이라고 분명히 말합니다(Anthropic). 예로 든 것이 잘못된 심각도 평가입니다. 보고서를 선별할 인력이 없는 프로젝트는 사람이 먼저 검증하는 Anthropic의 기존 공개 절차를 계속 이용할 수 있습니다(SiliconANGLE).

Anthropic 자체 수치를 보면 이 거래가 가치 있다고 보는 이유를 알 수 있습니다. 전문 침투 테스터들이 48개 프로젝트에서 나온 치명적·높음 심각도 발견 97건을 검토했습니다. 이 중 85건이 조율된 공개(coordinated disclosure) 기준을 충족했고, 11건은 중복이거나 실제 문제지만 이미 알려진 것이었으며, 1건은 무효였습니다(Anthropic). 별도로 wolfSSL은 초기 시범 운영에서 나온 보고서 74건 중 72건이 유효했고, 그 결과 CVE 5건이 나왔다고 밝혔습니다(SiliconANGLE).

curl을 운영하는 Daniel Stenberg는 이 스캐너가 "최근 몇 년간 보고된 curl 취약점 중 최악 중 하나"를 찾아냈다고 말했습니다(Anthropic). 다만 이 수치가 모두 Anthropic이나 그 파트너에게서 나왔다는 점은 염두에 두세요. Anthropic은 참양성률(true-positive rate)이 90%를 넘을 것으로 예상한다고도 하는데(Anthropic), 이는 전망일 뿐 여러분의 저장소에서 보장되는 수치가 아닙니다.

AI 스캐너가 실제로 하는 일: 찾고, 증명하고, 패치한다

전통적인 정적 분석은 코드를 규칙에 맞춰 대조합니다. 빠르고 예측 가능하지만 경고를 쏟아냅니다. 새로운 에이전트형 스캐너는 신입 보안 연구원에 가깝게 일합니다. 코드를 읽고, 어디서 깨질지 가설을 세우고, 실제로 깨뜨려 보고, 그 뒤에야 보고서를 씁니다.

눈여겨볼 부분은 중간 단계입니다. 실제로 동작하는 익스플로잇이 딸린 발견과, 자신만만한 문장 한 단락이 딸린 발견은 전혀 다른 물건입니다.

파이프라인을 왼쪽에서 오른쪽으로 읽어 보세요. 처음 세 단계는 정확성을 위한 것으로, 후보는 누군가 보기 전에 실제 테스트를 거칩니다. 네 번째와 다섯 번째 단계는 유용성을 위한 것으로, 무엇이 깨졌는지 설명하고 수정 초안을 제시합니다. 마지막 상자는 여러분 몫이고, 호박색인 데는 이유가 있습니다. Google은 CodeMender의 모든 패치가 사람의 검토를 거친다고 하고, GitHub의 Autofix는 제안만 합니다. Anthropic의 스캐너는 선별 과정에서 예외이므로 마지막 상자가 여러분에게 넘어옵니다.

2026년의 지형

OSS Scanner만 있는 것은 아닙니다. Google DeepMind는 버그를 찾는 에이전트 Big Sleep과 수정 코드를 작성하는 CodeMender를 만들었습니다. DeepMind는 이미 오픈소스 프로젝트에 보안 수정 72건을 업스트림했고, 모든 패치를 먼저 사람 연구원이 검토했다고 밝혔습니다(Google DeepMind). CodeMender는 이후 Google Cloud 기업 고객 대상 공개 프리뷰로 넘어갔으며, 샌드박스에서 개념 증명(PoC) 익스플로잇을 만들고 테스트를 거친 수정안을 개발자 검토용 diff로 돌려줍니다(Infosecurity Magazine).

OpenAI의 버전은 Aardvark로 출시됐습니다. GPT-5 기반 에이전트로, 저장소의 위협 모델을 만들고 새 커밋을 지켜보다가 샌드박스에서 이슈를 확인하고 패치를 제안합니다. OpenAI는 테스트 저장소의 알려진 취약점과 합성 취약점에서 92%를 기록했고, 발견한 이슈로 CVE ID 10개를 받았다고 밝혔습니다(OpenAI). OpenAI는 이후 이를 Codex에 통합하며 이름을 바꿨습니다. Aardvark 페이지에는 이제 "Aardvark is now Codex Security"라고 적혀 있고, 리서치 프리뷰로 제공됩니다(OpenAI). 문서는 Codex Security를 팀이 "취약점을 찾고, 확인하고, 수정"하도록 돕는 에이전트로 설명하며, 클라우드 버전은 아직 리서치 프리뷰입니다(OpenAI docs).

이 지도는 도구를 역할별로 묶은 것이며, 분류는 벤더가 아니라 저희 기준입니다. 맨 위 줄은 찾고 증명합니다. 가운데 줄은 파이프라인 안에서 모든 커밋에 작동합니다. 맨 아래 줄은 방향이 반대로, AI 시스템 자체를 테스트합니다.

가운데 줄에서 GitHub Copilot Autofix는 GitHub의 스캐너인 CodeQL이 띄운 알림에 대한 수정안을 제안합니다. Semgrep과 Snyk Code는 자체 엔진으로 비슷한 일을 하고, SonarQube는 코드 품질과 보안 점검을 함께 다룹니다. CodeRabbit은 pull request를 리뷰합니다. 맨 아래 줄에서 garak은 언어 모델의 약점을 탐색하고, PentestGPT는 모델로 침투 테스트를 수행합니다. 더 넓은 범위는 AI 사이버 보안 순위에서, pull request 도구는 코드 리뷰 순위에서 확인하세요.

이 표의 내용은 대부분 벤더 페이지에서 가져온 것이고, 벤더는 자사 제품을 좋게 설명하기 마련입니다. 쓸모 있는 열은 이용 조건이라고 보시면 됩니다. 이 조건은 빠르게 바뀝니다.

반대편: 메인테이너가 허우적대고 있다

진짜 버그를 찾아내는 바로 그 모델이 그럴듯한 가짜 버그도 만들어 냅니다. curl이 가장 분명한 사례입니다. curl의 버그 바운티는 2019년부터 2026년 초까지 운영되어 확인된 취약점 87건에 10만 달러 넘게 지급한 뒤 종료됐습니다. 2025년에는 확인된 보고서가 5% 미만이었고, 이전에는 15% 이상이었습니다(Daniel Stenberg).

바운티가 끝나기 직전 일주일 동안 curl에는 7건이 접수됐지만 취약점을 설명한 것은 하나도 없었습니다(The Register). Stenberg의 설명은 직설적이었습니다. 목표는 "AI가 생성했든 아니든, 쓰레기 같고 조사가 부실한 보고서를 우리에게 제출할 유인을 없애는 것"이었습니다. Apache Log4j의 Piotr Karwasz도 같은 양상을 이야기하며, 많은 보고서가 "우리 보안 모델의 기본을 간과해 가치가 아니라 잡음만 더한다"고 했습니다(Daniel Stenberg).

curl은 이후 더 나아갔습니다. Stenberg는 올여름 프로젝트가 한 달간 취약점 보고를 중단했으며 이를 "어쩌면 오랜만에 내린 최고의 프로젝트 결정"이라고 평가했습니다(Daniel Stenberg).

AI 잡음을 막으려고 바운티를 닫은 바로 그 프로젝트가, 최악의 버그 중 하나를 찾아낸 AI 스캐너는 칭찬했다는 점에 주목하세요. 모순이 아닙니다. 차이는 동작하는 재현 코드와, 이미 검증을 마치고 보내는 발신자에 있습니다. 주장을 스스로 증명하는 모델은 메인테이너에게 몇 분을 쓰게 하지만, 모델 출력을 그대로 붙여넣는 사람은 몇 시간을 쓰게 합니다.

Anthropic의 스캐너는 사람이라는 중간 단계를 건너뜁니다. 이것이 매력이자 위험입니다. 전달은 빨라지지만, 아무도 읽어 보지 않은 보고서가 문 앞에 도착할 수 있다는 뜻이기도 합니다. 프로젝트를 유지보수한다면 표에 있는 모든 벤더에게서 이런 보고서가 더 올 것으로 예상하세요.

공격자도 같은 모델을 쓴다

Anthropic은 공식 발표에서 "프런티어 모델은 취약점을 악용하고 사이버 작전을 수행하는 데 오용될 수 있다"고 말합니다(Anthropic). 현실적으로 해석하면 간단합니다. 누구든 강력한 모델에 공개된 코드를 주고 어디가 깨지는지 물을 수 있고, 오픈소스는 정의상 공개되어 있습니다.

이것이 자기 코드를 스캔해야 하는 진짜 이유입니다. AI 스캐너가 마법이라서가 아닙니다. 버그가 존재하는 시점부터 다른 누군가가 찾기까지의 간격이 짧아지고 있고, 그 사람보다 먼저 찾고 싶기 때문입니다. 스캔하지 않는 프로젝트는 안전한 것이 아니라 단지 관찰되지 않았을 뿐입니다.

무료인 것과 아닌 것

코드가 공개되어 있다면 쓸 만한 계층의 상당 부분이 무료입니다. Copilot Autofix는 CodeQL을 쓰는 공개 저장소에서 기본으로 켜져 있으며 Copilot 구독이 필요 없습니다(GitHub). GitHub는 이미 2024년에 모든 공개 저장소에 무료로 열었습니다(GitHub changelog).

Semgrep의 무료 에디션은 기여자 10명, 저장소 10개까지 지원하며 AI 크레딧 60개가 포함됩니다(Semgrep). Snyk의 무료 플랜은 프로젝트 5개와 월 100회의 Snyk Code 테스트를 허용하고(Snyk), 오픈소스 메인테이너가 신청해 무료로 이용할 수 있는 프로그램도 운영합니다.

유료 영역은 대체로 비공개 코드와 에이전트 쪽입니다. 아직 프리뷰인 GitHub의 새 에이전트형 autofix는 AI 크레딧을 사용하고, 비공개 저장소의 Copilot Autofix에는 Code Security 라이선스가 필요합니다(GitHub). Codex Security는 리서치 프리뷰 접근 권한이 필요합니다(OpenAI docs).

안전하게 참여하는 방법

무료라고 해서 결과까지 공짜는 아닙니다. 코드를 읽고 보고서를 보내오는 스캐너는 워크플로, 공개 절차, 때로는 평판에까지 영향을 줍니다. 몇 가지 단계를 밟으면 이를 관리할 수 있습니다.

1. 1먼저 자격 요건을 확인하세요. OSS Scanner는 핵심 인프라나 보안에 영향이 있는 프로젝트를 원하므로, pull request에 시간을 쓰기 전에 Anthropic 저장소의 기준을 읽어 보세요.
2. 2보고서가 갈 곳을 정하세요. GitHub의 비공개 취약점 보고나 보안용 이메일 주소처럼 비공개 채널을 써서, 수정이 나오기 전에 발견 내용이 공개되지 않게 하세요.
3. 3담당자를 정하세요. 한 사람이 모든 보고서를 받고 처리 방향을 결정합니다. 두 사람이 맡으면 서로 상대가 챙기고 있다고 생각하게 됩니다.
4. 4호스팅형 스캐너라면 데이터 약관을 읽어 보세요. 예를 들어 Semgrep은 옵트인한 AI 기능이 발견 사항이 포함된 파일 일부를 처리할 수 있다고 밝힙니다(Semgrep). 무엇이 내 환경 밖으로 나가는지 알아야 합니다.
5. 5읽기 전용 접근으로 시작하고, 패치는 제안으로만 두세요. 어떤 도구도 main 브랜치에 직접 푸시해서는 안 됩니다.
6. 6첫 보고서가 도착하기 전에 공개 일정을 문서로 정해 두세요. 침착할 때 만든 규칙은 훨씬 따르기 쉽습니다.

특별한 건 없습니다. 좋은 메인테이너가 외부 연구자를 대할 때 늘 지키는 기본 수칙을, 보고서가 몰려오기 전에 미리 적용하는 것일 뿐입니다.

소규모 팀을 위한 워크플로

제품을 만드는 2~10명 규모의 팀이라면 첫날부터 에이전트형 스캐너가 필요하진 않습니다. 실제로 비울 수 있는 큐가 필요합니다. 아래 루프는 6단계이며, 호박색 단계가 대부분의 팀이 건너뛰는 곳입니다.

유용한 스캐너와 잡음만 만드는 스캐너를 가르는 것이 재현 단계입니다. 보고서에 재현 코드가 있으면 직접 실행해 보세요. 없으면 요청하세요. 자기 주장이 동작함을 보여 주지 못하는 모델은 가설을 준 것일 뿐이고, 가설은 값쌉니다.

어디서 시작할지 모르겠나요? 아래 의사결정 트리가 흔한 경우를 정리해 줍니다. 위의 벤더 약관을 바탕으로 한 편집부 조언이니 상황에 맞게 조정하세요.

대부분의 소규모 팀에는 무료 pull request 스캐너와 결과를 책임질 한 사람이 더 나은 첫걸음입니다. 큐가 몇 주간 잠잠하게 유지되면 그다음에 에이전트형 도구를 추가하세요. 취미용 저장소는 호스트가 이미 제공하는 무료 기본 기능만으로 충분합니다. 핵심 경로에 놓인 라이브러리라면 OSS Scanner에 신청해야 할 대상입니다.

트리아지 비용 계산하기

가격표에 트리아지 시간을 적어 두는 곳은 없지만, 스캐너가 도움이 될지 해가 될지는 이 비용이 가릅니다. 좋은 도구도 중복은 어느 정도 만들어 냅니다. Anthropic 자체 검토에서도 97건 중 11건이었습니다. 아래 계산기는 보고서 건수를 시간으로 환산해 줍니다.

무효 비율을 높여 보고 시간이 얼마나 빨리 쌓이는지 확인해 보세요. 그다음 보고서당 소요 시간을 15분으로 줄여 보면, 동작하는 증명이 얼마나 아껴 줄지 대략 감이 옵니다(이 숫자는 측정값이 아니라 예시입니다). 그 차이가 AI 도구든 사람이든 재현 코드를 요구해야 하는 이유입니다.

보고서가 들어오기 시작하면 몇 가지 습관이 도움이 됩니다. 아래 그래픽에 요약했습니다.

첫 번째 쌍은 다시 강조할 만합니다. 심각도 평가는 모델이 내린 것이며 Anthropic 스스로도 틀릴 수 있다고 경고합니다(SiliconANGLE). 재현해 본 뒤에 직접 평가하세요. Claude Code 같은 어시스턴트는 버그가 진짜라고 판단한 뒤 수정과 회귀 테스트를 작성하는 데 도움이 되지만, 판단은 여전히 여러분의 몫입니다. 이런 도구에 대한 더 넓은 맥락은 코딩 어시스턴트 순위와 AI 코드 리뷰 도구 가이드를 참고하세요.

이 도구들이 아직 부족한 부분

코드에 흔적이 남는 유형의 버그, 즉 메모리 오류, 인젝션, 누락된 검사에는 강합니다. 반면 누가 무엇을 승인할 수 있는가처럼 비즈니스가 실제로 돌아가는 방식에 달린 결함에는 약합니다. 스캐너는 여러분의 의도를 알 수 없습니다.

또 보안의 나머지 부분을 대체하지도 못합니다. Google의 CodeMender는 패치가 업스트림에 반영되기 전에 사람이 검토하도록 하고(Google DeepMind), GitHub는 Autofix가 최선의 노력(best-effort) 방식으로 동작하며 커스텀 쿼리의 알림이 수정으로 해결됐는지는 확인할 수 없다고 밝힙니다(GitHub). 가장 얻을 게 많은 벤더들조차 출력을 확인하라고 말합니다.

솔직한 한계는 물량입니다. 버그를 찾는 비용이 고치는 비용보다 빠르게 내려가고 있습니다. 3인 프로젝트에 진짜 발견 사항 마흔 건을 안겨 주는 스캐너는 더 안전한 제품이 아니라 백로그를 만들어 준 것입니다. 얼마나 많이 찾느냐가 아니라 한 달에 얼마나 고칠 수 있느냐를 기준으로 도구를 고르세요.

자주 묻는 질문

Anthropic의 OSS Scanner는 모든 GitHub 저장소에 열려 있나요?

아닙니다. 옵트인 방식이며 OSS-Fuzz와 비슷한 기준으로 사례별로 평가하므로, 프로젝트가 인프라와 사용자 보안에 중대한 영향을 미쳐야 합니다. 메인테이너는 Anthropic의 GitHub 저장소에 pull request를 보내 신청합니다.

AI 스캐너가 침투 테스트를 대체하나요?

고객에게 중요한 영역에서는 그렇지 않습니다. 코드 수준 버그는 잘 다루지만 비즈니스 로직 결함은 잘 다루지 못합니다. 가끔 하는 사람의 검토와 함께, 항상 돌아가는 추가 계층으로 생각하세요.

Claude나 Gemini를 직접 써서 코드를 감사해도 되나요?

Claude나 Google Gemini에 코드를 붙여넣고 보안 리뷰를 요청할 수 있습니다. 함수 하나를 볼 때는 도움이 됩니다. 하지만 위의 전용 에이전트가 더해 주는 샌드박스, 저장소 전체 위협 모델, 익스플로잇 검증은 없으므로 오탐이 더 많을 것으로 예상해야 합니다.

가짜 같아 보이는 AI 작성 보고서를 받으면 어떻게 해야 하나요?

특정 버전을 대상으로 한 재현 코드를 요청하세요. 진짜 발견이라면 그 질문에 답할 수 있습니다. 조작된 것은 대개 답하지 못합니다. 계속 그런 보고서를 보내는 사람이 있다면 보고서를 닫고 넘어가도 됩니다.

무료 스캐너를 비공개 코드에 써도 안전한가요?

각 도구의 약관을 읽어 보세요. 완전히 자기 컴퓨터에서만 돌아가는 도구도 있고, 파일 일부를 호스팅된 모델로 보내는 도구도 있습니다. 비공개 저장소를 연결하기 전에 벤더가 무엇을 얼마나 오래 저장하는지 확인하세요.