Snyk은 MCP 서버를 직접 실행하여 스캔합니다. 이것이 의미하는 바는 다음과 같습니다.

Snyk의 agent-scan 도구는 설정에서 발견되는 모든 MCP 서버를 시작하고 해당 도구의 설명(tool descriptions)을 쿼리하는 방식으로 작동합니다. 이것은 버그가 아닙니다. 아키텍처(architecture)의 문제입니다. stdio MCP 서버에서 도구 설명을 가져오려면 서버를 실행해야만 합니다. 이 도구는 제품 설명에 적힌 그대로 동작합니다. 문제는 사용 사례(use case)입니다.

agent-scan이 실제로 수행하는 작업
snyk-agent-scan을 실행하면, 로컬 MCP 설정 파일인 ~/.cursor/mcp.json, Claude Desktop 설정, Windsurf 설정 등을 읽습니다. 발견된 각 서버에 대해 설정에 있는 명령 배열(command array)을 실행하고, 서버를 구동하며, MCP 프로토콜을 통해 연결한 뒤, 도구 설명을 가져와 분석을 위해 invariantlabs.ai에 있는 Invariant Labs의 API로 해당 데이터를 전송합니다. 한 개발자는 API가 429 Too Many Requests 응답을 반환했을 때 이를 직접 확인했으며, 이는 스캐너가 사용자 프롬프트 없이 서버를 실행하고, 연결하고, 데이터를 기기 외부로 전송했음을 증명했습니다. 이후 Snyk은 실행 전에 서버 이름, 명령 및 환경 변수를 보여주는 동의 흐름(consent flow)을 추가했습니다. CI/CD 환경에서는 --dangerously-run-mcp-servers 옵션으로 이 과정을 완전히 건너뛸 수 있습니다. 동의 프롬프트는 적절한 해결책입니다. 하지만 아키텍처에 대한 질문은 고민해 볼 가치가 있습니다.

근본적인 긴장 관계
여기서 중요한 점은 다음과 같습니다. Snyk의 접근 방식은 그들이 하려는 목적 자체로는 틀리지 않았습니다. 이미 신뢰하고 설치한 서버를 확인하려는 경우, 도구 설명을 가져오기 위해 서버를 실행하는 것은 합리적입니다. 이는 동작을 조사하기 위해 컨테이너(container)를 실행하는 것과 다르지 않습니다. 문제는 경계 지점에서 발생합니다: 신뢰할 수 없는 설정을 스캔할 때 말입니다. 보안 스캐너의 핵심 목적은 무언가를 실행하기로 결정하기 전에 그것이 안전한지 알려주는 것입니다. 만약 스캐너가 분석을 위해 서버를 시작했는데 그 서버가 악성(malicious)이라면, 스캐너는 방금 악성 페이로드(payload)를 실행한 셈이 됩니다. mcp.json의 명령 배열은 공격자가 제어할 수 있는 콘텐츠입니다. CI/CD 파이프라인(pipelines)에서도 마찬가지입니다.

--dangerously-run-mcp-servers 플래그가 존재하는 이유는 바로 대화형 동의 프롬프트(interactive consent prompts)가 자동화(automation)를 방해하기 때문입니다. MCP 설정(configs)을 스캔해야 하는 모든 CI 작업은 동의 흐름(consent flow)을 완전히 우회해야 합니다. 데이터 유출(Data exfiltration). 도구 이름, 설명 및 일부 설정이 분석을 위해 제3자 API로 전송됩니다. 규제 환경(regulated environments)에서는 이것이 컴플라이언스(compliance) 이슈가 됩니다. 어떤 환경에서든 이는 데이터 레지던시(data residency) 문제입니다.

Bawbel이 다르게 수행하는 방식
Bawbel은 서버를 절대 시작하지 않습니다. 파일을 읽고 텍스트를 분석합니다.

pip install bawbel-scanner
bawbel scan ./my-skill.md # 파일을 읽기만 하며, 절대 실행하지 않음
bawbel ssc https://server.io # .well-known/mcp.json을 가져오기만 하며, 절대 시작하지 않음

트레이드오프(trade-off)는 실재합니다. 정적 분석(static analysis)은 런타임 전용(runtime-only) 동작을 감지할 수 없습니다. 깨끗해 보이지만 실행 중에 외부로 신호를 보내는(phones home) 서버는 Bawbel은 통과하고 Snyk은 실패할 것입니다. 두 가지 모두 동시에 사실일 수 있습니다.

정적 분석이 할 수 있는 것:

• 프로덕션(production)에 반영되기 전 스킬 파일(skill files), 서버 매니페스트(server manifests), 시스템 프롬프트(system prompts)를 스캔
• 에이전트 코드(agent code)를 실행하지 않고 CI/CD에서 실행
• 외부 API 호출이 없는 에어갭(air-gapped) 환경에서 작동
• 121개의 탐지 규칙(detection rules)을 통해 48개의 AVE 공격 클래스(attack classes)를 탐지
• GitHub Security 탭 통합을 위한 SARIF 출력 생성

어느 것을 사용할 것인가
이미 로컬에서 실행 중인 서버의 런타임 동작 분석(runtime behavioral analysis)을 원하는 경우 Snyk agent-scan을 사용하십시오. 이는 현재 설정을 감사(auditing)하는 데 적합한 도구입니다.
배포 전 스킬 파일과 서버 매니페스트를 게이트키핑(gate)하고 싶을 때, 코드를 실행하지 않고 CI/CD에서 스캔하고 싶을 때, 또는 분석을 위해 신뢰할 수 없는 코드를 실행하는 것이 허용되지 않는 환경에서 작업할 때는 Bawbel을 사용하십시오. 이들은 서로 다른 위협 표면(threat surfaces)을 다룹니다. 이 차이는 중요합니다.

더 넓은 관점
MCP 생태계는 npm이나 PyPI와 유사한 에이전트 기능의 공유 저장소인 스킬 레지스트리(skill registries)를 향해 나아가고 있습니다. 이것이 대규모로 발생할 때, 스캐너가 분석을 위해 레지스트리 패키지를 실행하는지 여부에 대한 문제는 npm 생태계가 2018년부터 답해온 질문과 동일한 문제가 됩니다.

npm은 설치 훅 (install hooks)이 악성 코드를 실행하는 공급망 공격 (supply chain attacks)을 겪은 바 있습니다. 여기서 얻은 교훈은 다음과 같습니다: 분석 단계의 일부로 신뢰할 수 없는 코드를 절대 실행하지 마십시오. 정적 분석 (Static analysis)을 먼저 수행하십시오. 동적 분석 (Dynamic analysis)은 네트워크 액세스가 없는 샌드박스화된 격리된 환경에서 수행하십시오. 그리고 항상, 명시적으로, 동의를 구해야 합니다. 관련 링크 Bawbel Scanner: github.com/bawbel/scanner Snyk agent-scan: github.com/snyk/agent-scan AVE Standard: github.com/bawbel/ave dev.to의 원문 공개글: Execute First, Ask Never