Vercel의 AI 보안 스캐너 DeepSec 깊이 살펴보기

• 빠른 패턴 검색으로 의심스러운 코드를 찾고,
  Codex나 Claude가 파일 사이의 데이터 흐름과 방어 장치를 추적해 실제 보안 문제인지 조사하는 오픈소스 도구
• PR의 새 코드뿐 아니라
  오랫동안 수정하지 않은 기존 코드까지 검사하며, 분석 이력을 저장해 중단한 작업을 재개하고 이후에는 변경분을 처리함
• HTTP 라우트와 웹훅 등
  외부 입력이 들어오는 지점이 검사 대상에 포함됐는지 확인하고, 프로젝트의 인증 방식과 업무 맥락을 제공해 판단을 돕도록 구성함
• 실제 사이트의 729개 파일을 검사해
  잠재적 문제 504건을 찾았지만, 378건은 일반 버그였음. 후속 검토에서 중복 원인과 실제 공격 가능성을 따져 우선 조사할 영역을 좁힘
• 발견 건수를 곧바로 수정 목록으로 삼기보다
  중요한 결과를 재검증하고 코드 경로를 확인하는 방식으로 활용함. 모델 사용 비용과 오탐을 파악하도록 첫 검사는 작은 범위에서 시작함

패턴 스캐너와 코딩 에이전트의 역할 분담

• DeepSec은 Vercel의
  오픈소스 보안 스캐너로, 기존 저장소 전체와 PR에서 바뀐 파일을 모두 검토할 수 있음

• PR 검사만으로는 3년 전 작성한 인증 코드나 출시 이후 바뀌지 않은 웹훅을 자동으로 재검토하지 못함

• 전체 저장소 검사는 최신 모델이 아직 검토하지 않은 기존 코드까지 대상으로 삼음

• 전통적인 정적 스캐너는 문자열로 조립한 SQL, 인증 래퍼가 보이지 않는 라우트, 사용자 입력을 다른 서버로 전달하는 호출 같은
  알려진 패턴을 빠르고 예측 가능하게 찾음

• 다른 함수가 URL을 검증하는지, 라우트가 공개돼 있는지, 요청이 사설망까지 도달하는지 같은 맥락은 패턴만으로 판단하기 어려움

• Codex나 Claude 같은 코딩 에이전트가 파일을 따라가며 이러한 조건과 방어 장치를 조사함

• 파이프라인은
  저장소 파악 → 진입점 목록 → 패턴 검사 → AI 조사 → 재검증 → 보고서 순서로 진행됨

• 패턴 검사가 탐색 범위를 좁히고, 에이전트가 느리지만 깊은 추론을 맡음

• 추가 에이전트 검토는 오탐을 제거하고 심각도를 조정할 수 있음

• 단순히 에이전트에 “이 저장소의 보안 문제를 검토하라”고 요청하는 것과 달리, DeepSec은 검사 범위 확인, 증분 상태, 재개, 구조화된 발견 사항, 재검증, 일관된 보고 형식을 갖춘
  보안 검토 하네스임

보장하지 않는 것과 실행 전제

• DeepSec은
  저장소가 안전하다는 증명이 아니며, 버그를 놓치거나 잘못된 발견 사항을 생성할 수 있음

• 다음 보안 활동을 대체하지 않음

• 제품을 이해하는 사람이 작성하는
  위협 모델이 필요함

• 의존성 및 비밀정보 검사, 보안 테스트, 런타임 모니터링을 계속해야 함

• 민감한 코드의 수동 검토와 고위험 시스템의 침투 테스트도 필요함

• 로컬 실행에서도
  관련 코드와 프롬프트가 모델 제공자에게 전송됨

• 비공개 코드를 검사하기 전에 제공자와 게이트웨이의 데이터 정책을 확인해야 함

• 기본적으로
  신뢰할 수 있는 저장소를 대상으로 설계됨

• 프로젝트 접근 권한을 가진 코딩 에이전트처럼 취급해야 하며, 신뢰하지 않는 PR을 로컬에서 실행해도 안전하다고 가정해서는 안 됨

