취약점 관리 프로그램(VMP): 자산·스캔·슬러징 운영

취약점 관리가 왜 어려운가

국내 주요 보안 사고의 80% 이상이 알려진 취약점(패치가 이미 존재하는)을 통해 발생합니다. 수천 개의 자산에서 매월 수백 개의 CVE가 쏟아지는 상황에서 무엇을 언제 패치할지 판단하는 것이 핵심 과제입니다.

VMP 4단계 프레임워크

1단계: 자산 인벤토리 구축

# Nmap으로 내부 네트워크 자산 스캔
nmap -sV -O --osscan-guess \
  -oX assets.xml \
  192.168.0.0/24

2단계: 취약점 스캔

스캔 도구:

• 무료: OpenVAS/Greenbone, Nuclei
• 상용: Tenable Nessus, Qualys VMDR, Rapid7 InsightVM

# Nuclei로 웹 앱 스캔
nuclei -u https://app.company.com \
  -t cves/ \
  -severity critical,high \
  -o results.txt

3단계: 위험 우선순위 결정

CVSS만으로는 부족합니다. CVSS는 취약점 자체의 심각도이지, 우리 환경의 위험도가 아닙니다.

def calculate_priority(cve):
    score = cve.cvss_score * 10

    # 실제 공격 코드 존재 여부 (CISA KEV 목록)
    if cve.in_cisa_kev:
        score += 50

    # 인터넷 노출 여부
    if cve.asset.internet_facing:
        score += 30

    return score  # 70 이상 시 긴급 패치

4단계: 패치 관리 SLA

반드시 테스트 환경 → 스테이징 → 프로덕션 순서로 적용하세요.

취약점 관리 KPI

• MTTD: 취약점 공개 → 내부 탐지까지 평균 시간
• MTTP: 탐지 → 패치 완료까지 평균 시간
• 패치율: 기간 내 패치 완료 비율

취약점 관리는 보안팀 혼자 할 수 없습니다. 개발팀, 인프라팀, 경영진과 함께 프로세스를 만들어야 지속 가능합니다.

CVSS를 넘어: EPSS와 KEV

우선순위 결정에서 CVSS 점수만 보면 정작 악용되는 취약점을 놓칩니다. 두 지표를 함께 보세요.

• CISA KEV(Known Exploited Vulnerabilities): 실제 공격에 사용된 것이 확인된 목록 → 최우선.
• EPSS(Exploit Prediction Scoring System): 향후 30일 내 악용될 확률(0~1). CVSS 9.8이라도 EPSS가 낮으면 후순위가 될 수 있습니다.

# KEV + EPSS 결합 우선순위 (보강판)
def priority(cve):
    if cve.in_cisa_kev:          # 이미 악용 중
        return "긴급"
    if cve.epss >= 0.5 and cve.asset.internet_facing:
        return "높음"
    if cve.cvss >= 9.0:
        return "중간"
    return "정상 주기 패치"

당장 패치할 수 없을 때: 보상 통제

운영 중단 위험·호환성 문제로 즉시 패치가 불가능한 자산도 많습니다. 이때는 **가상 패치(Virtual Patching)**로 시간을 법니다.

• WAF/IPS 시그니처로 해당 취약점 악용 트래픽 차단.
• 취약 서비스의 외부 노출 차단(접근 통제, 세그멘테이션).
• 보상 통제를 적용했더라도 근본 패치 일정은 반드시 티켓으로 추적.

컨테이너·클라우드 취약점 관리

# 이미지 빌드 단계에서 차단 (CI에 통합)
trivy image --exit-code 1 --severity CRITICAL,HIGH my-app:latest

# IaC 설정 오류 점검
trivy config ./terraform

이미지는 한 번 빌드하면 끝이 아니라, 레지스트리에 있는 기존 이미지도 신규 CVE 발표 시 재스캔해야 합니다.

국내 규제 연계

• ISMS-P: 정기 취약점 점검과 조치 결과 관리가 인증 통제 항목입니다.
• 주요정보통신기반시설: 연 1회 이상 취약점 분석·평가가 법적 의무(정보통신기반보호법).
• 점검만 하고 조치를 추적하지 않으면 인증 심사와 사고 대응 모두에서 문제가 됩니다.

