지루해지지 않고 npm 감사에서 발견된 취약점을 선별하는 방법

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

달리세요 npm audit, 그리고 바로 이것이죠:

14 vulnerabilities (3 low, 6 moderate, 4 high, 1 critical)

와, 이걸 보세요. 취약점이 14개나 있네요. 아마 한 달 동안 방치되어 있던 프로젝트일 테고, 여러분이 손을 댄 건 고작 두 번 정도일 겁니다. 누군가 물어본다 해도 그 패키지 이름조차 떠올리지 못할 가능성이 큽니다. 아마도 직접적인 의존성 때문에 우연히 포함된 것들일 테니까요. 이 시점에서 첫 번째 조치는 늘 그렇듯 정해진 절차대로 진행됩니다: 다음 명령을 실행하세요. npm audit fix, 문제가 해결되는 것을 확인한 뒤 터미널을 닫고 평소처럼 하루를 보내면 됩니다. 실제로 14가지 취약점을 모두 낱낱이 파헤치는 사람은 아무도 없으니까요.

게으름? 아니요. 피로? 네, 그리고 이 문제는 “개발자들이 보안을 신경 쓰지 않는다”는 식으로 뭉뚱그리기보다는 별도의 문제로 지적할 가치가 있습니다. 왜냐하면 이 두 가지 원인에 대한 해결책은 매우 다르기 때문입니다.

npm audit의 노이즈 문제

npm audit 한 가지 장점은, 알려진 취약점이 의존성 트리 어딘가에 존재한다는 사실을 알려준다는 점입니다. 그것이 실행 중인 애플리케이션에 실제로 영향을 미치는지 여부를 알려주는가? 그건 또 다른 문제입니다.

4단계나 깊숙이 묻혀 있는 코드가 “High” 심각도 등급을 표시하기 시작하면, 이를 어떻게 처리해야 할까요? npm은 가장 일반적인 사용 사례에서 발생하는 영향도와 악용 가능성을 기준으로 심각도를 정의하지만, 여러분의 애플리케이션이 그 일반적인 사례에 해당하지 않을 수도 있습니다. 하지만 “우리는 절대 그 코드를 호출하지 않는다”는 것도 면책 사유가 될 수는 없습니다. 요청이 애플리케이션에 도달하기도 전에 설치 스크립트나 빌드 도구가 취약한 코드를 실행할 수 있기 때문입니다.

그리고 개수 문제도 있습니다. 그 14라는 숫자는 표시된 패키지의 수일 뿐, 개별적인 문제 건수를 의미하지는 않습니다. 하나의 패키지에 여러 건의 보안 권고 사항이 포함되어 있어도 개수로는 한 번만 집계되며, npm은 메타 취약점도 표시합니다. 메타 취약점이란, 선언된 의존성 범위가 하위 패키지의 취약한 버전으로만 해결될 수 있는 패키지를 말합니다. 따라서 14개의 “취약점”은 실제로는 서로 다른 형태로 나타나는 4~5개의 개별적인 문제일 수 있습니다.

더 큰 문제는 개발 의존성이 프로덕션 런타임 코드와 정확히 동일한 긴급도로 분류된다는 점입니다. 개발자의 노트북에 설치된 취약점이 있는 ESLint 플러그인과 공개 인터넷에 노출된 취약점이 있는 인증 라이브러리는 근본적으로 같은 수준의 긴급성을 가진 문제가 아닙니다. 하지만 이는 양날의 검과도 같습니다. CI에서 실행되거나, 기밀 정보를 다루거나, 배포하는 아티팩트를 구성하는 빌드 의존성은 단순히 다음 경로 아래에 위치한다는 이유만으로 우선순위가 낮은 것은 아닙니다. devDependencies.

이 도구가 반드시 고장 난 것은 아닙니다. 단지 여러분이 궁금해하는 질문에 답하는 데 필요한 실행 컨텍스트가 부족할 뿐입니다.

팀이 무기력해지는 이유

