취약점
CVE 조치: 보안 권고부터 수정된 빌드 출시까지
새로운 CVE가 발표됩니다. 어떤 제품에 취약한 패키지가 들어 있고, 어떤 릴리스가 그것을 출시했으며, 수정은 언제 나올까요? CVE 조치는 이 질문에 답하는 프로세스이며, 풀 리퀘스트가 머지되었다고 끝나지 않습니다. 수정된 빌드가 출시되어야 끝납니다.
업데이트
CVE 조치 프로세스
CVE 조치는 운영하거나 출시하는 소프트웨어에서 공개된 취약점을 제거하는 일입니다. 자체 코드라면 패치를 의미합니다. 일반적인 제품에서 대부분의 CVE가 나오는 오픈 소스 종속성이라면 취약점이 수정된 버전으로 옮기는 것을 의미합니다. 어느 쪽이든 단계는 같습니다.
- 영향받는 패키지와 버전이 들어 있는 모든 제품, 빌드, 릴리스를 찾습니다.
- 취약점이 영향을 미치는지, 얼마나 심각한지 평가합니다.
- 열려 있는 다른 모든 항목과 비교해 우선순위를 정합니다.
- 업그레이드, 패치, 교체로, 수정이 없다면 완화 조치로 수정합니다.
- 새 빌드에 실제로 수정된 버전이 들어 있는지 검증합니다.
- 무엇이 영향을 받았는지, 어떤 결정을 내렸는지, 수정이 언제 출시되었는지 기록합니다.
1단계: 영향받는 모든 빌드 찾기
보안 권고가 나온 뒤 첫 질문은 그 패키지가 어디에 있는가입니다. 소스 리포지토리로 이 질문에 답하면 느리고, 틀리는 경우도 많습니다. 잠금 파일의 버전, 빌드가 실제로 해석한 버전, 출시된 컨테이너 이미지의 버전이 모두 다를 수 있습니다. 전이적 종속성과 빌드가 패키지 관리자 밖에서 내려받는 패키지는 매니페스트에 아예 나타나지 않습니다.
신뢰할 수 있는 답은 각 릴리스의 SBOM을 보안 권고와 지속적으로 매칭하는 데서 나옵니다. 그 SBOM이 빌드 중에 기록된 것이라면 빌드가 실제로 사용한 항목이 나열되므로, 매칭 결과는 어떤 리포지토리가 그 버전을 언급하는지가 아니라 어떤 출시 빌드에 취약한 버전이 들어 있는지를 알려 줍니다.
2단계: 심각도와 악용 여부로 우선순위 정하기
심각도만으로는 너무 많은 취약점이 긴급으로 분류됩니다. 대부분의 팀은 세 가지 신호를 결합합니다.
| 신호 | 알려 주는 것 | 발표 주체 |
|---|---|---|
| CVSS | 악용될 경우 취약점이 얼마나 심각한지를 0~10점으로 평가 | FIRST(표준), NVD와 공급업체가 점수를 발표 |
| EPSS | 향후 30일 안에 악용될 추정 확률 | FIRST |
| KEV | 취약점이 실제로 악용되고 있는 것으로 알려져 있는지 여부 | CISA의 Known Exploited Vulnerabilities 카탈로그 |
그런 다음 자체 맥락을 더합니다. 영향받는 패키지가 고객에게 출시되는지 아니면 테스트 작업에서만 실행되는지, 취약한 함수가 실제로 사용되는지를 확인합니다. 출시되는 패키지에 있는, 악용이 알려진 취약점이 목록의 맨 위로 갑니다. 취약점 우선순위 지정은 이러한 신호를 하나의 방법론으로 만듭니다.
조치 기한
- CISA BOD 26-04. 2026년 6월 10일부터 미국 연방 기관은 네 가지 질문으로 각 기한을 정합니다. 자산이 공개적으로 노출되어 있는가, 취약점이 KEV 카탈로그에 있는가, 악용을 자동화할 수 있는가, 부분적 또는 전체적 제어권을 주는가. 답에 따라 가장 심각한 경우 포렌식 트리아지를 동반한 3일부터 다음 시스템 업그레이드 시 수정까지 다양합니다. 대부분의 KEV 항목에 2주를 주었던 BOD 22-01을 대체했습니다.
- EU Cyber Resilience Act. 제조사는 보안 업데이트를 포함해 취약점을 지체 없이 해결하고 조치해야 합니다(부속서 I, 제II부). 2026년 9월 11일부터는 제품에서 실제로 악용되고 있는 취약점이 보고 기한도 시작시킵니다. 24시간 이내의 조기 경보, 72시간 이내의 통지, 그리고 수정이 제공된 후 14일 이내의 최종 보고서입니다.
- 자체 정책. 대부분의 보안 프로그램은 심각도별 내부 목표를 정합니다. 그 목표가 무엇이든 1단계가 빨라야만 지킬 수 있습니다.
3단계: 수정 방법 선택
| 옵션 | 사용 시점 |
|---|---|
| 업그레이드 | 수정된 버전이 있는 경우. 호환성을 깨는 변경을 줄이려면 수정이 포함된 가장 작은 업그레이드를 선택합니다. |
| 상위 패키지 업그레이드 | 취약한 패키지가 전이적 종속성인 경우. 직접 종속성의 새 릴리스가 수정을 함께 가져오는 경우가 많습니다. |
| 오버라이드 |
상위 패키지가 수정을 릴리스하지 않은 경우. npm overrides, Yarn
resolutions 또는 pnpm.overrides로 전이적 종속성의 버전을 강제하고 테스트합니다.
|
| 패치 또는 백포트 | 아직 수정된 메이저 버전으로 옮길 수 없는 경우. 업스트림 수정을 사용 중인 버전에 적용합니다. |
| 교체 | 패키지가 유지 관리되지 않거나 계속 CVE가 나오는 경우. 대안으로 옮깁니다. |
| 완화 및 문서화 | 아직 수정이 없거나 제품이 영향을 받지 않는 경우. 노출을 줄이고, 평가 내용을 예를 들어 VEX 문으로 기록합니다. |
버전 선택부터 풀 리퀘스트 생성까지 이 단계의 대부분은 자동화할 수 있습니다. 자동화된 취약점 조치에서 무엇을 자동화하고 무엇을 사람에게 맡길지 다룹니다.
4단계: 머지된 수정이 출시된 수정은 아닙니다
풀 리퀘스트가 머지되었으니 CVE가 종결되었을까요? 꼭 그렇지는 않습니다. 수정은 리포지토리에 있지만, 빌드가 오래된 캐시를 복원하거나, 베이스 이미지에 여전히 이전 패키지가 들어 있거나, 릴리스 브랜치가 변경 사항을 반영하지 않았을 수 있습니다. 티켓에는 수정 완료로 표시되어 있는데 제품은 여전히 취약한 버전을 출시하는 것입니다.
반대편에서 확인해 고리를 닫으세요. 다음 빌드의 SBOM을 확인하고 취약한 버전이 사라졌는지 확인합니다. 그 SBOM이 캐시에서 복원된 패키지를 포함해 빌드가 실제로 가져온 항목을 기록한다면, 이 확인은 고객, 감사인, 규제 기관이 실제로 묻는 질문에 대한 답이 됩니다.
CRACI가 CVE 조치를 지원하는 방법
- 찾기. CRACI는 전이적 종속성과 캐시에서 복원된 패키지를 포함해 각 GitHub Actions 작업이 가져온 패키지를 기록하고, 모니터링 중인 SBOM을 지속적으로 재평가합니다. 조직 뷰는 빌드와 리포지토리 전반의 발견 사항을 집계하므로, 새 CVE가 어떤 빌드에 영향을 미치는지 확인할 수 있습니다.
- 할당. 보안 팀은 각 발견 사항을 분류해 수정 책임이 있는 팀에 보냅니다. CRACI는 취약점이 제품에 어떤 영향을 미치는지 기록할 수 있도록 VEX를 지원합니다.
- 검증. 각 새 빌드에는 완전성 상태가 표시된 자체 SBOM이 생성되므로, 빌드가 수정된 버전을 사용했는지 확인할 수 있습니다.
- 보고. CRA에 따른 실제 악용 취약점에 대해 CRACI는 통지의 내용을 준비하고, 제조사의 담당자가 Single Reporting Platform을 통해 제출합니다.
전체 기능은 취약점 추적에서 확인하세요.
CVE 조치: 자주 묻는 질문
CVE 조치란 무엇인가요?
CVE 조치는 CVE ID로 식별되는 공개된 취약점을 운영하거나 출시하는 소프트웨어에서 제거하는 일입니다. 종속성의 경우 대개 취약점이 수정된 버전으로 업그레이드하는 것을 의미하고, 자체 코드의 경우 패치를 의미합니다.
어떤 CVE를 먼저 수정할지 어떻게 우선순위를 정하나요?
심각도와 악용 증거를 결합하세요. CVSS는 취약점이 얼마나 심각한지를, EPSS는 향후 30일 안에 악용될 가능성을 추정하며, CISA의 Known Exploited Vulnerabilities 카탈로그는 이미 악용되고 있는 취약점을 나열합니다. 출시하는 패키지에 있는, 악용이 알려진 취약점이 맨 위로 갑니다.
CVE는 얼마나 빨리 조치해야 하나요?
누가 요구하느냐에 따라 다릅니다. CISA의 구속력 있는 운영 지침(BOD) 26-04는 취약점이 KEV 카탈로그에 있는지, 자산이 공개적으로 노출되어 있는지, 악용을 자동화할 수 있는지, 공격자에게 얼마나 많은 제어권을 주는지에 따라 미국 연방 기관에 3일부터 다음 시스템 업그레이드까지의 기한을 부여합니다. EU Cyber Resilience Act는 제조사에게 취약점을 지체 없이 조치하도록 요구하며, 2026년 9월 11일부터는 제품에서 실제로 악용되고 있는 취약점이 24시간 보고 기한을 시작시킵니다.
아직 수정된 버전이 없다면 어떻게 하나요?
완화하고 문서화하세요. 가능하다면 영향받는 기능을 비활성화하거나, 공격 경로를 차단하거나, 구성 요소를 교체하고, 평가 내용을 예를 들어 VEX 문으로 기록합니다. 그런 다음 수정된 릴리스를 지켜보다가 나오면 조치합니다.
전이적 종속성의 CVE는 어떻게 수정하나요?
먼저 해당 패키지를 가져오는 직접 종속성을 업그레이드해 보세요. 새 릴리스가 수정을 함께 가져오는 경우가 많습니다. 아직 없다면 대부분의 패키지 관리자에서 전이적 패키지의 버전을 강제할 수 있습니다. npm에서는 overrides, Yarn에서는 resolutions, pnpm에서는 pnpm.overrides입니다. 상위 패키지가 그 버전을 대상으로 빌드되지 않았으므로 결과를 테스트하세요.
새 CVE가 어떤 빌드에 영향을 미치는지 파악하세요
데모를 예약하고 워크플로 하나를 CRACI에서 실행해 보세요. 빌드가 실제로 가져온 모든 취약한 패키지와 새 보안 권고가 영향을 미치는 빌드를 확인할 수 있습니다.
데모 예약