자바스크립트와 Node.js 팀에 부족한 것은 보안 툴이 아니라, 개발자가 릴리즈 전에 실제로 사용할 수 있는 종속성 보안 워크플로우다.

패키지가 설치되고 CI(지속적 통합)가 실행되고 파이프라인 어딘가에서 스캐너가 실행되고 최종적으로 보고서가 생성된다. 멀리 떨어져서 보면 성숙한 과정으로 보일 수 있다. 그러나 많은 경우 개발자는 종속성 위험에 대해 너무 늦게, 너무 간접적으로, 너무 불분명하게 알게 되고, 문제를 쉽게 고칠 수 있는 시기를 놓치게 된다.

자바스크립트와 Node.js 보안의 진짜 문제는 더 이상 탐지가 아니라 실행 가능성이다.

바로 그 이유로 많은 팀이 종속성을 스캔하면서도 릴리즈 직전에 다음과 같은 중요한 질문에 답하는 데 여전히 어려움을 겪는다. 정확히 무엇이 취약한가? 직접 종속성인가, 전이 종속성인가? 수정된 버전이 있는가? 내 프로젝트에서 직접 수정할 수 있는가, 아니면 상위 종속성에 막혀 있는가? 발견된 사항 중 어떤 부분에 가장 먼저 주의를 기울어야 하는가?

이는 특이 사례가 아니라 실제 작업이다.

이 문제는 Node.js 프로젝트에서 쉽게 보이지 않을 것이다. 팀이 적절한 수의 직접 종속성을 관리하더라도 록파일(lockfile)을 통해 수백 또는 수천 개의 확정된(resolved) 패키지를 배포할 수 있다. 이 시점이 되면 더 이상 스캐너가 결과물을 생성할 수 있는지 여부는 난점이 아니다. 대부분은 생성할 수 있다. 난점은 문제가 파이프라인 노이즈 또는 마감 직전의 다급한 분류 작업으로 변하기 전에 개발자가 릴리즈 의사결정을 내릴 수 있을 만큼 그 결과가 충분히 이해하기 쉽고 로컬이며 실행 가능한지다.

많은 워크플로우가 바로 이 지점에서 실패한다. 탐지는 되지만 많은 경우 사용 편의성은 없다. Node.js 팀에 부족한 것은 스캐너가 아니라 워크플로우다.

빠진 조각은 종속성 보안에 대한 수정 가능성 우선 보기다. 어떤 것이 취약하다는 사실을 아는 데 그치지 않고, 지금 직접 실행할 수 있는 조치가 무엇인지, 무엇이 전이 종속성에 묻혀 있는지, 그리고 실제로 어떤 종류의 고정 경로를 다루고 있는지를 알아야 한다.

CVE 라이트 CLI의 다른 점

필자는 CVE 라이트 CLI(CVE Lite CLI)를 통해 이 문제를 살펴보고 있다. CVE 라이트 CLI는 자바스크립트 개발자에게 실제로 필요한 로컬 종속성 워크플로우를 중심으로 구축된 오픈소스 툴이다.

CVE 라이트 CLI는 플랫폼 경쟁에서 이기는 것이 아니라, 릴리즈 전에 개발자에게 명확한 답변이 필요한 순간에 문제를 해결하는 데 목표를 둔다.

이 툴의 작동 범위는 의도적으로 좁다. 악용 가능성 분석, 런타임 도달 가능성, 컨테이너 스캔, 비밀 정보 스캔 또는 인프라 스캔은 하지 않는다. 더 실용적인 작업, 즉 록파일에서 로컬로 자바스크립트와 타입스크립트 프로젝트를 스캔하고 알려진 OSV 기반 종속성 문제를 파악하고 직접 종속성과 전이 종속성을 분리하고 종속성 경로를 보여주고 수정 버전 가이드를 제시하고 개발자가 릴리즈 전에 실제로 사용할 수 있는 결과물을 생성하는 데 집중한다.

좁은 범위는 약점이 아니다. 오히려 이 툴이 유용한 이유가 그 좁은 범위에 있다.

너무 많은 보안 툴이 기업적 가시성을 중심으로 구축된다. CVE 라이트 CLI 워크플로우는 개발자의 의사결정을 중심으로 구축된다. 이 툴의 가치는 단순히 취약점의 존재를 알려주는 것이 아니라 개발자가 행동을 바꿀 수 있을 만큼 충분히 조기에 종속성 위험을 이해하도록 해준다는 점이다.

