CISA KEV로 취약점 패치 순서를 다시 짜는 방법

CISA Known Exploited Vulnerabilities Catalog는 공개된 CVE 중 실제 악용 근거가 확인된 항목을 모은다. 모든 KEV가 우리 조직에 존재하는 것도 아니고, KEV 밖의 취약점이 안전한 것도 아니다. 하지만 수천 개의 스캔 결과 중 공격자가 이미 사용하는 경로를 빠르게 분리하는 강한 입력이다.

2026년 6월 10일 CISA는 기존 BOD 22-01과 BOD 19-02를 대체하는 BOD 26-04를 발표했다. 이 지침은 미국 연방 민간 행정부 기관을 대상으로 하며, 다른 조직은 최신 CISA 원문과 자신의 규제·계약·위험 수용 체계를 기준으로 SLA를 정해야 한다. 오래된 “BOD 22-01 기한”을 복사해 현재 정책으로 표시하지 않는다.

KEV 데이터 파이프라인부터 신뢰할 수 있어야 한다

공식 카탈로그는 웹 화면뿐 아니라 JSON·CSV 등 기계 판독 형식으로 제공된다. 운영 파이프라인은 최소한 다음을 저장한다.

• CVE ID와 공급업체·제품
• 취약점 이름과 필요한 조치
• 카탈로그 추가 날짜
• CISA가 제공하는 조치 기한 필드
• 랜섬웨어 캠페인 관련 표시 등 제공 필드
• 원본 데이터 조회 시각과 스키마 버전
• 조직 자산 매칭 상태와 소유자

매일 또는 조직의 위험 허용 범위에 맞춰 동기화하고, 마지막 성공 시각, 레코드 수 급변, 파싱 오류, 중복 CVE를 모니터링한다. 수집이 멈추면 “신규 KEV 0건”으로 보일 수 있으므로 무변화와 장애를 구분해야 한다.

15분 안에 할 첫 분류

새 KEV가 들어오면 보안팀이 제품명을 전체 메일로 보내는 것보다 다음 질문을 자동·수동으로 나눈다.

1. 제품과 취약 버전이 자산·이미지·어플라이언스에 실제 존재하는가.
2. 인터넷, 파트너, 사용자 입력 또는 침해된 내부 호스트에서 도달 가능한가.
3. 취약 기능이 활성화돼 있고 공격 전제가 충족되는가.
4. 해당 자산이 보유한 데이터와 권한, 업무 중단 영향은 무엇인가.
5. 공급업체 패치·완화·서비스 종료 안내가 있는가.
6. 최근 로그에 악용 시도 또는 침해 흔적이 있는가.

자산 목록에 없다고 종료하지 않는다. 인터넷 스캔, 클라우드 자산, 구매 목록, DNS·인증 로그, 컨테이너 SBOM, 네트워크 장비 목록을 교차 확인한다. 오래된 어플라이언스와 자회사 환경이 중앙 스캐너 밖에 있을 수 있다.

패치 큐를 네 가지로 나눈다

큐	조건	기본 행동
A: 긴급	KEV 존재 + 외부 도달 또는 침해 징후	격리·조사·패치·자격증명 조치 병행
B: 높음	KEV 존재 + 내부 도달·높은 권한/데이터	빠른 변경 창, 이동 경로 제한
C: 확인	자산 매칭 불확실 또는 기능 비활성 주장	증거 확보, 공급업체·구성 검증
D: 비해당	제품·버전·기능이 명확히 없음	근거와 기준 날짜를 기록 후 재평가

비해당 판단에는 패키지 버전, 공급업체 확인, 스캐너 결과, 기능 설정처럼 재현 가능한 증거가 필요하다. 제품명이 다르거나 OEM으로 포함돼 자동 매칭이 실패할 수 있다.

패치와 침해 조사를 분리하지 않는다

실제 악용이 알려진 취약점은 패치 전에 이미 공격됐을 수 있다. 패치가 성공해도 웹셸, 새 관리자, 예약 작업, API 토큰, 악성 OAuth 앱이 남으면 사고는 끝나지 않는다.

조사 범위에는 다음이 포함될 수 있다.

• 취약 서비스의 접속·오류·프로세스·파일 변경 로그
• 새 계정·권한·SSH 키·토큰
• 비정상 외부 연결과 데이터 전송
• EDR·WAF·IDS 탐지 및 보안 장비 공백
• 취약 자산이 접근한 다른 시스템과 자격증명
• 로그 보존 시작점과 시간 동기화

구체적인 IOC와 조사 단계는 해당 CISA 경고, 공급업체 권고, 신뢰할 수 있는 사고 대응 자료를 최신 날짜로 확인한다. 로그가 없으면 그 사실 자체를 위험으로 기록하고 격리·자격증명 회전 범위를 보수적으로 정한다.

