Anthropic OSS Scanner: 무료 AI 보안 보고서를 받는 유지관리자의 실무 안내

무료 신청형 OSS Scanner의 등록·빌드·보고서 수신 경로를 확인하고, 오픈소스 유지관리팀의 재현·패치 검토·중단·복구 절차를 정리합니다.

고친 내용: OSS Scanner의 공식 발표와 등록 절차, 사람 검토가 없는 보고서의 재현·패치 검수 및 중단·복구 안내를 새로 작성했습니다.

무료 보안 보고서를 받을 준비가 돼 있나요

오픈소스 유지관리자에게 보안 제보는 반가우면서도 부담스러운 소식입니다. 설명을 읽고 버전을 확인한 뒤 재현을 시도해야 합니다. 실제 결함이면 수정과 공개 일정까지 조율해야 하죠. AI가 제보를 늘려도 이 작업을 처리할 사람이 갑자기 늘어나지는 않습니다.

Anthropic은 2026년 10월 8일 OSS Scanner를 발표했습니다. 적격 오픈소스 프로젝트가 신청하면 Claude Mythos를 포함한 자사의 가장 강력한 모델로 주기적인 보안 검사를 무료로 받는 서비스입니다. 기반 시설과 사용자 보안에 중요한 영향을 주는 프로젝트를 개별 심사합니다. 모든 저장소가 신청 즉시 등록되는 구조는 아닙니다.

신청을 고민한다면 보고서를 받을 담당자와 검토 시간을 먼저 정해 보세요. 이 글에서는 공식 안내를 짚고 유지관리팀이 적용할 수 있는 접수·재현·수정 절차를 제안합니다. 아래 운영 예제는 편집부가 구성했으며 실제 등록이나 스캔 결과를 뜻하지 않습니다.

이 절의 근거 S138

빠른 제보와 검증된 제보를 구별하기

서비스 보고서는 모델이 만들며 사람의 사전 검토와 분류를 거치지 않습니다. 재현 자료와 가능한 경우 패치 후보가 동봉되지만 틀리거나 유효하지 않은 제보도 생깁니다. 기존의 사람 검증을 거친 조정 공개 절차와 이 빠른 수신 경로를 구별해야 합니다.

Anthropic은 초기 시험에서 48개 프로젝트의 중대·높음 등급 후보 97건을 전문가가 검토했으며 85건이 자사의 조정 공개 기준을 충족했다고 밝혔습니다. 이 표본은 모든 향후 보고서의 정확도를 보장하지 않습니다. 발표에 실린 PostgreSQL·OpenSSL·wolfSSL·HotCRP 담당자의 호평도 출시사가 수집한 초기 피드백입니다.

유지관리팀에서는 유효한 결함, 이미 알려진 결함, 같은 결함을 다시 설명한 제보, 재현 실패, 의도된 동작을 따로 기록하는 편이 좋습니다. 같은 보고서라도 결함 자체는 맞고 심각도만 과장될 수 있습니다. 정확도를 한 숫자로 줄이면 이 차이가 사라집니다.

이 절의 근거 S138

신청 경로와 파일 배치를 먼저 확인하기

적격 프로젝트의 핵심 유지관리자는 공식 GitHub 저장소에서 projects/<name>/를 추가하는 PR로 신청합니다. project.yaml과 Dockerfile이 필요하고 threat_model.md는 선택 사항입니다. 빌드 파일은 프로젝트 자체 저장소의 경로를 설정하거나 신청 디렉터리에 둘 수 있습니다.

다음은 파일 배치를 설명하는 가상 예제입니다. example.org는 예시 도메인이며 이대로 신청하지 않습니다. 코드, 의존성, 운영체제 요구를 아는 유지관리자가 빌드 구성을 검토한 뒤 공식 템플릿과 대조하세요. 설정 파일을 복사하는 일보다 대상 저장소와 담당자를 정확히 지정하는 일이 먼저입니다.

projects/demo-parser/
  project.yaml
  Dockerfile
  threat_model.md  # 선택 사항

# project.yaml의 가상 예제
repo: https://github.com/example/demo-parser
primary_contact: security@example.org
disabled: false

이 절의 근거 S138 · S139

공개 연락처와 암호화 수신을 정하기

project.yaml의 메일 주소는 공개됩니다. 개인 주소 대신 공개 가능한 보안 별칭을 고려하세요. OpenPGP를 설정하면 primary_contact로만 암호화 보고서를 받으며 auto_ccs와 함께 쓰지 못합니다.