그 차이는 중요하다. CI 후반부에 도달하는 경고는 기술적으로는 정확할 수 있지만 운영 측면에서는 취약하다. 로컬에서 직접과 전이의 분리, 그리고 종속성 경로와 함께 표시되는 경고는 수정을 계획하는 데 있어 훨씬 더 유리하다.

이것이 CVE 라이트 CLI가 메우고자 하는 간극이다. 종속성 보안을 엔지니어링 의사결정이 실제로 내려지는 지점에 더 가깝게 옮긴다.

최근 CVE 라이트 CLI는 가능한 경우 직접 수정을 위한 정확한 패키지 명령까지 제시함으로써 워크플로우를 한층 더 발전시킨다. 개발자가 탐지에서 조치로 이동하는 시점에 이 툴의 유용성을 더 높여주는 기능이다.

패키지 명령을 제공하면 이 툴은 스캐너에서 로컬 교정 루프로 바뀐다. 즉, 스캔하고, 제안된 패키지 변경 사항을 적용하고, 브랜치 및 파이프라인의 피드백을 기다리지 않고 즉시 다시 스캔한다.

이 변화는 편리함을 넘어선 영향을 미친다. 멀리 떨어진 보고서에서는 체감하기 어려운 종속성 보안을 능동적인 엔지니어링 루프로 가져온다. 이를 통해 개발자는 동일한 작업 세션에 머무르며 변경을 수행하고 결과를 확인하고 계속 진행할 수 있다.

CVE 라이트 CLI를 사용한 로컬 우선 취약점 스캔

필자는 2026년 4월, 네스트(Nest), pnpm, 그리고 release-it까지 3개의 공개 오픈소스 프로젝트를 대상으로 CVE 라이트 CLI를 실행했다. 목표는 이런 프로젝트의 흠을 잡는 것이 아니다. 잘 관리되는 프로젝트에서도 종속성 문제는 발생하고, 스캔 결과는 시간이 지나면서 변할 수 있다. 핵심은 로컬 우선 툴이 개발자에게 행동을 구체화하기에 충분한 실질적인 정보를 줄 수 있는지 여부를 테스트하는 데 있었다.

네스트에 대한 실행은 더 완전한 사례 연구로 발전해서, 이제 더 큰 시사점을 명확히 보여준다. 즉, 로컬 우선 툴의 가치는 단순히 문제를 탐지하는 데 그치지 않고 개발자가 동일한 작업 세션 내에서 스캔 결과로부터 현실적인 교정 경로로 이동할 수 있게 해준다는 데 있다는 점이다.

CVE 라이트 CLI는 네스트에서 package-lock.json에 있는 1,626개의 패키지를 파싱해 알려진 OSV 일치 항목이 있는 25개의 패키지를 발견했다. 여기에는 높은 심각도 문제 1개, 중간 심각도 4개, 낮은 심각도 20개가 포함됐다. 수치보다 더 중요한 것은 구조다. 발견된 문제 중 12개는 프로젝트 내에서 직접 수정이 가능해 보였고 13개는 전이 문제였다.

이것이 바로 원시 상태의 수치에서는 드러나지 않는 차이점이다. 25개가 발견됐다는 경고와 별개로, 실질적인 엔지니어링 측면의 질문은 그 중에서 얼마나 많은 항목에 대해 즉각적인 조치를 취할 수 있냐는 것이다. 수정 가능성 우선 워크플로우는 이를 시각적으로 보여준다.

더 완전한 네스트 사례 연구에서 볼 수 있는 것은 많은 경우 교정은 한 번에 끝나지 않고 반복적인 작업으로 이뤄진다는 점이다. 한 종속성 경로에서는 문제를 해결하기 위해 여러 번의 순차적인 tar 업그레이드가 필요했다. 각 설치 이후 종속성 그래프가 변경됐기 때문이다. 바로 이 지점이 로컬 스캔-수정-재스캔 루프가 CI만으로 구성된 워크플로우보다 더 유용해지는 지점이다. 개발자는 업그레이드하고 브랜치를 푸시하고 파이프라인 스캐너를 기다렸다가 뒤늦게 필요한 업그레이드를 발견하는 대신, 종속성 상태가 깨끗해질 때까지 로컬에서 경로를 따라 계속 작업할 수 있다.