• 실행에는
  Node.js 22 이상, npm/pnpm/Yarn, Git 저장소, 지원하는 코딩 에이전트 모델 접근 권한, 코드 검사 권한이 필요함
  .deepsec/

안에 별도의 Node.js 작업 공간을 만들므로 상위 프로젝트가 JavaScript일 필요는 없음

• TypeScript, Go, Python, Lua, Terraform 등 텍스트 기반 코드베이스를 검토할 수 있음
• Apache 2.0 라이선스로 공개돼 있으며, 모델 호출과 선택적인 Vercel Sandbox 실행 비용은 별도임

초기 설정과 첫 실행의 비용 통제

npx deepsec init --plan --output json

으로 저장소를 변경하지 않고 설정 계획을 확인할 수 있음
npx deepsec init --scaffold-only

는 작업 공간의 뼈대만 만듦

• 패키지 설치, 로그인, 모델 선택, 저장소 검사, 유료 처리를 시작하지 않음

• 중요한 저장소에서는 생성된 디렉터리를 검토하고 필요한 설정 파일을 커밋한 뒤 진행하는 방식이 권장됨

• 일반적인
  npx deepsec init

은 모델과 인증 방식을 선택한 뒤 자동으로 다음 작업을 진행함

• 작업 공간을 생성하고 저장소를 분석한 뒤, 짧은 프로젝트 설명과 진입점 목록을 작성함

• 매처 검사 범위를 확인하고 로컬 패턴 검사를 거쳐 AI 검토를 시작함

• 모델 선택 목록에는 벤치마크와 상대 비용이 표시되며, 모델 구성이 바뀌므로 현재 목록을 확인해야 함

• 첫 실행은 수분에서 수시간이 걸릴 수 있고, 큰 저장소는 더 오래 걸릴 수 있음

• 첫 실행에는
  비용 및 시간 상한을 설정하는 것이 권장됨

• 예를 들어
  npx deepsec init --max-cost-usd 25 --max-duration 30m

으로 실행함

• 어느 한도든 도달하면 안전한 지점에서 중단하며, 같은 명령을 다시 실행하면 완료한 작업을 건너뜀
• 한도는 실행별로 적용되므로 재개를 반복할 때 누적 비용은 별도로 추적해야 함

.deepsec/

에서 pnpm deepsec process --limit 50

처럼 소량을 먼저 처리하면 비용, 속도, 발견 품질을 가늠할 수 있음

모델 인증 방식과 자격 증명

• 기본 인증 경로는
  Vercel AI Gateway임
• 필요하면 Vercel에 로그인하고 DeepSec 작업 공간용 작은 프로젝트를 생성함

--model-auth local

은 이미 로그인된 로컬 Codex 또는 Claude 세션을 사용하며, 게이트웨이 토큰이나 API 키를 설정하지 않음

• 선택한 에이전트에 맞는 유효한 로그인이 필요함

• flaviocopes.com 검사에서는 OpenAI API 키 없이 기존 ChatGPT 구독을 사용함

• 평가용으로 유용하지만, 큰 저장소 전체 검사에는 구독 한도가 부족할 수 있어 게이트웨이나 직접 API 키로 전환해야 할 수 있음

• 로컬 자격 증명은 원격 샌드박스로 전달할 수 없으며, 샌드박스에는 실제 API 토큰이 필요함

• OpenAI 또는 Anthropic의
  직접 API 키도 사용할 수 있음

• OpenAI는 Codex 에이전트와
  openai

제공자, Anthropic은 Claude 에이전트와 anthropic

제공자를 선택함
--ai-api-key-env

로 환경 변수 이름을 지정하면 DeepSec은 값이 아니라 이름만 저장함

• 키를 셸 기록에 남기지 않도록 입력하고, 이후 실행에서도 환경 변수를 제공해야 함
  .deepsec/.env.local

에 저장할 수도 있지만 Git에서는 제외해야 함

• 전체 인증 옵션은 모델 및 Vercel 설정 가이드에서 확인할 수 있음