팀 운영에서는 수신함을 보는 사람과 실제 판단하는 사람을 정해 두는 편이 좋습니다. 담당자가 휴가 중일 때 대신 읽을 사람도 필요합니다. 암호화 키를 쓰는 팀이라면 키 소유자 부재, 만료, 분실 때 보고서를 읽는 절차까지 마련하세요. 암호화 수신과 팀 내 전달 권한은 각각 확인할 항목입니다.

보고서 원문과 재현 자료를 공개 이슈로 그대로 옮기기 전에 공유 범위를 검토해야 합니다. 내부 추적표에는 접수 번호와 담당자, 상태를 적고 민감한 재현 자료는 접근을 제한한 곳에 둘 수 있습니다. 공개 연락처를 쓴다고 모든 제보 내용을 공개해도 된다는 뜻은 아닙니다.

이 절의 근거 S139

온라인 빌드와 오프라인 감사의 경계

초기 빌드는 네트워크가 연결된 격리 VM에서 진행되고 이후 감사는 인터넷 없이 수행됩니다. 의존성과 시험 자료는 빌드 단계에서 준비해야 합니다. 인터넷이 필요한 테스트는 이 경계에 맞춰 살펴보세요.

운영팀이 검토할 대상은 빌드 성공 여부뿐만이 아닙니다. 어떤 버전의 의존성을 가져오는지, 외부 다운로드가 바뀌어도 같은 결과가 나오는지, 개인용 토큰이나 운영 환경 설정을 요구하는지 확인합니다. 보안 검사에 필요한 환경을 만들면서 운영 비밀을 넣는 일은 피해야 합니다.

특히 생성한 이미지 안에 테스트용 자료가 있는지 확인하세요. 저장소 바깥 파일에 의존하는 테스트나 로컬 캐시 덕분에 통과한 빌드는 다른 환경에서 실패하기 쉽습니다. 네트워크 없이도 시험을 수행할 수 있는 상태를 준비하면 빌드 오류와 코드 결함을 구별하기 수월합니다.

이 절의 근거 S139

로컬 확인 도구를 실행하기 전에

공식 사전 확인 도구는 tools/validate.py와 tools/check <name>이며 VM 경로는 tools/check --qemu <name>입니다. git·Python 3·PyYAML과 Docker가 필요하고 QEMU 경로는 x86-64 Linux와 QEMU를 사용합니다. check는 네트워크가 있는 빌드를 실행하므로 신뢰할 수 있는 프로젝트와 환경에서만 사용하세요.

이 글의 명령은 사용 경로를 설명하기 위한 예이며 실행하지 않았습니다. 팀에서 직접 확인할 때는 운영 자격 증명이 없는 별도 환경을 마련하고 빌드가 접근할 네트워크를 검토하세요. VM을 사용해도 로컬 네트워크 접근 가능성을 별도로 살펴야 합니다.

검증 실패는 원인을 좁혀서 처리합니다. 서비스가 코드를 잘 분석하는지 평가하기 전에 환경부터 일치시켜야 합니다. 설정 오류는 필드와 경로를 확인하고 빌드 오류는 의존성과 컴파일 과정을 확인합니다. 이미지 안에서 테스트가 실패하면 같은 커밋을 기준으로 자료와 실행 조건을 비교합니다.

이 절의 근거 S139

위협 모델을 유지관리자의 언어로 쓰기

위협 모델에는 보호할 데이터, 신뢰하지 않는 입력, 권한 경계, 지원하는 배포 형태를 적어 보세요. 편집부의 가상 파서 프로젝트라면 외부 사용자가 올리는 파일을 처리하는 경로와 관리자가 직접 실행하는 진단 경로를 구별할 수 있습니다. 같은 오류라도 노출 조건이 다르면 대응 순서가 달라집니다.

심각도 기준에는 실제 조건을 적습니다. 인증 없이 외부 요청에서 도달하는 경로인지, 특정 플러그인을 켜야 나타나는지, 공격자가 이미 관리자 권한을 가져야 하는지 구별합니다. 개발자가 의도한 권한 경계를 문장으로 풀어 쓰면 제보를 검토할 때도 같은 기준을 사용할 수 있습니다.

범위를 너무 넓게 제외하지는 마세요. 테스트 도구라고 생각했던 코드가 배포 패키지에 포함되는지 확인할 필요가 있습니다. 반대로 지원하지 않는 구성에서만 일어나는 동작을 실제 운영 위험처럼 취급하면 검토 시간이 늘어납니다. 판단이 바뀐 항목에는 이유와 적용 버전을 남겨 다음 검토자가 이해하도록 합니다.