피로, 불안, 초조함: 이 모든 것이 의존성 및 CVE 피드를 모니터링할 때만 나타나는 현상은 아니지만, 의존성 보안은 이 세 가지를 모두 유발하는 주요 원인입니다.

티켓 더미는 끝이 없을 것처럼 보입니다. 누군가가 처리할 수 있는 속도보다 훨씬 빠르게 계속 쌓여만 갑니다. 50번째 취약점을 선별해 봤더니 그중 49개가 관련이 없거나, 접근이 불가능하거나, 이미 다른 곳에서 처리된 것으로 드러난다면, ‘고위험’이라는 라벨은 그다지 큰 의미를 갖지 못하게 됩니다. 이것이 바로 경보 피로입니다.

진정한 대가는 잡다한 대화나 알림 자체가 아니라, 그 속에 묻혀버리는 것들입니다. 모든 알림을 똑같이 취급한다면, 실제로 중요한 알림도 마찬가지로 취급받게 됩니다. 검토 작업은 단순히 체크리스트를 채우는 식으로 변질됩니다. CI에서 감사가 실행되고, 누군가가 개수만 대충 훑어볼 뿐, 실제로 검토되는 내용은 아무것도 없습니다. 결국 누군가가 다음과 같이 덧붙이게 됩니다. || true 감사 단계로 넘겨 파이프라인이 다시 정상 상태로 돌아오게 하고, 그 줄은 왜 거기에 있는지 모두가 잊어버릴 때까지 그대로 남아 있게 됩니다. 누군가가 관심을 끊은 것은 아닙니다. 단지 백로그가 누구도 처리해 나갈 수 있는 속도보다 더 빠르게 불어났을 뿐입니다.

업그레이드 자체도 상당한 부담이 따릅니다. npm audit fix 지정된 버전 범위에 맞는 업데이트만 적용합니다. 해당 범위를 벗어난 경우(SemVer 주요 버전 변경을 포함할 수 있음)에는 --force, 게다가 npm의 공식 문서에서도 이를 함부로 사용하지 말라고 경고하고 있습니다. 일부 문제에는 자동 수정 방법이 아예 없는 경우도 있습니다. “그냥 업데이트하면 된다”는 말은 겉보기만큼 간단한 해결책이 아닙니다.

더 합리적인 트라이아지 패스

그렇다고 해서 무시하라는 뜻은 아닙니다 npm audit. 즉, 출력의 모든 줄을 똑같이 시급한 것으로 취급하지 말라는 뜻입니다. 실제로는 그렇지 않기 때문입니다.

실제로 도움이 되는 몇 가지 방법:

단순한 심각도보다는 접근 가능성과 노출 정도를 우선시하십시오. 환경에서 접근할 수 없는 코드에 있는 중대한 CVE는, 일반적으로 요청 처리 과정에서 직접 노출되는 보통 수준의 CVE보다 우선순위가 낮습니다. 심각도 등급은 여러분의 호출 그래프를 알지 못하지만, 여러분은 알고 있습니다.
개발 단계에서 프로덕션 환경을 분리하고, 어떤 것이 실행되는지 확인하세요. 취약한 빌드 시간 도구와 취약한 런타임 종속성은 대개 서로 다른 대응 조치가 필요합니다. npm audit --omit=dev 유용한 첫 단계이긴 하지만, CI 환경에서 인증 정보를 사용하여 실행되는 개발 도구나, 번들러가 배포본에 포함시키는 코드는 여전히 중요합니다.
CVE가 아닌 패키지 단위로 일괄 처리하세요. 오래된 라이브러리 하나만으로도 여러 건의 보안 권고 사항이 발생할 수 있습니다. npm explain <package> 어떤 종속성이 이를 불러왔는지 보여 주며, 대개 실제 해결책은 바로 그 부분에 있습니다.
일정한 주기를 정하되, 필요 시 유연하게 대응할 수 있는 여지를 남겨두세요. 피드가 업데이트될 때마다 재분류를 하는 대신, 매주 또는 릴리스 주기에 맞춰 정기적으로 재검토하세요. 악용이 활발히 이루어지고 있거나 인터넷에 실제로 노출된 정황이 포착되면 대응 속도를 높이세요.
“지금은 아니에요”라는 대답도 타당한 답변이 될 수 있습니다. 노출 위험이 낮은 문제를 미루기로 한 공식적인 결정은 그 문제를 무시하는 것과는 다릅니다. 그 이유와 언제 다시 검토할지 기록해 둔 다음, 일을 계속 진행하세요.

