axios 및 Shai-Hulud를 대상으로 테스트를 거친 보안 npm 레지스트리

이 블로그 글의 AI 요약으로 바로 가기

주요 내용

Third Coming과 Miasma는 도난당한 장기 유효한 유지보수자 토큰이 아닌, 신뢰할 수 있는 CI 배포 경로를 악용했습니다.
게시물을 심사하는 레지스트리는 인증 결과가 정상으로 확인되더라도 해당 게시물을 적발할 수 있습니다.
SecureChain이 지원하는 패키지의 경우, 검증된 소스 코드를 사용하여 다시 빌드하면 도난당한 인증 정보를 이용한 재게시가 빌드 과정에 포함되는 것을 방지할 수 있습니다.
격리 기간은 악성 버전이 지연 시간이 만료되기 전에 제거될 경우에만 도움이 됩니다.

npm 보안 침해 사고가 꽤 자주 발생하다 보니, 매번 똑같은 후속 질문이 제기됩니다. 안전한 npm 레지스트리가 있었다면 이번 사고를 실제로 막을 수 있었을까요? 그 답은 보안 메커니즘에 따라 달라지는데, 바로 이 부분이 대부분의 공급업체가 설명에서 생략하는 부분입니다.

이 글에서는 SecureChain의 실제 통제 수단을 2026년에 발생한 네 가지 사건, 즉 axios, jscrambler, Shai-Hulud의 “Third Coming”, 그리고 Miasma와 대조하여 살펴봅니다. 각 사건은 이를 탐지하는 메커니즘과 매핑되며, 해당 매핑이 어느 정도의 신뢰도를 얻는지 함께 제시됩니다.

네 가지 별개의 사건이 아니라 두 가지 근본 원인

네 가지 캠페인을 작동 방식에 따라 나열해 보면, 네 그룹이 아니라 두 그룹으로 나뉩니다.

axios와 jscrambler 사건 모두, 프로젝트 자체의 CI 프로세스를 완전히 우회하여 레지스트리에 직접 악용된 도난당한 게시 자격 증명이 원인이었습니다. axios의 경우, 공격자는 표적형 사회공학 공격을 통해 수석 관리자의 컴퓨터에 접근한 뒤, 3월 31일에 두 개의 악성 버전을 수동으로 게시했습니다. 소스 저장소는 전혀 건드리지 않았으며, 두 릴리스 모두 해당 저장소 내 어디에도 커밋이나 태그가 남아 있지 않습니다. 7월에 발생한 jscrambler 사건도 동일한 수법을 따랐습니다. jscrambler 측은 이후 공격자가 유출된 npm 게시 자격 증명을 이용해 약 3시간 동안 5개의 악성 버전을 푸시했으며, 이 역시 저장소 내에는 해당 릴리스와 관련된 어떠한 기록도 남아 있지 않았음을 확인했습니다.

Third Coming과 Miasma는 이러한 패턴에 부합하지 않으며, 바로 그 차이점 때문에 단순히 관련 글에 링크를 걸기만 하는 대신 이 글을 작성하게 되었습니다. 두 사례 모두 유지보수자의 npm 토큰이 아닌 빌드 파이프라인을 통해 침투가 이루어졌습니다. Bitwarden의 경우, 침입 경로는 Bitwarden 자체 파이프라인에서 이미 사용 중이던 해킹당한 Checkmarx GitHub Action이었으며, 이후 릴리스 워크플로가 반복적으로 수정되어 사전 빌드된 타르볼이 Bitwarden의 OIDC 기반 npm 게시 경로를 통해 공개되었습니다. Miasma의 경우, Red Hat 직원의 GitHub 계정이 해킹당한 후 6월 1일 Red Hat의 @redhat-cloud-services 범위 내 최소 32개 패키지가 악성 릴리스를 배포했습니다. 공격자는 코드 검토 과정을 완전히 우회하는 ‘오펀 커밋(orphan commits)’을 푸시한 뒤, 리포지토리의 GitHub Actions OIDC 경로를 통해 배포했습니다. 두 공격자 모두 배포가 합법적으로 보이도록 하기 위해 유지보수자의 npm 자격 증명이 필요하지 않았습니다.

이러한 구분은 평가에 있어 중요합니다. Miasma가 이를 잘 보여주는 사례입니다. Wiz는 OIDC 토큰을 요청하고 유효한 SLSA 출처 증명서를 포함한 패키지를 배포하는 주입된 워크플로를 발견했는데, 이는 해당 패키지를 생성한 워크플로가 실제로는 정당한 CI 파이프라인이었으나, 아무도 승인하지 않은 커밋에 의해 실행된 것뿐이었기 때문입니다.

