<div id="readability-page-1" class="page"><div><div><h2 id="7dbf" data-testid="storyTitle">(번역) 최소 릴리스 기간은 저평가된 공급망 방어 수단입니다</h2><div tabindex="-1"><a rel="noopener follow" href="/?source=post_page---byline--5265fd9c99e6---------------------------------------" data-discover="true"><div><img alt="한정(Han Jung)" src="https://miro.medium.com/v2/resize:fill:64:64/1*tQfG8hfW5vM4hbRVZucMrg.png" width="32" height="32" loading="lazy" data-testid="authorPhoto"></div></a></div></div><blockquote>&gt; 원문: <a href="https://daniakash.com/posts/simplest-supply-chain-defense/" rel="noopener ugc nofollow" target="_blank">https://daniakash.com/posts/simplest-supply-chain-defense/</a></blockquote>2026년 3월 31일, axios가 침해를 당했습니다.axios는 지구상의 거의 모든 자바스크립트 프로젝트에 들어 있는 HTTP 라이브러리입니다. 누군가가 메인테이너의 npm 토큰을 탈취해 두 개의 악성 버전을 배포했고, <code>npm install</code>을 실행한 지 2초 만에 크로스 플랫폼 RAT가 명령 및 제어 서버로 통신을 시작했습니다. macOS, Windows, Linux 모두 해당됐습니다. 악성 코드는 실행 후 스스로를 삭제하고 <code>package.json</code>을 교체해 흔적을 지우기까지 했습니다.주간 다운로드 1억 건. 클라우드 환경의 80%에 존재합니다. 악성 버전은 npm에서 삭제되기까지 약 4시간 동안 공개 상태로 있었습니다.하지만 제 기본 패키지 정책은 이 침해된 버전들을 거부했을 겁니다. 화려한 스캐닝 도구가 아니라, 설정 파일의 단 한 줄 덕분에요.<pre># ~/.bunfig.toml [install] minimumReleaseAge = 604800 # 7일(초 단위)</pre>패키지 매니저가 배포된 지 7일이 안 된 패키지 버전은 아예 설치를 거부합니다. 7일이 지날 때쯤이면 axios처럼 침해된 버전들은 이미 사라져 있습니다. 발견되고, 신고되고, 레지스트리에서 제거됩니다.한 줄짜리 설정입니다. 스캐닝 도구도 없고, 기업용 구독도 필요 없습니다. 그냥… 기다리는 것뿐입니다.<figure><figcaption><a href="https://unsplash.com/@aronvisuals?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText" rel="noopener ugc nofollow" target="_blank">Aron Visuals</a>의 사진, <a href="https://unsplash.com/photos/selective-focus-photo-of-brown-and-blue-hourglass-on-stones-BXOXnQ26B7o?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText" rel="noopener ugc nofollow" target="_blank">Unsplash</a>에서</figcaption></figure><h2 id="2e08">실제로 얼마나 효과적일까요?</h2>궁금해졌습니다. 7일 지연이 axios 침해를 막아냈다면, 다른 공격들은 얼마나 막을 수 있었을까요?그래서 지난 8년간 널리 알려진 공급망 침해 사례 21건을 살펴봤습니다. 2020년 12월 솔라윈즈(SolarWinds) 침해부터 2026년 3월 axios 침해까지 각 사례마다 노출 기간을 확인했습니다. 악성 코드가 배포된 시점부터 발견되어 삭제되기까지 얼마나 걸렸는지를요.결과는 다음과 같습니다.<figure></figure>이 표본에서, 7일 릴리스 기간 정책은 단기간에 악성 배포된 사례 11건에서 설치를 막을 수 있었을 것으로 보입니다. 반면, 장기적인 침투, 메인테이너의 고의 파괴, 빌드 시스템 침해에 대해서는 효과가 거의 없습니다. 두 건의 사례에서는 노출 기간을 줄이는 효과가 있었을 겁니다.<h2 id="00da">방법론에 대한 참고 사항</h2>이건 통제된 연구가 아닙니다. 2018년부터 2026년 사이에 보안 권고문, CISA 경보, 벤더 블로그에서 널리 보도된 21건의 사례를 조사한 것입니다. 개발자들이 가장 많이 들어봤을 법한 사례들을 골랐습니다.“노출 기간(Exposure window)”은 악성 버전이 배포된 시점부터 레지스트리에서 제거되거나 표시된 시점까지의 시간입니다. 침해된 릴리스가 7일 이내에 제거된 경우, 즉 릴리스 기간 정책이 일반적인 <code>install</code>이나 <code>update</code> 과정에서 해당 버전을 걸러냈을 경우를 "차단됐을 것"으로 분류했습니다. "효과 없음"은 공격이 7일 이상 지속됐거나, 레지스트리 패키지와 무관한 공격이거나, 악성 주입이 아닌 정상 코드의 취약점인 경우입니다.표본에는 비(非)레지스트리 사례(솔라윈즈, 3CX, Polyfill.io, Codecov)와 순수 취약점(Log4Shell)도 완전성을 위해 포함했습니다. 이 사례들은 릴리스 기간 정책에 불리한 방향으로 분모를 늘립니다. 악성 패키지 배포 공격만 놓고 보면 차단율은 더 높습니다.<h2 id="eeec">왜 이렇게 효과적일까요?</h2>대부분의 악성 패키지 공격은 같은 방식으로 진행됩니다. 공격자가 메인테이너의 자격 증명(피싱, 유출된 토큰, 침해된 CI)을 탈취하고 악성 버전을 배포하면 시간과의 싸움이 시작됩니다. 커뮤니티가 이상한 점을 알아채고, 보안 도구가 이를 표시합니다. 마지막으로, 레지스트리가 패키지를 내립니다.악성 배포부터 정리까지 이 전체 과정은 거의 항상 수 시간에서 수 일 내에 완료됩니다. axios 공격은 4시간 만에 끝났습니다. Solana web3.js는 5시간, ua-parser-js는 4시간, Ledger Connect Kit은 5시간이었습니다.이건 순식간에 치고 빠지는 방식입니다. 공격자도 시간이 촉박하다는 걸 압니다.7일 지연은 이미 일주일간 커뮤니티의 검증을 통과한 패키지만 설치한다는 의미입니다. 악성 코드가 있었다면 이미 발견되어 삭제된 상태입니다. 그 패키지는 눈에 들어오지도 않습니다.이렇게 생각해보세요. 문에 가장 먼저 들어가는 사람이 아닌 겁니다. 수천 명의 다른 개발자들을 먼저 들여보내는 거죠. 바닥에 덫이 놓여 있다면, 여러분이 발을 딛기 전에 다른 누군가가 먼저 발견할 겁니다.<h2 id="6bb9">언제 효과적이고, 언제 불편할까요?</h2>설정 방법에 들어가기 전에, 솔직한 주의 사항 몇 가지를 먼저 말씀드리겠습니다. 이 방법이 모든 상황에 적용되는 건 아닙니다.효과적인 경우<ul><li id="7565">의존성을 정기적으로 업데이트할 때 (지연은 패키지 해결 과정에서 적용되므로 <code>install</code>과 <code>update</code> 시점에 걸러냅니다)</li><li id="f9cb">semver 범위(<code>^</code> 또는 <code>~</code>)를 사용해 패키지 매니저가 최신 버전을 해결할 때</li><li id="249e">커뮤니티가 침해를 적극적으로 감시하는 공개 레지스트리를 사용할 때</li></ul>덜 효과적인 경우<ul><li id="8341">잠금 파일을 완전히 고정하고 의도적인 일정에 따라서만 업데이트할 때 (다만 지연은 업데이트 시에도 여전히 보호합니다)</li><li id="0e8f">내부 패키지를 직접 만들고 사용할 때 (이 경우 허용 목록/우회 설정이 필요합니다)</li><li id="b86f">긴급 보안 패치가 즉시 필요할 때 (이를 지원하는 모든 도구에는 바로 이런 경우를 위한 우회 옵션이 있습니다)</li></ul>대체할 수 없는 것들<ul><li id="71c1">잠금 파일과 <code>npm ci</code> / <code>pnpm install --frozen-lockfile</code></li><li id="ef4e">CI/CD에서 <code>--ignore-scripts</code>로 postinstall 훅 차단</li><li id="08d9">SHA가 고정된 GitHub Actions</li><li id="079d">출처 검증 및 아티팩트 증명</li><li id="b1c9">Socket.dev 같은 동작 분석 도구</li></ul>릴리스 기간을 심층 방어(defense-in-depth)의 한 레이어로 생각하세요. 추가하기가 매우 쉬우면서도 가장 흔한 공격 패턴에 놀랍도록 효과적인 레이어입니다.<h2 id="2f65">그럼 어떻게 설정하나요?</h2>흥미롭지만 다소 황당한 부분이 있습니다. 대부분의 주요 자바스크립트 패키지 매니저들이 이제 이 기능을 지원합니다. 하지만 이름도, 단위도, 아무것도 합의하지 못했습니다.Bun (초 단위):<pre># bunfig.toml [install] minimumReleaseAge = 604800</pre>npm (v11.10+, 일 단위):<pre># .npmrc min-release-age=7</pre>pnpm (v10.16+, 분 단위):<pre># pnpm-workspace.yaml minimumReleaseAge: 10080</pre>Yarn 4 (v4.10+, 기간 문자열):<pre># .yarnrc.yml npmMinimalAgeGate: "7d"</pre>같은 개념인데 설정 이름은 네 가지입니다. 단위도 네 가지고요. <code>minimumReleaseAge</code>, <code>min-release-age</code>, <code>minimumReleaseAge</code>(이번엔 분 단위), <code>npmMinimalAgeGate</code>. 초, 일, 분, 기간 문자열입니다.꾸며낸 이야기가 아닙니다.<h2 id="c274">자바스크립트 이외의 생태계</h2>파이썬 생태계도 이를 따라가고 있습니다.uv (v0.9.17+):<pre># pyproject.toml [tool.uv] exclude-newer = "7d"</pre>pip (v26.0+):<pre>pip install --uploaded-prior-to=2026-03-24T00:00:00Z package-name</pre>pip는 상대적 기간이 아닌 절대 타임스탬프만 지원합니다. 매번 날짜를 수동으로 업데이트해야 합니다. 그다지 좋은 방식이 아닙니다.Deno는 CLI 플래그로 제공합니다.<pre>deno update --minimum-dependency-age=7d</pre>Cargo(Rust)에는 실험적인 불안정 플래그가 있으며, <code>cargo-cooldown</code>이라는 서드파티 도구도 있습니다.Go, Maven, Gradle, Composer, Bundler? 지원 없습니다. 제안조차 없는 것들도 있습니다. Java, Go, PHP 생태계를 사용 중이라면 패키지 매니저 수준에서는 방법이 없습니다.<h2 id="4efa">의존성 봇도 잊지 마세요</h2>Renovate나 Dependabot으로 의존성을 최신 상태로 유지한다면, 이 도구들에도 자체적인 지연 메커니즘이 있습니다.Renovate:<pre>{ "minimumReleaseAge": "7 days", "packageRules": [ { "matchPackageNames": ["*"], "minimumReleaseAge": "14 days" } ] }</pre>Dependabot:<pre># .github/dependabot.yml cooldown: default-days: 7 semver-major-days: 14 semver-minor-days: 7 semver-patch-days: 3</pre>두 도구 모두 보안 업데이트는 지연을 우회합니다. 올바른 선택입니다. CVE 패치가 나오면 바로 적용받아야 하니까요.<h2 id="0f68">이 방법으로 잡을 수 없는 것들</h2>제 표본의 21건 중 8건은 릴리스 기간 정책으로는 막을 수 없었을 겁니다. 이 사례들은 몇 가지 뚜렷한 범주로 나뉩니다.장기적인 침투. XZ Utils 백도어는 누군가가 2년에 걸쳐 메인테이너로서 신뢰를 쌓은 뒤 심어놓은 것입니다. event-stream 공격은 발견까지 2개월이 걸렸습니다. 공격자가 충분히 인내심을 가지고 기다린다면 7일 보류는 소용없습니다.메인테이너의 고의 파괴. colors.js 소유자가 항의 차원에서 라이브러리를 망가뜨리거나, node-ipc 메인테이너가 러시아 기기의 파일을 삭제하는 코드를 추가한 경우는 어떤 지연으로도 막을 수 없습니다. 메인테이너 자체가 신뢰받는 당사자이기 때문입니다.빌드 시스템 침해. 솔라윈즈와 3CX는 패키지 레지스트리 공격이 아니었습니다. 악성 코드는 독점 소프트웨어의 빌드 과정에 주입됐습니다. 패키지 매니저 설정으로는 손쓸 수 없습니다.CDN 및 인프라 공격. Polyfill.io는 도메인 탈취였습니다. Codecov는 자체 서버의 배시(bash) 스크립트가 변조된 것입니다. 이건 레지스트리 패키지가 아닙니다.정상 코드의 취약점. Log4Shell은 2013년부터 존재하던 실제 라이브러리의 버그였습니다. 릴리스 자체는 악성이 아니었습니다. 코드에 결함이 있었던 것뿐입니다.이런 범주들에는 다른 도구가 필요합니다. 잠금 파일 고정, Socket.dev 같은 동작 분석 도구, SBOM 생성, SHA가 고정된 GitHub Actions, 재현 가능한 빌드 등이 그것입니다.<h2 id="7b50">생태계의 절반은 여전히 무방비 상태</h2>자바스크립트와 파이썬 개발자는 지금 당장 설정할 수 있습니다. 하지만 Go, Java, PHP, Ruby를 쓴다면? 방법이 없습니다.생태계지원 현황npm, pnpm, Yarn 4, Bun, Deno완전 지원uv, pip지원 (pip는 불편)Cargo (Rust)실험적 / 서드파티RubyGems커뮤니티 레지스트리 베타만Go 모듈없음Maven / Gradle없음Composer없음Go에는 공개 제안조차 없습니다. Maven과 Gradle에는 알려진 논의가 없습니다. Composer에는 저장소에 기능 요청이 올라와 있습니다. 이 생태계들은 거대한 프로덕션 인프라를 운영하지만, 공급망 보안에서 가장 흔한 공격 패턴에 대한 내장 보호 기능이 전혀 없습니다.지원 목록에 없는 패키지 매니저를 관리하고 있다면, 이 기능이 최우선 기능 요청이 되어야 합니다. 또 다른 스캐닝 통합이 아닙니다. 또 다른 증명 명세도 아닙니다. 새 패키지에 대한 단순하고 설정 가능한 지연입니다.<h2 id="7410">이름이라도 통일할 수 있을까요?</h2>이 기능을 지원하는 도구들 사이에서도 명명 상황은 꽤 고통스럽습니다.도구설정단위Bun<code>minimumReleaseAge</code>초pnpm<code>minimumReleaseAge</code>분npm<code>min-release-age</code>일Yarn 4<code>npmMinimalAgeGate</code>기간 문자열uv<code>exclude-newer</code>기간 / 절대 날짜pip<code>--uploaded-prior-to</code>절대 타임스탬프Renovate<code>minimumReleaseAge</code>기간 문자열Dependabot<code>cooldown</code>일Bun과 pnpm은 설정 이름이 같은데 단위가 다릅니다. npm은 같은 개념이지만 케밥 표기법을 씁니다. Yarn은 어째서인지 <code>npmMinimalAgeGate</code>를 택했습니다. pip는 "7일"이라고 하는 대신 날짜를 직접 계산하게 만듭니다.폴리글랏(polyglot) 모노레포에서 이걸 설정한다면, 같은 기능을 위해 초, 분, 일, 기간 문자열을 머릿속에서 변환해야 합니다. 같은 기능인데 말이죠. 똑같은 일을 하는 기능이요.가벼운 명세가 나올 여지가 있습니다. 비공식적인 관례라도 좋습니다. <code>minimumReleaseAge</code>로 부르고, ISO 8601 기간 형식이나 단순 일 수를 사용하고, 그냥 넘어가면 됩니다.<h2 id="e102">왜 기본값이 아닐까요?</h2>npm에는 실제로 7일을 기본값으로 만들자는 공개 제안이 있습니다. 타당한 이야기입니다. 대다수의 개발자는 패키지가 배포된 즉시 필요하지 않습니다. 일주일을 기다려도 됩니다. 최신 릴리스가 진짜 필요한 드문 경우(긴급 핫픽스, 보안 패치)를 위해, 이를 지원하는 모든 도구에는 우회 옵션이 있습니다.하지만 기본값은 중요합니다. 지금 모든 패키지 매니저는 암묵적으로 <code>minimumReleaseAge = 0</code>을 기본값으로 사용합니다. 30초 전에 배포된 패키지도 아무 문제없이 설치됩니다. 생태계의 보안 태세 전체가 옵트인 방식이고, 대부분의 개발자는 이런 설정이 있는지조차 모릅니다.우리는 점점 더 정교한 스캐닝 도구, 출처 시스템, 증명 프레임워크를 만들어왔습니다. 그것들은 중요합니다. 하지만 가장 단순한 방어 수단 하나를 놓치고 있었습니다. 그냥 조금만 기다리는 것입니다.axios 공격자에게 주어진 시간은 4시간이었습니다. Solana web3.js 공격자는 5시간, Ledger Connect Kit 공격자는 5시간, ua-parser-js는 4시간이었습니다.그 모든 창문이 7일째 되기 전에 닫힙니다. 예외 없이.</div><div>패키지 매니저가 이 기능을 지원한다면, 서드파티 패키지에 대해 기본적으로 3~7일의 릴리스 기간을 적용하는 것을 고려해보세요. 긴급 업데이트를 위한 우회 경로는 열어두세요. 심층 방어의 한 레이어로 다루세요.패키지 매니저가 아직 지원하지 않는다면, 이슈를 열어보세요.최고의 보안이 항상 가장 복잡한 것은 아닙니다. 때로는 설치하기 전에 뭔가 잘못됐다는 것을 세상이 알아차릴 수 있도록 충분한 시간을 주는 것뿐입니다.</div></div>

