AX 패턴2026-09-16

2023년 빌드에 박힌 토큰이 3년 4개월 뒤에도 살아 있었다

에이전트가 25분 만에 찾았다

보안회사 Strix가 자율 에이전트로 추론 업체 Baseten을 점검했다. 공개 도커 이미지의 빌드 기록에서 깃허브 토큰을 찾았고 제품 레포 관리자 권한이 붙어 있었다. 걸린 시간은 25분이다.

거래를 트기 전에 상대 회사를 털어 본 기록이 오늘 해커뉴스 상단에 올라왔다. 보안회사 Strix는 추론 서비스를 쓰려고 후보를 보던 중 기업가치 130억 달러짜리 업체 Baseten의 도메인에 자기네 자율 해킹 에이전트를 붙였다. 자격증명도 소스코드도 주지 않았다. 25분 뒤 에이전트는 살아 있는 깃허브 토큰을 들고 돌아왔고 그 토큰에는 Baseten 제품 저장소의 관리자 권한이 붙어 있었다. 토큰이 만들어진 건 2023년 3월 3일이고 발견 시점은 2026년 7월이다.

한 줄 정리

3년 4개월 전 빌드에 섞여 들어간 토큰이 공개 이미지 안에 그대로 남아 제품 저장소 관리자 권한을 계속 들고 있었다.

파일이 아니라 빌드 기록에 남아 있었다

에이전트는 서브도메인을 훑다가 공개돼 있던 컨테이너 레지스트리를 찾았다. 인증 없이 저장소 목록을 뽑고 익명 pull 토큰을 받아 baseten-app 이미지를 통째로 내려받을 수 있었다.

토큰이 나온 자리가 이 사건의 핵심이다. 이미지 파일 안이 아니라 이미지 설정에 딸린 빌드 기록의 created_by 필드였다. 비공개 의존성을 받으려고 빌드 인자로 넘긴 깃허브 토큰이 실행된 명령줄에 값 그대로 펼쳐져 기록됐다. 도커 문서가 명시적으로 경고하는 패턴이고 파일에서 자격증명을 지워도 기록에는 사본이 남는다.

권한을 확인해 보니 이랬다.

저장소 권한
메인 제품 관리자, 푸시
클러스터 상태를 적용하는 GitOps 관리자, 푸시
CLI 배포용 Homebrew tap 관리자, 푸시
고객사별 비공개 저장소 읽기/쓰기

의존성 하나를 내려받으려고 만든 토큰이다. 필요한 건 읽기 권한 하나였는데 제품과 인프라와 배포 채널을 다 쥐고 있었고 만료도 없었다.

대응은 빨랐고 그게 유일하게 다행인 부분이다

신고가 7월 13일 밤 11시 10분, 다음 날 오전 레지스트리 비공개 처리, 오후 4시 34분 심각도 확인과 토큰 회전, 17일 나머지 항목 종료. 하루 안에 끊었다. Baseten은 이미 다른 AI 보안 도구도 쓰고 있던 회사다. 그런데도 2023년 이미지 하나가 3년을 살아남았다.

여기서 읽을 건 이 회사가 허술하다는 결론이 아니다. 애플리케이션과 소스 저장소는 다들 본다. 아무도 안 보는 건 옛날에 만들어 둔 이미지다.

공격 쪽 단가가 먼저 내려갔다

이 사건에서 제일 중요한 숫자는 권한도 연수도 아니고 25분이다. 사람 한 명이 붙어서 서브도메인을 훑고 레지스트리를 찾고 이미지를 까서 토큰을 골라내고 그 토큰의 권한 범위까지 확인하려면 하루는 걸리던 작업이다. 값이 그만큼 들었으니 작은 회사는 표적이 아니었다.

에이전트가 그 값을 25분으로 내렸다. 방어 쪽에도 같은 도구가 있지만 순서가 문제다. 공격은 누구에게 쓸지 고르지 않고 도메인 목록에 전부 돌려 볼 수 있다. 검사 대상을 좁힐 이유가 사라졌다는 게 이번 기록의 실질이다.

위시클레이 관점

이 얘기가 도커를 안 쓰는 팀과 무관해 보이지만 같은 모양의 물건을 다들 하나씩 갖고 있다. 만료 없는 전권 키다. n8n 워크플로에 넣어 둔 API 키, 예전에 쓰던 자동화 스크립트에 박아 둔 토큰, 대행사에 넘겨준 뒤 회수 안 한 접근 권한. Baseten의 토큰과 구조가 같다. 한 가지 일을 시키려고 만들었는데 권한은 전부 열려 있고 시한이 없다.

오늘 30분이면 되는 점검이 두 가지다. 하나는 우리가 발급한 키 목록을 뽑아 각각 "이 키가 하는 일 하나"와 "지금 가진 권한"을 나란히 적어 보는 일이다. 두 줄이 다르면 그 키는 줄여야 할 키다. 다른 하나는 만료일 칸이다. 비어 있는 키가 몇 개인지 세는 것만으로도 다음에 뭘 할지가 정해진다.

벤더 쪽은 다르게 봐야 한다. 130억 달러짜리 회사에 3년 묵은 관리자 토큰이 떠 있었다면, 우리가 쓰는 작은 SaaS 몇 개는 더할 가능성이 크다. 그렇다고 우리가 벤더를 털어 볼 수는 없다. 대신 우리 쪽에서 통제되는 건 그 벤더에게 뭘 주느냐다. 고객 명단 전체를 올릴 이유가 없는 도구에 전체를 올려 두지 않는 것, 읽기만 필요한 연동에 쓰기 권한을 주지 않는 것. 이 두 가지는 벤더의 보안 수준과 무관하게 우리가 정한다.

Strix가 본 마지막 장면도 그 얘기다. 고객사 이름으로 된 디렉터리가 줄줄이 있는 비공개 저장소가 그 토큰 범위 안에 들어 있었다. 남의 빌드 실수 하나가 우리 고객 목록까지 닿는 경로였다.

참고