AI 보안 에이전트가 Snowflake를 해킹했다. Copilot 이야기는 잡음이었다

6월에 AI 에이전트가 Snowflake의 내부 Jira에 침입했다. 그런데 거의 모든 보도가 앞세운 부분은 틀린 부분이었다. 처음 이야기는 GitHub Copilot이 취약한 코드를 작성했다는 것이었다. AI가 AI를 오염시킨다는 깔끔한 우화였다. 그 버전은 몇 시간밖에 가지 못했다. Wiz는 같은 날 자체 공개 내용을 수정했고 GitHub는 그 귀속을 단호하게 부인했다. 수정 후에도 남는 이야기는 오히려 더 이상하고 더 유용하다. 자율 에이전트가 실제 취약점을 찾고, 익스플로잇을 작성하고, 실패한 페이로드를 스스로 디버깅하고, 작동하는 자격 증명까지 빼냈다. 처음부터 끝까지다. 같은 코드를 본 기존 스캐너는 아무것도 찾지 못했다. 시간을 들여 읽을 가치가 있는 이야기는 이쪽이다.

핵심 요점 - Wiz의 자율 공격 보안 에이전트 Red Agent는 Snowflake의 공개 snowflake-connector-net 저장소에 있는 GitHub Actions 워크플로에서 스크립트 인젝션을 발견하고 Jira 토큰을 탈취하는 데 악용했다. 발견부터 자격 증명 유출까지 사람이 키보드에 손대지 않았다. - 취약점은 2026년 6월 18일 라이브 상태가 됐고 6월 23일 발견, 악용, 보고까지 이루어졌다. 모두 Snowflake의 HackerOne 프로그램 범위 안이었다. Snowflake는 같은 날 패치했고 감사 로그상 노출 기간에 Wiz 외 행위자는 없었다. - Copilot이 버그를 작성했다는 초기 주장은 몇 시간 만에 철회됐다. 취약한 패턴은 사람이 작성한 변경에 있었고 Copilot Autofix의 문서화된 기여는 다른 파일이었다. 공동 작성자 표시는 스쿼시 병합 과정에서 생긴 흔적이었다. - GitHub Advanced Security는 정확히 그 취약한 리비전을 스캔했지만 놓쳤다. 패턴 매칭형 스캐너와 에이전트가 같은 코드를 봤고, 코드의 의미를 이해한 쪽은 하나뿐이었다. - 진짜 에이전트형 행동은 좁지만 분명했다. 실패한 익스플로잇을 진단하고 다시 작성한 부분이다. 나머지는 언어 모델이 들어간 좋은 자동화였다.

무슨 일이 있었나

타임라인은 Wiz 공개 글과 이에 대한 Snowflake의 대응을 기준으로 정리했다.

• 2026년 6월 18일. PR #1218이 Snowflake의 공개 .NET 커넥터 저장소 snowflakedb/snowflake-connector-net에 병합된다. 누군가 GitHub 이슈를 열면 Jira 티켓을 자동 생성하는 jira_issue.yml 워크플로를 다시 작성한 변경이다. 이 수정은 안전한 패턴, 즉 이슈 제목을 환경 변수로 넘기고 jq --arg로 처리하던 방식을 제목을 셸 run: 블록에 직접 보간하는 방식으로 바꿨다.

• 6월 23일. Snowflake의 HackerOne 버그 바운티 프로그램 아래에서 GitHub 조직을 스캔하던 Wiz의 자율 보안 연구 에이전트 Red Agent가 워크플로를 인젝션 가능하다고 표시한다. 익스플로잇을 만들고 실행했지만 자체 페이로드에서 셸 문법 오류가 난다. 오류를 진단하고 페이로드를 다시 작성해 두 번째 시도에 성공한다. Azure에서 호스팅된 GitHub Actions 러너가 서비스 계정에 연결된 Jira API 토큰을 base64로 인코딩해 Wiz 리스너로 콜백한다. Wiz는 같은 날 HackerOne을 통해 보고한다.

• 6월 23일, 같은 날. Snowflake가 워크플로를 패치하고 안전한 패턴으로 되돌린다.

• 6월 24일. Jira 토큰을 폐기하고 교체한다. Snowflake 감사 로그 검토에서는 5일의 노출 기간 동안 Wiz 외 접근이 발견되지 않았다. Wiz는 개념증명 과정에서 가져온 데이터를 삭제했다고 말한다.

