Claude Security의 연속 스캔: '고침' 표시와 실제 배포 사이의 간격

보안 스캐너는 보통 한 시점의 보고서를 남깁니다. 스캔을 돌리고, 결과를 검토하고, 티켓을 만들고, 다음 분기에 다시 스캔합니다. 그 사이 코드는 계속 바뀝니다. Claude Security의 2026년 10월 21일 업데이트는 이 간격을 줄이겠다고 말합니다. 저장소 변경을 따라가고, finding이 실제로 고쳐졌는지 추적하고, 팀이 제공한 환경 지식을 스캔에 반영합니다.

이 변화의 핵심은 탐지율이 아닙니다. finding의 생명주기를 관리하는 일입니다. 그리고 그 생명주기에서 가장 위험한 단어는 “fixed”입니다. 코드가 바뀐 것과 취약한 버전이 실제로 배포된 것은 다릅니다.

이번에 추가된 것

Claude Security는 2026년 4월 public beta로 시작했습니다. 이번 업데이트도 Claude Enterprise 고객을 위한 public beta입니다. 일반 제공이 아니며, 관리자가 Claude console에서 활성화해야 합니다. Anthropic은 Claude Security가 Mythos를 포함한 전체 모델 패밀리로 구동되며 Cyber Verification Program 접근 권한이 필요 없다고 설명합니다.

영역	이전	이번 업데이트
스캔	수동 또는 예약된 시점	저장소 변경을 따라가는 연속 스캔
finding	스캔 결과	수정 여부를 추적하고 재발 시 reopen
맥락	코드 중심	프로젝트 knowledge base와 편집 가능한 threat model
심각도	일반 기준	프로젝트 threat model 기준 + exploit path
연동	내보내기·웹훅	API, MCP connector, webhook
권한	프로젝트 접근	view·triage·create를 나누는 RBAC

Anthropic은 4월 이후 수천 개 조직이 100만 건 넘는 취약점을 찾았다고 주장합니다. 이는 누적된 제조사 수치입니다. 탐지율, 오탐률, 실제 수정률을 독립적으로 검증한 자료는 이번 조사에서 확인하지 못했습니다.

연속 스캔은 어떻게 동작하나

Anthropic의 설명에 따르면 프로젝트를 만들고 Claude GitHub app(Enterprise Server 포함) 또는 GitLab 등의 access token으로 저장소를 연결합니다. 브랜치와 범위를 고르면 깊은 baseline scan을 한 번 수행하고, 이후에는 변경의 위험도와 복잡도에 따라 정기적으로 스캔합니다. 모든 커밋을 같은 깊이로 다시 보는 방식이 아닙니다.

프로젝트 하나에 여러 저장소를 담을 수 있습니다. 이는 서비스 사이의 경계에서 생기는 문제를 찾기 위한 것입니다. 예를 들어 백엔드가 클라이언트가 검증했어야 할 입력을 신뢰하는 경우, 단일 저장소 스캔으로는 놓치기 쉽습니다.

finding은 코드 변경과 대조됩니다. 팀이 Claude Code에서 고쳤든 다른 도구에서 고쳤든, 수정이 반영되면 finding을 fixed로 표시합니다. 나중에 같은 문제가 다시 발견되면 자동으로 reopen합니다. 이 “fixed → reopen” 루프는 정적 보고서에는 없는 기능입니다.

threat model이 스캔의 필터가 된다

각 프로젝트에는 knowledge base가 생깁니다. 배포 방식, 적용되는 보안 정책, 새 보안 엔지니어에게 알려줄 환경 정보를 적을 수 있습니다. Claude Security는 코드에서 threat model을 생성하고, 팀이 이를 검토·편집할 수 있게 합니다. 이후 스캔은 이 threat model을 기준으로 무엇을 flag할지 결정합니다.

이 설계는 오탐을 줄이는 데 유용합니다. 코드만 보면 “위험해 보이는” 패턴도, 실제 배포 환경에서 접근 불가능하거나 다른 통제로 막혀 있으면 우선순위가 낮아질 수 있습니다. 반대로 threat model이 틀리면 스캐너는 조용히 중요한 것을 건너뜁니다. threat model은 설정이면서 공격 표면입니다. 정기적으로 리뷰하고 버전을 남겨야 합니다.