Stories by Jung Han on Medium

한정

> 원문: https://daniakash.com/posts/simplest-supply-chain-defense/
2026년 3월 31일, axios가 침해를 당했습니다.
axios는 지구상의 거의 모든 자바스크립트 프로젝트에 들어 있는 HTTP 라이브러리입니다. 누군가가 메인테이너의 npm 토큰을 탈취해 두 개의 악성 버전을 배포했고, npm install을 실행한 지 2초 만에 크로스 플랫폼 RAT가 명령 및 제어 서버로 통신을 시작했습니다. macOS, Windows, Linux 모두 해당됐습니다. 악성 코드는 실행 후 스스로를 삭제하고 package.json을 교체해 흔적을 지우기까지 했습니다.
주간 다운로드 1억 건. 클라우드 환경의 80%에 존재합니다. 악성 버전은 npm에서 삭제되기까지 약 4시간 동안 공개 상태로 있었습니다.
하지만 제 기본 패키지 정책은 이 침해된 버전들을 거부했을 겁니다. 화려한 스캐닝 도구가 아니라, 설정 파일의 단 한 줄 덕분에요.
# ~/.bunfig.toml
[install]
minimumReleaseAge = 604800  # 7일(초 단위)
패키지 매니저가 배포된 지 7일이 안 된 패키지 버전은 아예 설치를 거부합니다. 7일이 지날 때쯤이면 axios처럼 침해된 버전들은 이미 사라져 있습니다. 발견되고, 신고되고, 레지스트리에서 제거됩니다.
한 줄짜리 설정입니다. 스캐닝 도구도 없고, 기업용 구독도 필요 없습니다. 그냥… 기다리는 것뿐입니다.
실제로 얼마나 효과적일까요?
궁금해졌습니다. 7일 지연이 axios 침해를 막아냈다면, 다른 공격들은 얼마나 막을 수 있었을까요?
그래서 지난 8년간 널리 알려진 공급망 침해 사례 21건을 살펴봤습니다. 2020년 12월 솔라윈즈(SolarWinds) 침해부터 2026년 3월 axios 침해까지 각 사례마다 노출 기간을 확인했습니다. 악성 코드가 배포된 시점부터 발견되어 삭제되기까지 얼마나 걸렸는지를요.
결과는 다음과 같습니다.
https://medium.com/media/690cca6a2002510204d8f95149155702/href
이 표본에서, 7일 릴리스 기간 정책은 단기간에 악성 배포된 사례 11건에서 설치를 막을 수 있었을 것으로 보입니다. 반면, 장기적인 침투, 메인테이너의 고의 파괴, 빌드 시스템 침해에 대해서는 효과가 거의 없습니다. 두 건의 사례에서는 노출 기간을 줄이는 효과가 있었을 겁니다.
방법론에 대한 참고 사항
이건 통제된 연구가 아닙니다. 2018년부터 2026년 사이에 보안 권고문, CISA 경보, 벤더 블로그에서 널리 보도된 21건의 사례를 조사한 것입니다. 개발자들이 가장 많이 들어봤을 법한 사례들을 골랐습니다.
“노출 기간(Exposure window)”은 악성 버전이 배포된 시점부터 레지스트리에서 제거되거나 표시된 시점까지의 시간입니다. 침해된 릴리스가 7일 이내에 제거된 경우, 즉 릴리스 기간 정책이 일반적인 install이나 update 과정에서 해당 버전을 걸러냈을 경우를 "차단됐을 것"으로 분류했습니다. "효과 없음"은 공격이 7일 이상 지속됐거나, 레지스트리 패키지와 무관한 공격이거나, 악성 주입이 아닌 정상 코드의 취약점인 경우입니다.
표본에는 비(非)레지스트리 사례(솔라윈즈, 3CX, Polyfill.io, Codecov)와 순수 취약점(Log4Shell)도 완전성을 위해 포함했습니다. 이 사례들은 릴리스 기간 정책에 불리한 방향으로 분모를 늘립니다. 악성 패키지 배포 공격만 놓고 보면 차단율은 더 높습니다.
왜 이렇게 효과적일까요?
대부분의 악성 패키지 공격은 같은 방식으로 진행됩니다. 공격자가 메인테이너의 자격 증명(피싱, 유출된 토큰, 침해된 CI)을 탈취하고 악성 버전을 배포하면 시간과의 싸움이 시작됩니다. 커뮤니티가 이상한 점을 알아채고, 보안 도구가 이를 표시합니다. 마지막으로, 레지스트리가 패키지를 내립니다.
악성 배포부터 정리까지 이 전체 과정은 거의 항상 수 시간에서 수 일 내에 완료됩니다. axios 공격은 4시간 만에 끝났습니다. Solana web3.js는 5시간, ua-parser-js는 4시간, Ledger Connect Kit은 5시간이었습니다.
이건 순식간에 치고 빠지는 방식입니다. 공격자도 시간이 촉박하다는 걸 압니다.
7일 지연은 이미 일주일간 커뮤니티의 검증을 통과한 패키지만 설치한다는 의미입니다. 악성 코드가 있었다면 이미 발견되어 삭제된 상태입니다. 그 패키지는 눈에 들어오지도 않습니다.
이렇게 생각해보세요. 문에 가장 먼저 들어가는 사람이 아닌 겁니다. 수천 명의 다른 개발자들을 먼저 들여보내는 거죠. 바닥에 덫이 놓여 있다면, 여러분이 발을 딛기 전에 다른 누군가가 먼저 발견할 겁니다.
언제 효과적이고, 언제 불편할까요?
설정 방법에 들어가기 전에, 솔직한 주의 사항 몇 가지를 먼저 말씀드리겠습니다. 이 방법이 모든 상황에 적용되는 건 아닙니다.
효과적인 경우
의존성을 정기적으로 업데이트할 때 (지연은 패키지 해결 과정에서 적용되므로 install과 update 시점에 걸러냅니다)
semver 범위(^ 또는 ~)를 사용해 패키지 매니저가 최신 버전을 해결할 때
커뮤니티가 침해를 적극적으로 감시하는 공개 레지스트리를 사용할 때
덜 효과적인 경우
잠금 파일을 완전히 고정하고 의도적인 일정에 따라서만 업데이트할 때 (다만 지연은 업데이트 시에도 여전히 보호합니다)
내부 패키지를 직접 만들고 사용할 때 (이 경우 허용 목록/우회 설정이 필요합니다)
긴급 보안 패치가 즉시 필요할 때 (이를 지원하는 모든 도구에는 바로 이런 경우를 위한 우회 옵션이 있습니다)
대체할 수 없는 것들
잠금 파일과 npm ci / pnpm install --frozen-lockfile
CI/CD에서 --ignore-scripts로 postinstall 훅 차단
SHA가 고정된 GitHub Actions
출처 검증 및 아티팩트 증명
Socket.dev 같은 동작 분석 도구
릴리스 기간을 심층 방어(defense-in-depth)의 한 레이어로 생각하세요. 추가하기가 매우 쉬우면서도 가장 흔한 공격 패턴에 놀랍도록 효과적인 레이어입니다.
그럼 어떻게 설정하나요?
흥미롭지만 다소 황당한 부분이 있습니다. 대부분의 주요 자바스크립트 패키지 매니저들이 이제 이 기능을 지원합니다. 하지만 이름도, 단위도, 아무것도 합의하지 못했습니다.
Bun (초 단위):
# bunfig.toml
[install]
minimumReleaseAge = 604800
npm (v11.10+, 일 단위):
# .npmrc
min-release-age=7
pnpm (v10.16+, 분 단위):
# pnpm-workspace.yaml
minimumReleaseAge: 10080
Yarn 4 (v4.10+, 기간 문자열):
# .yarnrc.yml
npmMinimalAgeGate: "7d"
같은 개념인데 설정 이름은 네 가지입니다. 단위도 네 가지고요. minimumReleaseAge, min-release-age, minimumReleaseAge(이번엔 분 단위), npmMinimalAgeGate. 초, 일, 분, 기간 문자열입니다.
꾸며낸 이야기가 아닙니다.
자바스크립트 이외의 생태계
파이썬 생태계도 이를 따라가고 있습니다.
uv (v0.9.17+):
# pyproject.toml
[tool.uv]
exclude-newer = "7d"
pip (v26.0+):
pip install --uploaded-prior-to=2026-03-24T00:00:00Z package-name
pip는 상대적 기간이 아닌 절대 타임스탬프만 지원합니다. 매번 날짜를 수동으로 업데이트해야 합니다. 그다지 좋은 방식이 아닙니다.
Deno는 CLI 플래그로 제공합니다.
deno update --minimum-dependency-age=7d
Cargo(Rust)에는 실험적인 불안정 플래그가 있으며, cargo-cooldown이라는 서드파티 도구도 있습니다.
Go, Maven, Gradle, Composer, Bundler? 지원 없습니다. 제안조차 없는 것들도 있습니다. Java, Go, PHP 생태계를 사용 중이라면 패키지 매니저 수준에서는 방법이 없습니다.
의존성 봇도 잊지 마세요
Renovate나 Dependabot으로 의존성을 최신 상태로 유지한다면, 이 도구들에도 자체적인 지연 메커니즘이 있습니다.
Renovate:
{
  "minimumReleaseAge": "7 days",
  "packageRules": [
    {
      "matchPackageNames": ["*"],
      "minimumReleaseAge": "14 days"
    }
  ]
}
Dependabot:
# .github/dependabot.yml
cooldown:
  default-days: 7
  semver-major-days: 14
  semver-minor-days: 7
  semver-patch-days: 3