• 8월 17일. Wiz Research의 threat exposure 책임자 Gal Nagli가 분석 글을 공개한다. 같은 날 19:57 UTC에 업데이트해 Copilot은 병합된 PR을 확인하고 통과시킨 공동 작성자로 표시됐을 뿐이며, 취약한 변경에 AI 지원이 있었는지는 불분명하다고 정정한다.

토큰은 Snowflake 내부 Jira의 엔지니어링, 보안 규정 준수, 버그 바운티 프로그램에 대한 읽기 접근 권한을 갖고 있었다. 고객 데이터는 건드리지 않았고 배포된 커넥터도 영향받지 않았다.

2026년 6월 23일 Wiz의 자율 Red Agent는 Snowflake의 snowflake-connector-net 저장소에 있는 GitHub Actions 워크플로에서 스크립트 인젝션을 찾아 악용했다. 취약점이 라이브 상태가 된 지 5일 만에 사람 개입 없이 내부 엔지니어링, 보안 규정 준수, 버그 바운티 프로젝트를 읽을 수 있는 Jira 토큰을 유출했다. Wiz Research 공개 글에 따른 내용이다. Snowflake는 같은 날 패치했고 감사 로그에서 제3자 접근을 찾지 못했다.

권한 사슬을 한 고리씩 따라가기

이 익스플로잇은 CI 파이프라인이 얼마나 많은 신뢰를 조용히 들고 있는지 잘 보여준다. 조작된 이슈 제목 하나가 어디까지 갈 수 있었는지 따라가 보자.

1. 트리거. 워크플로는 issues: opened에서 실행됐다. 지구상의 어떤 GitHub 계정이든 이슈 하나를 열면 실행시킬 수 있다는 뜻이다. 접근을 제한하려던 조건 검사는 이슈 열기 이벤트에서 항상 참으로 평가됐다고 기술 보도는 설명한다.

2. 인젝션. 새 코드는 TITLE=$(echo '${{ github.event.issue.title }}' | sed ...)를 실행했다. GitHub는 셸이 실행되기 전에 ${{ }} 템플릿을 확장하므로 sed 이스케이프는 너무 늦게 도착한다. 제목 안의 작은따옴표 하나가 문자열을 닫고 제목의 나머지가 셸 명령으로 실행된다.

3. 환경. 명령은 이제 GitHub Actions 러너 안에서 실행된다. 러너는 설계상 자격 증명이 가득한 기계다. 이 러너에는 서비스 계정용 Jira API 토큰이 있었다. Jira 티켓을 만드는 것이 워크플로의 본래 작업이었기 때문이다.

4. 유출. 페이로드는 토큰을 base64로 인코딩하고 대역 외 콜백으로 Wiz의 리스너에 보냈다. 워크플로 로그에는 의심스러운 내용이 남지 않았다.

5. 보상. 토큰으로 Snowflake 내부 Atlassian 환경에 인증할 수 있었고 엔지니어링, 보안 규정 준수, 버그 바운티 프로젝트를 읽을 수 있었다.

이 사슬의 모든 고리는 평범하고 승인된 지루한 인프라다. 공개 저장소, 자기 일을 하는 워크플로, 필요한 권한을 가진 서비스 계정이다. 취약점은 어느 한 설정 오류가 아니라 이들의 조합이었다. 워크플로의 영향 범위는 러너가 도달할 수 있는 모든 것이고, 러너는 보통 그것을 만든 팀이 기억하는 것보다 더 많은 곳에 도달할 수 있다. 고객이 에이전트 거버넌스를 물을 때 내가 하는 말과 같다. 질문은 에이전트가 무엇이냐가 아니라 에이전트가 무엇을 건드릴 수 있느냐다.

익스플로잇은 정당한 신뢰 다섯 층을 연결했다. 인증되지 않은 GitHub 이슈가 워크플로를 실행하고, 작은따옴표 인젝션이 셸 문자열을 탈출하고, 러너 환경에 Jira 서비스 계정 토큰이 있었고, 대역 외 콜백이 토큰을 유출했으며, 그 토큰이 Snowflake 내부 Jira 읽기 접근을 열었다. GitHub 템플릿 확장은 셸 이스케이프보다 먼저 실행되므로 정제 처리가 너무 늦었다. Wiz 분석에 따른 내용이다.

