504건 중 462건이 두 디렉터리에서 나왔다

AI 보안 스캐너를 자기 저장소에 돌려본 기록이 나왔다. 파일 729개에서 발견 504건. 여기서 멈추면 잘못 읽는다.

504건 중 462건이 두 디렉터리에서 나왔다. src/tools와 src/pages/tools, 92%다.

이 분포가 스캐너 결과를 읽는 방법을 정한다. 심각도로 정렬할 게 아니라 경로로 묶어야 한다.

출처: flaviocopes.com/deepsec — Vercel의 DeepSec을 제3자가 직접 돌려본 기록

확인된 것

원문에서 확인한 것만 적는다.

• DeepSec은 Vercel이 공개한 오픈소스 보안 스캐너로, 패턴 매칭과 AI 에이전트를 붙여 쓴다. 역할 분담이 명확하다.

  The pattern scanner finds code that deserves attention. The coding agent then reads that code, follows data across files, looks for defenses, and writes a security finding.

• 단계는 넷이다. 패턴 스캔(로컬·무료) → 에이전트 조사(유료) → 재검증(유료, 오탐 제거) → 리포트. npx deepsec init으로 격리된 .deepsec/ 작업공간과 전용 Node 환경을 만든다. 인증은 Vercel AI Gateway, 직접 API 키, 또는 로컬 Codex/Claude 로그인.

• 저자의 실행 결과 — flaviocopes.com, 조사 파일 729개:

  • 504 potential findings: 1 critical, 16 high, 67 medium, 42 high-impact bugs, 378 bugs
  • 504건 중 462건이 src/tools와 src/pages/tools에서 나왔다.
  • 378건은 일반 버그로 분류됐다. 잘못된 계산, 깨진 생성 출력, 엣지 케이스, UI 문제.
  • 비용 $0.00(로컬 ChatGPT 구독 사용). 실제 소비는 입력 14.4M 토큰, 출력 1.7M 토큰.

• 저자가 붙인 경고 두 개: 큰 저장소에서 무제한 첫 실행을 하지 말 것, 그리고

  The number of findings is not the number of changes you need to make.

• DeepSec 문서가 스스로 밝히는 한계: 저장소가 안전함을 증명하지 않으며 위협 모델링·의존성 스캔·테스트·런타임 모니터링·수동 리뷰를 대체하지 않는다. 재검증 이후에도 오탐률이 눈에 띈다고 문서에 적혀 있다고 저자가 전한다.

판단

1. 결과는 흩어진 504개가 아니라 몇 개의 덩어리다

462 대 42. 발견의 92%가 두 디렉터리에서 나왔다는 건, 그 구역의 성격이 만든 결과라는 뜻이다. 저 저장소에서는 브라우저용 도구 모음이었다.

그러면 읽는 순서가 정해진다. 심각도로 정렬해 위에서부터 읽으면 같은 원인의 항목을 400번 다시 읽게 된다. 경로로 묶으면 "이 구역을 어떻게 다룰 것인가" 한 번의 결정으로 수백 건이 정리된다.

코드 리뷰 도구를 비교하며 "모델에 묻지 말고 경로로 갈라라"고 적었는데, 그때는 어느 변경에 비싼 모델을 붙일지의 기준이었다. 여기서는 결과를 읽을 때도 같은 자가 쓰인다. 디렉터리는 사람이 만든 의미 단위라서, 모델 없이도 신뢰할 수 있는 분류기다.

2. $0.00은 도구의 속성이 아니라 요금제의 속성이다

저자는 로컬 ChatGPT 구독으로 돌려서 추가 과금이 없었다. 그런데 실제로 소비된 건 입력 14.4M, 출력 1.7M 토큰이다. 파일당 입력이 약 2만 토큰(14.4M ÷ 729).

그러니 "무료로 돌렸다"를 도구의 특성으로 읽으면 안 된다. 구독 경로가 없거나, 팀 CI에서 돌리거나, 저장소가 이 사례보다 크면 그 토큰이 그대로 청구서가 된다. 저자가 큰 저장소에서 무제한 첫 실행을 하지 말라고 쓴 이유가 여기 있다.

→ 도입 전 계산: 내 저장소의 대상 파일 수 × 2만 토큰을 내 API 단가로 환산해본다. 그 숫자가 감당되는지가 이 도구를 정기적으로 돌릴 수 있는지를 정한다. 한 번 돌려보는 것과 매주 돌리는 것은 다른 결정이다.

3. 378건의 일반 버그는 보너스이면서 동시에 위험이다

보안 스캐너를 돌렸는데 나온 것의 4분의 3이 보안이 아니었다. 잘못된 계산, 깨진 출력, 엣지 케이스, UI 문제.

공짜로 얻은 버그 목록이니 나쁜 일은 아니다. 문제는 그게 보안 리포트 안에 섞여 있다는 것이다. 한 번 섞이면 다음 실행에서 진짜 보안 항목이 와도 같은 더미로 보이고, 팀은 그 목록 전체를 안 읽게 된다.

→ 규칙: 보안 결과와 일반 버그를 처음부터 다른 통에 넣어라. 통을 나누지 않으면 둘 다 안 읽힌다. 그리고 일반 버그 쪽은 백로그에 넣기 전에 한 번 더 걸러야 한다 — 스캐너가 버그라고 한 것 중에는 의도된 동작도 있다.

4. 보안 도구에서 "못 하는 것" 목록은 선택이 아니라 필수다

DeepSec 문서는 저장소가 안전함을 증명하지 않는다고 쓰고, 대체하지 못하는 것들을 나열하고, 재검증 후에도 오탐이 남는다고 밝힌다.

이게 없는 보안 도구가 더 위험하다. "스캔 통과"가 안전의 증거로 쓰이는 순간, 그 도구는 순이익이 아니라 순손실이 된다. 없던 안심을 만들어내기 때문이다.

저자의 마지막 조언이 그래서 정확하다.

Never open a production incident from the title alone. Read the code path.

여기서 한 걸음 더 나가면 운영 규칙이 된다. 스캐너 결과를 이슈 트래커에 자동 생성하지 마라. 사람이 코드 경로를 읽고 분류한 것만 티켓이 된다. 자동 생성하면 백로그가 504개 늘어나고, 그 백로그는 영원히 안 읽힌다. (이건 원문에 없는 내 판단이다.)

모르는 것

• 직접 돌려보지 않았다. 위 수치는 저자가 자기 저장소에서 측정한 것이고 나는 그 글을 읽었다.
• 오탐률의 구체적 수치를 확인하지 못했다. DeepSec 문서에 적혀 있다고 저자가 전하지만, 나는 그 문서를 직접 보지 않았다.
• 한 저장소 사례다. 언어·프레임워크가 다르면 패턴 매처의 적합도가 달라지고, 462 대 42 같은 분포도 달라질 것이다.
• critical 1건이 실제로 악용 가능했는지 후속 확인이 글에 없다. 보안 스캐너 평가에서 가장 중요한 숫자인데 비어 있다.
• 팀 CI에 넣었을 때의 실행 시간을 모른다. 토큰 수는 나와 있지만 벽시계 시간은 없다.
• 재검증 단계가 오탐을 얼마나 줄였는지 전후 수치가 없다. 504는 재검증 이후 숫자인지 이전 숫자인지 내 독해로는 확정하지 못했다.