Claude Security 사용법: GitHub 보안 결과를 패치 전에 검수하는 법
TL;DR
Claude Security는 코드베이스를 스캔해 취약점 Finding과 권고 수정을 제시합니다. 이 결과를 확정 판정으로 받아들이면 안 됩니다. 한 저장소의 승인된 디렉터리나 브랜치만 먼저 스캔합니다. 이후 Finding의 위치·영향·재현 단계·권고 수정을 원본 코드와 대조하고 사람의 승인을 받습니다.
공식 문서에 따르면 이 기능은 Claude Enterprise 대상 public beta입니다. Claude Code on the Web, Extra Usage, 대상 저장소에 접근하는 Anthropic Claude GitHub App, 스캔 사용자의 premium seat가 필요합니다. No ZDR이며 스캔 결과는 확률적으로 달라질 수 있습니다.
핵심 3줄 요약
핵심 1
Claude Security는 GitHub 저장소의 취약점을 찾고 사람이 검토할 패치를 제안하는 기능입니다.
핵심 2
Finding의 severity만 보고 수정하지 말고 Location·Impact·Reproduction steps·Recommended fix를 원본 코드와 대조합니다.
핵심 3
완료 지점은 자동 패치가 아니라 확인 완료·오탐·확인 필요 중 하나로 남긴 내부 검수 기록입니다.
이 글에서 다룰 내용
Claude Security의 제공 조건과 데이터 경계, 파일럿 저장소를 좁히는 방법, 첫 스캔 실행 순서, Finding 근거를 대조하는 검수표, 패치 전에 사용하는 프롬프트, 사람의 승인과 중단선을 다룹니다.
Claude Security는 무엇이고 언제 쓰면 좋은가
한 문장 정의: Claude Security는 코드베이스에서 보안 취약점을 스캔해 사람이 검토할 targeted patch를 제안하는 Claude 내장 기능입니다.
새 기능이나 큰 변경을 배포하기 전에 저장소의 한 모듈을 점검할 때 유용합니다. 기존 보안 도구가 놓친 논리 수준의 문제를 추가로 살필 때도 맞습니다. Claude Security는 코드 문맥을 보고 Finding을 만들지만 기존 정적 분석, 수동 코드 리뷰, 테스트를 대체하지 않습니다.
공식 도움말은 스캔이 확률적으로 동작한다고 설명합니다. 같은 저장소를 다시 스캔해도 결과가 완전히 같다고 보장할 수 없습니다. Finding은 검토할 후보이며 코드가 안전하다는 증명도, 패치 적용 승인도 아닙니다.
시작 전에 확인할 제공 조건과 데이터 경계
Claude Security는 현재 Claude Enterprise 사용자 대상 public beta입니다. 조직 Owner가 Organization settings > Claude Security에서 Turn on for your organization을 켭니다.
공식 도움말에 따르면 스캔은 Claude Mythos 5에서 실행되지만 사용자가 이 모델에 직접 접근하는 방식은 아닙니다. Suggested patch는 Claude Code on the Web에서 열리며 계정에 제공된 모델을 사용합니다. 스캔 모델 접근과 패치 세션의 모델 접근을 같은 권한으로 묶지 않습니다.
실제 스캔 전에는 다음 조건을 각각 확인합니다.
- Claude Code on the Web이 조직에서 활성화돼 있는가
- Organization Billing settings에서 Extra Usage가 활성화돼 있는가
- Anthropic Claude GitHub App이 대상 저장소에만 접근하는가
- 스캔 담당자에게 premium seat가 있는가
- 코드 소유권과 스캔 권리가 조직에 있는가
현재 공식 도움말은 GitHub.com과 GitHub Enterprise Server 저장소만 지원한다고 안내합니다. 다른 호스팅 서비스까지 지원한다고 넓혀 말하면 안 됩니다. GitHub Enterprise Server를 쓰면 해당 인스턴스가 Claude Code on the Web에 연결돼 있어야 합니다.
No ZDR는 따로 확인해야 할 경계입니다. Anthropic은 법률 준수 또는 Usage Policy 위반 대응에 필요한 경우 데이터를 보존할 수 있다고 명시합니다. 비밀키, 고객정보, 운영 토큰이 들어 있는 저장소는 파일럿에서 제외합니다. 조직 정책과 현재 계약 조건도 먼저 확인합니다.
첫 스캔 범위를 정하는 검수 카드
처음부터 전체 monorepo를 넣지 않습니다. 공식 튜토리얼은 큰 저장소라면 디렉터리로 범위를 좁히는 방법을 권장합니다. 아래 항목은 제품이 자동으로 만드는 기록이 아니라 안전한 파일럿을 위한 내부 검수 규칙입니다.
- 저장소: 조직이 소유하고 스캔 권리가 확인된 비민감 파일럿 저장소
- 범위: 승인된 branch 또는 directory 한 곳
- 제외: 비밀값, 고객 데이터, 제3자 소유 코드, 라이선스상 스캔 권리가 없는 코드
- 검수자: 코드 소유자와 보안 검수자
- 비용 경계: Extra Usage와 Claude Security 별도 spend limit
- 완료 기준: Finding 한 건의 근거 대조와 검수 상태 기록
- 중단선: 권리·데이터 분류·재현 환경이 불분명하면 스캔 또는 패치를 중단
첫 시험에서는 운영 저장소 전체보다 작은 승인 범위를 고릅니다. 스캔 성공 여부, 결과 품질, 비용, 데이터 처리 경계를 한 번에 확인하기 쉽기 때문입니다.
Claude Security 첫 스캔 실행 순서
1. 관리자와 사용자의 준비 상태를 따로 확인합니다
Owner는 조직 설정에서 Claude Security가 켜졌는지 확인합니다. 스캔 담당자는 Claude Code on the Web 사용 권한, premium seat, Extra Usage, GitHub 연결 계정을 확인합니다.
보안 페이지가 Install GitHub App으로 계속 돌아가면 사용자 연결부터 확인합니다. 조직 설치가 성공했다고 사용자 연결까지 정상인 것은 아닙니다. 공식 도움말은 연결한 GitHub 계정의 조직 멤버십, SSO 승인, GitHub 조직 IP allow list를 별도 원인으로 안내합니다.
2. claude.ai/security에서 승인된 저장소를 고릅니다
Claude 왼쪽 사이드바의 Security 또는 claude.ai/security를 엽니다. 목록에서 승인된 GitHub 저장소를 선택합니다. 큰 저장소라면 처음 합의한 branch 또는 directory로 범위를 줄입니다.
저장소가 목록에 없으면 임의로 GitHub App 범위를 넓히지 않습니다. 관리자와 코드 소유자가 설치 대상과 접근 범위를 다시 확인한 뒤 별도 승인을 받습니다.
3. 첫 스캔을 실행하고 범위를 기록합니다
내부 검수 카드에는 스캔 시작 시각, 저장소, branch, directory, 담당자를 적습니다. 스캔 시간은 저장소와 에이전트 동작에 따라 달라질 수 있으므로 고정 완료 시간을 약속하지 않습니다.
공식 튜토리얼은 첫 스캔이나 큰 변경 후에 Standard와 Extended 중 scan effort를 고를 수 있다고 안내합니다. 어느 쪽이든 한 번의 결과를 완전한 탐지로 해석하지 않습니다.
4. Finding의 필드를 원본 코드와 대조합니다
스캔이 끝나면 Finding 하나를 엽니다. 공식 도움말이 설명하는 필드는 Title, Details, Location, Impact, Reproduction steps, Recommended fix, Severity, Status, Category, Repository, Branch, Date created입니다.
먼저 Repository·Branch·Location이 처음 승인한 범위와 맞는지 확인합니다. Details와 Impact는 원본 코드의 실제 데이터 흐름과 비교합니다. Reproduction steps는 격리된 비운영 환경에서만 재현합니다. 성공 여부와 관찰값은 따로 기록합니다.
5. 패치 전에 검수 상태를 결정합니다
내부 검수 상태는 확인 완료, 오탐, 확인 필요 세 가지로 기록합니다. 제품의 Open·Dismissed·Resolved 상태와는 다른 내부 규칙입니다.
- 확인 완료: 위치, 공격 조건, 영향과 재현 결과가 원본 코드에서 확인됨
- 오탐: 실제 코드 경로나 적용 조건이 맞지 않으며 그 근거를 기록함
- 확인 필요: 재현 실패, 소유자 판단 필요, 환경 차이처럼 근거가 부족함
오탐으로 판단하더라도 바로 Dismiss를 누르지 않습니다. 공식 기능은 dismissal reason과 선택적 note를 남길 수 있습니다. dismissed Finding은 이후 스캔에서 다시 나타나지 않습니다. 담당자와 검수자가 근거를 확인한 뒤 상태를 바꿉니다.
6. 승인된 Finding만 remediation으로 넘깁니다
공식 튜토리얼의 remediation 버튼은 해당 취약점에 초점을 맞춘 Claude Code on the Web 세션을 엽니다. 여기서 potential patch를 만들 수 있지만 자동 승인이나 자동 병합으로 보지 않습니다.
코드 소유자나 보안 검수자가 Finding 근거와 변경 범위를 승인한 뒤 remediation을 엽니다. 만들어진 diff와 테스트 결과는 사람이 검토합니다. 저장소의 기존 리뷰·병합 절차도 그대로 따릅니다. 이 글에서는 검수 기록 승인까지 마칩니다. 패치 생성과 병합은 다음 승인 단계입니다.
Finding 검수표를 작성하는 방법
Finding마다 다음 항목을 한 행으로 남깁니다.
- Finding 제목과 Category
- Repository·Branch·Location
- 원본 코드에서 확인한 입력과 위험 지점
- Impact와 실제 노출 조건
- Reproduction steps 실행 환경과 결과
- Recommended fix와 허용 변경 범위
- 내부 검수 상태: 확인 완료·오탐·확인 필요
- 검수자, 승인자, 검토 날짜
Severity는 High·Medium·Low로 표시되며 같은 Category라도 실제 코드의 악용 가능성에 따라 달라질 수 있습니다. 공식 도움말은 현재 severity를 사용자가 설정할 수 없다고 안내합니다. 심각도를 임의로 바꿨다고 쓰지 않습니다. 제품 severity와 내부 우선순위는 별도 필드로 보관합니다.
복사해서 쓰는 Finding 검수 프롬프트
아래 프롬프트는 Finding을 다시 쓰게 하는 요청이 아닙니다. 제공한 근거만 검수표로 정리합니다. 근거가 부족한 항목은 확인 필요로 남깁니다.
목표: Claude Security Finding 한 건을 패치 전에 내부 검수표로 정리합니다.
허용 입력: 승인된 Finding의 Title, Details, Location, Impact, Reproduction steps, Recommended fix, Severity, Status, Category, Repository, Branch, Date created와 사람이 제공한 원본 코드 발췌·재현 결과만 사용합니다.
제외 입력: 비밀키, 고객정보, 운영 토큰, 승인되지 않은 저장소·브랜치·파일, 제3자 소유 코드, 추측한 공격 경로는 사용하지 않습니다.
출력 형식: Finding 식별 정보 | 원본 코드 대조 | 재현 결과 | 영향·조건 | 권고 수정 검토 | 내부 상태 | 확인 필요 | 승인 지점 순서의 검수표로 작성합니다.
완료 기준: 모든 판단에 제공된 코드 위치나 재현 근거를 연결하고, 근거가 없는 항목은 확인 필요로 표시합니다.
무발명 조건: 입력에 없는 코드, 데이터 흐름, severity, 재현 성공, 패치 효과를 만들지 않습니다.
승인 지점: 사람 검수자가 확인 완료·오탐·확인 필요를 결정한 뒤에만 Dismiss 또는 remediation 여부를 정합니다.
실전 인사이트: Severity와 내부 우선순위를 분리합니다
제품 Severity는 Finding의 악용 가능성을 코드 문맥에서 분류한 값입니다. 내부 우선순위는 서비스 노출, 자산 중요도, 운영 일정과 기존 통제를 함께 보는 조직 판단입니다. 둘을 한 필드에 섞으면 제품 결과와 내부 결정의 경계가 사라집니다.
제품 Severity는 원문 그대로 보존합니다. 내부 우선순위와 승인 사유를 옆 필드에 따로 적습니다. 같은 Finding을 다시 검토할 때도 무엇이 제품 판단이고 무엇이 사람의 운영 판단인지 구분할 수 있습니다.
신뢰하기 전에 확인할 체크리스트
- 스캔한 저장소와 branch·directory가 승인 범위와 일치하는가
- 조직이 해당 코드를 소유하고 필요한 스캔 권리를 갖는가
- Finding의 Location이 원본 코드와 일치하는가
- Impact와 Reproduction steps가 실제 환경 조건을 반영하는가
- Recommended fix가 증거 없이 효과를 보장하지 않는가
- 오탐과 확인 필요를 구분해 기록했는가
- Dismiss와 remediation 전에 사람의 승인을 받았는가
- 패치 diff와 테스트를 저장소의 기존 검토 절차로 확인할 계획이 있는가
이 체크리스트를 통과해도 저장소 전체가 안전하다고 단정할 수 없습니다. 스캔은 기존 보안 도구와 수동 리뷰를 보강하는 증거 중 하나입니다.
주의할 점
Claude Security 결과는 완전한 취약점 탐지 보장이 아닙니다. 공식 문서는 스캔이 확률적으로 동작한다고 설명합니다. 결과가 없다는 사실만으로 안전을 확정하거나, Finding이 있다는 이유만으로 취약점을 확정하지 않습니다.
No ZDR 경계를 빠뜨리지 않습니다. 조직이 소유한 코드라도 데이터 분류와 계약 조건에 따라 외부 처리에 적합하지 않을 수 있습니다. 비밀값과 불필요한 민감정보를 제거하고 승인된 범위만 사용합니다.
지원 범위를 임의로 넓히지 않습니다. 현재 공식 도움말은 GitHub.com과 GitHub Enterprise Server를 지원합니다. 다른 호스팅 서비스는 지원하지 않는다고 안내합니다. severity 구성도 현재 지원되지 않습니다.
제품 상태와 내부 검수 상태를 섞지 않습니다. Open·Dismissed·Resolved는 제품 필드입니다. 확인 완료·오탐·확인 필요는 이 글에서 제안하는 내부 검수 규칙입니다. Dismissed Finding은 미래 스캔에서 다시 나타나지 않으므로 근거와 승인 없이 상태를 바꾸지 않습니다.
자주 묻는 질문
Claude Security는 모든 Claude 사용자에게 제공되나요?
아닙니다. 현재 공식 도움말은 Claude Enterprise 사용자 대상 public beta로 안내합니다. 스캔 담당자에게 premium seat가 필요합니다. Claude Code on the Web·Extra Usage·GitHub App 접근 조건도 확인해야 합니다.
GitHub가 아닌 저장소도 스캔할 수 있나요?
현재 공식 도움말은 GitHub.com과 GitHub Enterprise Server를 지원하며 다른 호스팅 서비스는 지원하지 않는다고 설명합니다. 계정 화면과 최신 도움말에서 현재 범위를 다시 확인합니다.
High Severity Finding은 바로 수정해야 하나요?
Severity만으로 자동 승인하지 않습니다. Repository·Branch·Location·Impact·Reproduction steps를 원본 코드와 대조하고 사람이 검수 상태와 내부 우선순위를 결정합니다.
Finding을 Dismiss하면 다음 스캔에 다시 나오나요?
공식 튜토리얼은 dismissed Finding이 이후 스캔에 다시 나타나지 않는다고 안내합니다. 오탐 근거와 dismissal reason을 확인하고 승인받은 뒤 Dismiss합니다.
출처
마무리
Claude Security를 처음 쓸 때는 전체 저장소 자동 수정부터 시작하지 않습니다. 조직이 소유한 코드에서 승인 범위를 좁혀 스캔합니다. Finding 한 건의 위치·영향·재현 단계·권고 수정을 원본 코드와 대조하는 데서 시작합니다.
검수 상태와 사람의 승인 지점을 분리하면 Finding을 무조건 믿거나 무조건 버리는 일을 줄일 수 있습니다. 패치는 검수 기록이 승인된 뒤 별도 remediation과 저장소의 기존 리뷰 절차로 넘깁니다.
