실제로 격차를 해소해 주는 npm audit 대안들

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

주요 내용

npm audit은 사용자의 소스 트리만 권고 사항 데이터와 비교할 수 있으므로, 1시간 전에 공개된 악성 버전은 탐지되지 않습니다.
그 격차를 해소하려면 하나의 도구만으로는 부족합니다. 행동 분석기, 출처 확인, 선별된 레지스트리가 각각 그 격차의 서로 다른 부분을 다루기 때문입니다.
결과를 바꾸는 제어 요소는, 애초에 해당 빌드가 무엇을 처리할 수 있는지 결정하는 요소입니다.

npm audit는 한 가지 일을 아주 잘 해냅니다. 이 도구는 사용자의 의존성 트리를 알려진 취약점 데이터베이스와 비교하여 일치하는 항목을 알려줍니다. 이미 문서화된 취약점의 경우, 이는 유용합니다. 하지만 아직 아무도 문서화하지 않은 취약점의 경우, audit는 아무런 정보를 제공하지 못하며, 그 시기에 해당 의존성을 설치하면 해당 취약점에 대한 권고문이 나오기도 전에 코드가 이미 의존성 트리에 포함되어 있게 됩니다.

이 도구는 자신이 확인하는 보안 권고 데이터에 해당 위협이 나타나기 전에 악성 패키지를 탐지하도록 설계된 적이 없습니다. 실제로 이러한 보안 취약점을 보완할 수 있는 npm audit 대안을 찾으려면, 사후에 경고가 표시되는 항목뿐만 아니라 빌드 과정에서 어떤 버전을 해결할 수 있는지 결정하는 요소를 면밀히 살펴봐야 합니다.

npm audit가 실제로 무엇을 확인하는지, 그리고 그 한계가 어디까지인지

npm audit는 2021년부터 npm의 감사 데이터를 뒷받침해 온 GitHub Advisory Database의 권고 데이터를 기준으로 의존성 트리를 확인합니다. 이는 패키지 내용이나 런타임 동작을 검사하는 것이 아니라, 권고 사항을 조회하는 기능입니다. 만약 1시간 전에 버전이 업데이트되었는데 아직 해당 버전을 다루는 권고 사항이 없다면, audit는 해당 버전을 비교할 대상이 없으므로 오류로 표시되지 않습니다.

이는 버그가 아닙니다. 바로 해당 도구의 정의 그 자체입니다. 2026년 3월에 발생한 약 3시간 동안 지속된 axios 침해 사건은 이것이 실제로 어떻게 나타나는지 보여줍니다. 백도어가 심어진 두 버전인 1.14.1과 0.30.4가 배포되어 설치 과정을 통해 확산되었지만, 당시 보안 권고 자료에는 여전히 아무런 언급도 없었습니다. 보안 권고가 발표된 후에는, 이미 설치가 완료된 디렉터리를 포함해 해당 버전들이 배포된 모든 곳에서 감사 과정을 통해 문제를 포착할 수 있었습니다. 하지만 결정적인 시점에 아무런 경고도 내지 못한 점은 문제였습니다.

알아두면 좋은 두 번째, 좀 더 세부적인 확인 방법이 있습니다. ‘npm audit signatures’ 명령어를 실행하면 다운로드한 패키지의 레지스트리 서명과, 해당 서명이 있는 경우 출처 증명서를 검증합니다. 이러한 제어 수단들은 모두 타임라인의 서로 다른 시점에서 작동하므로, 나란히 비교해 보면 더 쉽게 파악할 수 있습니다.

카테고리	어떤 것을 포착하는가	그것이 작용할 때
npm audit	해당 시스템이 확인하는 권고 사항 데이터에 기록된 알려진 취약점	해당 사항이 자문 데이터에 포함되면
행동 기반 및 정적 스캐너	의심스러운 새로운 패키지, 스크립트, 난독화	게시 후, 설치 전 또는 설치 후
레지스트리 서명 확인	변조 가능성을 시사할 수 있는 누락되거나 유효하지 않은 서명	서명이 확인되면
출처 확인	패키지의 명시된 출처 및 빌드 워크플로가 해당 인증 내용과 일치하는지 여부	증명이 확인될 때
검토 및 재구성된 레지스트리	출처 확인 또는 악성코드 검사를 통과하지 못한 유물	빌드가 이를 해결하기 전에

