Baseten의 대응은 전반적으로 훌륭했음. 7월 13일 밤 11시 10분에 유효한 basetenbot 토큰, 공개 Harbor 프로젝트, 저장소 권한을 신고했고, 다음 날 오전에 프로젝트가 비공개로 전환됨. 토큰은 여전히 작동한다고 알리자 오후 4시 34분에 보안팀 Anton이 심각도를 ‘치명적’으로 확인하고 토큰 교체까지 완료했다고 알렸으며, 내려받은 이미지의 안전한 삭제도 요청함.
오후 5시 5분에 삭제를 확인해 주고 같은 검사에서 찾은 낮은 심각도의 취약점 두 건도 전달했으며, 7월 17일에 나머지 조치도 완료됨. 9월에는 공개 계획과 글 초안을 전달했고, 감사의 표시로 티셔츠와 맨투맨도 받았음. 여기서 얻을 교훈으로, 바이브 코딩으로 만든 내부 에이전트의 기본 보안 경계를 어떻게 정해야 하는지가 궁금함.

신속한 소통과 수정은 좋았지만, 보상은 터무니없이 부족함. 기업가치가 130억 달러인 Baseten이 GitHub 조직의 관리자 권한까지 탈취할 수 있는 취약점을 비공개로 제보한 연구자에게 몇천 달러도 줄 수 없는 건가?
정직한 연구자에게는 Baseten 취약점을 찾느라 시간을 낭비하지 말라는 신호이고, 취약점으로 돈을 벌려는 범죄자에게는 좋은 표적이라는 신호가 됨.

바이브 코딩으로 만든 에이전트는 신입 직원이 아니라 신뢰할 수 없는 CI 작업처럼 다뤄야 함. 저장소 단위로 신원을 제한하고, 기본은 읽기 전용으로 두며, Actions 토큰이나 운영 환경 비밀정보를 물려주지 않아야 함.
읽기에서 쓰기로 넘어가는 모든 작업은 에이전트가 통제할 수 없는 외부 승인을 거치고, 감사 가능한 변경 내역을 남겨야 함. 외부 네트워크 통신도 경계에 포함해야 함. 읽은 내용을 임의의 외부 주소로 전송할 수 있다면 읽기 전용 권한만으로는 별 보호가 되지 않음.

이 정도는 빠른 대응이라기보다 아직은 표준적인 대응 시간에 가까워 보임. 취약점 수정에 허용되는 시간이 며칠, 몇 시간, 어쩌면 몇 분까지 줄어들고 있음.[1] OpenRouter 계정만 있으면 Strix와 GLM 5.3 Flash를 사용해 최첨단 Mytho 5 수준의 사이버 공격 역량으로 피해를 줄 수 있음.[2].
이 보안 패치 경쟁은 이미 시작됐고, 지난 70년간 만든 소프트웨어 중 여전히 쓰이는 것들을 모두 패치해야 할 지경임. 모든 소프트웨어 회사에 해당하며, 하지 않으면 끝장임.
[1]: https://news.ycombinator.com/item?id=49699402.
[2]: https://news.ycombinator.com/item?id=49705036.

침투 테스트 에이전트가 Baseten 이미지 저장소를 찾아낸 뒤 Docker 빌드 이력에서 유효한 GitHub 개인 액세스 토큰을 발견함. basetenbot 토큰에는 주력 제품 저장소, 클러스터를 관리하는 GitOps 저장소, Homebrew 탭의 관리자·푸시 권한이 있었고, 고객별 저장소를 비롯한 다른 비공개 저장소에도 읽기·쓰기 권한이 있었음.
요즘 악의적인 공격자가 이런 에이전트 기반 공격을 얼마나 많이 수행하고 있고, 그중 얼마나 알려지지 않고 있는지 걱정됨.

Strix에는 훌륭한 홍보지만 Baseten에는 상당히 나쁜 일임. 자사 보안 제품을 홍보하기에 이보다 좋은 소재는 찾기 어려울 듯함. Strix를 몰랐는데 이제 찾아보고, 내 도구 구성에 추가할지도 모르겠음.

사용해 보고 개선할 점이 있으면 알려주길 바람!

이게 합법인가? 안에 들어가거나 훔칠 의도가 없더라도 이웃집 자물쇠를 부수며 침입을 시도할 수는 없는 것 아닌가?