발견한 사항 중에서 가장 눈에 띄는 한 가지는 diff@2.2.3으로, gulp-diff를 통해 나타난 높은 심각도의 전이 종속성 문제였다. 또한 같은 스캔에서 중간 심각도의 직접 종속성인 diff@4.0.2, mocha를 통한 중간 심각도의 전이 종속성인 diff@7.0.0도 발견됐다. 이것이 Node.js 종속성 관리의 현실이다. 즉, 동일한 패키지가 여러 상위 항목을 통해 여러 형태로 나타나며, 교정을 위한 세부 사항도 제각기 다르다.

빈약한 툴이라면 개발자에게 취약점이 발견되었다는 사실만 알릴 것이다. CVE 라이트 CLI는 그보다 더 유용했다. 각 사례에서 종속성 경로를 명확하게 드러내서 교정 작업이 각기 다른 이유를 볼 수 있도록 했다.

동일한 네스트 스캔에서 tar@6.2.1이 수정 버전 가이드가 포함된 중간 심각도의 직접 종속성으로, form-data@2.3.3은 request를 통한 중간 심각도의 전이 종속성 문제로 발견됐다. 이 두 문제는 서로 범주가 다르다. 하나는 직접적인 업그레이드 의사결정을 가리키고 다른 하나는 상위 종속성 문제를 가리킨다. 이 지점에서 종속성 스캔은 단순한 체크리스트 실행을 넘어 실제 엔지니어링 작업이 되기 시작한다.

이 부분은 이와 같은 로컬 우선 종속성 워크플로우가 잘 작동하는 지점이기도 하다. 단순히 문제가 있음을 보고하는 것이 아니라 개발자에게 어떤 종류의 문제를 다루고 있는지를 보여준다.

release-it 스캔은 좀더 작은 규모에서 동일한 시사점을 보완했다. CVE 라이트 CLI는 545개의 패키지를 파싱해서 알려진 OSV 일치 항목이 있는 패키지 10개를 발견했다(중간 심각도 4개, 낮은 심각도 6개). 6개는 직접 수정 가능해 보였고 4개는 전이 문제였다.

곧바로 눈에 띈 두 가지 직접 발견 항목은 @isaacs/brace-expansion@5.0.0과 flatted@3.3.3으로, 둘 다 개발자가 신속하게 판단할 수 있는 종류의 문제다. 그러나 이 스캔에서는 각각 @npmcli/map-workspaces와 glob 상위 체인을 통해 전이적으로 도달한 두 개의 minimatch 항목도 발견됐다.

이는 툴이 크고 복잡한 종속성 그래프에 대해서만 유용한 것이 아님을 보여준다는 측면에서 중요한 발견이다. 즉, 모호한 종속성 우려를 구체적이고 조사 가능한 교정 경로로 전환하는 데 진정한 가치가 있는 소규모 프로젝트에서도 유용하다.

pnpm 스캔은 반대의 이유로 의미가 있었다. CVE 라이트 CLI는 pnpm-lock.yaml에서 563개의 패키지를 파싱했는데, 알려진 OSV 일치 항목을 전혀 반환하지 않았다. 이와 같은 종류의 결과는 간과하기 쉽지만 그래서는 안 된다. 제대로 된 로컬 워크플로우는 단순히 경고를 생성하는 데 그치지 않고, 명확히 수정이 필요한 항목이 없을 때는 개발자에게 신속하게 확신을 줄 수도 있어야 한다.

이 깨끗한 결과는 워크플로우에 가벼운 로컬 툴을 포함해야 하는 이유 중 하나다. 개발자에게는 조기 경고만 필요한 것이 아니라 빠른 확신도 필요하다.

종속성 보안을 개발자 워크플로우로 가져오기

여기서 더 큰 교훈은 오픈소스 프로젝트가 실패하고 있다는 것이 아니라, 종속성 보안을 둘러싼 개발자 워크플로우가 여전히 미성숙하다는 것이다. 결과를 수집하는 방법은 배웠지만 개발자가 패키지를 선택하고 록파일을 업데이트하고 릴리즈를 준비하는 지점에서 그 결과를 활용하는 방법은 배우지 못했다.