이것이 바로 ‘우선순위 분류’와 단순히 알림을 처리하는 것의 차이입니다. 그중 하나는 실제로 위험을 줄여줍니다.

SecureChain의 적용 분야

다음은 솔직하게 짚어볼 필요가 있는 차이점입니다: npm audit 이는 권고 사항입니다. 무엇이 문제인지 알려주며, npm audit fix 간단한 문제 해결은 시스템이 처리해 주지만, 어려운 결정은 여전히 여러분에게 달려 있습니다. 업그레이드가 타당하고 안전한지, 패치를 이전 버전으로 적용해야 하는지, 또는 지원 종료(EOL)된 패키지가 업스트림에서 수정되고 있는지 여부를 파악하는 것이 여러분의 역할입니다.

시큐어체인 경고 목록에 또 하나를 추가하는 대신, 해당 문제의 근본 원인을 해결합니다. 공개 레지스트리는 유지보수자가 공개한 타르볼을 그대로 제공합니다. 레지스트리의 서명 정보를 통해 해당 파일이 이후로 수정되지 않았음을 확인할 수 있지만, 패키지에 출처 증명서가 포함되어 있지 않은 한 소스 저장소와의 연관성을 입증할 수 있는 근거는 없습니다. SecureChain은 강화되고 격리된 환경에서 검증된 소스 코드를 기반으로 패키지를 재컴파일하고, 패키지가 사용자의 의존성 트리에 도달하기 전에 악성코드 및 의심스러운 코드가 포함되어 있는지 검사합니다. npm audit 이 시스템은 오타 도용(typosquat), 관리자 계정 탈취, 악성 설치 스크립트 등을 자체적으로 탐지하도록 설계된 것이 아니며, 이미 보안 권고 데이터에 포함된 내용만 보고합니다. 패치는 업스트림에서 여전히 수정 프로그램을 배포하고 있든, 아니면 소식이 끊겼든 상관없이 공개된 목표 대응 시간에 따라 제공되며, 일단 패키지에 대해 업스트림 릴리스가 수개월간 없는 경우, 무제한 라이프사이클 지원(ELS)
이미 사용 중인 버전에 대한 수정 사항을 지속적으로 제공합니다.

그렇다고 해서 트라이아지 작업이 사라지는 것은 아닙니다. 달라지는 점은 패키지가 빌드 단계에 도달하기 전에 얼마나 많은 불확실성을 떠안게 되느냐는 것입니다. 패키지는 SLSA 레벨 3을 지원하도록 빌드 및 서명되며, VEX 데이터와 패키지에 따라 SBOM이 함께 제공됩니다. 이는 아무도 수작업으로 만들고 싶어 하지 않지만, 대부분의 팀이 결국 감사를 위해 필요로 하는 부분입니다. VEX는 알려진 CVE 중 어떤 것이 특정 패키지 버전에 실제로 영향을 미치는지 명확히 밝혀주기 때문에, 노이즈 문제를 가장 직접적으로 해결해 줍니다.

여기서 중요한 관점은 다음과 같습니다. SecureChain은 여러분의 관심을 끌기 위해 경쟁하는 또 다른 피드가 아닙니다. 문제가 여러분의 문제로 대두되기 전에 상당 부분이 미리 처리되기 때문에, 애초에 대기열에 들어오는 항목의 수가 줄어드는 것입니다.

요약