두 도구 모두 보안 업데이트는 지연을 우회합니다. 올바른 선택입니다. CVE 패치가 나오면 바로 적용받아야 하니까요.
이 방법으로 잡을 수 없는 것들
제 표본의 21건 중 8건은 릴리스 기간 정책으로는 막을 수 없었을 겁니다. 이 사례들은 몇 가지 뚜렷한 범주로 나뉩니다.
장기적인 침투. XZ Utils 백도어는 누군가가 2년에 걸쳐 메인테이너로서 신뢰를 쌓은 뒤 심어놓은 것입니다. event-stream 공격은 발견까지 2개월이 걸렸습니다. 공격자가 충분히 인내심을 가지고 기다린다면 7일 보류는 소용없습니다.
메인테이너의 고의 파괴. colors.js 소유자가 항의 차원에서 라이브러리를 망가뜨리거나, node-ipc 메인테이너가 러시아 기기의 파일을 삭제하는 코드를 추가한 경우는 어떤 지연으로도 막을 수 없습니다. 메인테이너 자체가 신뢰받는 당사자이기 때문입니다.
빌드 시스템 침해. 솔라윈즈와 3CX는 패키지 레지스트리 공격이 아니었습니다. 악성 코드는 독점 소프트웨어의 빌드 과정에 주입됐습니다. 패키지 매니저 설정으로는 손쓸 수 없습니다.
CDN 및 인프라 공격. Polyfill.io는 도메인 탈취였습니다. Codecov는 자체 서버의 배시(bash) 스크립트가 변조된 것입니다. 이건 레지스트리 패키지가 아닙니다.
정상 코드의 취약점. Log4Shell은 2013년부터 존재하던 실제 라이브러리의 버그였습니다. 릴리스 자체는 악성이 아니었습니다. 코드에 결함이 있었던 것뿐입니다.
이런 범주들에는 다른 도구가 필요합니다. 잠금 파일 고정, Socket.dev 같은 동작 분석 도구, SBOM 생성, SHA가 고정된 GitHub Actions, 재현 가능한 빌드 등이 그것입니다.
생태계의 절반은 여전히 무방비 상태
자바스크립트와 파이썬 개발자는 지금 당장 설정할 수 있습니다. 하지만 Go, Java, PHP, Ruby를 쓴다면? 방법이 없습니다.
생태계지원 현황npm, pnpm, Yarn 4, Bun, Deno완전 지원uv, pip지원 (pip는 불편)Cargo (Rust)실험적 / 서드파티RubyGems커뮤니티 레지스트리 베타만Go 모듈없음Maven / Gradle없음Composer없음
Go에는 공개 제안조차 없습니다. Maven과 Gradle에는 알려진 논의가 없습니다. Composer에는 저장소에 기능 요청이 올라와 있습니다. 이 생태계들은 거대한 프로덕션 인프라를 운영하지만, 공급망 보안에서 가장 흔한 공격 패턴에 대한 내장 보호 기능이 전혀 없습니다.
지원 목록에 없는 패키지 매니저를 관리하고 있다면, 이 기능이 최우선 기능 요청이 되어야 합니다. 또 다른 스캐닝 통합이 아닙니다. 또 다른 증명 명세도 아닙니다. 새 패키지에 대한 단순하고 설정 가능한 지연입니다.
이름이라도 통일할 수 있을까요?
이 기능을 지원하는 도구들 사이에서도 명명 상황은 꽤 고통스럽습니다.
도구설정단위BunminimumReleaseAge초pnpmminimumReleaseAge분npmmin-release-age일Yarn 4npmMinimalAgeGate기간 문자열uvexclude-newer기간 / 절대 날짜pip--uploaded-prior-to절대 타임스탬프RenovateminimumReleaseAge기간 문자열Dependabotcooldown일
Bun과 pnpm은 설정 이름이 같은데 단위가 다릅니다. npm은 같은 개념이지만 케밥 표기법을 씁니다. Yarn은 어째서인지 npmMinimalAgeGate를 택했습니다. pip는 "7일"이라고 하는 대신 날짜를 직접 계산하게 만듭니다.
폴리글랏(polyglot) 모노레포에서 이걸 설정한다면, 같은 기능을 위해 초, 분, 일, 기간 문자열을 머릿속에서 변환해야 합니다. 같은 기능인데 말이죠. 똑같은 일을 하는 기능이요.
가벼운 명세가 나올 여지가 있습니다. 비공식적인 관례라도 좋습니다. minimumReleaseAge로 부르고, ISO 8601 기간 형식이나 단순 일 수를 사용하고, 그냥 넘어가면 됩니다.
왜 기본값이 아닐까요?
npm에는 실제로 7일을 기본값으로 만들자는 공개 제안이 있습니다. 타당한 이야기입니다. 대다수의 개발자는 패키지가 배포된 즉시 필요하지 않습니다. 일주일을 기다려도 됩니다. 최신 릴리스가 진짜 필요한 드문 경우(긴급 핫픽스, 보안 패치)를 위해, 이를 지원하는 모든 도구에는 우회 옵션이 있습니다.
하지만 기본값은 중요합니다. 지금 모든 패키지 매니저는 암묵적으로 minimumReleaseAge = 0을 기본값으로 사용합니다. 30초 전에 배포된 패키지도 아무 문제없이 설치됩니다. 생태계의 보안 태세 전체가 옵트인 방식이고, 대부분의 개발자는 이런 설정이 있는지조차 모릅니다.
우리는 점점 더 정교한 스캐닝 도구, 출처 시스템, 증명 프레임워크를 만들어왔습니다. 그것들은 중요합니다. 하지만 가장 단순한 방어 수단 하나를 놓치고 있었습니다. 그냥 조금만 기다리는 것입니다.
axios 공격자에게 주어진 시간은 4시간이었습니다. Solana web3.js 공격자는 5시간, Ledger Connect Kit 공격자는 5시간, ua-parser-js는 4시간이었습니다.
그 모든 창문이 7일째 되기 전에 닫힙니다. 예외 없이.
패키지 매니저가 이 기능을 지원한다면, 서드파티 패키지에 대해 기본적으로 3~7일의 릴리스 기간을 적용하는 것을 고려해보세요. 긴급 업데이트를 위한 우회 경로는 열어두세요. 심층 방어의 한 레이어로 다루세요.
패키지 매니저가 아직 지원하지 않는다면, 이슈를 열어보세요.
최고의 보안이 항상 가장 복잡한 것은 아닙니다. 때로는 설치하기 전에 뭔가 잘못됐다는 것을 세상이 알아차릴 수 있도록 충분한 시간을 주는 것뿐입니다.

(번역) 최소 릴리스 기간은 저평가된 공급망 방어 수단입니다

댓글