Anthropic OSS Scanner, 무료 오픈소스 감사를 제공하지만 유지관리자는 AI 출력을 분류해야 한다

Anthropic은 10월 8일 Anthropic OSS Scanner를 출시하며, 자격을 갖춘 오픈소스 프로젝트에 무료로 정기 취약점 감사를 제공하기 시작했다. 이 서비스는 AI 보조 보안 연구를 크게 확장하는 움직임이다. 다만 보고서가 사람의 검증 없이 전달되기 때문에 중요한 부담도 유지관리자에게 넘어간다.

이러한 절충이 이번 출시의 핵심이다. Anthropic은 자사 모델이 보안 연구원이 수동으로 검토할 수 있는 양보다 더 많은 코드를 조사할 수 있다고 말한다. OSS Scanner는 원시 발견 사항을 참여 프로젝트에 직접 전송해 이 검토 병목을 없앤다.

시점은 오픈소스 유지관리자에게 불편하다. Google은 최근 무효한 자동화 보고서가 급증하자 오픈소스 취약점 보상 프로그램의 일부를 중단했다. curl 프로젝트도 유지관리자들이 낮은 품질의 제출물에 어려움을 겪은 뒤 버그 바운티를 종료했다.

Anthropic은 자사 보고서가 과거 유지관리자들을 좌절시켰던 AI 생성 발견 사항보다 훨씬 나은 근거를 제공한다고 본다. 일부 사례에서는 초기 프로젝트 피드백도 이 주장을 뒷받침한다. 그러나 이 공개 서비스가 더 광범위한 저장소에서 정확도를 유지할 수 있는지는 아직 입증되지 않았다.

Anthropic OSS Scanner, 속도를 위해 사람의 검토를 교환하다

Anthropic OSS Scanner는 유지관리자에게 잠재적 취약점에 대한 더 이른 접근을 제공하지만, 각 참여 프로젝트는 모델의 결론을 검증할 책임을 지게 된다.

OSS Scanner 출시 발표에 따르면, 참여 프로젝트는 Anthropic의 가장 강력한 모델로부터 정기 스캔을 받는다. 여기에는 Anthropic이 고급 사이버보안 작업을 위해 개발한 Claude Mythos가 포함된다.

보고서는 전적으로 모델이 생성한다. Anthropic은 발견 사항이 프로젝트에 도달하기 전 보안 연구원이 이를 검증한다고 약속하지 않는다. 회사는 보고서가 부정확하거나 무효할 수 있다고 명시적으로 경고한다.

각 보고서는 단순히 의심스러운 코드 위치만 포함하도록 설계되지 않았다. Anthropic은 설명, 재현 지침, 가능한 경우 후보 패치를 제공한다고 말한다. 보고서에는 의심되는 결함이 언제 발생했는지 식별하는 코드 이력 분석도 포함될 수 있다.

이러한 근거는 유지관리자가 실제 취약점과 그럴듯하게 들리는 모델 출력을 반복 가능한 방식으로 구분해야 하기 때문에 중요하다. 구체적인 재현 절차가 있으면 엔지니어는 관련 코드를 실행해 보고된 동작이 실제로 발생하는지 관찰할 수 있다.

후보 패치는 다음 단계를 단축할 수 있다. 그러나 검토, 테스트, 호환성 점검, 하위 생태계와의 조율이 필요 없어진다는 뜻은 아니다. 보안 수정은 때때로 사용자나 의존 소프트웨어가 조용히 의존해 온 동작을 바꾼다.

Anthropic은 등록을 더 폭넓게 제공하기 전에 수십 개의 오픈소스 프로젝트와 파이프라인을 시험했다. 회사에 따르면 초기 스캔에서는 수백 건의 보고서가 나왔다. Anthropic은 여러 발견 사항을 결합하면 인증 없는 원격 코드 실행 공격으로 이어질 수 있다고 말한다.

