자동화된 파이프라인에 숨겨진 신뢰 문제

AI 에이전트에게 클론(clone), 설정(configure), 실행(execute)과 같은 행동 능력을 부여하는 순간, 대부분의 팀이 아직 깊이 고민하지 않은 신뢰 경계(trust boundary)가 생성됩니다.

발생한 상황

연구원들은 GitHub 저장소(repository)가 정적 스캐너(static scanners), 인간 검토자, 그리고 AI 코딩 에이전트에게는 완전히 깨끗해 보일 수 있으면서도, 정상적인 설정 워크플로우(setup workflow) 중에 실행되는 악성 페이로드(malicious payload)를 포함할 수 있음을 보여주었습니다. 이 공격은 인간을 속여 의심스러운 것을 실행하게 만들 필요가 없습니다. 에이전트 도구가 설계된 대로 작동하기만 하면 됩니다. 즉, 자율적으로 저장소를 클론하고 실행하는 것 말입니다.

이것이 바로 공격 표면(attack surface)의 전부입니다. 에이전트의 유능함이 곧 취약점입니다.

이는 새로운 옷을 입은 알려진 문제

저장소를 통한 공급망 공격(Supply chain attacks)은 새로운 것이 아닙니다. 타이포스쿼팅(Typosquatting), 의존성 혼란(dependency confusion), 악성 설정 스크립트(malicious setup scripts) 등 우리는 수년 동안 이러한 문제들과 싸워왔습니다. 여기서 새로운 점은 증폭기(amplifier)입니다. 즉, 높은 신뢰도와 종종 높은 권한을 가지고 자율적으로, 대규모로 작동하는 AI 코딩 에이전트입니다.

이전에는 악성 저장소가 인간의 간과를 필요로 했습니다. 이제는

과소평가되고 있는 점: 진짜 문제는 우리가 적절한 샌드박싱 (sandboxing), 권한 범위 설정 (permission scoping), 또는 행동 검토 (behavioral review) 없이 CI/CD 파이프라인과 개발 환경에서 코드를 실행하는 자율 에이전트 (autonomous agents)를 너무 빠르게 정상적인 것으로 받아들이고 있다는 것입니다. 공격 표면 (attack surface)은 AI의 추론 능력이 아니라, AI가 취하는 '행동'에 대해 우리가 부여한 무조건적인 신뢰입니다.

이러한 내러티브를 통해 이득을 보는 쪽은 누구일까요? 이러한 종류의 리스크를 (정당하게) 입증하고 있는 보안 연구원들입니다. "AI 에이전트가 속았다"라는 프레임은 주의를 끌기 좋지만, 그 밑바탕에 깔린 메시지, 즉 자동화된 실행 파이프라인에 더 나은 위생 (hygiene)이 필요하다는 점은 진정으로 중요하며 AI 드라마 속에서 묻혀서는 안 됩니다.

이것이 당신에게 의미하는 바

AI 코딩 에이전트를 사용하는 개발자라면: 에이전트가 프로젝트를 설정할 때 실제로 무엇을 '하는지' 이해해야 합니다. 자동으로 설치 스크립트를 실행하나요? 설정 훅 (setup hooks)을 실행하나요? 에이전트가 어떤 권한 하에서 실행되고 있는지 알고 있습니까? 아마도 이제는 확인해 볼 때입니다.

보안 팀 소속이라면: 에이전트 기반 도구들은 이미 공식적으로 승인되지 않았더라도 여러분의 환경 내에 존재할 가능성이 높습니다. "개발자 워크스테이션 침해 (developer workstation compromise)"에 대한 위협 모델 (threat model)이 방금 더 자동화되었습니다. 저장소를 복제하고 실행할 수 있는 에이전트는 매핑되기를 기다리는 권한 상승 (privilege escalation) 벡터입니다.

업계 전반에 대하여: 우리는 자율 실행 능력을 이를 제어할 수 있는 검토, 샌드박싱, 그리고 최소 권한 (least-privilege) 프레임워크를 개발하는 속도보다 더 빠르게 배포하고 있습니다. 이는 전형적인 보안 도입 곡선의 문제로, 기능은 앞서 나가고 방어력 강화 (hardening)는 뒤처지는 현상입니다. 지금의 차이점은 그 기능이 '자율적'이라는 것이며, 이는 그 격차가 더 날카로운 결과로 이어진다는 것을 의미합니다.

실질적인 단기적 영향은 명확합니다. 외부 저장소(repository)를 복제하고 설정 과정에서 코드를 실행하는 모든 자동화된 파이프라인은 임의 코드 실행 (arbitrary code execution)과 동일한 수준의 정밀한 검토를 거쳐야 합니다. 왜냐하면 그것이 정확히 임의 코드 실행이기 때문입니다. AI 에이전트가 "실행" 버튼을 누른다는 사실은 위험을 변화시키지 않으며, 단지 그 위험을 포착할 수도 있었던 인간의 일시 정지(pause)를 제거할 뿐입니다.

열린 질문 (The Open Question)

AI 코딩 에이전트가 개발 워크플로 (workflow)의 표준 구성 요소가 됨에 따라, 에이전트가 실행하는 작업의 보안 태세 (security posture)에 대한 책임은 누구에게 있을까요? 에이전트를 호출한 개발자일까요, 에이전트를 구축한 팀일까요, 아니면 이를 호스팅하는 플랫폼일까요? 왜냐하면 현재로서는 에이전트가 출시되기 전에 아무도 그 질문에 답하지 않고 있는 것처럼 느껴지기 때문입니다.

— Cor, Skyblue Soft

출처 (Sources)

• Clean GitHub repo tricks AI coding agents into running malware