보안업체 Wiz는 8월 17일 공개한 연구에서 자사의 자율 공격 보안 에이전트가 공개 snowflakedb/snowflake-connector-net 저장소에 속한 GitHub Actions 워크플로에서 스크립트 주입 취약점을 찾아 악용했으며, 이를 통해 Snowflake 내부 Jira에 대한 읽기 권한을 부여하는 토큰을 탈취했다고 밝혔습니다.
타임라인은 이례적으로 짧았습니다
취약점은 PR #1218이 병합된 2026년 6월 18일에 공개됐습니다. Wiz는 이를 찾아 악용한 뒤 6월 23일 HackerOne을 통해 보고했으며, Snowflake는 같은 날 1dc7766 커밋으로 패치했습니다. Jira 토큰은 6월 24일 회전됐습니다. 노출 기간은 5일이었습니다. 이 토큰은 Snowflake의 Atlassian 테넌트에서 qa@snowflake.net으로 인증됐고, 엔지니어링·보안 준수·버그 바운티 추적 프로젝트 전반에 대한 읽기 권한을 부여했습니다.
흔한 해석이 놓치는 점
이 사안은 "AI가 버그를 쓰고 다른 AI가 이를 악용했다"는 식으로 퍼지고 있습니다. 하지만 그 대칭성은 누구도 책임질 수 없는 부분입니다. 기자들에게 전해진 GitHub의 입장은 취약점에 이르게 한 기여는 사람이 작성한 것이며, Copilot이 이를 검토하지도 않았고 기여하지도 않았다는 것입니다. Wiz의 글에도 업데이트가 덧붙어 해당 코드 변경이 AI의 도움을 받았는지는 불분명하다고 인정했으며, 해당 풀 리퀘스트에서 Copilot Autofix가 문서상 기여한 것은 다른 파일에 대한 별도의 수정이었다고 적었습니다. 따라서 작성자 주장에는 공급업체의 이의 제기와 연구자의 유보가 붙어 있지만, 바로 그 주장이 보도의 중심에 서 있습니다.
이견이 없는 결과가 더 심각합니다
누구도 다투지 않는 사실은 따로 있습니다. 자율 에이전트가 정찰, 주입 가능한 워크플로 발견, 악용, 자격 증명 탈취, 별도 SaaS 시스템으로의 측면 이동까지 전체 킬 체인을 외부 도움 없이 완성했다는 점입니다. 대상은 대형 데이터 플랫폼 공급업체였습니다. 그리고 누가 버그를 작성했든, GitHub의 자체 스캐닝은 병합 전에 이를 잡아내지 못했습니다. 이는 방어 커버리지에 대한 발견이며, 작성자 논쟁과는 전혀 무관합니다.
무엇이 도달했고, 무엇은 아니었나
세 번째 왜곡도 짚을 필요가 있습니다. 이번 사안은 공개 커넥터 저장소의 CI 워크플로였고, 확보된 접근 권한은 Jira 프로젝트에 대한 읽기 권한이었습니다. Snowflake 데이터 플랫폼이 아니었고, 고객 데이터도 아니었습니다. Snowflake는 조사 결과 연구자들 외의 무단 접근 증거는 발견되지 않았으며, 감사 로그상 Wiz가 해당 엔드포인트에서 유일한 제3자였다고 밝혔습니다. "Snowflake가 침해됐다"와 "Actions 러너를 통해 Jira를 읽었다"는 같은 문장이 아닙니다.