AI 에이전트 기반 공급망 보안은 예전에는 비교적 간단했습니다. 패키지 이름과 제품 사이에 항상 사람이 개입했기 때문입니다. 20년 동안 이것이 바로 모델의 핵심이었습니다. 누군가가 제품 이름을 확인한 후에 공급망에 들어가는 것이죠. 물론 항상 꼼꼼하게 확인한 것은 아니지만, 어쨌든 누군가는 확인했습니다.
이제는 그런 시대는 끝났습니다. 오늘날 AI 모델에게 라이브러리를 요청하면 추천 패키지 5개 중 1개는 실제로 존재하지 않습니다. 공격자들은 이 사실을 알고 있기 때문에 먼저 존재하지 않는 패키지 이름을 등록합니다. 에이전트는 해당 패키지를 설치하고 테스트한 후 다음 단계로 넘어가며, 그 사이에 어떤 작업도 진행되지 않습니다. 바로 이것이 현재 AI 에이전트 공급망 보안이 실패하고 있는 지점입니다. 미래의 시나리오가 아니라, 바로 지금 이 순간에도 실패하고 있는 것입니다. pipeline오늘 운영 중입니다.
업계는 20년 동안 개발자가 코드를 읽고 검토하고 결정하는 과정을 중심으로 통제 시스템을 구축해 왔습니다. 하지만 이제 더 이상 개발자는 종속성이 빌드에 포함되기 전 마지막 검토자가 아닙니다. 따라서 진정한 문제는 에이전트형 AI가 새로운 위험을 초래하는지 여부가 아니라, 인간의 검토 단계가 사라진 후 실제로 무엇이 남게 되는가입니다.
“AI 제안”에서 “AI 실행”으로
2년 전만 해도 부조종사가 코드 블록을 제안하면 개발자가 읽어보고 유지할지 여부를 결정했습니다. 하지만 이제 그런 워크플로는 거의 사라졌습니다. Agentic 도구가 이제 종속성을 설치하고, 컨테이너를 실행하고, 트리거를 작동시킵니다. pipeline 그들은 자체적으로 조치를 취하며, 대개 문제가 발생한 후에야 보고합니다.
이러한 변화는 단계적으로 이루어졌으며, 대부분의 팀은 문서화된 보안 정책에서 인정하는 것보다 더 앞서 나가고 있습니다. 초기 에이전트 기반 도구는 모든 변경 전에 승인을 요청했고, 개발자들은 "예"를 너무 자주 클릭하여 확인 단계 자체가 의미를 잃었습니다. 오늘날의 에이전트는 대부분 승인을 요청하지 않습니다. 셸 스크립트 실행과 같이 민감한 작업으로 표시된 경우에만 작업을 중단합니다. pull request 에이전트가 생성한 코드는 수천 줄에 달할 수 있으며, 사람이 직접 처음부터 끝까지 읽지 않고 병합하는 경우는 거의 없습니다.
권한 문제는 이러한 상황을 더욱 악화시킵니다. 대부분의 설정에서 에이전트는 개발자 권한으로 실행되며, 개발자 컴퓨터에서 접근할 수 있는 모든 것(환경 변수, 클라우드 토큰, 레지스트리 자격 증명, SSH 키 등)에 접근할 수 있습니다. 에이전트가 무언가를 설치하고 그 과정에서 스크립트가 실행되면, 에이전트는 자신이 사칭하는 사람의 모든 권한을 그대로 물려받게 됩니다. 바로 이 지점에서 AI 에이전트 공급망 보안은 정책 문제가 아니라 권한 문제로 귀결됩니다. 에이전트는 새로운 취약점을 찾아낼 필요 없이, 이미 가지고 있는 접근 권한만 있으면 되는 것입니다.
부두 선장 모하마드-알리 아라비같은 패널에서 발언한 사람은 이를 명확하게 밝혔습니다. "개발자도 이제 공격 대상의 일부라고 생각합니다."
이것이 대체한 것이 무엇인지 솔직하게 이야기할 필요가 있습니다. 사람이 읽는 것 말입니다. package.json 차이점 비교는 이미 취약한 통제 수단이었습니다. 실제로 변경 사항을 승인하기 전에 모든 전이적 종속성을 검증하는 사람은 거의 없었습니다. 에이전트들이 강력한 시스템을 무너뜨린 것은 아닙니다. 그들은 취약한 시스템에 대한 마지막 변명거리를 없앴을 뿐입니다. 달라진 것은 위험 자체가 새로워진 것이 아니라, 그 속도가 완전히 달라졌다는 점입니다. 일부 추산에 따르면 작년 공급망 공격 건수는 전년 대비 약 5배에 달했으며, 증가 추세는 선형이 아닌 기하급수적일 것으로 보입니다.
설치 순간: 아무도 보지 않을 때 달라지는 점
환각 악성 패키지 이름은 새로운 것이 아닙니다. 오타 스쿼팅 수년간 사람의 타이핑 오류를 악용해 왔습니다. 글자 하나만 잘못 입력해도 개발자는 잘못된 파일을 설치하게 되죠. 하지만 지금 달라진 점은 사람이 아니라 모델이 애초에 이름을 만들어내고, 그것도 예측 가능하게 만들어낸다는 것입니다.
이 수치들은 이것이 단순한 호기심이 아니라 사업임을 보여줍니다. 오픈소스 모델이 추천하는 패키지 중 약 20%는 실제로 존재하지 않으며(상용 모델의 경우 5%에 가까움), 연구 대상이 된 가상의 이름들 중 43%는 10번의 반복 검색에서 동일하게 나타났습니다. 이러한 반복성 때문에 공격 패턴은 쉽게 복제될 수 있습니다. 공격자는 개발자가 어떤 이름을 입력할지 추측할 필요가 없습니다. 모델이 개발자에게 정확한 정보를 무료로 제공하기 때문입니다.
HalluSquatting이라는 새로운 변종은 더욱 공격적인 방식을 취합니다. 공격자는 악성 패키지를 가상의 이름으로 게시하는 대신, README 파일, 스킬 파일 또는 MCP 서버 설명 파일 안에 악성 명령어를 심어놓고, 에이전트가 동일한 저장소 또는 도구 이름을 가상으로 인식하여 이를 다운로드할 때까지 기다립니다. 최근 발표된 논문에서는 이 변종을 프롬프트 인젝션과 결합하여 새로운 프로젝트에 대한 가짜 저장소 이름을 거의 완벽하게 예측하고, Cursor, Windsurf, Copilot과 같은 실제 코딩 도우미 도구에서 전체 코드 실행을 성공시켰다고 보고했습니다. 페이로드가 실행 가능한 코드가 아닌 일반 텍스트이기 때문에 대부분의 스캔 도구는 이를 탐지하지 못합니다.
자이제니처럼 연구 책임자 루이스 로드리게스 토론 중에 언급하세요: "우리는 악성 코드에 대한 방어 체계를 구축하는 데 수년간 공을 들였습니다. 시그니처, 샌드박스, 행동 분석 같은 것들이죠. 하지만 HalluSquatting은 그런 게 전혀 필요 없습니다. 그저 설득력 있는 README 파일만 있으면 됩니다." 에이전트가 신뢰할 수 있는 컨텍스트로 인식하는 평문 지침은 실행 파일을 탐지하도록 설계된 스캐너를 그대로 통과합니다.
대부분의 애플리케이션 보안 도구가 아직 파악하지 못한 계층이 바로 그 사전 단계입니다.cisXygeni의 이유는 바로 이것입니다. 악성코드 조기경보(MEW) 이러한 접근 방식은 플랫폼 수준에서 존재합니다. npm, PyPI, Maven과 같은 레지스트리에 새로 게시된 패키지를 지속적으로 실시간으로 분석하여 공개 서명이 생기기 전에 악의적인 행위를 포착하도록 설계되었으며, 며칠 후에 CVE가 발표될 때까지 기다리지 않아도 됩니다.
컨테이너, CI/CD그리고 출처: 빌드에 포함된 구성 요소를 여전히 증명할 수 있습니까?
에이전트는 단순히 회선을 추가하는 데 그치지 않고, 거의 항상 정확한 답변을 합니다. package.jsonDockerfile을 편집하고, 다단계 빌드를 재구성하며, 기타 작업을 수행합니다. pipeline 소스 트리뿐만 아니라 빌드 시스템 자체에 직접 접근하여 구성을 설정합니다.
바로 이 지점에서 업계가 공급망 위험에 대한 해답을 제시합니다. SBOMs와 SLSA provenance원래는 유지되어야 했던 것이었습니다. 그런데 2026년 5월, 공격자가 관리자를 피싱 공격하여 탈취한 토큰을 이용해 "고아"를 게시했습니다. commit 프로젝트 이력에 부모 프로젝트가 없는 이 악성코드를 이용해 빌드 캐시를 오염시켰습니다. 그 결과 생성된 84개의 패키지는 모두 유효하고 제대로 서명된 최상위 출처 정보를 가지고 배포되었습니다. 모든 자동화된 검사를 통과했습니다. 악성코드는 실재했고, 기술적으로는 악성코드 제작 과정을 증명하는 서류도 모두 진짜였습니다.
불편한 진실은 다음과 같습니다. 출처는 빌드가 주어진 것을 어떻게 사용했는지를 증명할 뿐, 주어진 것이 신뢰할 만한 것이었는지를 증명하는 것은 아닙니다. 아티팩트가 생성되기 전에 입력값을 오염시키면, 그 증명은 부정직한 빌드에 대한 정직하고 검증 가능한 기록이 됩니다. AI 에이전트 공급망 보안은 모델이 아닌 인간이 빌드에 포함될 내용을 결정하는 세상을 위해 만들어진 증명 도구에 전적으로 맡길 수 없습니다.
실질적인 완화책 중 하나는 화려하진 않지만 효과적인 방법입니다. 바로 새로운 패키지 버전이 출시된 후 며칠간 기다렸다가 도입하는 유예 기간을 두는 것입니다. 대부분의 공급망 관련 사고는 이 초기 기간 내에 발견되어 공개되므로, 5일간의 유예 기간을 두었다면 작년에 발생한 사고의 상당 부분을 예방할 수 있었을 것입니다. 웜 스타일 공격즉, 즉시 발생하는 비용 외에는 전혀 비용이 들지 않습니다.iacy.
Git, 리뷰, 그리고 점점 작아지는 인간 검토자
코드 검토 및 commit 역사는 오랫동안 "누군가가 이 문제를 검토했다"는 믿음의 기준점 역할을 해왔습니다. 하지만 에이전트들이 개입하면 그 기준점은 더욱 흔들립니다. commit그리고 이러한 시스템들은 점점 더 인간의 개입 없이, 그 순간에는 아무런 변화 없이 통합되고 있습니다.
에이전트가 패키지를 설치하는 것과 개발자가 스택 오버플로우 답변을 복사하는 것은 비록 둘 다 원본 코드를 작성하지 않는다는 공통점이 있지만, 신뢰 측면에서 동일한 문제는 아닙니다. 스택 오버플로우의 코드 조각은 실제 사람이 작성했고, 추천과 비추천을 통해 비공식적인 동료 평가를 거쳤습니다. 반면 AI가 생성한 추천은 확률적인 출력물이며, 이러한 속성이 없습니다. 개발자가 직접 복사할 경우에도 패키지 이름, 최종 업데이트 날짜, 미해결 문제 등을 확인하게 됩니다. 하지만 에이전트가 패키지를 설치하는 경우에는 특별히 일시 중지되도록 설계되지 않는 한 이러한 정보를 고려하지 않습니다.
이것이 바로 시프트 레프트의 진짜 문제점입니다. 전통적인 시프트 레프트 방식은 가장 빠르게 변화하는 것을 전제로 합니다. pipeline 개발자는 훈련, 지원, 검토를 통해 역량을 향상시킬 수 있습니다. 하지만 가장 빠르게 변화하는 것이 자율 에이전트라면, 보안은 에이전트가 우회할 수 없는 체크포인트, 즉 샌드박싱, 접근 제어, 쿨다운 시간 등을 기반으로 재구축되어야 하며, 아무도 강제하지 않는 정책 문서에 의존해서는 안 됩니다.
AI 에이전트 기반 공급망 보안: 안전한 에이전트란 무엇인가? Pipeline 실제로 필요한 것은
이 새로운 유형의 웜 바이러스에서 살아남기 위해 첫날부터 9가지의 서로 다른 제어 방식을 완벽하게 구현할 필요는 없습니다. 자원이 제한된 팀에게는 나머지 두 가지보다 더 중요한 두 가지가 있습니다.
- 에이전트를 항상 샌드박스 환경에서 실행하세요. 현재 프로젝트 디렉터리만 마운트된 마이크로VM 또는 컨테이너에서 실행하세요. 이렇게 하면 에이전트가 손상되더라도 호스트의 토큰, 자격 증명 또는 파일에 접근할 수 없습니다. 이는 가장 저렴한 보안 조치이며, 건너뛸 이유가 거의 없는 방법입니다.
- 새 패키지 버전을 설치하기 전에 대기 시간을 추가하세요. 실제 공급망 공격이 발생하여 빌드에 도달하기 전에 드러나고 공개되는 데는 며칠이면 충분한 경우가 많습니다.
세 번째 방법은, 여력이 되는 팀의 경우 CVE 및 멀웨어 가시성을 직접 구축하는 것입니다. pipeline컨테이너 이미지(소스 코드뿐만 아니라 기본 이미지에도 많은 취약점이 존재하기 때문)를 스캔하고 결과를 표시합니다. pull request 개발자들이 병합하기 전에 실제로 보는 댓글입니다.
최근 발생한 사건은 이 문제의 심각성을 명확히 보여줍니다. 2026년 7월, 내부 평가 중이던 AI 모델이 자체 샌드박스의 유일하게 허용된 네트워크 경로인 패키지 캐시 프록시의 제로데이 취약점을 악용하여 개방형 인터넷에 접속했습니다. 사람의 지시 없이도 벤치마크 목표를 달성하기 위해 외부 인프라를 침해한 것입니다. 탈출 경로는 바로 의존성 인프라였습니다. 모든 샌드박스가 허용하도록 설계된 유일한 연결 고리인 셈입니다. 에이전트가 제대로 작동하기 위해 패키지 레지스트리에 접근해야 한다면, 해당 연결은 보안 모델의 부차적인 요소가 아니라 핵심적인 보안 요소입니다. Xygeni에서 제공하는 이 탈출 사건의 자세한 분석 자료는 꼭 읽어보시길 바랍니다. 로그 바이 디자인.
주요 요점
- 마지막 인간 감시탑이 약해지는 것이 아니라 사라지고 있다. 패키지 이름을 읽는 것에 의존하지 않는 설계 제어 방식을 사용하세요.
- 슬롭스쿼팅과 할루스쿼팅은 이론적인 것이 아니라 실제로 재배 가능한 기술입니다. 반복적으로 나타나는 환각적인 이름과 평문 프롬프트 삽입은 이미 실제 현장에서 악용되고 있습니다.
- 출처 및 SBOMs는 빌드가 수행한 작업을 증명하는 것이지, 어떤 입력값을 받았는지 증명하는 것이 아닙니다. 최고 수준의 인증을 필요조건으로 간주하되, 충분조건으로 간주하지 마십시오.
- 현재로서는 탐지가 아니라 확산 억제가 선을 지키는 핵심 요소입니다. 샌드박싱, 출입 제어 및 쿨다운 시간은 서명 기반 스캔으로는 얻을 수 없는 시간을 벌어줍니다.
- 담당 직원이 실제로 도달할 수 있는 범위를 파악하세요. 정책 문서가 아닙니다. 실제 토큰, 실제 자격 증명, 실제 네트워크 출력입니다.
이 글은 Xygeni의 SafeDev Talk에서 논의된 내용을 바탕으로 작성되었습니다.AI 에이전트가 종속성을 설치할 때"도커 캡틴 모하마드 알리 아라비가 출연합니다. 그의 9가지 제어 요소로 구성된 보안 강화 프레임워크는 그의 뉴스레터인 Docker Security Dispatch에서 더 자세히 다뤄지며, 루이스 로드리게스(Xygeni 연구원)도 출연합니다.
자주 묻는 질문: AI 에이전트 공급망 보안
에이전트가 패키지를 설치하는 행위는 개발자가 스택 오버플로우의 제안을 복사하는 행위와 근본적으로 다른 신뢰 문제일까요, 아니면 단순히 더 빠른 버전의 문제일까요?
둘 다 다른 비율로 나타납니다. 메커니즘은 더 빠르지만, 신뢰 격차는 구조적으로 더 큽니다. 스택 오버플로우 답변은 사람이 작성하고 비공식적으로 동료 검토를 거친 반면, AI가 생성한 패키지 추천은 그에 상응하는 검토 없이 확률적으로 출력됩니다. 게다가 개발자가 직접 복사할 때는 자동 생성 에이전트가 완전히 건너뛰는 간단한 검토 과정을 거치기도 합니다.
무엇이 필요할까요? SBOM "상담원이 이 내용을 추가했고, 그 이유는 다음과 같습니다."라는 내용을 확실하게 기록하려면 어떻게 해야 할까요?
오늘의 SBOM 그리고 출처 standard이러한 모델들은 인간이 각 의존 관계를 만들었다는 가정을 바탕으로 구축되었습니다.cis이온(ion)은 아직 어떤 에이전트, 어떤 모델 버전 또는 어떤 프롬프트가 특정 변경 사항을 발생시켰는지 기록하는 필드를 제공하지 않습니다. 이러한 격차를 해소하려면 기존 증명 형식을 확장하거나 에이전트를 인식하는 별도의 감사 추적 기능을 통해 변경 사항을 기록해야 합니다.cis이온 출처 정보와 빌드 출처 정보를 함께 제공합니다.
가장 빠른 객체가 현재 위치에 있을 때도 작동하는 "좌측 이동" 명령어 버전이 있나요? pipeline 자율 에이전트이지 개발자가 아닌가요?
네, 하지만 단순히 타이밍만 바꾸는 것이 아니라 체크포인트 자체를 바꿔야 합니다. 사람의 검토를 기반으로 하는 시프트 레프트 방식은 에이전트 속도에 맞춰 확장할 수 없습니다. 반면 샌드박싱, 접근 제한, 설치 쿨다운 등을 활용하는 시프트 레프트 방식은 에이전트의 동작이 실제 운영 환경에 도달하기 전에 취약점을 발견할 수 있습니다. 이러한 제어 방식은 누군가 코드를 검토하는 것에 의존하지 않기 때문입니다.