'Third Coming'의 경우 상황은 더 불분명합니다. Endor Labs가 공개 커밋 내역을 조사한 결과, 단계별 tarball을 게시하기 위해 릴리스 워크플로가 연달아 다섯 번 수정된 사실을 발견했습니다. 그 중 한 번의 시도에서는 출처 플래그가 아예 제거되기도 했으며, 분석 결과 성공적인 게시를 특정 실행에 귀속시키거나 서명된 사고 대응 타임라인으로 해석하는 것을 명시적으로 배제하고 있습니다.

어느 쪽이든 요점은 변함없습니다. 수명이 긴 토큰을 ‘신뢰할 수 있는 게시(Trusted Publishing)’로 대체하는 것은 axios와 같은 자격 증명 도용 사고 발생 후 권장되는 조치 그 자체이며, 두 사례 모두 그 조언이 한계에 부딪히는 지점을 보여줍니다. 왜냐하면 침해당한 파이프라인은 최종적으로 정상적인 인증서가 첨부되든 안 되든 상관없이 겉보기에는 합법적인 게시물을 생성할 수 있기 때문입니다. 녹색 인증서만 확인하는 레지스트리라면 Miasma를 아예 놓쳤을 것이며, Third Coming도 잡아냈다고 가정할 수 없습니다.

이름 짓는 전통도 이어졌다. 8월에는 “Here We Go Again”이라는 해시태그를 단 또 다른 캠페인이 등장했다. 이는 ‘Third Coming’의 반복이 아니라, 그 자체로 별개의 사건이다.

보안 npm 레지스트리가 파이프라인에 도달하는 항목을 어떻게 탐지하는가

이 부분이 ‘Third Coming’과 ‘Miasma’에 있어 중요한데, 두 경우 모두 해당 퍼블리시가 신뢰할 수 있는 워크플로우에서 비롯되었는지 여부를 확인하는 방식으로는 탐지되지 않기 때문입니다. 두 경우 모두 신뢰할 수 있는 CI 퍼블리싱 경로를 통해 이루어졌습니다.

설치 스크립트 차단이 더 이상 도움이 되지 않는 경우

npm은 별도의 차단 조치가 없는 한 패키지의 설치 스크립트를 자동으로 실행하며, 이는 대부분의 공격 캠페인이 가장 먼저 활용한 방식입니다. 악성 axios 종속성은 postinstall 훅을 통해 실행되었습니다. jscrambler의 첫 세 가지 변종은 preinstall을 사용했으며, 백도어가 삽입된 Bitwarden CLI와 Miasma 릴리스의 주요 파동 역시 마찬가지였습니다.

~ 기준 npm 12, 2026년 7월에 출시된 이 버전에서는 의존성 설치 스크립트가 기본적으로 비활성화되어 있습니다. 프로젝트에서 명시적으로 승인하지 않는 한 preinstall, install, postinstall이 더 이상 실행되지 않으며, npm은 루트 레벨에서 수행되는 암시적인 node-gyp 재구축도 차단합니다. binding.gyp 트리거하는 데 사용된 파일. 여기서 두 번째 부분은 단순한 이론적 논의가 아닙니다. Wiz가 6월 4일에 발표한 후속 보고서에 따르면, 미아스마(Miasma) 패키지를 악용하는 또 다른 공격 물결이 발생했기 때문입니다. binding.gyp 설치 중에 코드를 실행하는 것인데, 이는 스캐너가 스크립트 블록만 읽을 때 정확히 취하게 되는 조치입니다. 구형 클라이언트의 경우, --ignore-scripts 라이프사이클 스크립트의 일부만을 다루며, 그 외의 내용은 다루지 않습니다.

그리고 한 가지 한계가 있는데, jscrambler가 같은 사건에서 이를 시연했습니다. 8.18.0 버전부터 공격자는 동일한 드로퍼를 preinstall에서 제거하고, 파일 상단에 있는 자동 실행 함수로 옮겼습니다. dist/index.js, 그래서 설치 시점이 아니라 가져오기나 CLI 사용 시에 실행되어 아무 문제 없이 순조롭게 진행되었습니다 npm install --ignore-scripts. 공격자는 페이로드를 이동시킬 수 있습니다. 설치 스크립트를 차단한다고 해서 패키지에서 페이로드가 제거되는 것은 아닙니다.