CVE 라이트 CLI가 중요한 이유가 여기에 있다. 이 툴은 많은 자바스크립트 팀이 여전히 매일 겪는 워크플로우 문제를 해결한다.

문제의 본질은 하나의 프로젝트나 하나의 스캐너가 아니라 종속성 보안이 일상적인 엔지니어링 실무의 일부가 되는지다.

CVE 라이트 CLI는 그 방향을 향한다. 개발자에게 CI를 기다리도록 강요하지 않고 로컬 릴리즈 확인 기능을 제공한다. 모든 것을 하나의 목록으로 뭉뚱그리지 않고 직접/전이 항목으로 나눠 가시성을 제공한다. 교정 컨텍스트가 없는 모호한 패키지 이름 대신 종속성 경로를 제공한다. 개발자가 다음 단계를 추측하도록 하지 않고 가능한 경우 수정된 버전 가이드를 제공한다.

또한 CVE 라이트 CLI는 의도적으로 가볍고 좁은 범위에서 동작하도록 만들어져 신뢰와 채택의 장벽이 낮고 일반적인 Node.js 툴체인에 쉽게 추가할 수 있다.

이 점이 중요하다. 개발자에게 툴은 이미 과부하 상태다. 앞으로 개발자 워크플로우에서 자리를 차지하는 툴은 거창한 기능을 약속하는 툴이 아니라, 실제 문제를 깔끔하고 정직하게 해결하고 팀에 플랫폼을 강요하지 않는 툴이 될 것이다.

CVE 라이트 CLI에 실질적인 잠재력이 있는 이유가 이것이다. 즉, 개발자가 이미 작업하는 지점에서 개발자와 접하는 툴이다.

더 중요한 점은 종속성 보안을 이해하는 방식에 있어 이 툴이 더 폭넓은 변화를 향하고 있다는 점이다. 보안 툴은 취약점 탐지에서 취약점 해석으로, 문제 카운팅에서 컨텍스트 내에서의 위험 이해로 이동하고 있다. 그 지점에서는 개발자 워크플로우가 대시보드 볼륨보다 더 중요해진다.

개발자 툴체인에서 누락된 연결 고리

종속성 보안은 특별한 이벤트처럼 느껴져서는 안 된다. 릴리즈 전 린팅, 테스팅 또는 빌드 결과 확인과 같은 느낌이어야 한다. 즉, 엔지니어링 루프의 일상적인 일부가 되어야 한다.

이것이 CVE 라이트 CLI에 대한 가장 강력한 논거다. 보안을 멀리 털어진 통제 기능에서 일상적인 개발자 습관으로 가져오는 데 도움이 되는 툴이다.

두 번 이상의 조정이 필요한 종속성 경로에서는 로컬 우선 스캔-수정-재스캔 워크플로우가 반복적인 CI 피드백에만 의존하는 방법보다 실질적으로 더 빠를 수 있다. 개발자가 록파일 기반 종속성 상태를 로컬에서 스캔하고, 무엇이 직접 종속성이고 무엇이 전이 종속성인지 파악하고, 종속성 경로를 확인하고, 릴리즈 전에 수정할 항목을 안정적으로 포착할 수 있게 될 때 종속성 보안은 추상적인 정책이 아닌 실질적인 엔지니어링이 되기 시작한다.

자바스크립트 생태계에는 바로 이런 것이 더 필요하다.

보여주기 위한 보안 결과물은 더 이상 Node.js에 필요하지 않다. 필요한 것은 더 나은 개발자 워크플로우 인프라다. 조치를 취할 시간이 아직 남아 있는 동안 명확하고 즉각적이고 마찰이 적은 답을 줄 수 있는 툴이 필요하다. 종속성 의사결정이 내려지는 바로 그 지점에서 종속성 위험을 볼 수 있게 해주는 툴이 필요하다.

로컬 우선 록파일 인식 워크플로우는 그 방향을 가리킨다.

종속성 보안을 일상적인 소프트웨어 엔지니어링 업무의 일부로 만드는 것이 목표라면 로컬 우선 록파일 스캔은 부가적인 틈새 기능이 아닌 개발자 툴체인의 일부가 되어야 한다.
dl-itworldkorea@foundryco.com