GhostApproval 대응 가이드: AI 코딩 어시스턴트 심볼릭 링크 승인 위장 점검 포인트

서론

AI 코딩 어시스턴트는 개발자가 승인한 범위 안에서 파일을 읽고 수정한다는 전제를 갖고 있다. 그러나 승인창에 보이는 경로와 운영체제가 실제로 접근하는 경로가 다르면 이 전제는 쉽게 흔들린다. GhostApproval은 바로 이 지점을 노린 심볼릭 링크 기반 승인 위장 패턴이다.

공격자는 저장소 안에 project_settings.json, .config, .devcontainer/setup.sh처럼 정상 파일로 보이는 심볼릭 링크를 둔다. 이 링크는 실제로 ~/.ssh/authorized_keys, ~/.zshrc, ~/.bashrc, AI 도구 설정 파일, 클라우드 자격 증명 파일처럼 워크스페이스 밖의 민감한 경로를 가리킨다. 개발자가 “README대로 설정해줘”, “프로젝트 설정을 정리해줘”라고 AI 에이전트에 지시하면, 에이전트는 저장소 내부 파일을 수정한다고 표시하면서 실제로는 링크가 가리키는 민감 파일을 읽거나 쓸 수 있다.

Wiz는 2026년 7월 8일 이 패턴을 공개하며 Amazon Q Developer, Claude Code, Augment, Cursor, Google Antigravity, Windsurf 등 여러 AI 코딩 도구에서 유사한 문제가 확인됐다고 설명했다. SK쉴더스도 2026년 7월 13일 국내 개발 조직 관점에서 외부 저장소와 AI 도구 사용 통제를 점검해야 한다고 강조했다. 이 이슈의 핵심은 “AI 도구 사용 금지”가 아니라 “승인창이 실제 대상 경로를 기준으로 보안 결정을 돕는가”에 있다.

본론

승인창과 실제 파일 경로가 어긋나는 구조

심볼릭 링크는 파일명과 실제 대상 경로를 분리한다. 사용자는 저장소 내부의 링크 파일을 보고 있지만, 일반적인 파일 I/O는 링크 파일 자체가 아니라 링크가 가리키는 최종 대상에 접근한다. 전통적인 소프트웨어에서도 이 특성을 놓치면 CWE-61 계열의 링크 추적 문제가 발생한다.

GhostApproval의 특징은 이 오래된 파일 시스템 문제가 AI 코딩 에이전트의 Human-in-the-Loop 승인 모델과 결합한다는 점이다. 많은 에이전트는 사용자가 승인할 수 있도록 “수정하려는 경로”를 보여준다. 하지만 그 경로가 realpath()로 해석된 최종 대상인지, 워크스페이스 밖으로 벗어나는지, 민감 경로인지까지 확인하지 않으면 승인창은 충분한 보안 정보를 제공하지 못한다.

따라서 개발자는 로컬 프로젝트 파일 수정을 승인한다고 생각하지만, 실제로는 로그인 키 등록, 셸 초기화 스크립트 변조, 도구 설정 오염, 자격 증명 노출을 승인할 수 있다. 승인 절차가 있더라도 판단에 필요한 대상 정보가 빠지면 보안 경계로 기능하기 어렵다.

공격 흐름

공격자는 먼저 악성 저장소를 준비한다. 예를 들어 project_settings.json이 ~/.ssh/authorized_keys를 가리키거나, .devcontainer/setup.sh가 ~/.zshrc를 가리키도록 구성할 수 있다. 겉으로는 프로젝트 설정 파일이나 개발 환경 스크립트처럼 보이지만 실제 대상은 개발자 홈 디렉터리의 민감 파일이다.

그다음 README, 이슈, PR 설명, 설정 파일에 에이전트가 해당 파일을 수정하도록 유도하는 문구를 넣는다. “프로젝트 초기 설정을 완료해줘”, “누락된 설정값을 project_settings.json에 추가해줘”, “개발 환경 스크립트를 업데이트해줘” 같은 지시는 정상적인 개발 작업처럼 보인다.