작업 공간과 프로젝트 맥락

.deepsec/

는 자체 package.json

, 의존성, 설정, 상태를 가진 독립 작업 공간임

• 주요 파일은
  deepsec.config.ts

, generated-matchers.ts

, AGENTS.md

임
data/<project>/

아래에는 INFO.md

, SETUP.md

, project.json

과 setup/

, files/

, runs/

, reports/

가 저장됨

• 생성된
  .gitignore

는 자격 증명과 재생성 가능한 검사 상태를 제외하고, INFO.md

, SETUP.md

, 설정과 매처 파일 등은 커밋할 수 있게 둠

• 보안 보고서에는 민감한 코드 경로와 취약점 세부 정보가 들어갈 수 있으므로 커밋 전에 정책을 검토해야 함

INFO.md

는 모든 조사, 재검증, 우선순위 분류 프롬프트에 포함되는 프로젝트 맥락임

• 자동 생성 결과를 검토하고, 제품 기능, 신뢰하지 않는 입력의 진입점, 인증과 인가 방식, 민감한 데이터, 중요한 불변 조건, 위험해 보이지만 의도된 패턴을 짧고 사실적으로 기록해야 함

• 비밀정보를 넣어서는 안 됨

• flaviocopes.com의 초기 맥락에는
  정적 사이트와 작은 서버 측 영역의 구분이 담겼음

• Astro 7 기반 Cloudflare Pages 사이트, 브라우저 도구, 뉴스레터/후원/강의 복구/구매용 Pages Functions, 예약 Worker와 로컬 운영 스크립트가 있음

• 사용자 계정은 없고, 구매 흐름은 Paddle 웹훅 서명, 공개 폼은 Turnstile과 IP 기반 요청 제한으로 보호됨

• 강의 URL은 소지 자체가 접근 자격이 되는 방식임

• 교육용 보안 예제는 프로덕션 코드가 아니며, 공개 ID와 Turnstile 사이트 키는 비밀정보가 아니고, 편집기 명령과 MCP 설정은 로컬 도구에 해당함

진입점 목록과 검사 범위 확인

• 초기 설정은 HTTP 라우트, RPC 핸들러, 큐 소비자, cron 작업, CLI 명령, 웹훅, 에이전트 도구를 구조화된
  진입점 목록으로 만들고 data/<project>/setup/

에 저장함

• 이 목록을 매처가 도달한 파일과 비교해
  검사 사각지대를 확인함

• 발견 사항이 0건인 이유는 코드가 안전해서일 수도 있지만, 중요한 파일을 보지 못해서일 수도 있음

• 결과를 해석하기 전에 검사 범위를 확인해야 함

• 중요한 진입점에 매처가 없으면 프로젝트 전용 매처 생성을 시도하며, 그래도 범위를 충족하지 못하면
  유료 AI 단계 전에 중단함

매처의 구조와 검토 기준

매처(matcher) 는 보안상 민감한 코드를 조사 대상으로 고르는 규칙으로, 보통 파일 경로와 정규식을 조합함

• 취약점을 증명하는 것이 아니라, 진입점이나 위험한 연산이 있는 파일을 에이전트에게 넘기는 역할임

• 잡음 수준은 세 가지로 구분함
  precise

는 특정 버그를 강하게 시사하는 패턴임
normal

은 에이전트 조사가 필요한 유용한 후보임
noisy

는 좁은 파일군 전체를 검토할 필요가 있을 때 사용함

• 매처 범위가 넓어질수록 비용이 드는 AI 단계로 넘어가는 파일이 늘어남

• 프로젝트 전용 규칙은
  generated-matchers.ts

에 선언적 데이터로 저장됨

• DeepSec은 경로, 정규식, 예제, 후보 수를 검증하며, 이 단계에서 모델이 작성한 TypeScript를 실행하지 않음
• 실제 소스 디렉터리와 안정적인 코드 패턴을 가리키는지, 생성 파일을 제외하는지, 의도한 진입점에 도달하는지, 후보 수가 적절한지 사람이 확인해야 함

