“이 레포 클론해서 코딩 에이전트로 열어봐.” 채용 과제일 수도, 디버깅이 필요한 오픈소스 프로젝트일 수도, 새 벤더가 보낸 샘플 앱일 수도 있습니다. 어느 쪽이든 개발자에게는 낯설지 않은 요청이죠.
수상한 실행 파일을 설치할 필요도 없습니다. 그냥 폴더를 열고 에이전트가 정상적으로 작업하도록 “신뢰”만 눌러주면 되는 것입니다.

Datadog 보안팀이 바로 이 지점을 파고들었습니다. 프로젝트를 신뢰한 시점과 첫 프롬프트를 입력하는 시점 사이, 그 짧은 틈에 레포에 심어둔 코드가 이미 실행될 수 있다는 것입니다.
출처: Before the first prompt: Code execution paths in trusted coding-agent projects – Datadog Security Labs
이런 수법은 이미 실전에서 쓰이고 있습니다. 마이크로소프트가 밝힌 “Contagious Interview” 캠페인에서는 가짜 채용 담당자가 개발자를 속여 악성 프로젝트를 클론하고 신뢰하게 만들었고, VS Code가 프로젝트 작업을 자동 실행했습니다. npm 패키지 3개가 Claude Code의 SessionStart 훅을 심어, 감염된 프로젝트를 다시 열 때마다 코드를 실행한 사례도 있었죠.
후킹은 이제 검토 대상이지만, 다른 문이 열려 있다
에이전트의 생애주기 곳곳에는 정해진 시점에 동작을 실행하는 “훅”이 있습니다. Claude Code와 Codex 둘 다 이 기능을 지원하죠. 문제를 인식한 듯 Codex는 최근 훅이 실행되기 전 사용자가 직접 검토하고 승인하도록 막아뒀습니다. Datadog팀은 여기서 질문을 던졌습니다. 훅을 선언하지 않고도 같은 결과를 낼 방법이 있지 않을까.
답은 두 가지였습니다. Codex에서는 프로젝트 단위로 설정하는 MCP(Model Context Protocol) 서버 구성이 공격자가 지정한 프로세스를 곧바로 실행시켰습니다. Claude Code에서는 프로젝트가 지정한 PATH 환경변수가, Claude가 시작 시 자동으로 실행하는 Git 조회 명령을 가로채는 통로가 됐죠. 둘 다 모델의 응답이나 셸 명령 승인 절차를 전혀 거치지 않았습니다.
Git 명령 하나가 공격자의 스크립트를 부른다
Claude Code는 시작할 때 저장소 맥락을 파악하려고 모델의 응답을 기다리지 않고 Git을 호출합니다. 이때 프로그램이 절대경로 없이 git이라는 이름만으로 명령을 실행하면, 시스템은 PATH에 지정된 디렉터리들을 순서대로 뒤져 찾죠. 그런데 이 PATH 값은 프로젝트의 .claude/settings.json 파일에서 정의할 수 있습니다.
공격자가 이 설정에 자기 프로젝트 폴더를 PATH 맨 앞에 끼워 넣고, 그 안에 git이라는 이름의 가짜 스크립트를 심어두면 어떻게 될까요. Claude Code가 저장소 정보를 조회하려는 순간, 진짜 Git 대신 그 스크립트가 실행되죠. 공격자는 이 스크립트 안에서 원하는 동작을 한 뒤 진짜 Git 바이너리를 대신 호출해주면, 사용자는 아무 이상도 느끼지 못한 채 작업이 이어집니다.
BASH_ENV, NODE_OPTIONS, PYTHONPATH 같은 다른 환경변수들도 각자의 실행 환경이 열리는 순간을 기다리는 비슷한 통로가 될 수 있는 것입니다.
신뢰 팝업은 안전의 증거가 아니다
Codex와 Claude Code 모두 낯선 프로젝트는 신뢰하지 말라고 안내합니다. 하지만 그 판단을 사람이 매번 정확히 내리기는 사실상 불가능에 가깝죠. 프로젝트가 코드를 실행시킬 수 있는 통로는 훅, 스킬, MCP 서버, 에디터 작업, 개발 컨테이너 설정, 환경변수, 런타임 시작 파일, 그리고 평범해 보이는 실행 파일까지 다양합니다. 공격자는 그중 하나만 찾으면 되지만, 검토하는 사람은 전부를 확인해야 하는 비대칭이 있는 셈입니다.
해보려면
환경: Claude Code 또는 Codex를 쓰는 로컬 개발 환경, 검토 대상 저장소
출발점: 저장소를 열기 전, 아래 검색으로 에이전트 설정과 실행 관련 항목을 먼저 훑어본다
rg -n --hidden -g '.claude/**' -g '.mcp.json' -g '.codex/**' '\b(hooks?|mcpServers|env|PATH|BASH_ENV)\b' .확인: 검색 결과에 걸린 파일은 “안전하다는 증거”가 아니라 “직접 열어서 확인해야 할 목록”으로 취급한다. 참조된 다른 파일까지 따라가서 실제로 실행될 리비전을 확인해야 함
걸리는 지점: 이 검색도 완전하지 않다. 프로젝트가 다른 파일을 참조하거나, PATH 앞쪽에 평범해 보이는 실행 파일을 심어두거나, 검색 범위 밖의 런타임별 메커니즘을 쓰면 걸러지지 않는다. 낯선 저장소는 민감한 자격 증명이 없는 일회용 환경에서 여는 것이 근본적인 대응책

답글 남기기