콘텐츠 심사가 확인 절차를 간과하는 이유

‘Third Coming’과 ‘Miasma’에 실제로 대응하는 제어 메커니즘은 한 단계 앞서 위치하며, 게시자가 아닌 릴리스를 분석합니다. 콘텐츠 심사를 통해 예상치 못한 설치 후크, 존재할 이유가 없는 난독화된 코드, 게시된 아티팩트와 프로젝트 소스 간의 불일치, 그리고 버전 간에 나타나는 이상 현상을 탐지할 수 있습니다. Bitwarden 릴리스 사례는 이러한 마지막 신호가 얼마나 뚜렷하게 나타날 수 있는지 보여줍니다. Endor Labs의 재귀적 차이 분석(recursive diff)을 통해 발견된 바에 따르면 package.json 2026.4.0 버전을 광고하고 있었지만, 번들로 제공된 CLI의 압축된 메타데이터에는 여전히 2026.3.0 버전이 포함되어 있었는데, 이는 누군가가 디컴파일하기 훨씬 전에 재포장되었음을 시사한다.

SecureChain 측의 설명에 따르면, 이 단계에서는 모든 패키지가 강화되고 격리된 환경에서 소스 코드부터 재컴파일되며, 알려진 악성코드, 의심스러운 코드 패턴, 공급망 위험 요소에 대한 검사를 거치게 되며, 검사에서 불합격된 항목은 사용자의 환경에 도달하기 전에 차단됩니다. 이러한 기준에 따른 검사에서는 게시물이 해킹당한 개인 토큰을 통해 전송되었는지, 아니면 흠잡을 데 없는 인증서를 가진 침해된 CI 파이프라인을 통해 전송되었는지 여부는 중요하지 않습니다. 왜냐하면 인증서 자체가 검사 대상이 아니기 때문입니다.

이 부분에 대한 신뢰도는 중간에서 높은 수준이며, 스크립트 차단에 적용되는 것과 동일한 주의 사항이 있습니다. 이는 탐지 과정이며, 탐지에는 오탐률이 따르기 마련입니다. 악성코드는 자신의 동작을 지연시키거나, 위장하거나, 분할할 수 있으며, jscrambler가 사고 도중 전략을 전환한 사례는 공격자들이 스캐너가 감지하려는 대상에 따라 적응한다는 사실을 잘 상기시켜 줍니다. 이 도구는 릴리스의 정체성을 맹신하기보다는 릴리스의 내용을 직접 평가하기 때문에, 이 목록에 있는 도구 중 ‘Third Coming’과 ‘Miasma’를 그들만의 관점에서 대응할 수 있는 가장 가까운 도구입니다.

도용된 인증 정보를 이용한 탈취 공격에 대비한 npm 레지스트리 대체 솔루션, SecureChain

axios와 jscrambler는 더 깔끔한 사례이며, 바로 이런 상황에서 npm 레지스트리 대체 솔루션이 최소한의 위험 분산만으로도 그 가치를 입증합니다.

빌드 시 엄선되고 소스 코드에서 재컴파일된 카탈로그를 참조하도록 설정하면, SecureChain이 지원하는 모든 패키지에 대해, npmjs.com에 가장 최근에 업로드된 버전이 아닌, TuxCare가 보안이 강화된 환경에서 검증된 소스 코드를 기반으로 빌드한 버전이 적용됩니다. 도난당한 토큰으로 게시된 악성 타르볼은 해당 경로에 아예 존재하지 않습니다. 패키징이 아무리 설득력 있게 되어 있거나 다른 곳에서 얼마나 빨리 신고되든 상관없습니다. 여러분의 빌드는 공개 레지스트리의 사본을 절대 참조하지 않을 것이기 때문입니다. jscrambler의 침해 사례는 구조적으로 axios와 동일하지만 패키지 이름만 다른 것이므로, 동일한 보장이 두 경우 모두에 적용됩니다.