무엇이 에이전트형이었고 무엇이 아니었나

정확히 구분하고 싶다. “AI 에이전트가 Snowflake를 해킹했다”는 제목은 두 가지 게으른 해석을 부른다. 그냥 마케팅이 더 좋은 스캐너였다는 해석과 Skynet이 풀려났다는 해석이다. 세부사항을 보면 둘 다 성립하지 않는다.

모델이 들어간 평범한 자동화. 스캔과 플래깅이다. Red Agent의 CI/CD 기능은 GitHub 조직을 훑으며 신뢰할 수 없는 입력을 run: 블록에 보간하는 워크플로 파일을 찾는다. 잘 알려진 취약점 유형이고 알아볼 수 있는 모양이 있다. jira_issue.yml을 표시하는 것은 좋은 정적 규칙도 그럴듯하게 해낼 수 있는 일이다. 대상을 고르고 워크플로를 읽고 악용 가능하다고 판단하는 것은 숙련된 작업이지만 Wiz가 이미 지속적 공격 표면 관리 제품으로 파는 것과 크게 멀지 않다.

진짜 에이전트형. 익스플로잇 루프다. 에이전트의 첫 페이로드는 주석 문자를 사용했는데 셸 문법을 깨뜨려 실패했다. 에이전트는 발생한 bash 오류를 읽고 페이로드가 왜 잘못됐는지 파악하고, 스크립트를 제대로 닫도록 다시 작성해 두 번째 시도에 성공했다. 이후 훔친 토큰이 Snowflake Jira에서 실제로 작동하는지 확인하고 토큰이 어디까지 도달할 수 있는지도 평가했다. 새로운 런타임 실패를 자신의 공격에서 진단하고 누구의 프롬프트도 없이 적응하는 것은 시그니처 매칭이 아니다. 시도하고, 관찰하고, 수정하는 이 루프가 스캐너와 에이전트를 가르는 요소다. 내가 에이전트형 아키텍처에서 일반적으로 다뤄온 바로 그 루프다. Fortune 500 대상을 상대로, 사람 감독 없이, 공격적으로 작동한 것은 기록해둘 만한 첫 사례다.

에이전트가 전혀 아닌 부분. 범위, 윤리, 공개다. Red Agent는 Snowflake의 HackerOne 프로그램 안에서 작동했다. Wiz의 사람이 선택하고 승인한 샌드박스였다. 자율성은 실제였지만 경계 안에 있었고, 승인됐고, 모니터링됐다. 방어자에게 내가 강조하고 싶은 지점도 바로 이것이다. Wiz는 3월에 Red Agent를 출시했고 7월 말 정식 제공으로 전환했다. 일부는 Anthropic의 Claude Opus를 기반으로 만들어졌다. 이제 어떤 보안팀이든 이 기능을 제품으로 빌릴 수 있다. 이런 공격형 루프는 곧 매우 흔해질 것이다.

Red Agent의 스캔과 분류는 모델이 들어간 자동화에 가까웠다. 에이전트형 핵심은 익스플로잇 루프였다. 첫 페이로드가 셸 문법 오류를 내자 에이전트는 bash 실패를 진단하고 페이로드를 다시 작성해 두 번째 시도에 성공한 뒤 토큰을 검증하고 영향 범위를 파악했다. 모두 사람의 도움 없이 이루어졌다. Wiz 공개 글에 따른 내용이다.

Copilot 작성자 표시는 가장 덜 흥미로운 부분이다

첫 헤드라인들은 Copilot이 버그를 썼다고 말했다. 기록은 그렇지 않다. PR #1218에서 Copilot Autofix가 문서상 기여한 것은 다른 파일인 jira_close.yml에 대한 별도 수정이었다. 취약한 보간 코드는 이름이 있는 Snowflake 엔지니어의 커밋에 있었고, GitHub는 내부 검토 결과 Copilot Autofix가 해당 줄을 작성하지도 검토하지도 않았다고 기자들에게 말했다. 병합된 PR의 “Copilot 공동 작성” 표시는 스쿼시 병합 과정에서 트레일러를 끌고 들어가 생긴 흔적이었다. Wiz는 같은 날 글을 수정했고 The Register도 기사를 정정했다. Wiz CTO Ami Luttwak이 CSO에 한 말이 정직한 결론이다. 모든 PR에서 여러 에이전트가 작동하는 시대에는 “PR의 공동 작성자만 보는 것으로는” 누가 무엇을 썼는지 알 수 없다.

