OSS Scanner 신청 전 점검: 오프라인 빌드와 사람 검토 경계

오픈소스 유지관리자에게 취약점 보고가 많아지는 것은 발견 능력의 향상이면서 동시에 처리 대기열의 증가다. 재현 여부를 확인하고, 영향 범위를 정하고, 중복을 걷어낸 뒤 패치를 검토할 사람이 없다면 탐지 도구가 늘어도 수정은 빨라지지 않는다. Anthropic이 2026년 10월 8일 발표한 OSS Scanner를 검토할 때도 첫 질문은 정확도 순위보다 “우리 팀이 사람이 검토하지 않은 보고를 받아 처리할 수 있는가?”여야 한다.

이 글은 10월 9일 수집·확인한 공식 발표와 연구 글, 등록 FAQ의 보존 원문을 바탕으로 신청 판단표와 준비 절차를 정리한다. 10월 10일은 이 글의 공개 예정일이지 서비스 발표일이 아니다. OSS Scanner는 등록된 오픈소스 프로젝트에 무료로 주기적 검사를 제공하는 선택 가입 서비스다. 모든 저장소가 자동 승인되거나 고정된 주기로 검사를 받는다는 의미는 아니다.

1. 무료 검사보다 먼저 확인할 보고 처리 역량

기존 CVD는 사람이 검토한 취약점 보고를 유지관리자에게 전달하는 경로다. OSS Scanner는 그 수동 검토를 기다리지 않고 모델이 생성한 보고를 직접 받는 선택 경로다. 보고를 빨리 받는 대신 재현, 심각도 판단, 중복 분류의 부담이 유지관리자에게 더 직접적으로 넘어온다. 모델 내부의 재확인 절차가 있다고 해도 사람이 검증한 보고로 바뀌지는 않는다.

공식 FAQ는 기반 시설과 사용자 보안에 중요한 영향을 주는 기존 프로젝트를 대상으로, 원격 공격 노출과 의존 프로젝트 규모 등을 고려해 개별 심사한다고 설명한다. 핵심 유지관리자 여부도 수동 확인한다. 등록 PR을 만들었다는 사실은 승인이나 검사 완료의 증거가 아니다.

아래는 공식 자격 조건과 보고 경계를 실제 신청 판단으로 옮긴 편집 판단표다. 승인 기준을 새로 정의하거나 Anthropic의 결정을 대신하는 표는 아니다.

현재 팀의 상태	우선 판단	신청 전에 남길 자료
검증된 고위험 보고도 처리 대기 중	미검토 보고 수신은 보류하고 현재 분류 병목부터 확인	담당자, 밀린 보고의 재현·수정 상태
재현 담당자는 있지만 오프라인 환경이 없음	빌드 환경 준비를 먼저 진행	의존성이 설치된 Dockerfile과 빌드 확인 기록
보고 담당자와 재현 환경은 있으나 범위가 모호함	위협 모델과 심각도 기준을 먼저 합의	신뢰하지 않는 입력, 제외 범위, 중복 기준
보고 분류·패치 검토와 환경이 준비됨	자격 조건을 확인한 뒤 등록 PR 준비	project.yaml, 연락처, 환경 경로와 선택 위협 모델

검증된 고위험 보고 처리도 밀려 있다면, 무료라는 이유만으로 미검토 보고 경로를 추가하지 않는 편이 낫다. Anthropic은 처리 여력이 없는 프로젝트에 기존 CVD를 통한 사람이 검증한 공개 절차를 계속 제공한다고 설명한다. “가입하지 않으면 보안 지원이 모두 중단된다”는 식으로 읽을 필요는 없다.

처리 역량을 먼저 확인하는 편집 판단 흐름. 신청 PR은 승인이나 검사 완료가 아니며, 공식 자격 심사를 대신하지 않는다. 출처: red.anthropic.com/oss-scanner.

2. 등록 파일보다 까다로운 오프라인 감사 환경

핵심 유지관리자는 공식 저장소에 projects/<project>/project.yaml을 추가하는 PR로 신청한다. FAQ의 필수 정보는 복제할 저장소인 repo, 주 연락처인 primary_contact, 환경을 준비하는 Dockerfile 경로다. Dockerfile을 등록 저장소의 project.yaml 옆에 두는 방식에서는 해당 필드를 생략하는 예외가 있다. 경로 필드와 파일 위치를 동시에 어긋나게 작성하지 않는 것이 중요하다.

Dockerfile은 의존성을 미리 설치하고 프로젝트를 빌드해 오프라인 에이전트가 감사할 수 있게 해야 한다. 핵심 경계는 “모든 과정에서 인터넷 금지”가 아니다. Dockerfile을 빌드하는 단계에는 네트워크 접근이 있고, 그 이후 감사는 인터넷 없이 실행된다. 따라서 테스트 시작 뒤 패키지나 테스트 데이터를 추가로 내려받는 환경은 빌드 성공과 별개로 감사 준비가 끝나지 않았을 수 있다.