행동 분석 및 정적 분석 도구

감사 데이터와 자문 데이터가 일치하는 경우, 행동 분석 도구는 패키지 자체를 검사합니다. 이 도구들은 버전 간에 무엇이 변경되었는지 살펴봅니다. 명확한 이유 없이 새로 추가된 의존성, 이전 릴리스에는 없었던 설치 스크립트, 난독화된 코드, 아무도 요청하지 않은 네트워크 호출 등이 그 예입니다.

npm audit로는 파악할 수 없는 문제점들

이 도구가 특히 대응하도록 설계된 사례 중 하나는 완전히 새로운 패키지나, 관련 보안 권고가 전혀 없는 상태에서 불과 몇 분 전에 공개된 버전입니다. 이 도구는 CVE가 없더라도, 알 수 없는 도메인에 접속하는 의심스러운 설치 후 스크립트나, 필요도 없는데 캐싱 라이브러리에 수백 킬로바이트에 달하는 난독화된 코드를 삽입하는 diff를 감지할 수 있습니다. 이것이 바로 이 도구의 핵심 가치입니다. 즉, 다른 누군가가 먼저 이를 분류해 주기를 기다리기보다, 의심스러운 행동을 직접 포착해내는 것입니다.

여전히 부족한 점

이러한 도구는 신호를 실제로 대응할 만한 수준으로 만들기 위해 사전 조정이 필요하며, 오탐지는 결국 누군가가 해당 채널을 무음 처리하게 만드는 ‘경보 피로’를 유발합니다. 또한 이 도구들은 패킷의 출처를 확인하지 않고 단지 겉으로 보이는 동작만 분석하기 때문에, 스캔 기간 동안 비활성 상태를 유지하는 페이로드는 여전히 통과할 수 있습니다.

대부분은 레지스트리에 이미 등록된 내용과도 비교하여 검사하므로, 해당 내용이 레지스트리에 반영된 후에야 문제가 있음을 알려줍니다. 이는 권고 정보를 기다리는 것보다 확실히 개선된 점이지만, 빌드에서 무엇을 설치할 수 있는지 결정하는 것과는 다릅니다.

이 범주의 도구가 어떤 점에서 한계가 있는지 더 폭넓게 살펴보려면, ‘공급망 도구가 놓치고 있는 점’을 확인해 보세요.

출처 및 서명 검증

서명과 출처 정보는 감사 절차로는 확인할 수 없는 두 가지 질문, 즉 다운로드한 아티팩트가 올바르게 검증되는지, 그리고 어디서 빌드되었는지에 대한 답을 제공합니다.

npm audit 서명이 실제로 확인하는 사항

npm 출처 증명(provenance attestations)은 Sigstore를 사용하여 게시된 아티팩트를 이를 생성한 소스 저장소 및 빌드 워크플로우와 연결합니다. npm audit signatures 명령을 실행하면 패키지의 레지스트리 서명이 유효한지 확인하고, 증명이 존재하는 경우 해당 패키지가 소스 저장소 및 그 안에 기록된 빌드 워크플로우와 연결되는 유효한 증명을 포함하고 있는지 확인합니다.

유효한 서명이 왜 안전성 판정이 아닌지

이것들은 실제로 유용한 검증 방법입니다. 레지스트리 서명이 유효하지 않은 경우, 해당 아티팩트가 변조되었을 가능성을 시사할 수 있으며, 출처 정보를 확인하면 빌드 이력이 전혀 없는 패키지나, 사용자가 예상했던 소스 코드와 다른 곳을 가리키는 인증서를 발견할 수 있습니다.

하지만 두 가지 모두 코드 자체가 안전한지 여부를 평가하지는 않습니다. 출처 추적은 무언가가 어디서 왔는지를 알려줄 뿐, 실행된 후 어떤 동작을 하는지는 알려주지 않습니다. 은밀하게 침해당한 파이프라인이라도 여전히 완전히 유효한 인증서를 갖춘 빌드를 생성할 수 있습니다. 왜냐하면 그 인증서는 실제로 악성 코드로 구성된 실제 빌드를 정확하게 기술하고 있기 때문입니다. 정상적인 출처 추적 확인 결과를 신뢰 여부를 결정하는 데 필요한 하나의 참고 자료로만 삼아야 하며, 이를 최종 판단 기준으로 삼아서는 안 됩니다.

