AI '오토픽스'가 심은 취약점, AI 보안 에이전트가 5일 만에 뚫다

소프트웨어 개발에 AI 코딩 도구가 깊숙이 들어오면서, 취약점이 만들어지는 방식과 발견되는 방식이 동시에 바뀌고 있다. 클라우드 보안 업체 Wiz의 리서치팀은 자사의 자율형 AI 보안 도구인 'Red Agent'를 통해 Snowflake의 공개 저장소에서 심각한 GitHub Actions 워크플로 취약점을 찾아냈다. 이 조사는 Snowflake가 HackerOne을 통해 운영하는 취약점 공개 프로그램의 일환으로 이뤄졌고, 흥미롭게도 문제의 취약점은 AI가 관여한 코드 변경에서 비롯됐으며 이를 발견한 주체 역시 AI 에이전트였다.

안전 패턴을 걷어낸 '자동 수정'

문제가 된 저장소는 snowflakedb/snowflake-connector-net이고, 취약점은 jira_issue.yml 워크플로에 존재했다. 이 워크플로는 이슈가 열릴 때(issues: opened) 실행되도록 설정돼 있어, 사실상 아무 GitHub 사용자나 이슈를 하나 만들면 트리거할 수 있었다. 원래 이 저장소는 이슈 제목을 env 변수로 전달한 뒤 jq로 JSON 페이로드를 구성하는 안전한 방식을 쓰고 있었다. 그런데 2026년 6월 18일 병합된 PR #1218(커밋 4a1b8ce, 'SNOW-2069227: Update jira workflows')이 이 구조화된 파싱 패턴을 걷어내고, 공격자가 통제할 수 있는 이슈 제목을 ${{ github.event.issue.title }} 형태로 셸 스크립트에 직접 문자열 삽입하도록 바꿔버렸다.

주목할 점은 이 스쿼시 커밋이 'Copilot Autofix powered by AI'를 공동 작성자로 명시하고 있다는 것이다. Wiz의 8월 17일 업데이트에 따르면 Copilot은 병합된 PR과 코드 변경을 확인하는 공동 작성자로 참여해 '이상 없음'으로 판정했으나, 정작 결과물에 생긴 심각한 취약점은 잡아내지 못했다. 코드 변경 자체가 AI가 작성한 것인지는 명확하지 않지만, AI 보조 보안 검토가 취약점을 그대로 통과시켰다는 사실은 분명하다.

형식적으로만 존재했던 방어 조건

워크플로에는 얼핏 보호 장치처럼 보이는 if 조건이 있었다. 그러나 issues 이벤트에서는 github.event.pull_request 값이 항상 null이기 때문에, 조건은 결국 (null != 'whitesource-for-github-com[bot]')로 축소된다. 이는 언제나 참이 되므로 모든 사용자가 게이트를 통과했다. 또한 제목에 대한 sed 이스케이프 처리는 GitHub의 템플릿 확장 이후에 실행되어, 제목에 작은따옴표 하나만 넣어도 echo '...' 문자열을 벗어나 임의 명령을 실행할 수 있었다.

Red Agent는 실제 공격 과정에서 자율적 문제 해결 능력을 드러냈다. 처음에는 주석 문자(#)로 나머지 줄을 무력화하려 했는데, 이 문자가 TITLE=$(...)의 닫는 괄호까지 삼키면서 bash가 예기치 않은 EOF 오류를 냈다. 에이전트는 여기서 멈추지 않고 실행 오류를 스스로 분석한 뒤, 페이로드를 '; echo '' 형태로 바꿔 셸 구문을 올바르게 닫았다. 수정된 페이로드는 즉시 성공했고, Azure IP(20.106.182.197)의 GitHub Actions 러너에서 base64로 인코딩된 Jira 자격증명이 out-of-band 콜백으로 수 초 만에 회신됐다.

유출된 토큰은 qa@snowflake.net으로 snowflakecomputing.atlassian.net에 인증됐으며, Snowflake의 엔지니어링, 보안 컴플라이언스, 버그 바운티 추적 프로젝트 전반에 대한 읽기 권한을 부여했다. Wiz는 2026년 6월 23일 HackerOne(리포트 #3819931)을 통해 이를 책임 공개했고, Snowflake는 같은 날 워크플로를 패치(커밋 1dc7766, PR #1402)해 env 변수와 jq --arg 기반의 안전한 파싱 패턴을 복원했다. 해당 Jira 토큰은 폐기 후 교체됐고, 감사 로그 분석 결과 5일간의 노출 기간 동안 Wiz의 테스트 IP 외 외부 접근은 없었던 것으로 확인됐다. Wiz는 PoC 과정에서 접근한 데이터를 모두 안전하게 삭제했다고 밝혔다.

실무자가 가져갈 세 가지

이 사건은 한국 개발·보안 실무자에게 몇 가지 구체적인 시사점을 준다. 첫째, AI 코딩 도구는 확률적 패턴을 기반으로 코드를 예측하기 때문에, 과거에 폐기됐거나 안전하지 않은 셸 패턴을 무심코 되살릴 수 있다. AI가 만든 PR도 사람이 작성한 코드와 동일한 정적 분석과 보안 검토를 거쳐야 하며, 'AI가 확인했다'는 사실이 안전을 보장하지 않는다. 둘째, 취약점이 실제로 존재한 기간은 단 5일이었고 그 안에 자동화된 에이전트가 발견·검증·악용까지 마쳤다. 발견 창은 시간 단위로 좁아지고 있으므로, 신속한 패치 주기와 단기 수명(short-lived) 자격증명이 방어의 기본 전제가 되어야 한다.

셋째, AI 어시스턴트는 특정 코드 패턴이 왜 그렇게 작성됐는지에 대한 역사적 맥락을 갖지 못하는 경우가 많다. 이번 사례에서 제거된 env 변수와 jq 파싱 방식은 애초에 셸 인젝션을 막기 위해 의도적으로 도입된 것이었는데, 자동화된 PR이 그 의도를 모른 채 이를 직접 문자열 보간으로 되돌렸다. 결국 방어의 핵심은 개별 취약점 하나를 잡는 것이 아니라, AI 에이전트가 구조화된 데이터 파서를 문자열 보간으로 대체하지 못하도록 막는 가드레일을 파이프라인에 심는 데 있다. GitHub Actions에서 신뢰할 수 없는 입력을 run 블록에 직접 넣지 않는 것은 오래된 원칙이지만, 코드 작성 주체가 사람에서 AI로 넘어가는 지금 이 원칙을 강제하는 자동화된 검증 장치의 중요성은 오히려 커지고 있다.