공식 FAQ는 로컬에서 Dockerfile이 빌드되는지 확인하고, 만들어진 컨테이너 안에서 테스트가 통과하는지 확인할 것을 권장한다. 신청 전 설정은 공식 저장소의 tools/validate.py로 검사할 수 있다. 여기서는 그 도구나 컨테이너를 실행하지 않았으므로 특정 프로젝트의 준비 완료를 주장하지 않는다. 아래 그림은 제공자의 환경 경계를 설명하는 도식이며 실행 로그가 아니다.

네트워크는 Dockerfile 빌드에 허용되고 이후 감사에는 없다. 의존성과 필요한 자원의 사전 준비를 설명하며, 컨테이너를 실제 실행한 증거가 아니다. 출처: red.anthropic.com/oss-scanner.

편집상 권장하는 기록은 단순한 “빌드 성공” 한 줄이 아니다. 검사할 브랜치와 커밋, 컨테이너 생성에 필요한 파일, 컨테이너 내부에서 테스트에 필요한 자원이 이미 들어 있는지, 네트워크가 없는 이후 단계에서 무엇이 실패하는지를 함께 남기면 담당자가 환경 실패와 보고의 재현 실패를 구별하기 쉽다. 이것은 검증 효율을 높이기 위한 제안이지 서비스의 숨겨진 필수 등록 필드를 추가한 것이 아니다.

3. 위협 모델에는 무엇을 적어야 할까

threat_model은 선택 항목이며 정해진 필수 서식은 없다. FAQ는 검사할 코드, 공격자 입력으로 취급할 값, 무시할 범위, 심각도 분류 기준, 보고와 후보 패치의 형식, 중복 판정의 세밀함을 적을 수 있다고 설명한다. 생략해도 스캐너는 동작하지만 모호한 경우의 처리 방식은 추정하게 된다.

예를 들어 외부 입력을 읽는 파서와 내부 전용 변환 도구가 한 저장소에 있다고 가정하자. 이때 “외부 입력을 받는 파서를 우선 확인하고 내부 운영자의 수동 작업은 별도로 평가한다”는 범위 설명은 보고의 맥락을 좁힌다. 이 예시는 가상 프로젝트를 위한 문서 작성 제안이며 실제 취약점 발견 사례가 아니다. 내부 도구라도 실제 공격 경로가 있다면 무조건 안전하다고 제외해서는 안 된다.

심각도도 “충돌이 발생했다”에서 멈추지 말고, 누가 어떤 입력을 전달할 수 있으며 어떤 권한이나 정보에 영향을 미치는지 연결해야 한다. 중복 기준은 동일 원인·동일 수정으로 묶을지, 서로 다른 공격 경로는 별도 보고로 받을지 합의해 두는 편이 좋다. 후보 패치가 최소 재현용인지 병합 검토용인지도 명시할 수 있다. 원문에 없는 만능 위협 모델 템플릿을 서비스 공식 설정처럼 제시하는 것은 피해야 한다.

FAQ가 제안하는 선택 위협 모델의 작성 영역. 정해진 필수 서식은 없으며 중복 기준의 구체화는 편집 설명이지 공식 강제 설정이 아니다. 출처: red.anthropic.com/oss-scanner.

연락 방식도 운영 결정이다. FAQ는 추가 수신자를 auto_ccs로 지정할 수 있고 pgp 공개키를 통해 보고 메일 암호화를 선택할 수 있다고 설명한다. 다만 GPG 키를 포함하면 추가 CC를 함께 사용할 수 없고 주 연락처로만 메일이 간다. 담당자가 부재할 때 누가 접근하는지 먼저 정하되, 공개 등록 파일에 비밀키나 실제 취약점 내용을 넣는 식으로 혼동하지 말자.

4. 보고를 받으면 후보 패치부터 병합하지 않는다

연구 글에 따르면 보고에는 독립적으로 재현할 수 있는 재현 자료와 취약점 설명이 포함된다. 도입 시점을 찾는 이분 탐색은 가능한 경우에, 후보 패치는 제공 가능한 경우에 붙는다. 모든 보고에 곧바로 병합 가능한 수정이 붙는다고 보장하지 않는다.

이 글이 제안하는 처리 순서는 수신 기록, 격리된 환경에서의 재현, 위협 모델에 따른 영향·심각도 평가, 중복 판정, 후보 패치 검토와 회귀 테스트다. 공식 서비스가 강제하는 처리 상태명이 아니라 유지관리자의 작업 순서를 명확히 하기 위한 편집안이다. 재현 실패 때도 즉시 오탐으로 닫기보다 버전과 환경 차이를 기록하면 다시 확인할 수 있다. 실행 가능한 재현 자료는 위험할 수 있으므로 운영 환경에 그대로 실행하는 절차를 권하지 않는다.