이는 공격자가 영향을 받는 시스템에 먼저 로그인하지 않고도 잠재적으로 코드를 실행할 수 있다는 점에서 심각한 취약점 범주다. 다만 Anthropic은 이 초기 결과에 대한 완전한 독립 평가를 공개하지 않았다.

이번 출시는 Anthropic이 이전에 조정된 취약점 공개 프로그램을 통해 처리하던 작업을 확장한다. 그 과정에서는 보안 연구원이 유지관리자에게 통지하기 전에 발견 사항을 검토했다. 공개는 일반적으로 정해진 일정에 따라 이뤄졌다.

OSS Scanner는 별도의 신속 경로를 만든다. 자동화된 발견 사항은 유지관리자에게 비공개 이메일로 전송되며, Anthropic은 표준 공개 기한에 따라 이를 자동 공개하지 않을 것이라고 말한다.

Anthropic이 이후 사람의 검토를 거친 프로그램을 통해 발견 사항을 검증하면 해당 보고서는 회사의 기존 공개 절차에 들어갈 수 있다. 그때까지 자동화 보고서는 검증되지 않은 비공개 제출물로 남는다.

이 구분은 필수적이다. Anthropic은 등록된 소프트웨어가 안전하다는 인증을 제공하는 것이 아니다. 시스템이 성공한 경우 재현 가능한 근거로 뒷받침되는 또 하나의 취약점 가설 출처를 제공하는 것이다.

수치가 Anthropic이 절차를 바꾼 이유를 설명한다

이 서비스가 존재하는 이유는 Anthropic의 모델이 연구원이 검증할 수 있는 속도보다 훨씬 빠르게 후보 발견 사항을 생성할 수 있기 때문이다.

Anthropic은 지난 6개월 동안 중요한 소프트웨어 프로젝트를 스캔하면서 29,000건이 넘는 후보 취약점을 발견했다고 말한다. 같은 기간 연구원들은 약 6,000건의 보고서를 수동으로 검토했다.

이는 완료된 사람 검토 절차 밖에 23,000건이 넘는 후보 발견 사항이 남아 있음을 의미한다. 일부는 실제 보안 문제일 것이다. 다른 일부는 중복, 오해, 영향이 낮은 결함 또는 잘못된 모델 결론일 수 있다.

Anthropic은 유지관리자들이 검증되지 않은 출력에 대한 일괄 접근을 점점 더 요청했다고도 말한다. 회사는 이용 가능한 모든 결과를 받고자 한 프로젝트에 검증되지 않은 발견 사항 약 5,000건을 전송했다고 밝혔다.

이 수치는 Anthropic OSS Scanner의 운영 논리를 설명한다. 계속 수동 검토를 요구하면 Anthropic이 다룰 수 있는 저장소 수가 제한된다. 이 요건을 없애면 범위와 빈도, 불확실성이 동시에 증가한다.

회사는 이 변화를 개선되는 모델 성능과 연결한다. Anthropic은 2025년 초 언어 모델이 CyberGym 벤치마크에서 취약점의 20% 미만을 찾아냈다고 말한다. 2026년에는 그 결과가 85%를 넘었다고 한다.

벤치마크는 표준화된 테스트 세트이지, 현장 성능을 보장하는 것은 아니다. 실제 저장소에는 특이한 빌드 시스템, 문서화되지 않은 가정, 생성된 코드, 프로젝트별 보안 경계가 존재한다.

모델은 보안 영향을 올바르게 판단하지 못한 채 실제 소프트웨어 결함을 식별할 수도 있다. 도달할 수 없는 테스트 유틸리티의 범위를 벗어난 읽기는 네트워크 서비스로 노출되는 경우와 다른 위험을 제시한다.

Anthropic의 자체 수치는 두 번째 제약도 드러낸다. 후보 문제를 찾는 일은 더 이상 유일한 희소 자원이 아니다. 검증, 우선순위 설정, 수정, 공개가 워크플로에서 더 어려운 부분이 되고 있다.

