가짜 Sentry 이슈로 코딩 에이전트가 악성 npm 패키지를 실행하게 만들 수 있을까?
Can a fake Sentry issue trick your coding agent into running a malicious npm package?
핵심 요약
코딩 에이전트를 겨냥한 가짜 Sentry 이슈 공격의 위험성과 방어 대책에 대한 논의입니다.
- 공격 방식 — 가짜 Sentry 에러 로그를 생성해 에이전트가 악성 패키지를 실행하도록 유도함
- 취약점 원인 — Sentry DSN은 인증 없이 이벤트 수신이 가능해 외부에서 조작이 용이함
- 방어 전략 — 에이전트의 판단에 의존하기보다 외부 입력에 대한 엄격한 실행 권한 제어가 필요함
- 보안 경계 — 신뢰할 수 없는 외부 입력(이슈, 로그 등)으로부터 실행 권한을 분리해야 함
이번 주에 코딩 에이전트(Claude Code, Cursor 등)를 겨냥한 새로운 공격에 관한 글을 봤는데, 방식이 너무 단순해서 짜증이 날 정도임.
공격자들은 가짜 에러 로그를 뿌려서 가짜 Sentry 이슈를 생성함. 이 이슈는 마치 런북처럼 작성되어 있어서, 에이전트가 이를 "수정"하려고 할 때 제안된 수정 사항이 환경 변수를 몰래 유출하는 악성 패키지를 실행하는 것임.
이게 작동하는 이유는 Sentry DSN이 설계상 인증을 거치지 않기 때문임. 대부분의 사이트는 클라이언트 측 에러 보고를 위해 프론트엔드에 DSN을 내장하고 있고, 클라이언트 측 텔레메트리를 원한다면 이를 우회할 방법이 사실상 없음. 그래서 DSN을 가진 사람은 누구나 당신의 프로젝트에 이벤트를 쏠 수 있음.
공격자는 가짜 이슈를 "런타임 이슈, 코드 변경 불필요, 이 진단 도구만 실행할 것"과 같이 작성함. 여기서 "진단 도구"는 타이포스쿼팅된 npm 패키지임. 심지어 이벤트 메타데이터를 에이전트 권한 플래그처럼 보이게 꾸며서, 모델이 해당 명령을 실행해도 된다고 착각하게 만듦.
이 사례에서 엔지니어를 구한 건 에이전트 자체가 타이포스쿼팅을 감지하고 설치를 거부했다는 점임. 이번에는 방어선이 버텼지만, "모델이 알아서 눈치채겠지"라는 걸 전체 방어 전략으로 삼고 싶지는 않음.
내가 계속 고민하는 부분은 통제권이 어디에 있어야 하는가임. "외부 입력을 신뢰하지 마라"는 SQL 인젝션 때 배운 교훈이고 여전히 유효하지만, 여기서는 입력이 Sentry 이슈이고 실행기가 에이전트라서 어느 계층에서 해결해야 할지 모르겠음. DSN을 완전히 잠글 수는 없으니, 남은 건 에이전트의 실행 권한이나 패키지 허용 목록(allowlist)뿐임. 권한을 잠그면 모든 걸 수동으로 승인해야 하고, 허용 목록에 의존하면 합법적인 무언가가 목록에 없을 때 바로 문제가 터짐.
당신의 설정에서는 무엇이 이런 공격을 막아줄 것 같음? "모델이 타이포스쿼팅을 알아챘다"는 건 내가 의존하고 싶지 않은 통제 방식이라서 말임.