패치가 없거나 바로 적용할 수 없을 때

“다음 정기 점검까지 기다린다”는 선택 외에도 기능 비활성화, 외부 접근 차단, 관리 인터페이스 격리, WAF·IPS 규칙, 서비스 계정 권한 축소, 세션·키 회전, 모니터링 강화가 있다. 단, 공급업체가 제시한 완화가 실제 공격 경로를 막는지 검증해야 한다.

완화 티켓에는 다음을 남긴다.

• 막는 공격 전제와 남는 위험
• 적용 자산과 설정 증거
• 정상 서비스 영향
• 탐지 로그와 확인 담당자
• 패치 또는 교체 목표일
• 자동 만료 또는 재검토일

지원 종료 제품에서 패치가 불가능하면 단기 완화와 함께 교체·폐기 결정을 사업 책임자에게 올린다.

안전한 배포와 검증

KEV라고 해서 테스트 없이 전사 배포하면 핵심 서비스가 멈춰 복구 과정에서 통제를 꺼 버릴 수 있다. 긴급 변경에도 최소한 다음 순서를 지킨다.

1. 공급업체 원문과 파일 서명·해시·대상 버전을 확인한다.
2. 백업과 설정 내보내기, 복구 계정, 롤백 가능 여부를 확인한다.
3. 비운영 또는 카나리에서 기능·성능·로그를 시험한다.
4. 외부 노출 자산부터 단계적으로 배포한다.
5. 서비스 오류와 함께 악용 탐지 신호를 관찰한다.
6. 재스캔, 버전 조회, 모든 노드·인스턴스 적용을 확인한다.
7. 오래된 이미지·스냅샷·자동 확장 템플릿을 제거한다.

펌웨어와 어플라이언스는 다운그레이드가 불가능하거나 데이터 마이그레이션이 비가역적일 수 있다. “롤백” 대신 우회 장비, 트래픽 전환, 예비 노드 교체 같은 복구 계획을 준비한다.

SLA는 조직 맥락으로 승인한다

CISA 연방기관 지침의 기한을 참고할 수는 있지만, 민간 조직의 계약·법률 의무로 단정하지 않는다. 자체 SLA는 다음 요소를 조합한다.

• KEV 포함 여부와 추가 날짜
• 인터넷·파트너 노출
• 인증 전 공격 가능성
• 데이터와 권한의 영향
• 탐지 가시성
• 패치·완화 가용성
• 서비스 안전·가용성 영향

SLA를 넘기면 자동으로 위험 수용이 되지 않게 한다. 소유자, 경영 승인, 임시 완화, 새 날짜를 요구하고 만료된 예외를 상향 보고한다.

운영 지표

• 신규 KEV 수집부터 자산 매칭까지 걸린 시간
• 외부 노출 KEV 자산 수와 평균 노출 기간
• 매칭 불확실·소유자 없음 상태의 연령
• 패치 후 재스캔 및 전체 노드 적용률
• KEV별 침해 흔적 조사 완료율
• 만료된 완화·위험 수용 건수
• 데이터 피드 마지막 성공 시각

단순 “KEV 100% 완료”는 비해당 처리 품질과 로그 조사 누락을 숨길 수 있다. 증거 없는 비해당과 패치만 완료된 항목을 별도로 검수한다.

내부 연결

소프트웨어 구성요소를 자산에 연결하는 작업은 SBOM 거버넌스 실무 가이드를 참고한다. 컨테이너 패치 후에도 과도한 실행 권한이 남지 않게 하려면 쿠버네티스 Pod Security 기준선을 함께 본다.

운영 체크리스트

• KEV 공식 JSON·CSV를 자동 수집하고 갱신 실패를 경보한다.
• CVE를 서버·이미지·어플라이언스·소유자와 매칭한다.
• 외부 노출, 권한, 데이터, 업무 영향을 기준으로 큐를 나눈다.
• KEV 항목은 패치와 침해 흔적 조사를 함께 진행한다.
• 비해당 판단에 제품·버전·기능 증거와 기준 날짜가 있다.
• 패치 불가 완화에는 남는 위험과 만료일·교체 계획이 있다.
• 배포 뒤 재스캔과 모든 노드·템플릿 적용을 확인한다.
• 연방기관 지침과 조직의 법률·계약 SLA를 구분한다.

참고 기준

• CISA Known Exploited Vulnerabilities Catalog
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk
• CISA BOD 26-04 Implementation Guidance
• NIST Cybersecurity Framework 2.0

KEV의 가치는 목록을 구독하는 데 있지 않다. 새 항목을 빠르게 우리 자산에 연결하고, 이미 침해됐을 가능성까지 확인하며, 패치가 어렵다면 시간 제한이 있는 대안을 실행하는 운영 흐름에 있다.