이 전환은 전담 보안팀이 없는 프로젝트에 압박을 가한다. 주요 인프라 라이브러리는 기능 요청, 회귀 문제, 패키징 이슈, 커뮤니티 지원을 이미 처리하고 있는 소수의 유지관리자에게 의존할 수 있다.

잘 구성된 보고서조차 주의를 소모한다. 누군가는 동작을 재현하고, 영향을 받는 버전을 확인하고, 악용 가능성을 평가하고, 안전한 수정안을 설계하며, 릴리스를 조율해야 한다.

보안팀은 오랫동안 정적 분석, 퍼징, 의존성 스캔으로 의심스러운 동작을 식별해 왔다. 퍼징은 충돌이나 다른 실패를 드러내기 위해 예상치 못한 입력을 소프트웨어에 공급한다.

AI 취약점 스캔은 추론 계층을 더한다. 모델은 함수 간 관계를 살피고, 의도된 동작을 추론하며, 버전 이력을 조사하고, 표적화된 테스트를 구성할 수 있다.

Anthropic은 기존 기법이 아무것도 찾지 못한 뒤에도 자사 모델이 새로운 조사 경로를 추적한 경우가 있다고 말한다. 이전 연구에는 소스 제어 이력 조사와 의심되는 취약점에 대한 개념 증명 프로그램 작성이 포함됐다.

이러한 폭넓은 추론은 패턴 기반 도구가 놓치는 결함을 찾아낼 수 있다. 동시에 설득력은 있지만 잘못된 서사를 만들어낼 수도 있다. 따라서 설명의 유창함보다 동반 근거의 품질이 더 중요하다.

오픈소스 유지관리자가 최종 검증 계층이 된다

Anthropic의 무료 서비스는 비싼 모델 연산을 유지관리자에게서 옮기지만, 보안 분류에 드는 사람의 비용까지 없애지는 않는다.

핵심 유지관리자는 프로젝트의 등록 저장소를 통해 참여를 신청해야 한다. 이들은 구성 세부 사항과 소프트웨어 빌드 지침을 담은 풀 리퀘스트를 제출한다.

각 프로젝트는 저장소 주소, 주 보안 담당 연락처, Dockerfile을 제공한다. Dockerfile은 컨테이너 안에서 프로젝트를 빌드하는 데 필요한 환경과 명령을 설명한다.

프로젝트는 위협 모델도 제공할 수 있다. 이 문서는 어떤 자산이 중요한지, 신뢰할 수 없는 데이터가 어디로 들어오는지, 유지관리자가 심각도를 어떻게 분류하는지를 설명한다.

이러한 맥락은 명백한 오해를 방지할 수 있다. 그렇지 않으면 스캐너가 의도적인 동작을 취약점으로 간주하거나, 신뢰할 수 없는 입력을 전혀 처리하지 않는 코드의 중요성을 과장할 수 있다.

Anthropic은 참여 프로젝트를 격리된 가상 머신 안에서 빌드한다. 설정 과정에서는 필요한 의존성을 가져오기 위해 네트워크 접근을 사용할 수 있다. 실제 보안 분석은 강화된 샌드박스 안에서 인터넷 접근 없이 실행된다.

발견 사항은 이후 프로젝트가 지정한 연락처에 이메일로 전송된다. 유지관리자는 등록 구성에 OpenPGP 키를 게시해 암호화된 전달을 요청할 수 있다.

이 서비스는 자격을 갖춘 오픈소스 프로젝트로 제한된다. Anthropic은 자격 요건이 Google의 OSS-Fuzz 프로그램 기준과 유사하다고 말한다. 프로젝트는 인프라 또는 사용자 보안에 중대한 영향을 미쳐야 한다.

이 기준은 OSS Scanner를 누구나 어떤 저장소에든 지정할 수 있는 공개 도구와 구별한다. Anthropic은 등록을 통제하고, 승인된 프로젝트의 모델 연산 비용을 부담한다.

