CVE란 무엇인가? 구조, 심각도 및 취약점 해결 방법

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

소프트웨어를 설치할 때 ‘CVE-’로 시작하는 코드가 깜빡이는 것을 보고 그 의미가 무엇인지 궁금해한 적이 있으신가요? 여러분만 그런 게 아닙니다. 우리 모두 그런 경험이 있죠. 이 코드들은 중요한 사이버 보안 비상 신호입니다. 이번 글에서는 CVE 식별자의 구성 요소를 살펴보고, 그 구조를 설명하며, ‘전달적 의존성’과 같은 개념과 취약점 패치에 대한 모범 사례를 함께 알아보겠습니다.

CVE란 무엇인가요?

예전에는 “IIS 경로 탐색”처럼 결함 자체를 지칭하는 고유한 이름이 취약점에 붙여졌지만, 수십 년에 걸쳐 취약점이 누적되면서 표준화된 식별자가 필요하게 되었습니다.

CVE(Common Vulnerabilities and Exposures) 식별자는 공개적으로 알려져 있고 확인된 사이버 보안 결함에 대해 표준화된 명칭을 제공합니다. 이러한 공통된 용어를 통해 보안 전문가와 공급업체는 특정 취약점에 대해 신속하고 정확하게 소통할 수 있습니다. 소프트웨어 내 CVE를 식별하는 것은 필수적입니다. 특히 외부 구성 요소가 많은 환경에서는 더욱 그러합니다. 이를 통해 보안 팀은 패치 적용의 우선순위를 정하고, 위험을 평가하며, 악용되기 전에 결함을 신속하게 수정함으로써 데이터와 시스템 가용성을 보호할 수 있기 때문입니다.

CVE는 마치 자주 이용하는 쇼핑몰에서 물건을 주문했을 때 받는 추적 번호와 비슷하다고 생각하시면 됩니다. 이는 버그를 추적하고, 해당 취약점의 영향을 받은 패키지 버전을 파악할 수 있는 방법입니다.

모범 사례에 대한 전체적인 개요를 확인하시려면, 당사의 심층 가이드에서 CVE 패치 적용에 대해 자세히 알아보실 수 있습니다.

CVE의 구조

CVE는 다음과 같은 형식입니다: ‘CVE-2025-1111‘ – 접두사 CVE, 결함이 발견된 연도, 고유 식별자 순으로 구성됩니다.

이 번호는 MITRE Corporation과 490개 이상의 CNA로 구성된 글로벌 네트워크에 의해 할당됩니다. 이러한 CNA(CVE 번호 부여 기관)에는 Microsoft, Red Hat, Oracle과 같은 IT 벤더는 물론 다양한 기관 및 보안 연구원들이 포함됩니다.

국가 취약점 데이터베이스(NVD)는 CVE가 CVE 목록에 게시되면 해당 CVE의 정보를 보완하는 역할을 맡고 있습니다. 실제로 이는 MITRE와 NVD 간의 인계가 이루어진 후, NVD가 추가 메타데이터를 통해 CVE 정보를 보완한다는 것을 의미합니다. 이 인계가 완료되면 거쳐야 할 절차가 있습니다. NIST에 따르면, 이 절차에는 다음이 포함됩니다:

CVE와 함께 제공되는 자료를 검토합니다.
CWE (C일반 취약점 목록) 해당 취약점을 분류하는 CWE ID가 할당됩니다.
(CVSS v3.1 또는 v4.0 지표에 따른) 악용 가능성과 영향도 지표가 할당됩니다.
이 취약점에는 CPE(Common Platform Enumerator) 항목이 연관되어 있습니다.
마지막으로, 보강된 데이터가 공개되기 전에 선임 분석가가 품질 검증을 수행합니다.

CVE가 공개되면 향후 추가적인 유지보수 작업이 진행될 수 있습니다. 수정 사항이 반영되거나, 참고 자료가 추가되거나, 설명이 업데이트되는 등의 조치가 있을 수 있습니다.

취약점 이해

다음 명령어를 실행하면 npm audit 명령어를 실행하거나 프로젝트 내에서 패키지를 설치할 때 다음과 같은 출력이 표시될 수 있습니다: 7개의 고위험 취약점. “이게 무엇이고 어떤 모습일까?”라고 궁금해하실 수 있습니다 . 초기 출력에는 CVE가 나열되지 않고, 대신 영향을 받는 패키지와 해당 버전이 나열됩니다. 다음은 Angular v18을 설치할 때의 npm audit 출력 예시입니다( Angular 16과 같은 구버전의 경우, 1년 넘게 누적된 의존성 노후화로 인해 화면이 더 복잡해집니다):


롤업  4.0.0 - 4.58.0

중요도: 높음

롤업 4 경로 탐색(Path Traversal)을 통한 임의 파일 쓰기 취약점 - https://github.com/advisories/GHSA-mw96-cpmx-2vgc

`npm audit fix --force`를 통해 수정 가능

@angular-devkit/build-angular@를 설치합니다19.2.22, 이는 호환성 변경 사항입니다

node_modules/rollup

  @angular/build  18.1.0-next.0 - 19.2.21 || 20.0.0-다음.0 - 20.2.0-rc.1 || 20.3.4 - 20.3.17

  취약한 버전의 rollup에 따라 다름

  node_modules/@angular/build

    @angular-devkit/build-angular  *

    @angular/build의 취약한 버전에 의존

    취약점이 있는 버전의 copy-webpack-plugin에 의존합니다

    node_modules/@angular-devkit/build-angular