보고서를 받으면 주장부터 작은 단위로 나누기

메일을 받은 담당자는 바로 패치를 합치기보다 보고서가 주장하는 조건을 추립니다. 영향받는 버전과 코드 위치, 필요한 권한, 입력 경로, 예상 피해를 별도 항목으로 적으세요. 설명이 길어도 이 항목을 채우지 못하면 추가 확인이 필요합니다.

접수표의 상태는 미검토, 재현 중, 유효, 중복, 오탐, 수정 검토, 배포 대기로 구분할 수 있습니다. 중복 보고서에는 기존 항목을 연결해 같은 결함을 두 번 수정하지 않도록 합니다. 재현에 필요한 정보가 빠졌다면 재현 불가 사유를 적고 담당자에게 넘깁니다.

우선순위는 모델이 적은 등급에 팀의 노출 조건을 더해 정합니다. 인터넷에 노출된 기본 설정과 내부 전용 선택 기능을 같은 순서로 처리할 필요는 없습니다. 다만 영향이 작다고 결론 내릴 때도 코드 경로와 배포 조건을 기록하세요. 이 기록이 있어야 나중에 새로운 배포 형태가 생겼을 때 다시 판단할 수 있습니다.

재현 자료는 격리 환경에서 읽고 확인하기

재현 자료와 제안 패치는 검토할 입력입니다. 내용을 읽어 외부 주소 접속, 파일 삭제, 권한 변경, 자격 증명 접근이 있는지 먼저 살펴보세요. 운영 서비스나 실제 사용자 자료를 재현 실험에 쓰지 않습니다. 별도 환경에 필요한 최소 자료만 준비하는 편이 안전합니다.

가상 파서 프로젝트라면 보고서가 지목한 커밋을 고정하고 합성 입력을 준비합니다. 실행 명령과 환경, 관찰한 오류를 기록한 뒤 입력을 줄여 같은 실패가 남는지 확인합니다. 이것은 재현을 검토하는 일반적인 절차이며 구체적인 공격 코드를 제시하거나 실행한 사례는 아닙니다.

재현이 실패하면 곧바로 오탐으로 닫기보다 운영체제, 컴파일 옵션, 의존성, 분기와 권한 조건을 대조하세요. 조건을 맞춰도 주장한 피해가 나타나지 않을 때 그 근거를 남깁니다. 오류 발생과 실제 권한 침해 사이의 차이를 검토자가 설명해야 합니다. 반대로 재현 성공만으로 피해 규모까지 확정하지는 않습니다.

패치 후보를 회귀 테스트로 바꾸기

제안 패치를 적용하기 전에 무엇을 바꾸는지 읽습니다. 입력을 전부 거부하거나 권한 검사를 우회하는 수정은 오류를 없애도 정상 기능을 망칠 수 있습니다. 수정 전후에 같은 재현 입력을 비교하고 기존에 정상 처리하던 입력도 함께 시험하세요.

가상 파서의 회귀 테스트는 문제 입력을 거부하는 경우와 허용할 정상 파일을 처리하는 경우를 함께 다룰 수 있습니다. 테스트의 기대 결과에는 프로젝트 규약을 사용합니다. 모델이 제안한 예외 메시지나 동작을 검토 없이 새 규약으로 삼지 않습니다.

유지관리자는 지원 버전으로 수정이 필요한지 살펴야 합니다. 최신 분기만 고쳐도 배포 중인 이전 버전이 남아 있을 수 있습니다. 변경을 검토할 사람, 테스트 결과를 확인할 사람, 릴리스를 승인할 사람을 정하고 패치 후보가 검토와 시험을 모두 통과했는지 확인합니다. 발견과 배포를 서로 다른 완료 상태로 기록하면 진행 상황을 잘못 읽는 일을 줄일 수 있습니다.

공개 기한이 없다는 말의 의미

공식 README는 이 모델 생성 보고서에 90일 공개 기한을 두지 않고 서비스 측에서 공개하지 않는다고 설명합니다. 이 방침이 코드의 안전을 보장하거나 다른 발견자의 공개를 막아 주지는 않습니다.

유지관리팀은 자신의 보안 정책에 따라 수정과 공지 일정을 정해야 합니다. 영향받는 사용자에게 무엇을 알려야 하는지, 패치가 나오기 전에 완화책이 필요한지, 관련 프로젝트와 함께 조율할지 판단합니다. AI 보고서를 받았다는 사실만으로 공개 의무나 일정이 자동 해결되지는 않습니다.