회사는 일반 상용 보안 제품에서 사용하는 것보다 더 실험적이고 토큰 집약적인 스캔 방법도 적용한다. 이 선택은 오픈소스 서비스를 더 깊은 감사를 위한 시험장으로 위치시킨다.

유지관리자는 등록 후에도 통제권을 유지한다. 다른 풀 리퀘스트를 통해 구성을 편집하고, 빌드 지침을 업데이트하고, 스캔을 일시 중지하거나 프로젝트를 철회할 수 있다.

각 발견 사항을 어떻게 처리할지도 이들이 결정한다. Anthropic은 자동으로 공개 이슈를 만들거나, 취약점 식별자를 부여하거나, 원시 자동화 출력에 공개 시계를 적용하지 않는다.

이 접근 방식은 잘못된 보고서가 프로젝트가 악용 가능한 결함을 출시했다며 공개적으로 비난할 가능성을 낮춘다. 또한 유지관리자가 패치를 평가하기 전에 기술 세부 사항이 노출되는 일도 피한다.

그러나 비공개 전달이 역량 제약을 해결하지는 않는다. 소규모 프로젝트는 자원봉사자가 처리할 수 있는 것보다 더 많은 신뢰도 높은 보고서를 받을 수 있다. Anthropic은 보고서 양에 대한 보편적인 상한을 발표하지 않았다.

프로젝트에는 자체적인 접수 규칙이 필요하다. 실용적인 워크플로는 재현 가능하고 외부에서 도달할 수 있는 문제를 비현실적인 조건이 필요한 충돌과 구분해야 한다.

팀에는 지속적인 기술 기록도 필요하다. 검색 가능한 엔지니어링 지식 기반은 재현 단계, 영향을 받는 버전, 패치 결정, 후속 작업을 보존할 수 있다.

여러 보고서가 근본 원인을 공유할 때 이러한 문서화는 중요해진다. 문서화가 없으면 서로 다른 유지관리자가 같은 조사를 반복하거나 브랜치마다 일관되지 않은 수정을 적용할 수 있다.

AI 취약점 스캔이 이제 정확성 시험에 직면하다

핵심 질문은 더 이상 AI 모델이 취약점을 찾을 수 있는지 여부가 아니라, 유지관리자의 관심을 정당화할 만큼 충분한 검증된 신호를 제공할 수 있는지다.

Anthropic의 가장 강력한 초기 근거는 시스템을 시험한 프로젝트에서 나온다. PostgreSQL 기여자 Noah Misch는 여러 보고서가 결함을 식별했고 거의 바로 사용할 수 있는 수준의 수정안도 포함했다고 말했다.

OpenSSL Corporation의 Anton Arapov는 원시 출력 결과가 사람이 작성한 보고서와 비교해도 긍정적이라고 평가했다. 그는 엔지니어가 직접 테스트할 수 있는 작동하는 익스플로잇을 제공받는 가치가 크다고 강조했다.

가장 구체적으로 보고된 결과는 wolfSSL에서 나왔다. Anthropic이 공개한 피드백에 따르면, 이 프로젝트는 74건의 발견 사항을 받았으며 그중 2건을 제외한 모든 항목을 유효한 것으로 판단했다. 이 가운데 5건은 일반적으로 CVE라고 불리는 Common Vulnerabilities and Exposures 기록으로 등록됐다.

이 결과는 한 초기 배포 사례에서 높은 정밀도를 시사한다. 그러나 프로그래밍 언어, 프로젝트 유형, 빌드 구성, 위협 모델 전반에서 동일한 비율이 나타난다는 점을 입증하지는 않는다.

이 표본은 Anthropic 자체의 출시 자료에서도 나온 것이다. 회사는 파일럿 과정에서 수용, 거부, 중복, 이의 제기된 모든 보고서를 보여 주는 완전한 데이터셋을 공개하지 않았다.

