본문으로 건너뛰기

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

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 운영, CVSS 점수 공식 기준참조 데이터베이스

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

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

취약점 대응 우선순위 결정

CVSS(Common Vulnerability Scoring System) 점수는 취약점의 심각도를 0~10 사이 숫자로 표현합니다. 이 점수를 기반으로 대응 기한을 결정합니다.

대응 기한의 정본

CVSS 심각도별 대응 기한표(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 사용 시 최초 시작에 35분, NVD 데이터 동기화에 1030분 소요됩니다. 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 생성 (우선순위별 패치 계획)
충족되는 표준 요구사항

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

ISO/IEC 18974

항목 ID요구사항자체인증 체크리스트
4.1.5취약점 대응 절차Do you have a documented procedure to identify and remediate known vulnerabilities in supply software?
4.3.2취약점 식별 및 추적Do you have a process for identifying, tracking, and remediating known vulnerabilities in supply software?

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/       다음