두 가지 사항에 대해 명확히 할 필요가 있는데, 이 두 가지를 혼동하는 것이 바로 이 주장이 과대포장되는 원인이기 때문입니다. 첫 번째는 ‘커버리지’입니다. SecureChain은 npm 레지스트리에서 가장 많이 의존되는 패키지들을 중심으로 서비스를 시작했으며, 사용자가 의존하는 패키지가 아직 카탈로그에 포함되어 있지 않다면 이를 추가할 예정입니다. 따라서 앞서 언급한 보장은 의존성 트리가 우연히 포함하는 모든 이름이 아니라, 커버리지 대상 패키지에만 적용됩니다. 두 번째는 재현 정확도입니다. 공개된 npm 패키지는 종종 저장소의 원본 소스 코드가 아닌 트랜스파일링되거나 번들링된 출력을 포함하고 있으며, 이를 바이트 단위로 일치시키려면 게시자의 빌드 환경을 그대로 재현해야 하는데, 생태계는 이를 보장하지 않습니다. SecureChain 재빌드는 게시자의 타르볼을 비트 단위로 복제한 것이 아니며, 애초에 그럴 의도도 없었습니다. 이는 출처를 추적할 수 있는 빌드이며, 게시자의 타르볼을 더 이상 신뢰할 수 없게 된 상황에서 이는 별개의, 더 유용한 특성입니다.

이러한 추적 가능성을 보장하기 위해 관련 메타데이터가 제공됩니다. SecureChain 패키지는 SLSA 레벨 3 출처 추적을 지원하도록 빌드 및 서명되며, 검증된 소스에서 빌드가 실행되고 지속적인 테스트가 뒷받침됩니다. 또한 TuxCare는 가능한 경우 SBOM 및 VEX 메타데이터를 공개합니다. SBOM 적용 범위는 패키지마다 다르며, 패키지에 따라 SPDX 또는 CycloneDX 형식으로 지속적으로 확대되고 있으므로, 일률적인 세트라고 가정하지 말고 최신 문서를 확인하시기 바랍니다.

검역 창은 수명이 짧은 릴리스에 대해 결정론적입니다

스크리닝, 스크립트 블로킹, 소스 코드 재컴파일. 이 세 가지 모두 무언가 잘못된 점을 감지함으로써 작동합니다. 반면, 격리 창은 굳이 무언가를 감지할 필요가 없습니다.

갓 공개된 버전의 해결을 충분히 오랫동안 지연시키면, 그 기간 내에 철회된 릴리스는 빌드에 포함될 자격을 영원히 상실하게 됩니다. 어떤 분석도 이루어지지 않으며, 조정할 수 있는 오탐률(false negative rate)을 가진 분류기도 존재하지 않습니다. 기간의 길이와 제외 항목은 여전히 구성상의 결정 사항이지만, 이는 화이트보드 앞에서 간단히 결정할 수 있는 종류의 문제입니다. 하지만 문제는 문구 자체에 있습니다. 단순히 시간이 지났다고 해서 버전이 안전해지는 것은 아닙니다. 이는 다른 누군가가 문제를 발견할 시간을 벌어줄 뿐입니다. 지연 기간이 지나도록 남아 있는 악성 릴리스는 다른 버전과 마찬가지로 검토 대상이 되는데, 이것이 바로 jscrambler 8.14.0에서 발생한 상황입니다.

사건	노출 창	24시간 격리 조치 대상
axios	3월 31일 UTC 기준 00:21부터 03:15까지, 약 3시간	네, 두 버전 모두 그 범위 안쪽 깊숙이 들어와 있었습니다.
샤이-훌루드 “세 번째 재림”	4월 22일 UTC 기준 21:57부터 23:30까지, 93분	네, 그 내부에서 이미 사용 중단되었습니다.
미아즈마	6월 1일에 두 차례에 걸쳐 커밋이 이루어졌으며, 대부분의 버전은 UTC 기준 13:00까지 취소되었습니다.	그럴 가능성이 높지만, 모든 버전에 대해 확인된 것은 아닙니다.
jscrambler	7월 11일, 약 3시간 동안 진행된 5가지 버전	부분적으로는 8.14.0 버전이 레지스트리에서 삭제된 적이 없기 때문입니다

이 중 두 건은 분석보다 산술이 우세함을 보여주는 사례로 확인되었습니다. jscrambler는 반례에 해당합니다. Miasma는 그 중간에 위치하는데, Wiz가 UTC 기준 13:00까지 대부분의 악성 버전이 무효화되었으나 당시 두 개는 여전히 활성 상태였다고 보고했기 때문입니다. 이는 빠른 부분적 제거가 이루어졌음을 입증하지만, 24시간의 유효기간이 만료되기 전에 모든 버전이 사라졌는지는 확인되지 않았습니다.