독립적인 측정을 위해서는 단순히 보고서 수를 세는 것 이상이 필요하다. 연구자들은 유효성, 심각도, 중복 여부, 재현 시간, 패치 시간, 그리고 제안된 수정으로 발생한 회귀 수를 검토해야 한다.

관리자의 노력 역시 중요한 지표다. 더 많은 실제 결함을 찾아내는 스캐너라도, 유효한 보고서마다 설득력 있는 수많은 오탐이 섞여 들어온다면 전체적으로는 부담이 될 수 있다.

이 위험은 이론적인 것이 아니다. 다른 오픈소스 커뮤니티에서도 충분한 근거가 없는 자동화 취약점 제출이 급증한 사례가 있었다.

Google은 자동화 보고서가 크게 늘어난 뒤 Open Source Software Vulnerability Rewards Program의 일부를 중단했다고 밝혔다. 회사의 설명에 따르면, 해당 제출물 대부분은 유효하지 않았다.

curl 프로젝트는 2026년 1월 버그 바운티를 종료했다. 관리자는 AI가 생성한 보고서가 그에 상응하는 보안 가치를 제공하지 못한 채 시간을 소모시킨다고 반복해서 경고해 왔다.

Linux 관리자들도 중복된 자동화 보고서를 관리하기 어렵다고 설명했다. 여러 사람이 유사한 도구를 실행해 같은 의심스러운 패턴을 발견하고, 거의 동일한 제출물을 독립적으로 보낼 수 있다.

Anthropic의 옵트인 설계는 이 문제의 일부를 해결한다. 권한을 가진 관리자만 프로젝트를 등록할 수 있으며, 보고서는 지정된 연락처로 직접 전달된다. 외부인이 제출량을 최대화하도록 유도하는 금전적 보상도 없다.

필수 재현 절차는 증거 기준도 높인다. 관찰 가능한 동작을 보여 주는 보고서는 단지 코드 패턴을 위험하다고 표시하는 보고서보다 더 유용하다.

그렇더라도 재현 절차가 의미 있는 공격 경로를 입증하지 못한 채 충돌만 보여 줄 수 있다. 실제 사용자가 결코 배포하지 않는 인위적인 빌드 옵션이나 구성에 의존할 수도 있다.

후보 패치도 또 다른 불확실성의 원인이다. 패치는 근본 취약점을 그대로 둔 채 테스트만 통과시킬 수 있다. 다른 버그를 도입하거나 다운스트림 호환성을 깨뜨릴 수도 있다.

초기 결과는 자동적인 신뢰가 아니라 신중한 관심을 정당화한다. Anthropic OSS Scanner는 등록 대상이 협조적인 파일럿 프로젝트를 넘어 확장된 뒤에도 출력 결과가 계속 유용하다는 점을 입증해야 한다.

OSS Scanner는 기존 보안 도구를 보완한다

Anthropic은 자사의 스캐너를 퍼저, 의존성 데이터베이스, 코드 리뷰, 조정된 공개를 대체하는 수단이 아니라 추가적인 탐지 시스템으로 포지셔닝하고 있다.

가장 명확한 역사적 비교 대상은 퍼징 인프라로 중요한 오픈소스 프로젝트를 지속적으로 테스트해 온 Google의 OSS-Fuzz 서비스다.

OSS-Fuzz는 도구가 의미 있는 프로그램 동작을 유발하는 입력을 생성할 수 있을 때 효과적이다. 특히 파일, 네트워크 메시지 또는 기타 신뢰할 수 없는 데이터를 파싱하는 소프트웨어에 유용하다.

그러나 퍼징은 테스트 하니스와 관찰 가능한 실패에 의존한다. 일부 권한 부여 오류, 비즈니스 로직 결함, 다단계 공격 경로는 즉각적인 충돌을 일으키지 않는다.