scan --matchers <slug>

로 개별 매처를 실행하고 매칭된 파일을 표본 검토할 수 있음

• 무관한 파일 수백 개를 고르는 매처는 검사 범위를 개선하지 못하면서 비용만 늘릴 수 있음

일상적인 검사와 AI 조사

.deepsec/

에서 status → scan → process → revalidate → report

순서로 상태 확인부터 보고서 생성까지 진행함
export --format md-dir --out ./findings

로 발견 사항별 Markdown 파일을 내보낼 수 있음

• 첫 전체 검토는 전체 파이프라인을 따르지만, 이후 실행은 증분 방식이므로 수정할 때마다 모든 명령을 실행할 필요는 없음

scan

은 활성 매처를 적용해 후보 파일 기록을 만들며 AI 모델을 호출하지 않음
dangerouslySetInnerHTML

이 있어도 값이 이미 정제됐거나 신뢰하는 정적 콘텐츠일 수 있으므로, 후보는 취약점 확정이 아님

• Next.js, React, Express, Fastify, NestJS, Hono 등을 감지해 프레임워크별 매처와 위협 힌트를 활성화할 수 있음
• 다른 생태계는 일반 매처를 사용할 수 있으며, 현재 범위는 지원 기술 목록에 있음

process

는 대기 중인 후보 파일을 묶어 코딩 에이전트에 전달하는 유료 처리 단계임

• 소스 파일, 후보 매칭,
  INFO.md

, 파일 간 코드를 추적할 저장소 도구, 구조화된 출력 형식을 제공함

• 에이전트는 호출자, 미들웨어, 검증, 인가와 다른 방어 장치를 찾고 0개 이상의 발견 사항을 반환함

• 각 항목에는 심각도, 신뢰도, 영향받는 줄, 설명, 권장 수정 등이 들어감

• 모델, 에이전트, 시간, 확인 가능한 비용과
  분석 이력을 기록함

• 이력은 추가만 가능하며, 나중에 다른 모델로 분석해도 이전 기록을 삭제하지 않음

재검증, 우선순위 분류, 수정

revalidate

는 발견 사항을 다시 조사해 true-positive

, false-positive

, fixed

, uncertain

, duplicate

중 하나로 분류함

• 결과가 많으면
  --min-severity HIGH

로 심각도가 높은 항목부터 시작할 수 있음

• 코드를 다시 읽고 Git 이력을 살펴볼 수 있어 별도 비용이 들며, 문서상 재검증 이후에도 상당한 오탐이 남음

• 발견 제목만으로
  프로덕션 사고 대응이나 위험한 패치를 시작해서는 안 됨

• 공격자가 통제하는 입력이 실제 연산에 도달하는지, 다른 파일에 방어 장치가 있는지 코드 경로를 확인해야 함

triage

는 발견 사항의 텍스트와 악용 가능성, 영향을 바탕으로 P0, P1, P2, skip 같은 작업 우선순위를 부여함

• 접근할 수 없는 내부 프로토타입의 높은 심각도 버그보다 공개 결제 엔드포인트의 중간 심각도 문제가 더 급할 수 있음

• 소스를 다시 읽지 않는 저렴한 분류 단계이므로, 진위를 확인하는 재검증을 대체하지 않음

• 수정 전에
  신뢰하지 않는 입력 → 빠진 통제 → 민감한 연산 → 영향의 각 연결을 확인해야 함

• 예를 들어 URL의 청구서 ID에 테넌트 소유권 검사가 빠지면, 해당 ID로 데이터베이스를 조회해 다른 테넌트의 청구서를 반환할 수 있음

• 빠진 통제는 가장 좁은 공통 경계에서 고치고, 차단돼야 하는 경우의 테스트와 일반 프로젝트 테스트를 추가하거나 실행함

• 이후
  scan

, process

, revalidate

를 다시 실행하면 파일 해시로 변경을 감지함

• 중요한 문제는 두 번째 에이전트 백엔드로 확인할 수 있지만, 두 에이전트의 판단이 일치해도 증명은 아님