Anthropic은 finding마다 threat model 기준의 심각도와 공격자가 취약 코드에 도달하는 경로를 설명하고, 경우에 따라 attack path diagram을 제공한다고 합니다. 이는 “심각도 숫자”보다 실제 도달 가능성을 보려는 시도입니다. 다만 설명이 정확한지, 다이어그램이 최신 코드와 맞는지는 별도 검증이 필요합니다.

“fixed”의 네 가지 상태

보안 도구의 fixed 표시를 배포 완료로 읽으면 안 됩니다. 최소한 다음 네 상태를 분리하는 편이 좋습니다.

상태	의미	필요한 증거
open	문제가 코드에 존재	finding, 재현 또는 코드 위치
fixed in code	수정 커밋이 병합됨	commit/PR, 리뷰, 테스트
verified in runtime	수정된 artifact가 실제 환경에 배포됨	image digest, 배포 버전, 런타임 확인
accepted risk	위험을 인정하고 예외 처리	승인자, 만료일, 보상 통제

Claude Security가 코드 변경을 보고 fixed로 표시하는 것은 두 번째 상태까지입니다. 세 번째 상태는 CI/CD와 런타임 검증의 몫입니다. 네 번째 상태는 보안 조직의 정책 결정입니다. 이 구분이 없으면 “스캐너가 fixed라고 했는데 왜 아직 취약한가”라는 혼란이 반복됩니다.

특히 마이크로서비스나 모바일 앱처럼 배포가 여러 단계로 나뉘는 환경에서는 코드 수정과 프로덕션 반영 사이에 며칠이 걸릴 수 있습니다. 그동안 finding을 닫아 버리면, 실제 공격 표면은 열려 있는데 대시보드는 초록색이 됩니다.

CI 게이트에 넣는 방법

아래 정책은 제품 설정이 아니라 개념을 설명하기 위한 미실행 예시입니다. 실제 Claude Security API나 CI 시스템의 스키마와 다를 수 있습니다.

# Illustrative policy, not a Claude Security configuration file.
security_gate:
  block_on:
    - severity: critical
      reachable: true
      state: open
    - severity: high
      reachable: true
      state: open
  require_for_fixed:
    - fix_commit
    - deployed_artifact
  waiver:
    owner: required
    reason: required
    expires_at: required

게이트의 목적은 모든 finding을 막는 것이 아닙니다. 실제로 도달 가능한 critical/high를 배포 전에 멈추고, 예외에는 책임자와 만료일을 남기는 것입니다. “fixed in code”만으로 게이트를 통과시키면 배포 지연을 놓칩니다. 반대로 모든 finding을 무조건 막으면 오탐이 배포를 멈추고, 팀은 예외를 남발하게 됩니다.

API와 MCP가 여는 자동화, 그리고 위험

새 API는 프로젝트와 finding을 나열·조회하고, finding을 resolve/reopen하며, 프로젝트와 저장소를 생성·관리할 수 있습니다. 사용자는 Claude Security 설정에서 personal access token을 만들 수 있고, 이 token은 사용자가 볼 수 있는 범위만 본다고 합니다. webhook으로 새 finding을 외부 시스템에 알릴 수 있습니다.

MCP connector는 Claude.ai와 Claude Code에서 finding을 불러오고, 질문하고, 수정을 시작하고, 같은 세션에서 resolved로 표시하는 흐름을 만듭니다. 편리하지만 자동화의 위험도 커집니다. finding을 닫는 권한이 있는 token이 유출되면, 실제로 고치지 않고 상태만 바꿀 수 있습니다. API token의 범위, 만료, 감사 로그, webhook payload의 민감정보를 함께 설계해야 합니다.

RBAC는 view, triage, create project를 나눕니다. 코드를 소유한 팀에 프로젝트를 열어 주되, 모든 팀에 프로젝트 생성 권한을 주지 않을 수 있습니다. 이는 운영상 중요한 변화입니다. 보안 도구의 권한은 “스캔을 볼 수 있는가”와 “상태를 바꿀 수 있는가”를 분리해야 합니다.