침입한 게 아니라 이웃이 떨어뜨린 열쇠를 찾아 돌려준 것임. 일반적으로는 합법이지만, 보안 업무를 하려면 변호사에게 확인하는 게 좋음. 취약점을 알려줬을 때 어떤 멍청이의 심기를 건드리느냐에 따라 보안 연구자가 법적 곤경에 처하기도 함.

글에 명시되지는 않았지만, 연구 전에 Baseten의 허락을 받았다는 암시는 있음.
여러 소프트웨어 회사에 제품을 팔아본 입장에서 흥미로운 점은, 많은 기업용 공급업체 계약이 사전 통지와 조율을 전제로 공급업체에 대한 침투 테스트를 명시적으로 허용한다는 것임. 우리 고객이 그 조항을 행사한 적은 없는 것 같지만, 이제 실행이 워낙 쉬워져 앞으로 훨씬 자주 활용될 듯함.

적어도 대부분의 관할권에서는 합법이 아님. 다만 Baseten이 소송을 거는 건 극도로 어리석은 일일 테고, 악의가 없었던 만큼 해커도 가벼운 처분 정도를 받을 가능성이 높아 보임.

정당한지와 별개로, 보안 도구 회사가 실제 고객이나 공급업체를 홍보 소재로 삼는 것은 불편함. 굳이 ‘피해자’의 이름을 밝히지 않고도 전달할 수 있었을 내용임. 복잡한 다단계 공격도 아닌데, 글의 어조는 “Baseten이 얼마나 크게 잘못했는지 보라”에 가까움.
Strix가 이미지를 내려받아 내부를 살펴보기로 한 시점에 선을 넘었다고 봄. 데이터를 적극적으로 빼내서 들여다보고, 거기서 얻은 인증정보로 내부 시스템을 나열하고 탐색하기 시작하면 화이트햇의 범위를 한참 벗어남.
자가 점검용 제품이라 안전하게 탐색해도 된다고 가정하는 건 이해함. 바로 그렇기 때문에 제3자를 대상으로 실행하는 건 무책임하고 불법의 경계에 가까움. 허락을 받았더라도 저장소 검색이나 다운로드까지 허용했을지는 의문임.
공개 이미지에 남겨둔 접근 권한이 “말도 안 되게 많다”는 식의 표현도, 마치 의도적으로 그렇게 설정한 것처럼 들려 전문성이 부족해 보임. 도와주려는 상대를 공개적으로 깎아내리는 팀의 보안 도구는 꺼림칙함.
덧붙이면, 글에는 이름만으로 알 수 없는 여러 저장소의 용도와 기능이 나오고, 비공개 저장소의 customers/ 아래에서 Baseten 고객 이름으로 된 디렉터리들을 확인했다고 명시돼 있음. 저장소를 복제하지 않았더라도 내용 목록을 조회해 기밀 고객 정보를 추출했다면 정당한 변명이 되지 않음. Strix는 허용되지 않았다는 걸 알면서도 그 작업을 수행한 셈임.

대상을 익명으로 처리하면 신빙성은 조금 떨어질 수 있겠지만, 실명을 공개해 망신주는 것보다는 훨씬 품위 있는 방식으로 보임.

결국 로그에서 관리자 토큰을 찾아낸 것임.

이런 문제를 몇 번 봤음. Docker 빌드 인수를 그런 식으로 사용한다면 --provenance=false 를 추가해 해당 빌드 메타데이터를 없앨 수 있음. 그래도 Dockerfile 안에서 비밀정보의 사용 범위를 제한할 수 있는 빌드 시크릿이 더 나은 방법임. 메타데이터 자체는 이미지를 검사할 때 유용하기도 함.

정말 AI 경제로 들어서고 있음. 저축한 돈을 SPY에 넣기 전에 세계 정세 혼란 속에서 주가가 오를지 내릴지만 알 수 있으면 좋겠음.

지금은 Trump가 최대 변수임. AI 관련 투자 흐름보다 SPY에 훨씬 큰 영향을 미치고 있음.

Baseten을 추론 서비스 제공업체로 검토하면서 먼저 간단히 점검해 봤고, 지금도 후보로 고려 중임. 빠르게 패치한 팀에는 박수를 보냄.

삭제 결과는 반드시 검증해야 함. 디스크 삭제 도구를 쓴 뒤 섹터를 확인했더니, 1KB 미만 파일이 제대로 지워지지 않았음. 내 비밀정보도 그렇게 남아 있었음.