AI 코딩 공급망 보안 — 출처 증명이 코드 검토를 대신할 수 없는 이유

1. 핵심 요약

소프트웨어 공급망은 외부 패키지·소스 저장소·빌드 도구를 거쳐 제품이 만들어지고 배포되는 경로입니다. AI 코딩 도구도 이 경로에서 패키지를 선택하고 설정을 읽으며 명령을 실행합니다. 기존 공급망에 모델의 판단과 도구 실행이 추가된 셈입니다.

사건의 근거는 GTIG의 관측 보고서입니다. 아래 체크리스트는 npm·SLSA·GitHub 문서와 사건을 대조한 편집부의 제안이며, 방어 효과를 직접 측정한 실험 결과는 아닙니다.

2. 구글이 관측한 것과 추정한 것

GTIG는 금전적 이익을 노리는 공격 그룹 UNC6780(TeamPCP)과 이 그룹의 자격증명 탈취 악성코드 DUSTMAKER를 다룹니다. 자격증명은 계정이나 서비스에 접근하는 토큰·키 같은 인증 정보입니다. 보고서는 악성코드에서 확인한 기능과 공격자의 의도를 추정한 부분을 함께 싣고 있으므로, 둘을 구분해 읽어야 합니다. [1]

MCP(Model Context Protocol)는 AI 앱이 외부 도구와 데이터를 연결할 때 사용하는 프로토콜입니다. 이 사건에서 다루는 것은 그 연결에 쓰이는 소프트웨어의 배포 경로입니다. MCP라는 규격 자체의 결함으로 치환해서 읽으면 조사 범위가 달라집니다.

GTIG는 AI 코딩이 개발 속도를 높이면서 외부 의존성 검토가 줄었을 가능성을 제기합니다. 그러나 이 보고서만으로 AI 도입이 사고율을 얼마나 높였는지 계산할 수는 없습니다. 비교 집단과 노출 규모를 둔 인과 실험이 아니라, 위협 추적과 사고 대응에서 확보한 관측입니다.

3. 출처 증명이 보장하는 범위

출처 증명(provenance)은 소프트웨어를 누가 어떤 입력과 절차로 빌드했는지 기록한 정보입니다. 증명문(attestation)은 이런 정보를 전달하는 진술이며, 여기에 붙은 서명은 진위 확인에 쓰입니다. SLSA는 소프트웨어 공급망의 보안 보장 수준을 정의하는 명세입니다. SLSA의 Build L3는 빌드 간 격리와 서명용 비밀 정보 보호 등 강화된 빌드 환경을 요구합니다. 서명 하나가 있다는 이유만으로 이 요구를 모두 충족했다고 판정할 수는 없습니다. [2]

npm의 신뢰된 게시(trusted publishing)는 등록해 둔 CI/CD 워크플로가 패키지를 게시하도록 인증하는 방식입니다. CI/CD는 코드 검사·빌드·배포를 자동화한 절차이고, 워크플로는 그 실행 단계를 정의한 파일입니다. OIDC(OpenID Connect)를 이용해 실행 환경의 신원을 확인하므로 장기간 보관하는 게시용 토큰을 줄일 수 있습니다. npm은 GitHub Actions에서 조직·저장소·워크플로 파일을 등록하도록 안내합니다. [3]

GTIG 표 1은 DUSTMAKER가 GitHub Actions 실행 환경의 OIDC 토큰을 악용해 악성 패키지를 게시하는 기능을 갖췄다고 설명합니다. GTIG는 이 패키지에 유효한 서명이 붙은 SLSA Build L3 증명문이 함께 제공된다고 기술합니다(보고서 표기: SLSA Build 3). 이는 GTIG의 기술 설명을 인용한 것입니다. 공개 보고서에는 해당 빌드 환경의 구성과 SLSA 요구사항을 독립적으로 재검증할 자료가 충분히 제시돼 있지 않습니다. [1]