즉, 이는 rollup 패키지가 전이적 종속성으로 설치되었다는 뜻입니다. 영향을 받는 버전은 4.0.0 – 4.58.0입니다. 해당 버전에는 심각도가 높은 보안 취약점이 존재합니다. 이 취약점은 “경로 탐색을 통한 임의 파일 쓰기(Arbitrary File Write via Path Traversal)” 결함이라고 불립니다. 이는 악의적인 공격자가 rollup을 속여 사용자가 의도하지 않은 위치에 파일을 작성하도록 유도하는 입력을 생성할 수 있음을 의미합니다. 이는 소프트웨어 공급망 취약점의 전형적인 사례입니다. 사용자가 패키지를 설치했지만, 롤업 이 함께 설치되었는데, 이는 사용자가 의도적으로 설치한 것이 아닙니다.

@angular-devkit/build-angular

  └── @angular/build (취약점이 있는 버전)

        └── rollup (4.0.0 - 4.58.0) ← 취약점이 있는 패키지

결함 수정

만약 우리가 계속해서 롤업 예제를 계속 살펴본다면, 보안 애플리케이션 개발자로서 CVE 수정 패치를 직접 작성하고 있지 않더라도 이 취약점을 해결할 수 있는 몇 가지 방법이 있습니다. npm audit fix –force 이 명령을 실행하면 문제를 문제를 해결할 수 있지만, 이 접근 방식에는 그 나름의 장단점이 따릅니다..

해당 명령어를 실행하면 @angular-devkit/build-angular 를 버전 19.2.22로 업그레이드됩니다. 이 버전은 호환성 변경 사항으로 표시되어 있으며 빌드 구성 및 API에 영향을 줄 수 있습니다. 추후 코드 수정이 필요할 수도 있는데, 누가 그런 일에 시간을 낼 여유가 있겠습니까?

이 문제를 해결하는 방법을 알아보려면 다음과 같은 조치를 취해 볼 수 있습니다:

현재 사용 중인 Angular 버전을 확인하여 새 버전으로의 전환이 얼마나 큰 변화일지 파악해 보세요.
다음의 변경 내역을 참조하십시오. @angular-devkit/build-angular 버전의 변경 내역을 참조하십시오.
새 브랜치를 생성하고 해당 브랜치에서 수정 사항을 적용하십시오. 절대로 main 브랜치에서는 수정하지 마십시오.
변경 사항이 너무 위험하다고 판단되면 이를 인지하고 보류하십시오.

재정의

오버라이드를 사용하는 것은 당장의 문제를 해결해 줄 수 있는 임시 방편이지만, 위험 요소도 따릅니다. 이는 패치된 특정 버전의 롤업 패키지의 특정 패치 버전을 강제로 적용하게 될 수 있습니다. @angular-devkit/build-angular의 호환성 문제를 일으키는 업그레이드를 거치지 않고도 특정 버전의 롤업 패키지를 강제로 적용할 수

패치된 버전을 package.jso파일에 아래와 같이 추가할 수 있습니다. 예시 JSON에 있는 버전은 2026년 2월 기준 최신 패치 버전입니다.

{

  "overrides": {

    "rollup": "^4.59.0"

  }

}

반드시 다음 명령을 실행하십시오 npm install 명령어를 실행하여 패치된 버전을 설치하고, npm audit를 실행하여 설치되었는지 다시 한 번 확인하십시오. 그러면 취약점이 사라진 것을 확인할 수 있을 것입니다.

이 해결책이 효과가 있는 이유는 overrides 필드가 npm에게 “어떤 일이 있어도, 변명 없이 이 패키지를 설치하라”라고 지시하기 때문입니다. 이는 overrides를 사용하여 전이적 종속성 트리를 완전히 우회합니다.

다음과 같은 경우 오버라이드는 좋은 방법입니다:

정말 배송을 해야 하는데, 시스템 업그레이드로 인해 막혀버렸네요
이 취약점은 운영 환경용 도구가 아닌 빌드 도구에 존재하므로 위험도가 낮습니다
빌드를 테스트한 결과, 오류가 없는 것으로 확인되었습니다

이 경우 overrides 필드는 단지 임시적인 것이므로, 이 문제를 해결하는 더 나은 방법들이 있습니다. 브랜치에서 테스트를 수행하고 테스트가 통과된다면 호환성 변경 사항을 수용해도 됩니다. 문제가 없고 검토가 완료되었다면 진행하세요. 호환성을 깨지 않는 패치가 이미 존재한다면 그것을 사용하세요. 빌드를 깨지 않는 메이저/마이너 패치가 있는지 변경 내역을 확인하세요. 마지막으로 해야 할 일은 실제 위험을 평가하는 것입니다.

앞서 언급했듯이, rollup 은 빌드 도구이지 프로덕션 환경용 도구가 아니므로 위험이 더 낮습니다. 일반적으로 프로덕션 환경에서는 실행되지 않습니다. 오버라이드 를 사용하면 결국 잘못된 안도감을 줄 수 있습니다. npm audit 경고는 더 이상 받지 않게 되겠지만, 동시에 테스트되지 않은 변경 사항을 프로젝트나 빌드에 도입하게 되는 셈입니다.

결론은 간단합니다. 호환성 변경 사항을 수용할 수 있다면 그렇게 하세요. 그렇지 않다면 오버라이드를 사용하세요.

요약