두 가지는 동시에 참일 수 있다. Copilot Autofix를 사용하는 GitHub Advanced Security는 취약한 워크플로를 포함한 해당 PR의 최종 리비전을 스캔했지만 인젝션을 표시하지 않았다. Wiz의 설명에 있는 사실이고 GitHub도 부인하지 않았다. 동시에 Copilot이 취약점을 작성했다는 구체적인 주장은 근거가 없다. AI 지원 검토가 자신이 문제없다고 통과시킨 코드에서 심각한 버그를 놓쳤다는 것은 AI 리뷰의 한계에 관한 실제 이야기다. 다만 AI가 버그를 썼다는 이야기는 아니다. 둘을 섞으면 자신의 PR에서 AI 검토를 얼마나 신뢰할지 결정하는 사람에게 아무 도움도 되지 않는다.

Wiz는 처음에 Copilot이 취약한 코드 작성에 관여한 것처럼 표현했지만 같은 날 Copilot Autofix의 문서화된 기여는 같은 PR의 다른 파일이었고 공동 작성자 표시는 스쿼시 병합 흔적이었다고 정정했다. GitHub는 사람이 잘못된 리팩터링을 작성했고 Copilot은 해당 코드를 검토하지 않았다고 말한다. 논쟁이 없는 사실은 GitHub Advanced Security가 취약한 리비전을 스캔하고도 아무것도 표시하지 않았다는 점이다. Wiz의 업데이트된 글과 CSO 보도에 따른 내용이다.

지금 무엇을 해야 하나

비밀 정보를 담은 GitHub Actions를 운영한다면 이번 주에 다음을 하자.

1. 워크플로에서 run: 블록 안의 ${{ github.event.* }}를 grep하라. 이슈 제목, PR 제목, 브랜치 이름, 댓글 본문을 셸에 직접 보간하면 모두 인젝션 가능하다. 예외 없다. 값을 env: 변수로 옮기고 올바르게 인용해 전달하거나 jq --arg로 파싱하라. Snowflake가 복구한 패턴이 이것이다.

2. 러너를 자격 증명 저장소라고 가정하라. 워크플로 토큰을 최소 범위로 줄이고, 장기 서비스 계정 토큰보다 단기 OIDC 자격 증명을 선호하며, 신뢰할 수 없는 이벤트(issues, pull_request_target, 댓글)로 시작되는 모든 워크플로를 인터넷에 노출된 코드로 취급하라.

3. AI 리뷰를 마지막 방어선으로 두지 마라. GitHub 자체 스캐너가 정확히 이 코드를 보고도 통과시켰다. 검사를 여러 층으로 두고, 검토, 작성, 스캔을 모두 한 벤더의 모델에 맡긴 워크플로는 특히 의심하라.

4. 5일의 창도 느리다고 생각하라. 에이전트는 이 저장소에 대해 아무것도 모르는 상태에서 1주일도 되지 않아 실제 자격 증명에 도달했다. 공개 및 대응 절차가 공격자의 체류 시간을 몇 달로 가정한다면 가정을 바꿔라. Snowflake처럼 같은 날 실행할 수 있는 자격 증명 교체 런북을 준비하라.

자주 묻는 질문

GitHub Copilot이 Snowflake 취약점을 작성했나?

현재 증거로는 아니다. Copilot Autofix는 병합된 PR의 공동 작성자로 표시됐지만 문서화된 변경은 다른 파일이었고, 표시는 스쿼시 병합 과정에서 생긴 흔적이었다. GitHub는 사람이 취약한 코드를 작성했다고 말한다. 사실인 것은 GitHub Advanced Security가 취약한 리비전을 스캔하고도 인젝션을 놓쳤다는 점이다.

Wiz 에이전트는 어떻게 Snowflake Jira에 들어갔나?

