무슨 일이 있었냐면
AI 침투 테스트 에이전트를 만드는 Strix 팀이 흥미로운 글을 올렸어요. AI 모델 배포 플랫폼으로 잘 알려진 Baseten의 프로덕션 GitHub 조직에서 관리자 권한을 얻기까지 25분밖에 안 걸렸다는 내용이에요. 물론 허가받은 테스트였고, 문제는 이미 조치된 뒤에 사례로 공개된 것으로 보여요. 블로그 주소에 "harbor"와 "github-pat-takeover"라는 단어가 들어 있는데요. 이 키워드가 사건의 뼈대를 말해줘요. 어딘가에 GitHub 개인 액세스 토큰, 줄여서 PAT가 노출되어 있었고, 그 토큰이 가진 권한이 생각보다 훨씬 컸다는 거예요.
이 이야기가 왜 중요하냐면, 화려한 제로데이 취약점이나 복잡한 익스플로잇이 등장하지 않기 때문이에요. 그냥 "토큰 하나가 어딘가 굴러다녔다"는 흔한 실수가, 회사의 모든 소스코드와 배포 파이프라인을 통째로 넘겨줄 수 있다는 걸 보여주거든요. 그리고 그 실수를 찾아내는 데 사람이 아니라 AI 에이전트가 투입되어 25분 만에 끝냈다는 점이 시대의 변화를 말해줘요.
PAT가 뭐고 왜 위험하냐면
GitHub에서 뭔가 자동화하려면 비밀번호 대신 쓰는 열쇠가 필요해요. 그게 PAT(Personal Access Token)예요. CI에서 코드를 받아오거나, 스크립트로 이슈를 만들거나, 패키지를 올릴 때 이 토큰을 써요. 문제는 이 열쇠가 "개인"에게 묶여 있다는 거예요. 조직 관리자가 자기 계정으로 토큰을 만들어서 어떤 도구에 넣어두면, 그 토큰은 그 사람이 할 수 있는 모든 일을 할 수 있어요. 조직의 모든 저장소 읽기, 쓰기, 설정 변경, 멤버 추가, 심지어 저장소 삭제까지요.
특히 예전 방식의 클래식 PAT는 권한 단위가 너무 커요. "repo" 권한 하나를 체크하면 그 계정이 접근할 수 있는 모든 저장소에 전부 접근돼요. 저장소 하나만 읽으려고 만든 토큰이 실제로는 수백 개 저장소의 열쇠인 셈이죠. GitHub가 나중에 내놓은 파인그레인드(fine-grained) PAT는 저장소 단위, 권한 단위로 쪼개서 줄 수 있고 만료일도 강제되는데, 아직도 많은 회사가 습관적으로 클래식 토큰을 쓰고 있어요.
그러면 이런 토큰은 어디서 새어 나올까요? 경로는 생각보다 다양해요. 도커 이미지를 빌드할 때 토큰을 환경변수나 파일로 넣었다가 이미지 레이어에 그대로 구워지는 경우가 아주 흔해요. 이게 뭐냐면, 도커 이미지는 파일 시스템의 변경 이력을 층층이 쌓아 저장하기 때문에, 나중 단계에서 파일을 지워도 앞 층에는 남아 있거든요. 그 이미지가 공개 레지스트리에 올라가거나, 레지스트리 접근 설정이 느슨하면 누구나 층을 벗겨서 토큰을 꺼낼 수 있어요. 그 밖에도 CI 로그에 토큰이 찍히는 경우, 공개 저장소의 오래된 커밋 히스토리에 남아 있는 경우, 설정 파일이 실수로 함께 올라가는 경우가 있죠.
토큰 하나가 조직 전체로 번지는 과정
이런 테스트가 보통 어떻게 흘러가는지 그려볼게요. 먼저 에이전트가 대상 회사와 관련된 공개 자산을 훑어요. 공개 저장소, 공개 이미지, 문서, 서브도메인 같은 것들이죠. 그러다 토큰처럼 생긴 문자열을 발견하면 "이거 아직 살아 있나?"를 바로 확인해요. GitHub API에 던져보면 토큰 주인이 누구고 어떤 권한이 있는지 금방 나오거든요. 여기서 토큰 주인이 조직 관리자라면 게임은 사실상 끝이에요. 조직의 모든 프라이빗 저장소, 거기 저장된 CI 시크릿, 배포 워크플로우, 다른 서비스로 이어지는 클라우드 자격증명까지 한 줄로 이어지니까요.
"25분"이라는 숫자가 무서운 이유가 여기 있어요. 사람이 손으로 했다면 어디를 볼지 고민하고, 도구를 세팅하고, 문자열을 검증하는 데 반나절은 걸릴 일을, 에이전트는 정찰부터 검증까지 쉬지 않고 돌려요. 공격자도 똑같은 도구를 쓸 수 있다는 걸 생각하면, "우리 토큰이 어디 남아 있을지 언젠가 정리해야지"라는 여유는 더 이상 없다는 얘기예요.
특히 Baseten처럼 다른 회사의 AI 모델을 대신 돌려주는 플랫폼이 뚫리면 문제가 자기 회사에서 끝나지 않아요. GitHub 관리자 권한이면 배포 코드를 몰래 바꿔서 고객 모델의 입출력을 가로채는 공급망 공격이 가능해지거든요. 이게 뭐냐면, 내가 직접 공격당하는 게 아니라 내가 믿고 쓰는 도구나 서비스가 오염되어서 피해가 나한테까지 흘러오는 걸 말해요.
처음 있는 일은 아니에요
비슷한 사고는 꾸준히 있었어요. 2022년 토요타는 공개 GitHub 저장소에 5년 동안 남아 있던 접근 키 때문에 고객 정보 서버가 노출됐고, 같은 해 우버는 내부 스크립트에 박혀 있던 관리자 자격증명으로 사내 시스템 대부분이 뚫렸어요. 2024년 초 메르세데스-벤츠는 직원이 공개 저장소에 올린 GitHub 토큰 하나로 사내 GitHub 엔터프라이즈 전체가 열렸고, 같은 해 뉴욕타임스도 노출된 GitHub 토큰 때문에 수천 개 저장소가 유출됐어요. 심지어 GitHub 자신도 2022년 말 도난당한 PAT 때문에 데스크톱 앱의 코드 서명 인증서를 폐기해야 했죠.
패턴이 똑같아요. 너무 강한 토큰이, 너무 오래, 엉뚱한 곳에 남아 있었다. 달라진 건 이제 그걸 찾는 쪽도 AI라는 점이에요. Strix 같은 자율 침투 테스트 에이전트, XBOW 같은 AI 버그헌터가 사람보다 빠르게 이런 구멍을 찾기 시작했고, 방어 쪽에서는 GitHub 시크릿 스캐닝과 푸시 보호, gitleaks나 trufflehog 같은 오픈소스 스캐너가 대응하고 있어요.
우리 팀에서 당장 확인할 것들
이 사례에서 뽑아낼 수 있는 실천 항목은 명확해요.
- 클래식 PAT를 파인그레인드로 바꾸고 만료일을 걸어두세요. 특히 조직 소유자 계정으로 만든 토큰이 어떤 도구에 들어가 있는지 지금 목록을 뽑아보세요.
- CI에서는 토큰 대신 OIDC를 쓰세요. GitHub Actions가 클라우드에 짧은 수명의 자격증명을 그때그때 받아오는 방식이라, 훔쳐도 금방 만료돼요.
- 도커 이미지에 시크릿을 굽지 마세요. 빌드 시점에만 필요한 토큰은 BuildKit의 시크릿 마운트를 쓰고, 멀티 스테이지 빌드로 최종 이미지에 흔적을 남기지 마세요.
- 시크릿 스캐너를 파이프라인에 넣으세요. 커밋 전에 막는 푸시 보호가 가장 싸고, 이미 올라간 히스토리는 주기적으로 훑어야 해요.
- 조직 소유자 수를 최소로 줄이고 SSO와 2단계 인증을 강제하세요. 관리자가 열 명이면 열쇠가 열 개 굴러다니는 거예요.
정리하면
노출된 GitHub 토큰 하나가 조직 관리자 권한으로 이어지는 데 25분이면 충분했고, 이제 그 구멍을 찾는 건 AI 에이전트예요. 기술이 아니라 습관의 문제라서 더 무서운 이야기예요.
여러분 팀은 마지막으로 토큰 목록을 정리한 게 언제인가요? 그리고 AI 에이전트가 이런 테스트를 대신하는 시대에, 보안 팀의 역할은 어떻게 달라져야 할까요?
🔗 출처: Hacker News