이러한 상충 관계는 실제로 존재합니다. 격리 기간을 두면 정상적인 패치 적용이 다소 늦어지게 되는데, 빠르게 변화하는 업스트림 종속성에 맞춰 제품을 출시하는 팀들은 속도가 느린 내부 플랫폼을 사용하는 팀들보다 이 문제를 더 크게 체감합니다. 또한 이는 여기서 구현하기 가장 간단한 통제 수단 중 하나이지만, 실제 업무에 도움이 될 만큼 효과적이지 않아 보인다는 이유로 평가 과정에서 가장 쉽게 무시당하기 쉬운 방법이기도 합니다.

풀-스루 캐시를 넘어선 사설 npm 레지스트리의 보안

전환은 일상적으로 잘 작동할 때만 의미가 있으므로, 여기서는 운영 측면을 다루겠습니다.

통합 코드는 두 줄로 이루어져 있습니다. .npmrc, 해당 호스트에 대한 레지스트리 줄과 인증 줄을, TuxCare에서 발급한 CLN 토큰을 사용하여 작성합니다. 이때 YOUR_CLN_TOKEN을 실제 토큰으로 대체하십시오:

registry=https://artifacts.tuxcare.com/npm/
//artifacts.tuxcare.com/npm/:_authToken=YOUR_CLN_TOKEN

package.json 변경되지 않습니다. 이름과 버전은 그대로 유지되며, 동일한 엔드포인트가 SecureChain 빌드가 있는 경우 이를 제공하고, 그 외의 모든 항목에 대해서는 공개 업스트림 패키지를 제공하므로, 별도로 연결해야 할 두 번째 레지스트리는 없습니다.

대규모 도입에 앞서 테스트해 볼 만한 문제가 하나 있습니다. package-lock.json 이 기록에는, 그 밖의 여러 항목과 더불어, 각 타르볼의 출처를 나타내는 해결된 URL과 해당 타르볼의 바이트에 대한 무결성 해시가 포함됩니다. 호스트를 변경할 때 해결된 URL이 바뀌는 것은 예상되는 일입니다. 흥미로운 점은 무결성 해시입니다. 해시는 어떤 호스트에서든 바이트 단위로 동일한 타르볼에 대해 유효성을 검증하므로, 단순히 호스트가 변경되는 것만으로는 해시에 영향을 미치지 않습니다. 그러나 SecureChain을 재구축하면 공개된 아티팩트와 바이트 단위로 동일하지 않게 되는 것은 당연한 일입니다. 바로 이러한 불일치가 EINTEGRITY 오래된 공용 레지스트리 잠금 파일이 그 아래에 있는 새로운 레지스트리와 마주칠 때.

그러니 겉보기상의 차이점보다는 재생성된 잠금 파일을 염두에 두고 계획을 세우세요. 삭제 node_modules 그리고 package-lock.json, 새로운 레지스트리를 대상으로 새로 설치를 실행한 다음, SecureChain URL과 체크섬을 기록한 생성된 잠금 파일을 커밋하세요. 이 작업은 먼저 임시 브랜치나 클론에서 수행하여, CI가 자동으로 감지하는 것이 아니라 직접 확인할 수 있는 diff가 되도록 하세요. 그런 다음, 해당 변경 사항을 한 번에 모든 저장소에 별도의 커밋으로 반영할지, 아니면 점진적으로 적용할지 미리 결정하십시오. 레지스트리 변경을 기능 브랜치에 섞어두면, 그 존재조차 몰랐던 누군가에 의해 구성 설정이 몰래 되돌려질 수 있습니다.

두 단계만 더 거치면 이 제안이 의무 사항으로 전환됩니다. CI를 npm ci 아직도 실행 중인 곳이라면 어디든 npm install, since npm ci 커밋된 잠금 파일에서 설치 작업을 수행하며, 잠금 파일과 package.json 조용히 업데이트하는 대신 반대 의견을 표명하세요. 그런 다음 빌드 에이전트에서 registry.npmjs.org로의 외부 접속을 차단하세요. 해당 문제가 해결될 때까지, .npmrc 누구나 이 제안을 무시하고 배포 차단을 해제할 수 있습니다.

해당 출구 차단 설정을 모든 곳에 적용하기 전에 스테이징 환경에서 테스트해 보세요. 스테이징 환경에서 문제가 발생하면 어떤 파이프라인과 도구가 레지스트리 설정을 우회해 왔는지 파악할 수 있으며, 이러한 목록은 사고로 기록되는 것보다 문서로 남기는 편이 훨씬 더 유용합니다.

다른 npm 레지스트리가 필요한 이유

