Node.js 보안, CI 이전 단계부터 시작해야
Node.js 보안은 CI 단계가 아닌 개발자가 패키지를 신뢰하는 순간부터 시작되어야 한다. npm 공급망 공격 사례를 통해 의존성 위험의 일상화와 기존 CI 중심 보안의 한계를 지적하며, 개발자 워크플로 초기 단계에서의 보안 접근이 필요하다고 강조한다.
많은 팀에서 의존성 보안은 가장 중요한 신뢰 결정이 이미 내려진 후에야 이루어진다. 패키지가 추가되고 록파일이 변경되며 기능 개발이 진행된 후에야 파이프라인이 해당 코드를 애플리케이션이 신뢰해야 하는지 묻는다. 이 워크플로는 의존성 보안이 주로 규정 준수 체크로 여겨지던 시절에는 합리적이었다. 스캐너를 실행하고 보고서를 생성한 뒤 위험도가 기준을 넘으면 빌드를 실패시키고, 다음 조치를 누군가 결정하는 방식이었다.
그러나 현대 Node.js 생태계는 달라졌다. 위험은 더 이상 CI에서 시작되지 않는다. 개발자가 패키지를 신뢰하기로 결정하는 순간부터 시작된다. 따라서 Node.js 보안의 다음 단계는 파이프라인 강화에만 국한될 수 없다. 의존성이 애플리케이션의 일부가 되기 전, 풀 리퀘스트가 다른 사람의 문제가 되기 전, 빌드 로그가 중요한 변화가 발생했다는 사실을 처음 깨닫는 순간이 되기 전에 개발자 워크플로에 더 가까이 다가가야 한다.
모든 설치가 신뢰 결정이다
npm 생태계는 거대한 규모의 신뢰 위에 구축되어 있다. 모든 설치가 신뢰 결정이며, 모든 전이 의존성은 그 결정을 유지보수자, 패키지, 스크립트, 릴리스 파이프라인, 애플리케이션 팀이 직접 검사하지 않을 수도 있는 인프라까지 확대한다. 이 모델은 자바스크립트에 놀라운 속도를 제공했지만, 동시에 가장 깊은 보안 취약점 중 하나를 만들어냈다.
최근 npm 공급망 사고들은 이 문제의 심각성을 보여준다. 2026년 3월에는 침해된 유지보수자 계정을 통해 악성 Axios 버전이 npm에 게시되었다. 마이크로소프트는 해당 패키지들이 설치 중에 2단계 페이로드를 가져오려고 시도했다고 설명했다. 2026년 5월 TanStack는 공격자가 GitHub Actions 동작과 러너 신뢰 경계를 악용해 합법적인 릴리스 파이프라인을 통해 42개 npm 패키지의 84개 악성 버전이 게시되었다는 사후 보고서를 발표했다. 보안 연구자들은 5월 npm 생태계 전반에 걸친 Mini Shai-Hulud 활동도 보고했으며, 짧은 기간에 수백 개의 악성 패키지 버전이 게시되었다.
이 사고들이 모두 전통적인 CVE는 아니다. 일부는 악성 패키지 침해이고, 일부는 CI/CD 자격증명 도난이며, 일부는 유지보수자나 파이프라인 침해다. 그러나 모두 동일한 더 큰 문제를 가리킨다. 의존성 위험은 이제 일상적인 소프트웨어 엔지니어링의 일부가 되었으며, 이를 완전히 다운스트림 보안 프로세스로 미룰 수 없다는 것이다.
문제는 스캐너가 아니다. 문제는 인계다. 보편화된 의존성 위험은 개발자들이 보안 도구로부터 무엇을 필요로 하는지를 바꾸고 있다. 팀들에게 스캐너가 없는 것이 문제가 아니라, 그 체크 결과가 너무 늦게 도착하고 행동해야 할 사람에게 맞지 않는 언어로 전달된다는 점이 문제다. 풀 리퀘스트가 실패하고, 긴 취약점 보고서가 나타난다.