취약점 관리

• 1: 취약점 관리 프로세스
• 2: 지속적 모니터링
• 3: 취약점 대응

graph TD
    A["SBOM 수집"] --> B["관리 포털 업로드"]
    B --> C{"취약점 분석"}
    C -->|취약점 발견| D["티켓 생성 (Jira)"]
    D --> E["개발팀 할당"]
    E --> F["패치/완화 조치"]
    F --> G["재검증 및 완료"]
    C -->|정상| H["모니터링 유지"]

1 - 취약점 관리 프로세스

1. 식별 (Identification)

가장 먼저 해야 할 일은 ‘우리가 무엇을 쓰고 있는가’와 ‘그것이 위험한가’를 파악하는 것입니다.

• SBOM 활용: 모든 프로젝트의 구성요소를 식별합니다.
• 취약점 DB 매핑: NVD(National Vulnerability Database), GitHub Advisory 등 공신력 있는 데이터베이스와 SBOM의 컴포넌트를 매핑하여 CVE(Common Vulnerabilities and Exposures)를 찾아냅니다.

CVE 데이터베이스

알려진 취약점은 CVE(Common Vulnerabilities and Exposures) 번호로 식별됩니다.

예시: Log4Shell

• CVE-2021-44228
• Apache Log4j 2.0-beta9 ~ 2.14.1
• CVSS 점수: 10.0 (Critical)

NVD 연동

SBOM 관리 포털은 NVD(National Vulnerability Database)와 연동하여 자동으로 취약점을 탐지합니다.

2. 평가 (Assessment)

모든 취약점이 즉시 고쳐야 할 만큼 위험한 것은 아닙니다. 실제 영향도를 평가하여 우선순위를 정해야 합니다.

• CVSS 점수: 기본 점수(Base Score)를 참고하되, 맹신하지 않습니다.
• EPSS (Exploit Prediction Scoring System): 해당 취약점이 실제로 공격될 확률을 고려합니다.
• 도달 가능성 (Reachability): 취약한 라이브러리가 코드 내에서 실제로 호출되고 있는지 분석합니다. 호출되지 않는다면 우선순위를 낮출 수 있습니다.

CVSS (Common Vulnerability Scoring System)

추가 고려사항

CVSS 점수 외에 다음을 고려합니다.

• 악용 가능성 (Exploit Available)
• 영향 범위 (Public-facing vs Internal)
• 완화 조치 가능 여부

3. 조치 (Remediation)

평가 결과 위험하다고 판단된 취약점은 다음 중 하나의 방법으로 조치해야 합니다.

1. 업데이트 (Update): 취약점이 해결된 안전한 버전으로 라이브러리를 업그레이드합니다. (가장 권장)

<!-- Before -->
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.14.1</version>  <!-- Vulnerable -->
</dependency>

<!-- After -->
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.17.1</version>  <!-- Patched -->
</dependency>

2. 완화 (Mitigation): 패치가 불가능한 경우, 설정 변경이나 WAF(웹방화벽) 규칙 추가 등으로 공격 경로를 차단합니다.

예시: Log4Shell 완화

# JVM 옵션으로 JNDI lookup 비활성화
-Dlog4j2.formatMsgNoLookups=true

3. 수용 (Acceptance): 비즈니스 영향도가 낮거나 도달 불가능한 경우, 위험을 수용하고 모니터링합니다. (단, 승인 절차 필요)

4. 검증 (Verification)

조치가 완료된 후에는 반드시 재검증을 수행해야 합니다.

• 재빌드 및 스캔: 패치 후 다시 빌드하여 SBOM을 생성하고 스캔했을 때 취약점이 사라졌는지 확인합니다.

2 - 지속적 모니터링

왜 지속적 모니터링인가?

어제 안전했던 소프트웨어가 오늘은 위험할 수 있습니다. (Zero-day vulnerability) 소프트웨어 코드는 변하지 않았더라도, 그 코드가 사용하는 라이브러리에서 새로운 취약점이 발견될 수 있기 때문입니다. 따라서 빌드 시점에만 검사하는 것으로는 불충분합니다.

자동화된 모니터링 체계