개발자가 이 저장소를 열고 AI 코딩 어시스턴트에 작업을 맡기면 에이전트는 파일 수정 도구를 호출한다. 승인창에는 저장소 내부의 무해한 경로가 표시될 수 있지만, 실제 읽기나 쓰기는 심볼릭 링크를 따라 워크스페이스 밖 민감 파일에서 발생한다.

피해 형태는 다양하다. authorized_keys가 변조되면 공격자 공개키가 등록되어 SSH 접근이 가능해질 수 있다. .zshrc나 .bashrc가 바뀌면 다음 터미널 실행 때 원치 않는 명령이 실행될 수 있다. AI 도구 설정이 오염되면 이후 세션에서 자동 실행, 권한 확대, 추가 지시 오염이 이어질 수 있다. 클라우드, GitHub, npm, SSH 관련 자격 증명 파일이 읽히면 개발자 권한 탈취로 이어질 수 있다.

위험이 커지는 개발 환경

영향 대상은 특정 제품 하나로 한정되지 않는다. 로컬 파일 시스템 권한을 가진 에이전트형 코딩 도구라면 같은 유형의 위험을 검토해야 한다. 특히 신뢰하지 않는 외부 저장소, PoC, 채용 과제, 오픈소스 PR, 패키지 샘플을 AI 도구로 바로 열 때 위험이 커진다.

에이전트가 파일 읽기와 쓰기, 셸 실행, 설정 변경 권한을 넓게 갖고 있거나 auto-approve, YOLO 모드, 광범위한 workspace trust가 켜져 있으면 피해 범위가 더 커진다. 개발자 장비에 SSH 서버, 원격 접속 도구, 클라우드 CLI, 배포 키, GitHub 토큰이 활성화된 경우에도 계정 탈취나 공급망 침해로 이어질 가능성이 높아진다.

컨테이너나 VM 격리 없이 개인 홈 디렉터리와 프로젝트 디렉터리를 같은 권한 경계로 다루는 환경도 취약하다. git status는 워크스페이스 안의 변경만 보여주므로, 홈 디렉터리의 민감 파일 변경은 개발자가 놓치기 쉽다.

제품별 공개 정보 기준으로 Amazon Q Developer, Cursor, Google Antigravity는 패치가 배포된 것으로 보도됐다. Amazon Q Developer는 Language Server 1.69.0, Cursor는 3.0, Google Antigravity는 1.19.6 이상 확인이 권고된다. Claude Code는 벤더가 취약점 해석을 다르게 봤으나 심볼릭 링크 경고와 해석 관련 하드닝이 언급됐다. Augment와 Windsurf는 공개 시점 기준 대응 상태 확인이 필요하다. 조직은 제품명만으로 안전하다고 판단하지 말고 실제 대상 경로 표시, 워크스페이스 외부 접근 차단, 승인 전 디스크 쓰기 금지가 구현됐는지 확인해야 한다.

개발자 점검 포인트

외부 저장소를 AI 코딩 도구로 열기 전에는 저장소 내부 심볼릭 링크를 먼저 확인한다.

find . -type l -ls
find . -type l -exec sh -c 'for p do printf "%s -> %s\n" "$p" "$(readlink "$p")"; done' sh {} +

워크스페이스 밖을 가리키는 링크도 별도로 확인한다.

find . -type l -exec sh -c 'for p do t=$(realpath -m "$p"); case "$t" in "$PWD"/*) ;; *) echo "OUTSIDE: $p -> $t";; esac; done' sh {} +

특히 .vscode, .cursor, .windsurf, .amazonq, .devcontainer, scripts, setup, postinstall, 숨김 파일 아래 링크를 우선 점검한다. AI 도구로 작업한 뒤에는 git status만 보지 말고 민감 파일의 변경 시간도 확인한다.

ls -la ~/.ssh/authorized_keys ~/.zshrc ~/.bashrc ~/.profile ~/.config 2>/dev/null
find ~ -maxdepth 3 -mmin -120 \( -name authorized_keys -o -name '.zshrc' -o -name '.bashrc' -o -name 'credentials' -o -name 'config' \) -ls 2>/dev/null