대규모 언어 모델은 이러한 관계를 추론할 수 있다. 서로 다른 구성 요소를 거쳐 데이터를 추적하고, 프로젝트가 명시한 보안 모델을 고려하며, 표적화된 실험을 생성할 수 있다.

전통적인 정적 분석도 또 다른 비교 대상이다. 이는 완전한 프로그램을 실행하지 않고 소스 코드를 검사하며, 위험한 흐름이나 패턴을 식별하는 규칙을 적용한다.

정적 분석기는 반복 가능하며 모든 소프트웨어 변경 시 실행할 수 있다. 유용성은 규칙의 품질, 언어 지원, 그리고 팀이 반복되는 경고를 관리할 수 있는 능력에 달려 있다.

소프트웨어 구성 분석은 포함된 패키지와 알려진 취약점에 초점을 맞춘다. 의존성이 영향을 받는 버전과 일치한다는 사실은 알려 줄 수 있지만, 일반적으로 이전에 알려지지 않은 결함을 발견하지는 못한다.

Anthropic의 서비스는 소스 코드 내부의 알려지지 않은 취약점을 겨냥한다. 이 서비스의 모델은 리포지토리를 기존 취약점 카탈로그와 대조하는 데만 제한되지 않는다.

이 모든 접근 방식에서 사람의 검토는 여전히 필요하다. 보안 엔지니어는 배포 맥락, 공격자의 동기, 호환성 요구 사항, 그리고 스캐너의 즉각적인 테스트 환경을 넘어서는 영향을 이해한다.

도구들은 서로를 강화할 수도 있다. AI가 생성한 가설은 퍼징 대상이 될 수 있다. 퍼저가 발견한 충돌은 모델이 근본 원인을 분석할 수 있는 구체적인 증거를 제공할 수 있다.

모델은 패치를 제안할 수 있고, 정적 분석과 회귀 테스트는 그 변경에서 새로운 문제를 검토할 수 있다. 이어 의존성 분석은 업데이트된 릴리스가 필요한 다운스트림 제품을 식별할 수 있다.

Anthropic의 표준 공개 정책은 연구진이 문제를 검증할 때도 여전히 관련이 있다. 이 정책은 일반적으로 통지 후 90일이 지나거나 패치가 출시된 시점에 공개하는 방식을 목표로 한다.

이 정책은 활발히 악용되고 있는 치명적 취약점에는 더 짧은 일정을 허용한다. 또한 수정 작업에서 진전을 보이고 있는 관리자에 대한 기간 연장도 설명한다.

원시 OSS Scanner 보고서는 이 자동 일정의 적용 대상이 아니다. Anthropic은 해당 보고서가 이후 사람의 검토를 거치는 절차에 들어가지 않는 한 공개하지 않겠다고 밝혔다.

이러한 분리는 관리자가 조사할 여지를 제공한다. 동시에 장기간 해결되지 않은 발견 사항에 관한 거버넌스 문제도 남긴다.

Anthropic은 향후 일부 심각도가 높은 자동화 발견 사항에 공개 기간을 도입할 수 있다고 밝혔다. 회사는 정책이 변경될 경우 사전 통지하고 프로젝트가 서비스를 떠날 수 있는 선택권을 제공하겠다고 약속했다.

현재로서는 이 서비스가 공개적 책임성보다 비공개 방어 접근을 우선한다. 이는 합리적인 출시 초기 입장이지만, 참여 관리자가 책임감 있게 대응한다는 전제에 크게 의존한다.

서비스의 성패를 좌우할 요소

Anthropic OSS Scanner가 유용한 보안 인프라가 될지, 아니면 또 다른 부담스러운 자동화 보고서 출처가 될지를 보여 줄 세 가지 신호가 있다.

첫 번째 신호는 새로 등록된 프로젝트의 경험이다. Anthropic의 파일럿 피드백은 강력한 기술 전문성과 성숙한 보안 프로세스를 갖춘 기존 팀에서 나왔다.