특히 “미검토 보고 수신일”과 “사람이 검증했다고 통지받은 날”을 별도 필드로 보관할 이유가 있다. 현재 FAQ는 미검증 OSS Scanner 결과에 자동으로 90일의 조정 공개 기간을 두지 않는다고 설명한다. 이후 기존 CVD에서 사람이 검증하면, 사람이 검증했다는 통지를 받은 날부터 90일의 CVD 정책이 적용될 수 있다. 최초 자동 메일을 받은 날부터 무조건 카운트다운이 시작된다고 쓰면 다른 경로를 섞는 셈이다.

미검증 보고와 사람 검증 통지는 별도 시점이다. 이후 수동 검증 시 통지일부터 90일 CVD 정책이 적용될 수 있으며, 향후 정책 변경 가능성도 남아 있다. 출처: red.anthropic.com/oss-scanner.

미검증 결과는 영구 비공개라는 보장도 아니다. FAQ는 향후 일부 고위험 보고에 공개 기간을 도입할 수 있고, 변경 시 충분한 고지와 탈퇴 선택권을 제공한다고 설명한다. 신청 시점의 약관과 정책을 다시 읽어야 한다. 수신을 중단할 필요가 생기면 disabled: true를 추가하는 PR로 일시 중지하거나 프로젝트 디렉터리를 삭제하는 PR로 탈퇴할 수 있다. 이때 기존 CVD 보고 경로로 돌아간다는 설명도 함께 확인하자.

5. 숫자는 신청 결정을 대신하지 못한다

Cyber Mission 발표의 “참양성 비율 90% 초과를 기대한다”는 문구는 제공자의 기대다. 독립적으로 확립된 전체 서비스 정확도, 모든 취약점을 찾아내는 재현율, 개별 프로젝트의 성능 보장이 아니다. “90% 이상 안전해졌다”로 바꿀 수 없다.

연구 글이 제시한 초기 검증 표본도 분모가 다르다. 제공자가 선택한 48개 프로젝트의 높은·치명적 심각도 후보 97건 중 85건이 자체 CVD 기준을 충족했고, 원문은 이를 반올림해 88%로 설명한다. 나머지 12건 중 11건은 실제 문제지만 알려진 문제 또는 같은 검사 결과와 중복되었고, 1건은 무효였다. CVD 기준 통과와 참양성 판정은 같은 지표가 아니다. 이 초기 표본을 모든 프로젝트에 적용하는 독립 무작위 평가로 취급해서도 안 된다.

또 연구 글의 29,000건 초과는 후보 취약점 수이고 약 6,000건은 사람이 검토·분류한 규모다. 후보 수를 확정된 결함 수로 바꾸는 제목은 피해야 한다. 이번 신청 판단에서 유용한 사실은 거대한 발견 수보다 사람이 검토하는 역량이 병목이라는 점과 미검토 경로를 선택하면 자신의 처리 대기열이 달라진다는 점이다.

따라서 등록을 결정하기 전에 표의 어느 행에 해당하는지 먼저 정하고, 오프라인 환경과 범위 문서를 담당자에게 전달할 수 있는 형태로 만든다. 승인 후에도 보고의 타당성과 패치 품질은 별도로 확인한다. 무료 서비스와 자동 탐지라는 이유가 사람의 병합 결정을 없애지는 않는다.

6. 근거와 적용 범위

이 판단표와 처리 순서는 공식 문서에 근거한 편집 제안이며, 실제 등록·컨테이너 빌드·보안 감사나 독립 성능 검증을 수행한 결과가 아니다. AI를 활용해 공개 자료를 해설하고 그림을 작성했으며, 공식 제품 화면이나 실제 취약점 보고를 재현한 이미지는 사용하지 않았다. 자격 심사, 검사 주기와 정책은 제공자의 조건이며 모든 프로젝트에 동일하게 보장되지 않는다.

이번 글은 일반적인 보안 스캐너 정확도 비교가 아니라 무료 선택 가입 서비스의 환경 준비와 보고 처리 경계를 다룬다. 숫자의 분모를 더 확인하고 싶다면 기존 DeepsecBench 해설의 정밀도와 재현율 구분을 함께 읽을 수 있다. 서로 다른 평가의 점수를 직접 비교하라는 뜻은 아니다. 신청 준비에 직접 관련된 내부 글은 확인되지 않아 내부 링크는 이 한 편만 연결하고, 실제 등록 판단에 필요한 공식 근거를 아래에 모았다.

• Anthropic Cyber Mission 발표: 무료 선택 가입과 사람이 검토하지 않은 보고, 기대 참양성 비율의 맥락.
• OSS Scanner 연구·출시 글: 보고의 구성과 초기 검증 표본의 분모.
• OSS Scanner 공식 FAQ: 신청 자격, 파일 필드, 오프라인 환경, 위협 모델, 공개 정책과 중단 방법.