프로젝트별 설정과 사용자 정의 매처

deepsec.config.ts

에서 웹 앱과 Worker 등 여러 프로젝트의 루트와 priorityPaths

를 설정할 수 있음

• API, 인증, 핸들러, 큐 경로처럼 먼저 처리할 영역을 지정함

promptAppend

에는 “웹훅 핸들러는 신뢰할 필드를 해석하기 전에 서명을 검증해야 한다” 같은 프로젝트 규칙을 추가할 수 있음

• 모호한 보안 조언을 길게 나열하기보다 사실적인 규칙을 짧게 유지해야 함

data/<id>/config.json

의 ignorePaths

로 테스트 픽스처나 생성 파일 등을 제외할 수 있음

• 매처 범위가 잘못돼 잡음이 많다면 결과를 숨기기보다 매처 자체를 수정해야 함

• 선언적 경로와 정규식만으로 부족하면
  코드 기반 사용자 정의 매처를 작성할 수 있음

• 예제는
  src/rpc/**/*.ts

에서 registerRpc(...)

를 찾는 internal-rpc-entrypoint

매처임
regexMatcher

, MatcherPlugin

, DeepsecPlugin

을 이용해 구성하고, 기존 generatedMatchersPlugin

을 유지한 채 추가함

• 실제 핸들러를 놓치면 범위를 넓히고 무관한 파일을 잡으면 좁혀야 함

• 목표는 완전한 정적 분석기를 만드는 것이 아니라
  깊이 검토할 파일을 제대로 선택하는 것임

변경 파일과 PR 검토

• 전체 초기 감사 뒤에는
  process --diff origin/main

으로 현재 브랜치의 변경 파일을 직접 검토할 수 있음

• 변경 파일을 찾고 로컬 매처를 실행한 뒤, 매처가 반응하지 않은 파일까지 모든 변경 파일을 에이전트가 검토함
  --diff-staged

는 스테이징한 변경, --diff-working

은 커밋하지 않은 파일과 추적하지 않는 파일을 대상으로 함

--comment-out comment.md

는 새 발견 사항이 있을 때만 PR용 Markdown 요약을 생성함

• 직접 모드의 종료 코드는 새 발견이 없으면
  0

, 하나 이상 있으면 1

이며, 그 외 비정상 코드는 명령 실패를 뜻함

• CI 차단 조건으로 활용할 수 있지만, 처음에는
  권고 모드로 보고서를 보관하고 품질을 확인해야 함
• 팀이 비용과 오탐을 이해한 뒤 차단 검사로 전환하는 방식이 권장됨

신뢰하지 않는 PR의 CI 보안

• PR은 애플리케이션 코드뿐 아니라
  package.json

, 설치 스크립트, DeepSec 설정 등 CI에서 실행되는 파일도 바꿀 수 있음

• 신뢰하지 않는 코드를 실행하는 작업에 강력한 저장소 권한을 함께 주어서는 안 됨

• 첫 작업은
  코드 읽기, 검토 실행, 산출물 작성만 하고 저장소 수정 권한을 갖지 않음

• 두 번째 작업은 안전하게 정제한 산출물을 읽고 PR 댓글만 작성하며 PR 코드를 실행하지 않음

• 일반적인
  pull_request

이벤트에서 포크 PR에는 저장소 비밀정보가 전달되지 않으므로, 건너뛰거나 격리 환경으로 옮겨야 함

• 검토 작업에는 모델 자격 증명이 존재하므로 악성 변경이 접근 가능한 비밀정보를 탈취하려 할 수 있음

• 공식 PR 모드 워크플로를 출발점으로 저장소의 신뢰 정책을 적용해야 함

• 외부 GitHub Actions는 전체 커밋 해시로 고정하고 권한을 제한함

• 외부 기여에 비밀정보를 사용하는 분석을 실행하기 전에는 신뢰할 수 있는 승인을 요구함

정기 CI 검사와 상태 보존

