취약점 분석: 오픈소스의 알려진 위험 찾기

1. 이 챕터에서 하는 일

SBOM을 기반으로 사용 중인 오픈소스 컴포넌트에 알려진 CVE 취약점이 있는지 스캔합니다. 단순히 목록을 뽑는 것에 그치지 않고, CVSS 점수로 심각도를 평가하고 대응 우선순위를 결정하는 것까지 다룹니다.

이 챕터를 마치면 vulnerability-analyst agent가 output/vulnerability/cve-report.md 와 output/vulnerability/remediation-plan.md 를 자동으로 생성합니다. 두 문서는 ISO/IEC 18974가 요구하는 취약점 식별, 추적, 평가, 대응 절차의 근거 산출물이 됩니다.

이 단계의 위치

SBOM 생성이 입력, 이 취약점 분석이 산출입니다. CI에서 자동으로 묶어 돌리려면 DevSecOps → SCA를 참고하세요.

2. 배경 지식

취약점 분석이 필요한 이유

사용 중인 오픈소스에 이미 알려진 취약점이 있을 수 있습니다. 모르는 상태가 가장 위험합니다.

2021년 Log4Shell (CVE-2021-44228) 사례는 이를 극명하게 보여줍니다. 수억 개의 시스템이 취약한 상태였지만, 많은 조직은 자신들이 log4j를 사용하고 있다는 사실조차 몰랐습니다. SBOM이 있었다면 영향 범위를 즉시 파악하고 대응 우선순위를 결정할 수 있었을 것입니다.

ISO/IEC 18974가 취약점 식별을 핵심 요구사항으로 규정하는 이유는 세 가지입니다:

방어 가능한 위험: 알려진 취약점(Known Vulnerabilities)은 CVE 데이터베이스에 이미 등록되어 있습니다. 조회만 해도 알 수 있는 위험을 방치하는 것은 변명이 되지 않습니다.
무료 공개 데이터: CVE 데이터베이스(NVD, OSV)는 누구나 무료로 조회할 수 있습니다. 비용 문제가 아니라 체계의 문제입니다.
타이밍이 전부: 모니터링 체계가 없으면 패치 타이밍을 놓칩니다. Log4Shell은 공개 당일부터 대규모 공격이 시작됐습니다.

사용 도구 소개

이 챕터에서는 도구 두 가지(OSV, Dependency-Track)와 참조 데이터베이스 하나(NVD)를 사용합니다. 모두 무료이며, OSV는 Docker 없이도 즉시 사용할 수 있습니다.

도구	특징	사용 방법
OSV (osv.dev)	Google 운영, API로 간단 조회, 추가 설치 불필요	HTTP API
Dependency-Track	웹 UI, SBOM 업로드, 지속 모니터링, 대시보드	Docker Compose
NVD	미국 NIST 운영	참조 데이터베이스

권장 순서: OSV API로 먼저 빠르게 조회하고, 이후 Dependency-Track으로 지속 모니터링 체계를 구축합니다.

NVD가 모든 CVE에 CVSS 점수를 매기지는 않습니다

NIST는 2026-04-15부터 NVD 보강(enrichment) 작업을 위험 기반으로 전환했습니다. CISA KEV 등재, 연방정부 사용 소프트웨어, EO 14028이 정의한 중요 소프트웨어에 해당하는 CVE만 우선 보강하고, 그 외는 "Not Scheduled"로 분류합니다. 즉 CVSS 점수 없이 등록만 된 CVE가 계속 늘어납니다. 대응 우선순위를 CVSS 점수 하나에만 의존하지 말고, 아래 KEV·EPSS를 함께 참고하세요. NVD를 보완하는 대안으로 ENISA가 운영하는 EUVD(European Union Vulnerability Database, europa.eu)와 GNA(GCVE Numbering Authority) 연합이 운영하는 GCVE(db.gcve.eu)도 함께 조회할 수 있습니다.

도구 설치 및 실행 명령어는 도구 설치 및 설정 페이지를 참조합니다.

취약점 대응 우선순위 결정

CVSS(Common Vulnerability Scoring System) 점수는 취약점의 심각도를 0~10 사이 숫자로 표현합니다. 점수가 높을수록 위험합니다. 이 점수를 기반으로 아래처럼 등급을 나누고, 등급별로 대응 기한을 정합니다.

등급	CVSS 점수	대응 기한
Critical	9.0~10.0	1주일 내
High	7.0~8.9	4주일 내
Medium	4.0~6.9	1개월 내
Low	0.1~3.9	다음 릴리즈

예를 들어 CVSS 7.5라면 High 등급이므로 4주일 안에 패치나 완화 조치를 해야 합니다.

대응 기한의 정본

위 표의 근거(KWG 기준선과 조직별 SLA 강화안)와, CVE 노이즈를 줄이는 VEX 개념은 취약점 대응 기한과 VEX에 정리돼 있습니다.

이 기준은 output/process/vulnerability-response.md 에 프로세스로 문서화되어 있어야 합니다. 챕터 04-process 에서 이미 작성했다면 해당 문서를 참조합니다.

샘플 프로젝트 실습 예상 결과

samples/java-vulnerable/ 를 실습 대상으로 사용할 경우:

탐지: log4j-core 2.14.1
CVE: CVE-2021-44228 (Log4Shell) — JNDI lookup을 통한 원격 코드 실행
CVSS: 10.0 (Critical) → 즉시 대응 필요
대응: log4j-core 2.17.1 이상으로 업그레이드

samples/python-mixed-license/ 를 실습 대상으로 사용할 경우:

GPL 라이선스 혼재 탐지는 라이선스 분석(챕터 05-1)에서 처리
취약점은 해당 패키지 버전에 따라 별도 확인 필요

3. 셀프 스터디