~/.ssh/authorized_keys에 모르는 키가 추가됐는지, 셸 초기화 파일에 curl|sh, base64 decode, 원격 URL, SSH 키 추가, 토큰 유출 명령이 들어갔는지 확인한다. AI 도구 설정 파일에는 자동 실행, MCP 서버, hook, allowlist, approval bypass 설정이 추가됐는지 살핀다.

조직 차원의 통제 기준

조직은 AI 코딩 도구별 최소 버전 기준을 정하고 MDM, EDR, 소프트웨어 인벤토리로 준수 여부를 확인해야 한다. 외부 저장소 분석은 가능하면 컨테이너, VM, ephemeral dev environment에서 수행하고, 홈 디렉터리 전체 접근 대신 프로젝트 디렉터리 단위 allowlist를 적용한다.

승인창에는 요청 경로와 최종 해석 경로를 모두 표시하도록 벤더 설정과 정책을 요구한다. 워크스페이스 밖 파일 쓰기는 기본 차단하고, 예외는 파일 단위로 명시 승인하게 한다. 승인 전 디스크 쓰기도 금지해야 한다. 승인창이 사전 승인 장치가 아니라 사후 되돌리기 장치로 동작하면 통제 효과는 제한적이다.

EDR과 SIEM에서는 AI 코딩 도구 프로세스가 홈 디렉터리 민감 파일에 읽기 또는 쓰기 접근하는 이벤트를 탐지한다. 프로젝트 경로 밖 파일에 대한 쓰기 이벤트를 “AI 도구 프로세스 + 민감 경로” 조건으로 룰화하고, authorized_keys, .zshrc, .bashrc, .profile, 클라우드 credential 파일 변경 후 신규 네트워크 연결이나 SSH 로그인 시도를 상관 분석한다.

도구 평가 시에는 파일 수정 전 lstat와 realpath로 심볼릭 링크 여부와 최종 경로를 확인하는지, 최종 경로가 워크스페이스 밖이면 기본 차단 또는 고위험 경고를 띄우는지, 승인 UI가 링크 파일명뿐 아니라 실제 대상 경로를 표시하는지 확인한다. auto-approve 모드에서도 외부 접근이 별도 차단되는지, 읽기 작업에도 동일한 경로 해석과 외부 접근 통제가 적용되는지, 감사 로그에 요청 경로와 최종 경로, 호출 도구, 사용자 승인 여부가 남는지도 점검 대상이다.

결론

GhostApproval은 새로운 파일 시스템 취약점이라기보다 AI 코딩 도구의 승인 모델이 기존 심볼릭 링크 위험을 충분히 반영하지 못할 때 생기는 신뢰 경계 문제다. 개발자가 보는 승인창과 운영체제가 실제로 접근하는 파일이 다르면, 사람의 승인은 형식적으로만 남는다.

개발자는 신뢰하지 않는 저장소에서 auto-approve 모드를 끄고, 심볼릭 링크와 민감 파일 변경을 작업 전후에 확인해야 한다. 조직은 AI 코딩 도구 업데이트와 격리 실행 환경, 워크스페이스 외부 접근 차단, realpath 기반 승인 UI를 기준으로 운영 정책을 정리해야 한다. AI 도구를 안전하게 쓰려면 “무엇을 승인했는가”가 아니라 “실제로 어느 파일에 접근했는가”를 기준으로 통제해야 한다.

참고자료

• Wiz, “GhostApproval: A Trust Boundary Gap in AI Coding Assistants”, 2026-07-08, https://www.wiz.io/blog/ghostapproval-a-trust-boundary-gap-in-ai-coding-assistants
• SK쉴더스 EQST Now, “GhostApproval: AI 코딩 어시스턴트 심볼릭 링크 승인 위장 결함”, 2026-07-13, https://www.skshieldus.com/security-insights/trends/eqstnow-ghostapproval-ai-coding-assistant-symlink-approval-spoofing
• The Hacker News, “GhostApproval Symlink Flaws Could Let Malicious Repos Run Code in AI Coding Agents”, 2026-07-09, https://thehackernews.com/2026/07/ghostapproval-symlink-flaws-could-let.html

본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.