이슈 제목을 셸 스크립트에 직접 보간하는 워크플로를 발견했다. 조작한 제목으로 이슈를 열면 러너에서 임의 명령이 실행됐고, 러너에는 Jira 서비스 계정 토큰이 있었다. 에이전트는 대역 외 콜백으로 토큰을 유출하고 내부 Jira 프로젝트를 읽는 데 사용했다. Snowflake는 보고 당일 워크플로를 패치했고 다음 날 토큰을 교체했다.

실제 공격이었나?

승인된 공격이었다. Red Agent는 Snowflake의 HackerOne 버그 바운티 프로그램 범위에서 작동했고 Wiz는 즉시 공개했으며 Snowflake 감사 로그는 취약점이 살아 있던 5일 동안 Wiz만 접근했다는 것을 확인했다. 고객 데이터는 접근되지 않았다. 하지만 승인되지 않은 에이전트도 동일한 기법을 쓸 수 있다는 것이 핵심이다.

AI 보안 에이전트에 어떤 의미가 있나?

공격형이 방어형보다 앞서 있다는 뜻이다. 자율 에이전트는 실제 취약점이 배포된 지 며칠 만에 찾아내고, 악용하고, 범위까지 파악했지만 같은 코드를 본 자동 스캐너는 아무것도 찾지 못했다. 방어팀은 에이전트 속도의 발견을 새로운 기본값으로 보고 인터넷에서 트리거할 수 있는 것은 그 속도로 탐색될 것이라고 가정해야 한다.

결론

Copilot 소동을 걷어내면 두 가지 사실이 남는다. 비싸고 전통적인 보안 스캐너가 이 코드를 검토하고 통과시켰다. 자율 에이전트는 같은 코드를 읽고 무기화할 만큼 이해했으며, 그 과정에서 자기 실수도 스스로 고쳤다. “병합”부터 “기계에 의해 악용”까지 5일이라는 간격이 보안팀이 바라봐야 할 숫자다. 공격형 에이전트는 이제 연구 데모가 아니라 제품이고 주말도 쉬지 않는다. Copilot 작성자 표시는 다음 달이면 잊힐 것이다. 이 능력은 잊히지 않는다.

자신의 파이프라인 안에서 공격형이든 방어형이든 에이전트에 어느 정도 자율성을 줄지 고민하고 있다면, 나는 이런 주제를 고객과 정기적으로 논의한다. 연락해 달라.

출처

• Wiz Research(Gal Nagli), “Wiz Red Agent, GitHub Copilot 지원 PR의 결함을 통해 Snowflake 내부 Jira에 진입”: https://www.wiz.io/blog/red-agent-snowflake-copilot-cicd-bug (2026년 8월 17일 게시, 2026년 8월 17일 19:57 UTC 업데이트, 2026년 8월 29일 확인)

• Wiz, “Wiz Red Agent 소개: AI 기반 공격자”: https://www.wiz.io/blog/introducing-the-wiz-red-agent (2026년 3월 23일 게시, 2026년 8월 29일 확인)

• Cybersecurity News, “AI 에이전트, Snowflake GitHub 워크플로 해킹”: https://cybersecuritynews.com/ai-agent-hacks-snowflake-github-workflow/ (2026년 8월 20일 게시, 2026년 8월 29일 확인)

• CSO Online, “AI 검사를 통과한 Snowflake 결함, 다른 AI에 의해 악용”: https://www.csoonline.com/article/4211501/snowflake-flaw-slips-past-ai-checks-gets-exploited-by-another-ai.html (2026년 8월 19일 게시, 2026년 8월 29일 확인)

• Infosecurity Magazine, “Wiz AI 에이전트, Snowflake GitHub 저장소의 치명적 결함 발견”: https://www.infosecurity-magazine.com/news/wiz-ai-agent-finds-snowflake/ (2026년 8월 18일 게시, 2026년 8월 29일 확인)

• daily.dev(The Next Web 제공), “GitHub, Copilot Autofix가 Snowflake 결함을 작성했다는 Wiz 주장 반박”: https://daily.dev/posts/github-disputes-wiz-s-claim-that-copilot-autofix-wrote-a-snowflake-flaw-ybruxnh95 (2026년 8월 18일 게시, 2026년 8월 29일 확인)

• snowflakedb/snowflake-connector-net 저장소: https://github.com/snowflakedb/snowflake-connector-net (2026년 8월 29일 확인)