• 신뢰하는 기본 브랜치에서 실행하는
  예약 전체 검사는 PR 검사보다 단순함
• 예제는 수동 실행 또는 매주 월요일 06:00 예약 실행, 읽기 전용 저장소 권한, 60분 제한, Node.js 24를 사용함
• 의존성 설치 후
  scan

, process

, 높은 심각도 재검증, Markdown 내보내기를 진행함

• 상태가 없는 새 CI 실행에서는
  대기 중인 모든 후보를 처리하므로, 활성화 전에 로컬에서 제한된 검사를 해봐야 함
• 전체 검사는 예상보다 오래 걸리고 비용이 커질 수 있음

--limit

로 작업을 여러 실행에 나눌 경우 .deepsec/data/

를 비공개 저장소에 보존해야 함

• 상태는 보통 Git에서 제외되므로, 보존하지 않으면 새 실행기가 같은 첫 묶음을 반복 처리할 수 있음
• 보고서를 남기려면 비공개 산출물 보관 단계도 필요하며, 공개 빌드 로그에 취약점 보고서를 게시해서는 안 됨
• 민감한 저장소에서는 Actions를 검토한 커밋 해시로 고정해야 함

Vercel Sandbox와 여러 저장소로 확장

• 큰 저장소는
  Vercel Sandbox microVM으로 작업을 분산할 수 있음
• 예제는
  --sandboxes 10 --concurrency 4

로 각 샌드박스에 작업 일부를 배정함

• 호스트가 실제 모델 자격 증명을 보관하고 제공자 요청에만 추가하므로, 샌드박스는 원본 자격 증명을 보지 못함

• 샌드박스는 로컬 실행에 수시간에서 수일이 걸리거나, 후보가 수천 개이거나, 검사 작업 트리와의
  격리가 필요하거나, 예약 작업을 예측 가능한 시간 안에 끝내야 할 때 유용함

• 작은 저장소와 중간 규모 저장소는 로컬 실행이 더 간단함

• 분산 실행에는 인프라, 인증, 업로드 시간과 비용이 추가됨

• microVM, 인증, 시간 제한, 네트워크 정책, 자격 증명 중개는 Vercel Sandbox 튜토리얼에서 다룸

• 하나의
  .deepsec/

작업 공간으로 여러 저장소를 관리할 수 있음
init-project

로 추가하고 setup --project-id

를 실행한 뒤, 후속 검사에도 프로젝트 ID를 지정함

• 웹 앱, API, Worker, 백그라운드 서비스로 나뉜 같은 제품에 유용함
• 대시보드 하나를 만들기 위해 무관한 저장소를 합치기보다 함께 검토하는 제품 단위로 묶는 편이 적합함

flaviocopes.com 전체 검사 사례

• 대부분 정적 콘텐츠인 사이트지만,
  Cloudflare Pages Functions, 구매 웹훅, 강의 복구, 공개 도구, 운영 스크립트를 포함한 전체 저장소를 검사함
• 모델은
  **Codex의 **gpt-5.6-sol

, xhigh

추론을 선택하고, API 키 없이 로컬 Codex 로그인과 ChatGPT 구독을 사용함

• 설정 과정에서 위협 모델과 검사 범위를 확인하고 프로젝트 전용 매처 4개를 생성함
• 2개는 Astro 페이지 진입점, 나머지는 로컬 Node.js 운영 스크립트와 Codex MCP 서버 등록을 찾음
• 위협 모델은 작은 서버 측 영역, 구매와 공개 폼, 강의 링크, 로컬 스크립트, 배포 자격 증명, AI 엔드포인트를 중요한 경계로 파악함
• 교육용으로 의도적으로 위험하게 작성한 코드가 프로덕션 엔드포인트가 아니라는 점도 기록함

729개 파일을 조사해 잠재적 발견 사항 504건을 생성함

• critical 1건, high 16건, medium 67건, high-impact bugs 42건, bugs 378건으로 나뉨

• 첫 결과 다음 단계는 재검증이며, 504개 항목을 곧바로 수정 작업으로 바꾸는 흐름이 아님

