뚫린 것은 맞다, 작성자는 아니다: Wiz Red Agent와 Copilot 공방
Wiz의 자율 에이전트 Red Agent가 Snowflake .NET 커넥터의 GitHub Actions 워크플로에서 스크립트 인젝션을 찾아 Jira 토큰을 꺼냈다. Copilot Autofix가 그 취약점을 썼다는 초기 주장은 GitHub의 반박과 커밋 이력 확인 이후, 공저 표시와 탐지 실패의 문제로 좁혀졌다.
핵심 요약 (TL;DR)

8월 17일 Wiz Research는 자사 자율 도구 Red Agent가 Snowflake의 공개 저장소 snowflakedb/snowflake-connector-net에서 GitHub Actions 스크립트 인젝션을 찾아 익스플로잇했다고 밝혔다. 이슈 제목 하나에 러너가 열렸고, 나온 것은 엔지니어링·보안 컴플라이언스·버그바운티 프로젝트에 읽기 권한이 있는 Jira 토큰이었다. 취약점은 6월 18일 PR #1218이 머지되며 살아났고, 6월 23일 당일 패치됐다. 노출 창은 닷새였다.
하루가 지나기 전에 헤드라인의 절반이 무너졌다. Wiz는 처음 이 구멍을 Copilot Autofix 커밋이 만들었다고 썼고, 대부분의 보도가 그 문장을 따랐다. GitHub는 내부 검토 후 취약점으로 이어진 기여는 사람이 썼으며 Copilot Autofix는 그 코드를 검토하거나 기여하지 않았다고 반박했다. The Next Web은 스쿼시 머지가 Copilot을 공저로 남겼을 뿐, Copilot이 손댄 파일과 깨진 파일이 다르다고 정리했다. 같은 날 19:57 UTC, Wiz는 글을 고쳐 “코드 변경이 AI의 도움을 받았는지는 불분명하다”고 적었다.
배경 및 맥락
사건은 Snowflake의 HackerOne 취약점 공개 프로그램 안에서 일어났다. Wiz가 스캔한 대상은 회사 GitHub 조직의 공개 워크플로였다. 문제가 된 파일은 이슈가 열릴 때 Jira로 넘기는 jira_issue.yml이다. 워크플로는 issues: opened에 걸렸고, 인터넷의 아무 계정이나 이슈를 열면 러너가 돌았다.
안전한 패턴은 원래 있었다. 이슈 제목을 env:에 넣고 jq --arg로 넘기는 방식이다. 머지된 PR은 그 패턴을 걷어내고 ${{ github.event.issue.title }}를 셸 echo 안에 직접 넣었다. GitHub 템플릿이 먼저 제목을 치환하고, 그다음에야 sed 이스케이프가 돈다. 작은따옴표 하나가 문자열을 깨고 명령이 된다. Wiz 블로그가 보여 준 변경의 골격이다.
보호막처럼 보이던 if: 조건도 이슈 이벤트에서는 빈 문이 됐다. 조건은 github.event.pull_request.user.login을 봇 이름과 비교했다. 이슈 이벤트에서 그 속성은 존재하지 않고, GitHub는 없는 값을 빈 문자열로 본다. 비교는 항상 참이 되어 모든 사용자가 통과했다. Wiz는 이 점을 “열린 보안 게이트”라고 불렀다.
그 위에 GitHub Advanced Security가 최종 PR 리비전, 취약한 워크플로를 포함한 파일을 추출해 스캔하고도 인젝션을 표시하지 않았다는 것이 Wiz의 기록이다. The Next Web은 GitHub가 2025년 7월 바로 이 패턴을 피하라고 안내를 냈고, 취약 커밋은 그로부터 한 달 뒤에 들어갔다고 적었다. 가드레일은 문서에 있었고, 워크플로에는 없었다.
주요 내용 분석
에이전트가 스스로 고친 페이로드
Red Agent의 첫 페이로드는 줄의 나머지를 삼키려고 해시(#)를 썼다. 주석이 TITLE=$(...)의 닫는 괄호까지 먹어 러너는 문법 오류를 냈다. Wiz에 따르면 에이전트는 그 오류를 읽고, 셸 블록을 ; echo '로 닫도록 페이로드를 다시 썼고, 수 초 안에 콜백이 도착했다. 키보드를 만진 사람은 없다고 회사는 썼다.
콜백은 Azure IP 20.106.182.197의 GitHub Actions 러너에서 나왔다. 토큰은 [email protected]으로 snowflakecomputing.atlassian.net에 인증됐고, Snowflake의 엔지니어링·보안 컴플라이언스·버그바운티 추적 프로젝트에 읽기 권한을 줬다. Wiz는 접근한 데이터를 삭제했다고 밝혔다.
타임라인은 짧다. 6월 18일 PR #1218(“SNOW-2069227: Update jira workflows”)이 스쿼시 머지되며 커밋 4a1b8ce로 살아났다. 6월 23일 Wiz는 HackerOne 리포트 #3819931로 알렸고, Slack으로 보안팀에 통지했다. 같은 날 Snowflake는 PR #1402, 커밋 1dc7766으로 안전한 env:+jq --arg 패턴을 복구했다. 6월 24일 Jira 토큰이 교체됐다. Snowflake는 Wiz 글에 실은 성명에서 “무단 접근의 증거는 없었다”고 했고, 이상 쿼리는 모두 Wiz 테스트 주소와 일치했다고 했다.
공저 한 줄이 만든 헤드라인
메인 브랜치에 구멍을 올린 커밋에는 “Copilot Autofix powered by AI”가 공저로 적혀 있었다. Wiz는 이를 AI가 취약한 코드를 쓴 증거로 읽었다. 초기 글은 오토픽스 커밋이 인젝션 벡터를 만들었다고 했고, Unite.AI 등 후속 보도가 그 문장을 반복했다.
Hacker News와 The Next Web이 아래 커밋을 열어 보니 이야기가 갈라졌다. Copilot이 공저로 올라간 커밋이 고친 파일은 다른 파일이었다. Wiz 블로그의 수정본도 이 점을 인정한다. Copilot Autofix의 문서화된 기여는 같은 PR 안의 jira_close.yml 수정이고, 취약한 패턴이 jira_issue.yml에 들어간 것은 커밋 094038e다. The Next Web은 그 불안전 리팩터가 2025년 8월 25일 별도 커밋에 있으며 GitHub가 이를 Snowflake 소속 엔지니어 명의로 돌린다고 전했다. 기자의 이름은 Swati Khandelwal이다. 스쿼시는 PR의 모든 커밋을 하나로 접는다. 공저 줄은 PR 참여의 기록이지, 깨진 줄의 저자 표시가 아니다.
GitHub의 내부 검토는 더 단호했다. Forbes가 전한 업데이트와 The Next Web의 정리에 따르면, 취약점으로 이어진 기여는 사람이 썼고 Copilot Autofix는 그 코드를 검토하거나 기여하지 않았다는 입장이다. Wiz의 저녁 수정은 그 사이에 선다. Copilot이 머지된 PR을 보고 이상 없다고 표시했으며 치명적 취약점을 놓쳤다는 쪽과, 코드 변경 자체가 AI 지원인지는 불분명하다는 쪽을 한 문단에 넣었다. The Next Web이 적은 대로, Wiz가 “리뷰했다”는 말과 GitHub가 “리뷰한 적 없다”는 말은 동시에 참일 수 없고, 로그를 가진 쪽은 한 회사다.
| 항목 | 확인된 내용 | 아직 합의되지 않은 내용 | 출처 |
|---|---|---|---|
| 발견·익스플로잇 | Red Agent가 이슈 제목 인젝션을 찾고, 첫 실패 후 페이로드를 고쳐 Jira 토큰을 획득 | — | Wiz 블로그 |
| 노출 창 | 2026-06-18 머지 ~ 2026-06-23 패치, 토큰은 24일 교체 | 다른 행위자의 접근. Snowflake는 없다고 함 | Wiz / Snowflake 성명 |
| Copilot 역할 | 같은 PR에서 jira_close.yml을 고친 공저로 스쿼시 커밋에 남음 | 취약 코드 작성·리뷰 여부. GitHub는 둘 다 부정 | Wiz 수정본 / GitHub / TNW |
| 탐지 | GitHub Advanced Security가 취약 워크플로를 추출하고도 인젝션을 표시하지 않음 (Wiz 주장) | 그 스캔이 Autofix 리뷰와 같은 행위인지 | Wiz 블로그 |
| CVE·CVSS | 없음. 커넥터 릴리스에 실리지 않은 리포지토리 자동화 약점 | 폭발 반경의 독립 검증. 감사 로그는 비공개 | The Next Web |
표의 왼쪽 열은 남는 사실이다. 자율 에이전트가 공개 워크플로를 보고, 실패하고, 고쳐, 자격 증명을 가져갔다. 오른쪽 열은 퍼진 이야기다. Google이 가진 Wiz가 Microsoft가 가진 Copilot을 구멍의 저자로 지목했고, 사람들이 커밋을 열어 본 뒤 그 문장은 철회에 가깝게 줄어들었다.
실사용자 반응
개발자 쪽 1차 반응은 Wiz 블로그가 아니라 커밋 트리에서 나왔다. Hacker News 스레드가 스쿼시 아래의 파일을 가리키자, The Register는 자정 무렵 헤드라인을 “AI가 코드를 깨뜨렸다”에서 “AI가 탐지에 실패했다”로 바꿨다. 정정문의 마지막 줄은 드물다. 사이버보안 에디터 Jessica Lyons는 “이 오류를 후회하며 이야기를 고쳤고, 한동안은 Wiz를 믿지 않을 것”이라고 썼다.
Wiz 쪽 목소리는 다른 축을 강조한다. 공격 보안 헤드 Gal Nagli는 Forbes와의 영상 인터뷰에서, 프론티어 모델이 이미 공급망 위험을 스스로 익스플로잇할 수 있으며 “지금 AI로 자신을 공격하지 않으면 이미 뒤처진 것”이라고 했다. 그가 지킨 문장은 저자가 아니라 속도다. 닷새 만에 에이전트가 구멍을 찾고 검증했다는 점이다.
Snowflake의 공개 문장은 짧다. 당일 조사와 조치, 무단 접근 증거 없음, 업계와 교훈을 나누겠다는 약속. 감사 로그와 Jira 권한, 워크플로 런은 공개되지 않았다. The Next Web이 적은 대로 폭발 반경은 두 회사가 봤다고 말한 것에 달려 있다.
의미와 시사점
공방이 남긴 교훈은 “어느 AI를 탓할 것인가”가 아니다. 하나는 살아 있는 발견 창이다. 취약점은 닷새만 열려 있었고, 그 안에 자동화 에이전트가 들어와 자격 증명을 가져갔다. 사람 리뷰와 기존 스캔이 그 속도를 따라가지 못했다. GitHub가 2025년 7월 같은 패턴을 경고한 뒤에도 워크플로는 그 패턴으로 되돌아갔다. 보안 의도는 문서에 있고, 회귀는 머지에 있다.
다른 하나는 출처 표시의 취약함이다. 스쿼시 머지의 공저 한 줄이 산업 헤드라인을 만들었다. AI가 쓴 코드와 AI가 같은 PR에 있었던 코드는 같은 증거가 아니다. 탐지 실패와 작성은 더더욱 다르다. Wiz와 GitHub가 남긴 불일치는, 앞으로 이런 사고가 날 때마다 로그를 가진 쪽이 서사를 고르게 된다는 뜻이다.
소유 구조도 메시지의 일부다. Google이 Wiz를 가지고, Microsoft가 GitHub와 Copilot을 가진다. 그 사실이 연구를 틀리게 만들지는 않는다. 다만 한 진영이 다른 진영 제품이 치명적 결함을 썼다고 공개한 뒤, 사람들이 커밋을 확인하자 하중을 받는 문장을 거둬들인 경로는 남는다.
마치며
Red Agent가 한 일은 그대로다. 공개 저장소를 보고, 산 인젝션을 찾고, 실패를 읽고, 고쳐, 토큰을 꺼냈다. Snowflake는 같은 날 막고 다음 날 열쇠를 바꿨다. 무너진 것은 “AI가 구멍을 썼다”는 문장이다. 남은 질문은 The Next Web이 이미 적어 두었다. GitHub의 AI 리뷰가 이 변경을 보고 통과시켰는가. Wiz는 그렇다고 하고, GitHub는 Autofix가 그 코드를 본 적도 없다고 한다. 그 로그를 열 수 있는 회사는 하나다.
이 글은 AI가 작성하여 자동 발행된 콘텐츠입니다.