셀프스터디 모드 (약 45분~1시간)

Dependency-Track 사용 시 최초 시작에 3~~5분, NVD 데이터 동기화에 10~~30분 소요됩니다. OSV API 방식으로 먼저 진행하면 즉시 결과를 볼 수 있습니다.

사전 조건 확인:

챕터 05-1(SBOM 생성)이 완료되어 있어야 합니다. output/sbom/ 디렉터리에 .cdx.json 파일이 존재하는지 먼저 확인합니다.

Bash
ls output/sbom/
# *.cdx.json 파일이 있어야 한다

단계별 실습:

1단계 — SBOM 파일 존재 확인

Bash
ls output/sbom/*.cdx.json

파일이 없으면 챕터 05-1로 돌아가 SBOM을 먼저 생성합니다.

2단계 — vulnerability-analyst agent 실행

실행 전 확인

현재 Claude 세션을 먼저 종료(/exit 또는 Ctrl+C)한 뒤, 새 터미널에서 아래 명령을 실행하세요.

Bash
cd agents/05-vulnerability-analyst
claude

3단계 — agent 자동 처리 확인

agent가 자동으로 다음을 수행합니다:

output/sbom/ 의 CycloneDX SBOM 파일 파싱
각 컴포넌트에 대해 OSV API 조회
CVSS 점수 기준으로 심각도 분류
대응 계획 초안 작성

예상 출력 (java-vulnerable 기준):

[INFO] SBOM 파일 로드: output/sbom/java-vulnerable.cdx.json
[INFO] 컴포넌트 4개 발견
[INFO] OSV API 조회 중...
[WARN] CVE-2021-44228 탐지: log4j-core 2.14.1 (CVSS 10.0, Critical)
[INFO] 리포트 생성 완료

4단계 — cve-report.md 확인

Bash
cat output/vulnerability/cve-report.md

다음 항목이 포함되어 있어야 합니다:

탐지된 CVE 목록 (CVE ID, 컴포넌트, 버전, CVSS, 심각도)
컴포넌트별 상세 분석
영향 범위 평가

5단계 — remediation-plan.md 확인

Bash
cat output/vulnerability/remediation-plan.md

다음 항목이 포함되어 있어야 합니다:

우선순위별 패치 계획 (Critical → High → Medium → Low 순)
각 취약점별 대응 기한
패치 버전 또는 대안 라이브러리

6단계 — Critical/High 취약점 대응 계획 검토

탐지된 Critical/High 취약점에 대해 실제 대응 가능 여부를 검토합니다:

패치 버전이 존재하는가?
패치 적용 시 호환성 문제가 없는가?
즉시 패치가 불가능한 경우 완화 조치(WAF 규칙 추가, 기능 비활성화 등)가 있는가?

7단계 — (선택) Dependency-Track 실행

웹 UI로 대시보드를 확인하고 싶다면:

Bash
# docker-compose.yml 이 있는 디렉터리에서
docker compose up -d
# http://localhost:8081 접속 후 SBOM 업로드

각 단계 예상 결과 요약:

3단계 완료 후: CVE 조회 결과 터미널 출력 (java-vulnerable이면 CVE-2021-44228 포함)
4단계 완료 후: cve-report.md 생성 (탐지된 CVE 목록, CVSS 점수, 영향도)
5단계 완료 후: remediation-plan.md 생성 (우선순위별 패치 계획)

충족되는 표준 요구사항

이 실습을 완료하면 아래 요구사항이 충족됩니다.

18974 §4.1.5, §4.3.2

각 항목의 자체 인증 체크리스트 문항 원문과 입증자료는 요구사항 상세 대조표에 있습니다.

4. 완료 확인 체크리스트

아래 항목을 모두 충족하면 이 챕터를 완료한 것으로 봅니다.

output/vulnerability/cve-report.md 생성됨
output/vulnerability/remediation-plan.md 생성됨
Critical/High 취약점이 목록에 포함됨 (없으면 "없음"으로 명시)
CVSS 점수 기반 심각도 분류가 적용됨
취약점별 대응 기한이 명시됨
패치 버전 또는 대안이 제시됨

cve-report.md 주요 섹션 예시:

Markdown
## 탐지된 취약점 요약

| CVE ID         | 컴포넌트   | 버전   | CVSS | 심각도   | 대응 기한 |
| -------------- | ---------- | ------ | ---- | -------- | --------- |
| CVE-2021-44228 | log4j-core | 2.14.1 | 10.0 | Critical | 즉시      |

## 컴포넌트별 상세 분석

### log4j-core 2.14.1

- 취약점: Log4Shell — JNDI lookup 원격 코드 실행
- 영향도: 전체 애플리케이션 서버
- 패치 버전: 2.17.1 이상

이 단계는 ISO/IEC 18974 §4.3.2 요구사항을 충족합니다.

산출물 예시

취약점 산출물 Best Practice에서 생성된 파일의 실제 형식을 확인할 수 있습니다.

5. 다음 단계

이 챕터를 완료하면 교육 체계 구축 단계로 이동합니다.

실행 전 확인

현재 Claude 세션을 먼저 종료(/exit 또는 Ctrl+C)한 뒤, 새 터미널에서 아래 명령을 실행하세요.

Bash
cd agents/06-training-manager
claude

Claude 프롬프트가 열리면 시작 을 입력합니다.

또는 셀프스터디 방식으로 교육 체계: 조직 전체의 오픈소스 인식 높이기로 이동합니다.

진행 상황 확인: output/progress.md 파일에서 전체 완료율을 확인할 수 있습니다.

완료 후 output/ 상태:

output/
├── organization/   완료
├── policy/         완료
├── process/        완료
├── sbom/           완료
├── vulnerability/  완료  <- 이 챕터
└── training/       다음