공급망 공격은 침투 지점에서 끝나지 않는다. 중요한 것은 토큰 하나가 새어 나온 뒤, 그 토큰이 어디까지 갈 수 있느냐다. npm 공급망 공격, GitHub 앱 권한, AI 에이전트 도구, 주거용 프록시 봇넷은 서로 다른 사건처럼 보인다. 하지만 같은 질문으로 묶인다. 신뢰한 실행 주체가 악성 입력을 받았을 때, 시스템은 어디에서 멈추는가. 공급망 보안의 핵심은 탐지가 아니라 폭발 반경이다 Grafana의 TanStack npm 공급망 랜섬 사건은 이 질문을 선명하게 보여준다. 사건은 2026년 5월 11일 Mini Shai-Hulud 캠페인을 통해 self-hosted runner에서 악성 코드가 실행되며 시작됐다. Grafana는 관련 자격 증명을 회전했다고 판단했지만 하나를 놓쳤고, 공격자는 그 자격 증명으로 전체 저장소 컬렉션을 복제했다. 5월 16일 랜섬 요구가 왔다. ...
한 줄 요약: Guix substitute와 guix pull 취약점은 재현 가능한 빌드만으로는 소프트웨어 공급망 보안을 설명하기 어렵다는 사례다. 패키지 매니저의 신뢰 경계는 빌드 결과물뿐 아니라 업데이트 경로, 캐시, 키, 롤백 정책까지 포함한다. 왜 지금 이슈인가 개발자 커뮤니티에서 Guix 취약점이 이야기되는 이유는 Guix 자체의 점유율 때문만은 아니다. Guix는 재현 가능한 빌드(Reproducible Build), 함수형 패키지 관리, 롤백 가능한 프로필을 핵심 기능으로 삼아 온 도구다. 그런 도구에서도 guix substitute와 guix pull 같은 업데이트 경로가 문제가 될 수 있다는 점은 생각할 거리를 남긴다. ...
한 줄 요약: LLM 생성 코드가 의존성에 섞이는 문제는 취향 논쟁이 아니라 공급망 보안, 리뷰 비용, 유지보수 책임의 문제다. 먼저 볼 것은 출처, 검증 가능성, 장애가 났을 때 고칠 사람이 남아 있는 구조다. 왜 지금 이슈인가 LLM이 만든 코드, 오픈소스 공급망 보안, 에이전트가 올리는 PR은 이제 따로 보기 어렵다. 더 까다로운 질문은 “누가 썼나”가 아니라 “왜 이렇게 만들었는지 설명할 사람이 있나”다. git-annex의 Joey Hess는 LLM 생성 코드가 들어간 의존성을 피하려고 의존성 트리를 계속 점검했다고 썼다. 그 과정에서 큰 변경이 다음 릴리스에서 설명 없이 되돌려진 사례, 2만 6천 줄 규모 코드베이스에 1만 줄 변경과 1,489줄짜리 이상한 커밋 메시지가 붙은 사례, 다른 프로젝트 코드를 복사하라는 프롬프트에 가까운 변경을 봤다고 한다. ...