릴리스 공지에는 확인된 영향 범위와 고친 버전, 사용자가 취할 조치를 적습니다. 검증하지 않은 추정 피해를 확정적으로 쓰지 말고 검토 중인 부분은 구별하세요. 공개 자료의 상세 수준을 정할 때도 실제 악용 위험과 사용자에게 필요한 정보를 함께 고려합니다.

이 절의 근거 S139

수신 중단과 빌드 실패를 운영 상태로 관리하기

설정의 disabled: true는 보고서 수신을 일시 중단하고 신청 디렉터리를 제거하면 등록을 철회합니다. 빌드 실패는 primary_contact로 통보됩니다. 변경은 공식 저장소의 PR 경로를 따릅니다.

보고서가 누적돼 검토를 감당하지 못하면 접수 속도와 처리 능력을 비교해 일시 중단을 결정할 수 있습니다. 중단해도 이미 받은 결함의 수정 책임은 남습니다. 누적 항목을 담당자에게 배정하고 다시 받을 조건을 정해 놓으세요. 담당자 확보나 빌드 복구, 중대 항목 처리 완료 같은 조건을 팀이 선택할 수 있습니다.

빌드 실패를 수정할 때는 마지막 성공 커밋과 실패 커밋을 비교합니다. 실패 원인이 저장소 변경인지 외부 의존성인지 확인하고 담당자가 검토한 빌드 설정으로 복구하세요. 복구 기록에는 실패 기간과 검사하지 못한 범위를 적습니다. 정상 수신으로 돌아왔다는 사실을 누락 기간까지 검사됐다는 의미로 확대하면 안 됩니다.

이 절의 근거 S139

퍼징·정적 분석과 함께 놓고 판단하기

Google의 OSS-Fuzz는 퍼징과 분산 실행을 결합해 오픈소스 오류를 찾는 서비스입니다. GitHub의 code scanning은 CodeQL 또는 다른 분석 도구를 연결하고 저장소 경고를 검토하는 경로를 지원합니다. OSS Scanner는 모델이 제안한 발견 내용을 메일로 받는 경로입니다. 세 접근법은 결과를 내는 방식과 유지관리자가 확인할 자료가 다릅니다.

편집부가 제안하는 비교 기준은 실제로 고친 결함, 검토에 쓴 시간, 중복, 놓친 범위입니다. 퍼징의 실행 입력과 크래시, 정적 분석의 코드 경로, 모델 보고서의 주장과 재현 자료를 같은 접수표에 연결하면 이미 알고 있던 문제를 구별하기 좋습니다. 도구마다 다른 환경에서 나온 탐지 건수를 곧바로 우열로 읽지는 마세요.

검사 대상과 설정이 달라지면 발견 범위도 달라집니다. 서비스가 아무 보고서도 보내지 않았거나 테스트가 모두 통과했다는 사실만으로 안전 인증을 받은 것은 아닙니다. 권한 검토와 의존성 관리, 변경 리뷰를 함께 수행하면서 각 도구가 확인한 범위를 기록하세요.

이 절의 근거 S145 · S146

성과를 발견 수보다 처리 결과로 측정하기

무료 서비스에도 유지관리자의 시간은 듭니다. 편집부의 권장 기록은 보고서별 접수 시각, 첫 검토까지 걸린 시간, 재현 시간, 수정 시간, 배포 시각입니다. 검토를 중단한 제보에도 사유를 남겨야 전체 부담을 계산할 수 있습니다.

유효 보고서 비율을 계산할 때는 분모를 명시하세요. 접수 전체인지 검토가 끝난 보고서인지에 따라 숫자가 달라집니다. 중복과 심각도 조정은 별도 열로 두고 아직 검토하지 않은 항목을 오탐으로 계산하지 않습니다. 처리량이 늘어도 미검토 항목이 더 빠르게 쌓이면 팀의 부담은 커집니다.

다음 주에도 받을지 결정할 때는 중대 결함을 실제 배포에서 줄였는지와 정상 기능의 회귀가 생겼는지를 함께 보세요. 도구가 만든 패치를 그대로 채택한 비율보다 검토를 거쳐 안전하게 반영한 결과가 유용합니다. 팀이 작은 범위에서 시작하고 기록을 보고 확대하면 무료 검사와 사람의 처리 능력을 맞출 수 있습니다.