SK텔레콤은 SBOM 관리 포털을 통해 중앙 집중화된 모니터링 환경을 제공합니다.

1. 일일 동기화 (Daily Sync)

SBOM 관리 포털은 NVD, OSS Index 등 글로벌 취약점 데이터베이스와 매일 동기화됩니다.

2. 실시간 영향도 분석

새로운 CVE가 데이터베이스에 등록되는 즉시, 저장된 모든 프로젝트의 SBOM과 대조 분석을 수행합니다. 우리 프로젝트가 해당 취약점의 영향을 받는지 1시간 이내에 파악할 수 있습니다.

3. 알림 (Alerting)

위험도(Critical, High)가 높은 새로운 취약점이 탐지되면, 담당자에게 즉시 알림이 발송됩니다.

• Slack/Teams 연동: 팀 채널로 실시간 알림 전송
• 이메일: 보안 담당자 및 프로젝트 PL에게 리포트 발송
• Jira 티켓 생성: 자동으로 이슈를 생성하여 조치 프로세스 시작

모니터링 대상

• 운영 중인 서비스 (Production): 현재 고객에게 서비스되고 있는 버전
• 개발 중인 프로젝트 (Development): 릴리스 예정인 차기 버전
• 레거시 시스템: 더 이상 개발되지 않지만 운영 중인 시스템 (관리가 소홀하기 쉬움)

자동화 워크플로우

graph TD
    A[신규 CVE 발표] --> B[SBOM 관리 포털<br/>자동 수집]
    B --> C{영향 받는<br/>프로젝트?}
    C -->|Yes| D[Slack 알림]
    D --> E[담당자 확인]
    E --> F[Jira 티켓 생성]
    F --> G[패치 작업]
    G --> H[검증]

3 - 취약점 대응

긴급 대응 프로세스

초고위험(Critical) 취약점이 공개되었을 때, 신속한 대응이 기업의 생존을 결정합니다.

graph TD
    A["취약점 공개 (Zero-day)"] --> B["영향도 파악 (SBOM 검색)"]
    B --> C{영향 받는 시스템 식별}
    C -->|식별됨| D[비상 대응팀 소집]
    D --> E["완화 조치 (긴급 패치/WAF)"]
    E --> F["근본 조치 (라이브러리 업데이트)"]
    F --> G[재검증 및 모니터링]
    C -->|식별 안 됨| H[지속 모니터링]

시나리오: Log4j 사태 재연

가상의 상황을 통해 대응 절차를 익혀봅시다.

상황 발생 (D-Day 09:00)

• 뉴스: “Apache Log4j 2.x 버전에서 치명적인 원격 코드 실행 취약점(Log4Shell) 발견”
• 보안팀: 즉시 SBOM 관리 포털 검색 시작

1. 영향도 파악 (09:10)

SBOM 관리 포털의 Global Search 기능을 활용하여 전사적으로 log4j-core 컴포넌트를 검색합니다.

• 검색어: pkg:maven/org.apache.logging.log4j/log4j-core
• 결과: 총 150개 프로젝트 중 12개 프로젝트에서 취약한 버전(2.0-beta9 ~ 2.14.1) 사용 중임이 식별됨.

2. 비상 전파 (09:30)

식별된 12개 프로젝트의 담당자에게 긴급 알림(Slack/SMS) 발송.

“귀하의 프로젝트(OOO시스템)가 Log4j 취약점(CVE-2021-44228)에 노출되었습니다. 즉시 조치 바랍니다.”

3. 긴급 완화 조치 (10:00)

라이브러리 업데이트에는 시간이 걸리므로, 즉시 적용 가능한 완화 조치를 먼저 수행합니다.

• 조치: JVM 시작 옵션에 -Dlog4j2.formatMsgNoLookups=true 추가 후 재기동.

4. 근본 조치 (D+1일)

개발팀은 안전한 버전(2.17.1 이상)으로 의존성을 업데이트하고 테스트를 거쳐 정식 배포를 진행합니다.

5. 검증 및 종료 (D+3일)

모든 대상 시스템의 SBOM이 갱신되었으며, SBOM 관리 포털에서 해당 취약점이 더 이상 탐지되지 않음을 확인하고 비상 상황을 종료합니다.