콘텐츠 스크리닝과 재빌드 및 해결은 서로 다른 오류 모드를 다루며, 동일한 오류 모드를 두 번 다루는 것이 아닙니다. 스크리닝은 ‘Third Coming’과 ‘Miasma’에 해당하는데, 이는 퍼블리시의 출처에 의존하지 않기 때문입니다. 선별된 카탈로그를 기반으로 한 재빌드 및 해결은 ‘axios’와 ‘jscrambler’에 해당합니다. 이는 지원 대상 패키지의 경우, 서명된 아티팩트와 SLSA 레벨 3 출처 정보를 바탕으로 악성 아티팩트가 빌드 해결 경로에 절대 유입되지 않기 때문입니다.

팀에서 여전히 공개 레지스트리에서 직접 해결하고 있다면, npm용 SecureChain 견적을 받아보고 그 취약점을 해결하는 데 드는 비용이 얼마인지 확인해 보세요.

자주 묻는 질문

보안 npm 레지스트리란 무엇인가요?

발행자의 아티팩트를 그대로 전달하는 대신, 해당 레지스트리가 담당하는 종속성에 대해 재빌드 및 검증된 패키지를 제공하는 레지스트리 계층입니다. 실제로는 SecureChain 빌드가 있는 경우 이를 사용하고, 그 외에는 공개된 업스트림 패키지를 사용하는 혼합 방식으로, 모든 것이 동일한 엔드포인트를 통해 제공됩니다. 이는 통과하는 내용을 검사하지 않고 가용성과 속도를 향상시키는 풀스루(pull-through) 캐시와는 다른 개념입니다.

보안이 철저히 갖춰진 npm 레지스트리였다면 ‘Shai-Hulud의 세 번째 재림’ 캠페인을 막을 수 있었을까?

레지스트리가 게시자의 신원과 별개로 콘텐츠를 심사한다면 가능합니다. 악성 릴리스 자체에 유효한 인증서가 포함되어 있었는지는 확인되지 않았으므로, 여기서는 신원 기반 검사만으로는 신뢰할 수 없습니다. 릴리스의 내용을 분석하는 심사 단계—새로운 빌드 훅, 난독화된 코드, 일치하는 커밋이 없는 파일 등을 확인하는 과정—을 통해, 인증서의 내용과 무관하게 이러한 문제를 탐지할 수 있습니다. Miasma는 동일한 실패 모드의 더 명확한 예시인데, 해당 릴리스들은 유효하고 서명된 SLSA 출처 정보를 포함하고 있었기 때문입니다.

격리 기간을 두었다면 axios가 중단되었을까요?

네. 악성 버전은 약 3시간 동안 배포된 후 삭제되었으므로, npm이 표현할 수 있는 가장 짧은 기간인 ‘1일’의 채택 지연만 있었더라도, 해당 버전이 악성으로 식별될 필요 없이 악성 상태였던 전체 기간 동안 배포 자격을 상실했을 것입니다. 이 필터링 기능은 ‘min-release-age’ 설정으로, 일 단위의 값을 지정하며 npm 11.10.0 이상 버전에서 지원됩니다. 이전 버전의 클라이언트는 이 설정을 아무런 경고 없이 무시하기 때문입니다. 이 설정은 소급 적용 방식의 검사가 아니라 의존성 해결 과정에서 필터링 역할을 하므로, 이미 커밋된 락파일에 고정된 악성 버전은 별개의 문제입니다.

npm 레지스트리를 대체하는 것이 실제로 일상 업무에 어떤 변화를 가져올까요?

주로 설치 명령어가 어디서 호출되는지. package.json 그리고 대부분의 업무 흐름은 그대로 유지됩니다. package-lock.json 한 번 재생성해야 합니다. 해결된 URL과 그 안에 포함된 무결성 해시 모두 이전 레지스트리의 아티팩트를 가리키기 때문입니다.

비공개 npm 레지스트리의 보안은 단순히 비공개 레지스트리를 구축하는 것만으로도 처리될 수 있나요?

그 자체만으로는 아닙니다. 캐싱 프록시는 패키지가 어디서 오는지에 대한 통제 지점을 제공하지만, 통제 지점 자체만으로는 그곳을 통과하는 것이 신뢰할 수 있다고 단정할 수는 없습니다. 설치 과정이 실제로 더 안전해지는지는 그 통제 지점에서 어떤 것이 실행되는지와, 그 주변 경로도 차단되었는지에 달려 있습니다. CI가 여전히 공개 레지스트리에서 직접 패키지를 해결하는 것이 일반적인 보안 취약점입니다.

요약