보안 기업 Strix는 자사와 고객의 데이터를 맡기기 전에 벤더를 먼저 점검하는 관행을 갖고 있다. 이들은 저렴하고 빠른 추론 인프라를 찾던 중 기업 가치 130억 달러로 평가받는 추론 플랫폼 Baseten을 후보로 검토했고, 계약에 앞서 자체 자율 해킹 에이전트인 Strix를 *.baseten.co 도메인에 겨눴다. 자격 증명도, 소스 코드도 주지 않은 블랙박스 방식이었다. 약 25분 뒤 에이전트가 들고 온 것은 Baseten 내부 저장소들에 대해 관리자 권한을 가진 살아 있는 깃허브 개인 액세스 토큰이었다.
정찰에서 시작해 레지스트리까지
점검은 통상적인 모의 침투와 마찬가지로 정찰에서 출발했다. 잊혀진 서브도메인에 걸린 서비스가 인프라 전체에서 가장 치명적인 취약점이 되는 경우가 많기 때문이다. Strix는 호스트를 열거하고 인증서 투명성 로그를 뒤지며 공격 표면을 그려나갔고, 결국 gcp-us-east4-zlw.registry.baseten.co에서 Harbor 컨테이너 레지스트리를 찾아냈다. Harbor는 이미지를 프로젝트 단위로 묶어 관리하는데, 그중 한 프로젝트가 공개 상태였다. 별도의 토큰이나 인증 없이도 저장소 목록을 조회하고 익명 풀 토큰을 발급받아 실제 이미지 매니페스트와 블롭을 내려받을 수 있었으며, 여기에는 baseten/baseten-app이라는 이미지가 포함돼 있었다.
공개된 레지스트리를 발견한 것만으로 보고서를 쓰고 넘어갈 수도 있었다. 하지만 기업이 의도적으로 이미지를 공개하는 경우도 있어, 노출 자체가 아니라 그 노출이 어떤 실질적 영향을 갖는지가 핵심이다. Strix는 이미지를 실제로 내려받아 내부를 확인했다. 처음 눈에 띈 것은 AWS 키 한 쌍이었지만, 자격 증명이 어느 계정에 속하는지만 확인하는 읽기 전용 sts:GetCallerIdentity 호출에 InvalidClientTokenId가 돌아와 이미 폐기된 키로 판명됐다.
파일이 아니라 빌드 이력에 남은 토큰
에이전트는 여기서 멈추지 않고 이미지 레이어를 풀어 TruffleHog를 돌리고 이미지 설정을 직접 들여다봤다. 그러다 전형적인 깃허브 개인 액세스 토큰이 image config의 history[].created_by 필드에 남아 있는 것을 발견했다. 이 필드는 각 빌드 단계가 어떻게 생성됐는지를 기록하는데, 여기에는 GITHUB_TOKEN 값이 그대로 전개된 RUN 명령이 들어 있었다. 토큰으로 읽기 전용 GET /user 요청을 보내자 200 응답과 함께 basetenbot이라는 계정 이름이 돌아왔다. 주목할 점은 토큰이 발견된 위치다. 도커 이미지는 파일시스템 레이어뿐 아니라 빌드 이력을 담은 config도 함께 배포되기 때문에, 자격 증명 파일을 지워도 이력에 남은 복사본은 그대로 유출된다.
권한 없는 토큰이라면 영향도 없겠지만, 확인 결과는 정반대였다. 깃허브는 X-OAuth-Scopes로 repo를 반환했고 계정은 basetenlabs 조직에 속해 있었다. 개별 저장소 권한을 읽기 전용으로 조회하니, 이 토큰은 Baseten의 메인 제품 저장소에 관리자·푸시 권한을 갖고 있었다. 즉 다른 기업들이 모델을 돌리는 데 의존하는 추론 플랫폼의 소스 코드를 변조할 수 있는 수준이었다. 더 심각한 것은 클러스터의 원하는 상태를 정의하고 이를 인프라에 적용하는 GitOps 저장소로, 유출된 빌드 토큰에서 프로덕션 인프라 변경으로 이어지는 경로가 열려 있었다. Baseten CLI가 개발자 머신에 설치되는 Homebrew tap까지 포함돼 있어, 배포 채널을 건드리면 공급망 공격으로 번질 수 있었다. 어느 비공개 저장소의 최상위에는 고객 이름으로 된 하위 디렉터리가 줄지어 있는 customers/ 폴더도 보였다.
Strix는 이 시점에서 오탐이 아님을 충분히 입증했다고 판단해 멈췄다. 고객 저장소를 복제하거나 무언가를 푸시하거나 설정을 바꾸지 않고 곧바로 취약점 신고 메일을 작성했다. 문제의 빌드 이력에는 타임스탬프가 찍혀 있었는데, 토큰이 담긴 단계는 2023년 3월 3일에 실행됐다. 3년 넘게 지난 2026년 7월에도 그 토큰은 모든 권한을 그대로 유지하고 있었다. Baseten 보안팀은 이를 심각 등급으로 확인하고 레지스트리 프로젝트를 잠근 뒤 다음 날 오후까지 토큰을 폐기하는 신속하고 전문적인 대응을 보였다.
실무자가 가져갈 교훈
근본 원인은 익숙한 실수다. 비공개 의존성을 가져오기 위해 빌드 인자로 토큰을 넘기면 Git 인증은 성공하지만, 도커가 그 인자 값을 이미지 메타데이터와 이력에 기록해 버린다. 게다가 git config --global은 인증 정보가 포함된 URL을 Git 설정 파일에 써 넣어 또 다른 복사본을 남긴다. 도커 스스로도 경고하는 패턴이다. 올바른 해법은 자격 증명을 이미지에 남기지 않는 BuildKit 시크릿 마운트와 임시 인증을 쓰고, 레이어뿐 아니라 빌드 이력까지 함께 점검하는 것이다. 그리고 반드시 기존 토큰을 폐기해야 한다. Dockerfile을 고쳐도 이미 누군가 내려받은 이미지에는 아무 소용이 없기 때문이다.
이 사례가 한국의 인프라 담당자에게 주는 시사점은 분명하다. 애플리케이션과 소스 저장소에 집중하다 보면 오래된 컨테이너 이미지를 잊기 쉽고, 이미지의 파일을 스캔하더라도 빌드 이력은 놓치곤 한다. Baseten처럼 대응이 빠르고 이미 AI 보안 도구를 쓰는 조직에서도 2023년 빌드의 토큰이 제품·배포 저장소 관리자 권한을 쥔 채 방치돼 있었다. 컨테이너와 깃허브를 함께 쓴다면 공개 레지스트리 노출 여부, 이미지 이력에 남은 자격 증명, 그리고 살아 있는 토큰의 실제 권한 범위를 자기 손으로 먼저 확인하는 편이 낫다. 공격자가 같은 경로를 자동으로 따라오기 전에 말이다.