SLSA FAQ는 Build 수준이 개별 빌드의 신뢰성을 다루며, 간접 의존성까지 같은 수준을 요구하지 않는다고 명시합니다. 간접 의존성은 내가 설치한 패키지가 다시 불러오는 패키지입니다. 따라서 한 패키지의 Build 수준을 전체 의존성의 보안 판정으로 확장할 수 없습니다. [4]

운영에서는 예상한 저장소·커밋·빌드 절차와 출처 증명이 맞는지 확인한 다음, 의존성 변경과 실행 동작을 별도로 검토해야 합니다. 신뢰된 게시를 장기 토큰 방식으로 되돌리는 것이 해법은 아닙니다. npm도 신뢰된 게시를 우선하고, 불필요한 기존 게시 토큰을 제거하며, 배포 환경의 검토 절차를 적용하도록 권고합니다. [3]

4. 작업 공간 설정도 실행 경로입니다

GTIG는 DUSTMAKER가 .claude/, .vscode/, .cursor/ 같은 프로젝트 설정 폴더에 파일을 만들거나 수정한다고 보고합니다. 이런 파일은 시작 작업이나 빌드 명령을 자동으로 실행하게 하거나 AI 도구의 동작을 바꾸는 데 쓰일 수 있습니다. 프로젝트에 익숙한 폴더 이름이라는 이유로 변경 검토에서 제외하면, 애플리케이션 소스 밖의 실행 경로를 놓칠 수 있습니다. [1]

프롬프트 인젝션은 외부 문서나 코드에 섞인 지시문이 AI의 실제 작업 지시처럼 처리되도록 유도하는 공격입니다. 설정을 읽고 모델이 명령을 실행하는 경우와, 편집기의 시작 설정이 직접 명령을 실행하는 경우는 구분해야 합니다. 모델을 거치는 경우에는 지시문 처리와 도구 권한이 관여합니다. 편집기 설정이 직접 명령을 실행하는 경우에는 해당 프로그램의 실행 설정과 권한을 확인해야 합니다.

GitHub 공식 문서는 외부 액션을 전체 커밋 SHA로 고정하고 소스를 검토하라고 권고합니다. SHA는 특정 커밋을 식별하는 값입니다. 고정은 나중에 태그가 가리키는 코드가 바뀌는 위험을 줄이지만, 처음 고른 커밋이 안전한지는 따로 확인해야 합니다. 워크플로 파일에는 코드 소유자 검토를 적용하고, 토큰 권한은 기본적으로 읽기 권한만 부여한 뒤 필요한 작업에 한해 추가하라고 안내합니다. [5]

5. 분석 중단은 안전 판정이 아닙니다

GTIG이 발견한 악성코드 주석에는 AI 보안 분석 도구가 안전 정책을 이유로 분석을 거부하게 만들려는 것으로 추정되는 지시문이 들어 있습니다. 공격자는 분석 결과를 바꾸려 할 수도 있지만, 분석 자체가 끝나지 않게 만들려 할 수도 있습니다. 여기서 중요한 관측은 그런 지시문이 악성코드에 포함됐다는 사실이며, 실제 우회 성공률은 보고서에 없습니다. [1]

이 글의 제안은 검사 실행 상태와 보안 판정을 분리하는 것입니다. 아래 표는 특정 제품의 기능 설명이 아니라, 검사 결과를 배포 절차에 연결할 때 사용할 수 있는 상태 설계입니다.

예를 들어 “AI 분석이 오류를 반환했으니 경고가 없는 것으로 처리”하는 배포 조건은 미검사 코드를 통과시킬 수 있습니다. 이는 설명을 위한 가상 예시입니다. 미완료 상태를 기록하고 보완 검사나 검토를 요구하면 이런 논리 오류를 줄일 수 있습니다. 다만 다른 분석기가 같은 공격을 확실히 잡는다는 보장은 없으며, 이를 이유로 분석 도구의 안전장치를 해제할 필요도 없습니다.

대상 파일 목록과 실제 검사 완료 파일 목록을 함께 남겨야 부분 누락도 보입니다. AI의 요약 한 문장에 의존하지 않고 실행 상태·검사 범위·발견 사항을 따로 수집하는 것이 운영상 확인할 지점입니다.