도메인 등록 전 사전 검토를 수행하는 등록 기관

그러면 대부분의 팀이 이미 해결했다고 여기는 부분이 대두됩니다.

프록시 또는 미러 대 검사 및 재구축 기능을 갖춘 레지스트리

선별되고 소스 코드에서 재빌드된 레지스트리와 비교한 프록시 또는 미러 npm 레지스트리

많은 팀이 공개 npm 레지스트리 앞에 프록시나 미러 역할을 하는 사설 npm 레지스트리를 운영하고 있습니다. 이는 업링크 기능을 갖춘 Verdaccio이든, Nexus나 Artifactory에서 구성된 프록시 리포지토리이든 상관없습니다. 이러한 제품들은 캐싱 이상의 다양한 기능을 수행할 수 있지만, 해당 구성에서는 이 작업이 아웃바운드 트래픽의 병목 지점이 되며, 허용되는 소스를 지정하는 유일한 지점이 됩니다. 검사는 이 과정에 포함되지 않습니다. 경로상 어디에서도 아티팩트를 검증하지 않는다면, 악성 업스트림 패키지는 캐시에서 제공될 때에도 여전히 악성 상태를 유지합니다.

다른 유형의 레지스트리는 레지스트리를 통과하는 항목을 처리하여, 해당 아티팩트를 심사하고 출처를 확인하며, 경우에 따라 공개 레지스트리가 마지막으로 게시한 내용을 그대로 제공하는 대신 해당 출처에서 다시 빌드하기도 합니다. 예를 들어, TuxCare의 SecureChain은 npm 패키지를 소스 코드에서 다시 빌드하고, 레지스트리에 등록되기 전에 이를 심사합니다. 이는 본질적으로 다른 수준의 보장을 제공하며, 패키지의 출처를 통제하는 것을 넘어 실제로 무엇이 설치되는지를 통제할 수 있게 해주는 핵심 요소입니다.

소스 코드에서 패키지를 다시 빌드하면 무엇이 달라지나요?

소스 코드부터 재빌드하면, 스캐닝만으로는 해결할 수 없는 오류 유형, 즉 업스트림 저장소에 실제로 있는 내용과 일치하지 않는 게시된 아티팩트 문제를 해결할 수 있습니다. 빌드 과정에서 해결된 버전을 통제된 파이프라인에서 예상된 소스 코드를 기반으로 재빌드한다면, 소스 코드 자체가 여전히 깨끗한 한, 도난당한 토큰을 이용해 공개 레지스트리에 직접 푸시된 변조된 타르볼은 해당 경로로 유입될 수 없습니다. 이는 “절대 나쁜 일이 일어나지 않는다”는 보장보다는 범위가 좁지만, 확실한 보장이며, 보안 권고문이 작성되든 안 되든 상관없이 유효합니다.

도구를 중첩해도 여전히 타이밍 간격이 발생하는 이유

이 모든 과정을 종합해 보면 상당히 광범위한 영역을 다루게 됩니다. 알려진 취약점에 대한 npm audit, 새로운 패키지에 대한 동작 스캔, 서명 및 출처 확인 등이 포함되죠. 하지만 이 중 어느 것도 패키지 관리자가 애초에 어떤 아티팩트를 가져올 수 있는지에 대해서는 별다른 변화를 주지 못합니다.

종래에 의존성 설치 스크립트는 패키지가 설치되는 즉시 실행되어 왔으며, 이는 대개 스캐너가 문제를 감지하기 전이고 사람이 직접 확인하기 전의 시점이었습니다. 이것이 바로 axios 공격이 그토록 효과적이었던 이유입니다. 백도어가 삽입된 릴리스가 드로퍼를 실행하는 설치 후 스크립트를 가진 완전히 새로운 종속성을 끌어왔기 때문입니다. npm v12부터는 프로젝트가 allowScripts 정책에 해당 스크립트를 명시적으로 허용하지 않는 한, 종속성 설치 스크립트가 기본적으로 차단됩니다. 이로 인해 해당 경로의 일부는 차단되지만, 여전히 손상된 종속성의 설치 스크립트가 실수로 승인될 가능성은 남아 있습니다.

