Dependency cooldowns는 당신을 무임승차자로 만든다

dependency cooldowns는 새 버전을 바로 받지 않고 N일 대기한 뒤 채택하는 방식이다. 공급망 공격이 보통 며칠 안에 발견된다는 점을 이용하지만, 실제로는 다른 사람들이 먼저 피해를 보는 free-rider 구조에 기대게 된다.

이 방식은 개인에게는 약간 유리할 수 있어도, 생태계 전체에는 비용을 떠넘긴다. 게다가 Python처럼 여러 package manager가 존재하는 환경에서는 각 도구가 별도로 지원해야 하고, 각 프로젝트마다 설정을 반복해야 하므로 관리 부담이 크다. 설정을 우회해 버리는 실수도 쉽게 발생한다.

대안은 각 프로젝트의 cooldown이 아니라 중앙 dependency server의 upload queue다. 패키지를 publish한 뒤 곧바로 distribute하지 말고, 일정 기간 대기시키는 방식이다. 이 기간 동안에는 다음을 할 수 있다.

• 내부 lint와 자동 보안 검사 실행
• built package 기준의 공개 diff 표시
• 명시적으로 참여한 beta tester에게만 배포
• 유지보수자에게 사전 알림 발송

이 모델은 Debian의 upload queue와 비슷하다. Debian은 업로드 후 2~10일의 대기 기간을 두고 testing으로 넘긴다. 저자는 language-specific package index도 이처럼 publication과 distribution을 분리해야 한다고 본다.

upload queue의 장점은 보안만이 아니다. 릴리스가 공개되기 전에 시간이 생기므로, release credential의 힘을 줄이고, 새 버전이 갑자기 등장하는 불필요한 surprise도 없앤다. 유지보수자에게 "Release 2.4.1 has entered the upload queue" 같은 알림을 보내면 공격 탐지에도 도움이 된다.

이 논리는 AI/LLM 환경에서는 더 강해진다. 저자는 markdown도 사실상 executable file format처럼 동작한다고 본다. Agent Skills처럼 markdown 파일을 내려받아 LLM의 행동이 바뀌는 구조에서는, 공급망 공격과 프롬프트 오염이 더 위험해진다. Soapstones 같은 AI agent용 public memory system도 사실상 markdown package manager이므로 같은 문제가 발생한다.

그래서 저자는 AI 쪽에서는 double upload queue가 필요하다고 주장한다. 한 번은 관리자/모더레이터가 보안상 검토하고, 또 한 번은 에이전트 소유자가 승인해야 한다. 비밀정보 업로드나 "Disregard that!"류의 악성 문구 유입을 막기 위해서다.

비용 문제에 대해서는, 대형 package index가 실제로는 완전히 빈곤하지 않다고 본다. Debian의 보안팀처럼 예외 처리를 할 수 있고, 상용 프로젝트에 대해서는 expedited review를 유료 서비스로 제공해 보안 운영비를 크로스서브시드할 수 있다고 제안한다. 결국 개인적으로는 합리적인 cooldown도, 공동체 차원에서는 무모한 기본값이 될 수 있으니, 저자는 분산된 냉각보다 중앙 upload queue가 더 나은 해법이라고 결론짓는다.