• Codex는 약
  입력 1,440만 토큰, 출력 170만 토큰을 처리함

• 화면에는
  $0.0000

이 표시됐지만, 별도 API 청구가 없었을 뿐 ChatGPT 구독 용량을 사용함

발견 건수를 실제 대응 계획으로 바꾸기

• 후속 Codex 검토에서는 파일을 수정하지 않고
  근본 원인별 묶기, 원격 접근 가능한 프로덕션 위험 분리, 대응 순서 결정을 요청함

• 인터넷에서 도달 가능한지, 입력을 공격자가 통제하는지, 다른 파일에 방어가 있는지 확인함

• 보안 문제와 일반 제품 버그를 구분하고, 여러 보고서가 같은 원인인지와 실제 영향을 검토함

• 504건 중
  **462건은 **src/tools

와 src/pages/tools

의 브라우저 도구에서 나왔음

• 일반 버그 378건에는 계산 오류, 잘못 생성된 출력, 경계 사례, UI 문제가 포함됐으며 모두 보안 긴급 상황은 아님

• 도구 구현과 Astro 페이지 양쪽에서 같은 문제가 보고돼, 공통 원인 하나를 수정하면 여러 항목을 해결할 수도 있음

• 실제 조사 대상은 다음
  세 영역으로 좁혀짐

• 서버 측 구매, 강의 복구, 공개 폼 흐름을 조사함

• 실행 가능한 콘텐츠를 렌더링하거나 명령과 코드를 생성하는 브라우저 도구도 대상임

• 로컬 운영 스크립트에서는 신뢰하지 않는 데이터가 셸이나 파일 시스템 연산에 도달할 수 있는 경로를 살핌

• 나머지는 일반 제품 품질 작업으로 넘기거나, 수동 확인을 기다리거나, 보고된 경로가 실제로 존재하지 않으면 제외할 수 있었음

• 반복할 만한 흐름은 위협 모델과 진입점 목록 구성 → 제한된 표본 검사 → 잠재적 발견으로 취급 → 중요 결과 재검증 →
  근본 원인과 도달 가능성별 묶기 → 수정 전 코드 경로 확인임

• 시작점은 신뢰하지 않는 입력이 인증, 비공개 데이터, 돈, 인프라, 되돌릴 수 없는 동작과 만나는 지점임

적합하지 않은 경우와 도입 순서

• DeepSec은
  애플리케이션과 서비스에 가장 잘 맞으며, 다음 경우에는 우선 선택으로 덜 적합함

• 민감한 서버 코드가 없는 정적 사이트나 외부 입력이 없는 작은 스크립트에는 덜 적합함

• 프로젝트별 위협 맥락이 없는 라이브러리와 생성 코드도 해당함

• 로컬에서 신뢰할 수 없는 저장소나 발견 사항을 검토하고 수정할 사람이 없는 프로젝트에도 적합하지 않음

• 라이브러리와 프레임워크도 검사할 수 있지만, 위험성이 다른 애플리케이션의 사용 방식에 좌우되므로
  사용자 정의 프롬프트와 매처가 필요할 수 있음

• 사소한 수정마다 저렴하게 확인하는 용도로는 적합하지 않음

• PR 직접 모드에서도 검토하는 파일마다 모델 작업이 필요함

• 빠른 피드백에는 린터, 테스트, 의존성 스캐너, 좁고 명확한 정적 규칙을 사용하고, 깊은 저장소 추론이 비용을 정당화하는 곳에 DeepSec을 사용함

• 도입은
  --scaffold-only

로 생성물 검토 → 실제 위협 경계 보완 → 작고 제한된 검사 → 전체 저장소 확대 순서가 권장됨

• 패턴 검색의 맥락 부족과 에이전트 단독 검토의 누락 가능성을 보완하고, 조사할 코드 경로와 이력을 남기는 것이 핵심임

• 현재 명령은 DeepSec 문서, 전체 소스는 vercel-labs/deepsec에서 확인할 수 있음

댓글과 토론