어떤 숫자를 봐야 하나

“100만 건”은 탐지 성과의 분자일 뿐입니다. 조직이 알아야 할 것은 자기 코드에서의 비율입니다.

지표	질문
확인된 true positive rate	finding 중 실제 문제로 확인된 비율
false positive rate	개발자가 무효라고 판정한 비율
triage time	finding 생성부터 담당자 배정까지
fix time	확인부터 수정 커밋까지
deploy time	수정 커밋부터 프로덕션 반영까지
reopen rate	fixed 후 같은 문제가 다시 열린 비율
escaped defects	스캔을 통과했지만 사고로 이어진 건수

특히 reopen rate와 deploy time을 같이 봐야 합니다. reopen이 많으면 수정이 임시방편이거나 스캔 맥락이 불안정하다는 신호일 수 있습니다. deploy time이 길면 “fixed” 대시보드와 실제 위험 사이의 간격이 커집니다.

도입 전에 확인할 것

GitHub app 또는 access token의 권한이 읽기 전용으로 충분한가. 필요한 저장소와 브랜치로 범위를 좁혔는가.
threat model을 누가 리뷰하고 승인하는가. 변경 이력이 남는가.
finding 상태를 기존 Jira·SIEM·취약점 관리 시스템과 어떻게 동기화하는가.
API personal access token의 범위와 만료, 회수 절차가 있는가.
MCP connector를 통해 finding을 닫을 수 있는 사용자를 제한했는가.
webhook payload에 코드 조각이나 민감정보가 포함되는가.
public beta의 데이터 보존과 학습 사용 조건을 계약서에서 확인했는가.
“fixed”와 “배포 완료”를 구분하는 자체 지표가 있는가.

Anthropic은 Enterprise 고객에게 두 달간 매월 25,000달러의 사용 크레딧을 제공한다고 합니다. 2026년 12월 31일까지의 사용분에 적용됩니다. 이는 도입 비용을 낮추는 제안이지, 탐지 정확도나 운영 비용 전체를 보장하는 숫자는 아닙니다.

한계

Claude Security는 코드와 저장소 맥락을 보는 도구입니다. 실제 런타임 설정, 배포된 artifact, 네트워크 경계, 클라우드 권한을 직접 검사하는 DAST나 CSPM을 대체하지 않습니다. threat model이 코드에 없는 통제를 잘못 가정하면 false negative가 생길 수 있습니다. public beta이므로 기능과 가격, API 스키마가 바뀔 수 있습니다.

또한 “연속”이라는 표현은 모든 커밋을 전체 스캔한다는 뜻이 아닙니다. 위험도와 복잡도에 따라 스캔 깊이가 달라집니다. 중요한 변경이 얕게 지나가지 않도록 브랜치 보호, 리뷰, 별도 정적 분석을 함께 두는 편이 안전합니다.

결론: 스캐너가 아니라 생명주기 시스템으로

Claude Security의 업데이트는 탐지 기능 하나를 더한 것이 아니라 finding을 계속 살아 있는 상태로 관리하는 방향으로 이동했습니다. 그 가치는 “몇 건 찾았나”보다 “고친 것이 실제로 배포됐는가”를 추적할 수 있게 하는 데 있습니다.

도입한다면 대시보드의 fixed 숫자를 그대로 믿지 마세요. 코드 수정, 배포 artifact, 런타임 확인, 예외 승인을 분리하고, 그 네 상태를 CI와 감사 로그에 연결해야 합니다. 그래야 연속 스캔이 보안팀의 보고서가 아니라 개발팀의 배포 게이트가 됩니다.

참고 자료

Claude: Claude Security now scans continuously and tracks fixes (2026-10-21)

이 주제를 직접 따라가며 배우고 싶다면

보안 finding을 코드 수정에서 배포 검증까지 연결하는 일은 개발 흐름의 통제 문제입니다. Claude Code에서 프로젝트 규칙, 훅, 서브에이전트, MCP 권한을 실제 작업에 묶는 연습을 하고 싶다면 이 강의가 도움이 됩니다.

Claude Code·하네스 엔지니어링 강의 보기