해당 신뢰 모델이 어떻게 작동하는지 자세히 알아보지 않으셨다면, 라이프사이클 스크립트의 작동 원리와 현재 기본 설정에 대해서는 ‘npm 패키지를 안전하게 설치하는 방법’ 안내서에서 다루고 있습니다. 스크립트 차단 기능은 npm이 종속성을 선택하고 가져온 후 해당 설치 스크립트가 실행될지 여부를 제어합니다. 이는 악성 버전이 선택될 수 있는지 여부를 결정하는 것은 아닙니다.

이 점이 바로 명심해 두어야 할 차이점입니다. 이러한 검사만으로는 빌드가 참조하는 패키지 소스를 변경할 수 없으며, 이를 변경하는 한 가지 방법은 빌드가 참조하는 레지스트리를 변경하는 것입니다.

npm audit가 이를 감지하기 전에 격차를 해소하기

npm용 SecureChain: 도입부터 빌드, 운영, EOL 이후까지 포괄적인 지원

SecureChain은 감사 기능을 대체하는 도구가 아닙니다. 이는 npm 의존성을 해결하기 위해 사용하는 별도의 레지스트리입니다. SecureChain은 공개 npm 레지스트리를 대신하여, 소스 코드부터 재컴파일하여 엄선된 저장소를 제공하며, 패키지가 설치 가능해지기 전에 사전 검증을 수행합니다. 따라서 빌드 과정에서 가져오는 패키지는 이미 소스 코드 검증과 악성코드 검사를 거친 상태입니다. 단순한 권고 사항에 그치는 탐지 기능을 넘어 더 강력한 조치를 원하는 팀의 경우, 이를 통해 의사결정 시점을 상류 단계로 앞당길 수 있으며, 이 단계에서는 권고 사항의 시의적절성 문제가 훨씬 덜 중요해집니다.

지원 범위는 채택 단계부터 빌드, 운영, 수명 종료 이후까지 포괄하며, 사용 중인 패키지는 SLA에 따라 패치되고, 업스트림 유지보수가 중단되면 ‘Endless Lifecycle Support’가 이를 이어받습니다. 모든 패키지에는 SLSA 레벨 3 출처 정보, SBOM 및 VEX 데이터가 포함되어 있으며, 워크플로우 변경은 필요하지 않습니다.

전이적 종속 관계에 숨어 있는 위험에 대해 더 자세히 알아보시려면 온디맨드 웨비나를 시청하거나, SecureChain에 대해 담당 팀과 상담해 보세요.

자주 묻는 질문

npm audit를 대체할 만한 좋은 도구는 무엇인가요?

바로 교체할 수 있는 방법은 아닙니다. npm audit는 이미 해결 중인 디렉터리 트리 내에서 알려진 보안 권고 사항을 추적하는 데 여전히 합리적인 방법입니다. 더 강력한 옵션들은 결정이 이루어지는 시점을 변경하여, 빌드 과정에서 패키지를 가져오기 전에 미리 선별하는 방식인데, 이는 보안 권고 사항 일치 기능의 설계상 할 수 없는 일입니다.

npm audit는 악성 패키지를 탐지하나요?

Audit은 보안 권고 데이터에 포함된 내용만 확인합니다. 악성 코드도 보안 권고 대상에 포함되며, npm 보안 팀과 OpenSSF의 malicious-packages 프로젝트를 통해 GitHub 보안 권고 데이터베이스에 등록되지만, GitHub은 이에 대한 알림 경로로 audit이 아닌 Dependabot을 문서화하고 있습니다. 어느 쪽이든, audit은 패키지를 직접 검사하는 것이 아니라 보안 권고 데이터와 대조하는 방식이기 때문에, 새로 공개된 악성 버전의 동작을 통해 이를 탐지할 수 없습니다.