더 폭넓은 등록은 다양한 언어, 아키텍처, 유지보수 모델을 상대로 스캐너를 시험하게 된다. 결과는 초기 정확도가 선별된 집단을 넘어 이전되는지 보여 줄 것이다.

공개적으로 문서화된 수정 사항은 유용한 증거를 제공할 것이다. 커밋 참조, CVE 기록, 관리자 회고 자료는 어떤 보고서가 의미 있는 보안 개선으로 이어졌는지 보여 줄 수 있다.

귀속 표기는 선택 사항이지만, Anthropic은 프로젝트가 관련 커밋에 스캐너 보고서 식별자를 포함하도록 권장한다. 이러한 식별자는 어떤 발견 사항이 패치로 이어졌는지 회사가 측정하는 데 도움이 될 수 있다.

두 번째 신호는 시간에 따른 보고서 품질이다. Anthropic은 해결되지 않은 취약점을 노출하지 않으면서도 집계된 정밀도, 중복, 심각도, 완화 데이터를 결국 공개해야 한다.

가장 유익한 척도는 후보 발견 사항의 총수가 아니다. 관리자가 과도한 조사 없이 재현하고, 수용하고, 수정하는 비율이다.

오탐률이 하락하면 대규모 언어 모델이 중요한 유용성 임계점을 넘었다는 Anthropic의 주장은 더 강해질 것이다. 분류 비용이 상승하면 그 주장은 약화될 것이다.

세 번째 신호는 다른 보안 프로그램의 대응 방식이다. Google은 유효하지 않은 자동화 제출을 처리한 뒤 중단했던 오픈소스 보상 절차를 재검토할 계획이다.

Anthropic의 성공적인 배포는 버그 바운티와 공개 프로그램에서 사용하는 증거 기준에 영향을 줄 수 있다. 재현 절차와 테스트 가능한 패치는 모든 기계 생성 보고서에 요구되는 요소가 될 수 있다.

배포가 부실할 경우 더 엄격한 필터가 도입될 수 있다. 인정된 조직이 사람의 검증을 수행하지 않는 한 관리자는 자동화 발견 사항을 기본적으로 거부할 수 있다.

Anthropic은 공격자의 적응도 주시해야 한다. 방어적 발견 사항을 찾아내는 동일한 모델 역량이 악의적인 연구자가 널리 배포된 소프트웨어를 조사하는 데 도움이 될 수 있다.

회사는 고급 사이버 역량에 대해 접근 제어와 모니터링을 적용한다고 밝혔다. OSS Scanner는 격리된 환경에서 실행되고 발견 사항을 비공개로 전달함으로써 노출을 추가로 제한한다.

이러한 조치로 더 광범위한 경쟁을 없앨 수는 없다. 모델은 계속 개선될 것이며, 유사한 역량은 제공업체, 보안 기업, 로컬 시스템 전반으로 확산될 것이다.

따라서 완화 속도는 갈수록 중요해진다. 프로젝트가 공격자가 이를 악용하기 전에 취약점을 재현하고, 패치하고, 테스트하고, 수정 사항을 배포할 수 없다면 먼저 취약점을 발견하는 것만으로는 보호 효과가 거의 없다.

오픈소스 관리자는 이 서비스를 코드에 대한 판정이 아니라 추가적인 보안 입력으로 평가해야 한다. 자격을 갖춘 프로젝트는 등록 요건을 검토하고 충분한 분류 역량을 보유했는지 판단할 수 있다.

더 나은 질문은 AI 스캐너가 가끔 실수하는지 여부가 아니다. 모든 보안 기법에는 한계가 있다. 핵심은 Anthropic의 보고서가 소비하는 것보다 더 많은 엔지니어링 시간을 절약하는지다.

이제 Anthropic OSS Scanner는 그 균형을 공개적으로 입증해야 한다. 향후 수개월 동안의 관리자 결과는 모델이 찾아냈다고 주장하는 취약점의 양보다 더 중요할 것이다.