본문으로 건너뛰기

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

1. 이 챕터에서 하는 일​

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

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

2. 배경 지식​

취약점 분석이 필요한 이유​

"사용 중인 오픈소스에 이미 알려진 취약점이 있을 수 있습니다. 모르는 것이 더 위험하다."

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

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

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

사용 도구 소개​

이 챕터에서는 두 가지 도구를 사용합니다. 두 도구 모두 무료이며, 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 점수대응 기한조치
Critical9.0~10.0즉시 (24시간 내)즉시 패치 또는 서비스 중단 검토
High7.0~8.91주일 내우선 패치 계획 수립 및 완화 조치
Medium4.0~6.91개월 내다음 릴리즈에 패치 포함
Low0.1~3.9다음 릴리즈백로그 등록, 누적 패치

이 기준은 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 파일이 존재하는지 먼저 확인합니다.

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

단계별 실습:

1단계 — SBOM 파일 존재 확인

ls output/sbom/*.cdx.json

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

2단계 — vulnerability-analyst agent 실행

실행 전 확인

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

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] 컴포넌트 12개 발견
[INFO] OSV API 조회 중...
[WARN] CVE-2021-44228 탐지: log4j-core 2.14.1 (CVSS 10.0, Critical)
[INFO] 리포트 생성 완료

4단계 — cve-report.md 확인

cat output/vulnerability/cve-report.md

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

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

5단계 — remediation-plan.md 확인

cat output/vulnerability/remediation-plan.md

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

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

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

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

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

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

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

# 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 주요 섹션 예시:

## 탐지된 취약점 요약

| 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)한 뒤, 새 터미널에서 아래 명령을 실행하세요.

cd agents/06-training-manager
claude

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

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

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

완료 후 output/ 상태:

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