스캐너 결과와 실제 자산이 맞지 않을 때

VMP 운영에서 자주 나오는 문제는 스캔 결과 건수가 아니라 스캔되지 않는 자산입니다. 보고서에 없는 자산은 위험이 없는 것이 아니라 보이지 않는 것입니다.

원인

• 오토스케일링·컨테이너처럼 수명이 짧은 자산이 스캔 주기 사이에 생겼다 사라짐
• 인증 스캔 계정이 일부 서버에서 만료돼, 네트워크 스캔 수준의 얕은 결과만 나옴
• 클라우드 계정이 새로 생겼지만 스캐너 연동 대상에 추가되지 않음

대조 절차

1. 자산의 기준 목록을 CMDB가 아니라 실제 소스(클라우드 API, EDR 에이전트 목록, DHCP·DNS 기록)에서 뽑습니다.
2. 스캐너가 최근 N일 안에 스캔한 자산 목록과 비교합니다.

# 예: 실제 실행 중인 EC2 목록과 스캐너 내보내기 비교
aws ec2 describe-instances --filters Name=instance-state-name,Values=running \
  --query 'Reservations[].Instances[].PrivateIpAddress' --output text | tr '\t' '\n' | sort > live.txt
cut -d, -f1 scanner_last30d.csv | sort > scanned.txt
comm -23 live.txt scanned.txt     # 실행 중인데 스캔 기록이 없는 자산

3. 인증 스캔 성공 여부를 자산별로 확인해, 인증 실패 자산은 별도 목록으로 관리합니다.

해결과 재발 방지

• 컨테이너는 실행 시점 스캔 대신 이미지 레지스트리·CI 단계 스캔으로 보완하고, 실행 중인 이미지 목록과 연결합니다.
• 스캔 커버리지(실제 자산 대비 스캔된 비율)를 KPI에 추가해, 취약점 건수와 함께 보고합니다.

자주 묻는 질문 (FAQ)

Q. 스캐너가 너무 많은 취약점을 쏟아냅니다. 어디부터? KEV 목록 + 인터넷 노출 자산의 교집합부터 보세요. "악용 가능 × 노출됨"이 실제 위험입니다.

Q. 패치하면 서비스가 깨질까 두렵습니다. 그래서 테스트→스테이징→프로덕션 단계와 롤백 계획이 필요합니다. 패치 회피가 누적되면 그 자체가 가장 큰 위험이 됩니다.

참고 자료

• CISA KEV — Known Exploited Vulnerabilities Catalog
• FIRST EPSS — Exploit Prediction Scoring System

VMP 운영 루프

1. 자산 인벤토리 (CMDB/클라우드 태그) 없이 스캔은 의미 없음
2. 스캔: 인프라·컨테이너·의존성(SCA)·웹
3. 티켓: 소유자·기한·재현 정보
4. 검증: 패치 후 재스캔
5. 예외: 만료일 있는 waiver만 허용

참고 자료

• OWASP Vulnerability Management
• NIST SP 800-40

자주 묻는 질문 (FAQ)

Q. Critical를 전부 즉시 막을까요?
인터넷 노출·원격코드실행은 즉시. 내부 전용·완화 통제가 있으면 기한형 예외가 현실적입니다.

Q. 스캐너만 바꾸면 해결되나요?
아니요. 소유자 지정·SLA·경영 보고가 없으면 티켓만 쌓입니다.

검증 환경·편집자 주

• 검증 시점: 2026-09 (문서·CLI 플래그는 벤더 업데이트에 따라 달라질 수 있음)
• 명령어는 읽기 전용 조회 위주이며, 프로덕션 적용 전 스테이징에서 plan/dry-run을 권장합니다.
• 본문은 공식 문서 링크와 운영에서 반복되는 실패 패턴을 기준으로 편집 검토했습니다.

실무 적용 순서 (요약)

1. 현재 상태 측정(메트릭·비용·오류율) 없이 도구부터 바꾸지 말 것
2. 가장 작은 범위에서 변경 → 롤백 조건 명시
3. 체크리스트를 런북/티켓 템플릿에 옮겨 팀 공유
4. 한 달 뒤 지표로 효과 재평가 후 확대