6. 오늘 적용할 체크리스트

아래 항목은 기존 도구를 모두 교체하라는 제안이 아닙니다. 현재의 의존성 도입과 게시 절차에 확인 단계를 배치하는 목록입니다. GitHub·npm의 직접 권고와 편집부의 적용 제안을 구분했습니다.

• 작업 공간 설정을 변경 검토에 포함합니다. 숨김 폴더의 신규 실행 설정을 확인하고, 코드 검토에서 누락되지 않게 합니다. GTIG 사례에서 도출한 편집부 제안입니다.
• 외부 액션을 검토한 전체 커밋 SHA로 고정합니다. 액션 소스를 검토하고 보안 업데이트도 계속 반영합니다. 고정 자체가 코드의 무해함을 보장하지는 않습니다. GitHub 권고입니다. [5]
• 테스트에 필요 없는 게시 권한을 주지 않습니다. 기본 토큰 권한을 최소화하고 필요한 작업에만 높입니다. 외부의 미검토 코드를 특권 워크플로에서 실행하지 않습니다. GitHub 권고입니다. [5]
• 신뢰된 게시의 등록 정보를 점검합니다. 허용한 저장소와 워크플로가 현재 절차와 맞는지 확인하고, 불필요한 게시 토큰을 제거합니다. npm 권고입니다. [3]
• 출처 확인과 의존성 검토를 따로 남깁니다. 출처가 예상과 일치해도 신규 패키지와 설치·실행 동작을 검토합니다. SLSA의 보장 범위를 반영한 편집부 제안입니다.
• 검사 미완료가 배포 통과로 처리되는지 확인합니다. 무해한 테스트 파일로 시간 초과·분석 오류·일부 파일 누락을 모의해 결과 상태를 확인합니다. 악성코드 없이도 점검할 수 있는 편집부 제안입니다.

에이전트 실행 격리와 승인 방식의 세부는 에이전트 샌드박스 리포트에서 다룹니다. 이 글은 외부 코드가 개발·게시·검사 절차로 들어오는 경로에 초점을 맞췄습니다.

7. 아직 결론이 아닌 것

• GTIG의 관측을 독립 재현하지 않았습니다. 사건과 악성코드 기능은 2026년 9월 9일 구글 보고서에 귀속합니다. 이즐러가 피해 환경이나 악성코드를 직접 분석한 결과가 아닙니다.
• AI 도입의 사고율 증가분은 계산할 수 없습니다. 보고서의 위험 해석에는 추정이 포함되며, AI 사용 여부에 따른 비교 실험이나 전체 노출 건수가 제공되지 않습니다.
• 보안 분석 방해의 성공률은 확인되지 않습니다. 악성 지시문이 있었다는 사실과 그 목적에 대한 추정만으로 특정 AI 제품을 보편적으로 우회할 수 있다고 결론 내리지는 않습니다.
• GTIG이 기술한 SLSA Build L3 사례의 적합성을 직접 판정하지 않습니다. 빌드 구성과 검증 기록이 충분히 공개되지 않아 명세 요구를 모두 대조할 수 없습니다. 게시 인증·서명·Build 수준을 동일시하지 않습니다.
• 권고의 방어 효과를 수치화하지 않았습니다. 최소 권한·변경 검토·미완료 처리에도 구현과 운영의 한계가 있습니다. 출처 증명은 계속 필요한 검증 수단이며 전체 코드 안전성 판정을 대신하지 않습니다.
• 현재 감염 패키지 목록을 제공하는 글이 아닙니다. 보고서에 등장한 프로젝트 이름만으로 현재 버전의 안전 여부를 판정할 수 없습니다. 이 글은 도입·실행·게시·검사 절차를 점검하는 자료입니다.

8. 참고자료

사건 설명은 GTIG에, 제품 동작은 각 공식 문서에 귀속했습니다. 표와 체크리스트의 운영 제안은 이 자료들을 대조한 편집부의 해석입니다. 원문의 악성 지시문과 공격 실행 절차는 전재하지 않았습니다.