악용 증거로 정하는 취약점 우선순위

한 줄로 말하면

KEV(Known Exploited Vulnerabilities)는 “취약점 점수가 높은 순서”가 아니라 실제로 악용되고 있다는 증거가 있는 취약점을 먼저 고치기 위한 우선순위 신호야. 다만 목록에 올랐다는 사실만으로 모든 자산의 대응 순서가 완성되지는 않아. 인터넷에 노출됐는지, 공격 뒤 자산을 얼마나 크게 장악할 수 있는지, 이미 침해가 있었는지를 함께 봐야 해.

비유로 이해하기

건물 관리자가 수리 목록을 들고 있다고 해보자. 금이 간 벽이 많다고 해서 가장 눈에 띄는 금부터 고치는 건 아니야. 실제로 누군가 그 틈으로 들어왔고, 바깥에서 바로 닿으며, 안쪽 전체로 통하는 문이라면 먼저 막아야 하지.

KEV는 이 목록에서 “실제로 침입에 쓰였다는 증거가 확인된 틈”을 표시하는 표지판에 가까워. 하지만 표지판만으로 어느 건물부터 들어갈지 정할 수는 없어. 그 틈이 있는 건물이 인터넷에 노출됐는지, 침입자가 얻을 수 있는 권한이 무엇인지, 이미 누가 들어왔는지를 자산별로 확인해야 해.

여기까지가 직관을 돕는 비유야. 실제 취약점 관리는 건물의 중요도, 자산의 노출 상태, 패치 가능 여부와 침해 대응을 별도로 기록하고 조정하는 일까지 포함해.

정확한 정의

KEV Catalog는 CISA가 활성 악용 증거를 바탕으로 취약점을 올리는 목록이야. CISA는 2026년 7월 14일 발표에서 SonicWall SMA1000의 서버 측 요청 위조와 코드 주입, Microsoft Active Directory Federation Services의 접근 통제 세분성 부족, Microsoft SharePoint Server의 중요 기능 인증 누락 등 네 취약점을 목록에 추가했다고 밝혔어.¹

여기서 CVE는 취약점을 가리키는 공통 식별자야. 이번 발표의 네 항목도 각각 CVE-2026-15409, CVE-2026-15410, CVE-2026-56155, CVE-2026-56164라는 식별자를 갖고 있어.¹ 식별자는 대상을 정확히 부르는 데 필요하지만, 그 자체가 패치 순위를 결정하지는 않아.

우선순위는 다음처럼 층을 나눠서 읽을 수 있어.

flowchart TD
    A[취약점 발견] --> B{활성 악용 증거가 있는가}
    B -->|예| C[KEV 목록과 대조]
    B -->|아니오| D[다른 위험 신호와 함께 평가]
    C --> E{공개 노출 자산인가}
    E -->|예| F{악용 뒤 전체 장악에 가까운가}
    E -->|아니오| G[자산 맥락과 완화 상태 확인]
    F -->|예| H[우선 수정·침해 확인]
    F -->|아니오| G

왜 중요한가

취약점 관리에서 경고의 개수는 곧 대응 순서가 아니야. CISA가 소개한 BOD 26-04는 미국 연방 민간 행정부 기관을 대상으로, KEV에 올라온 취약점 중에서도 공개된 자산에 있고 악용 뒤 자산을 완전히 통제할 수 있는 고위험 항목을 우선 처리하도록 요구해. 위험이 낮은 취약점은 뒤로 미룰 수 있다는 구조도 함께 둬.¹

이 규칙은 두 가지를 분리해 보여줘. 첫째, 실제 악용 증거는 “지금 공격에 쓰이는가”를 알려주는 시간 신호야. 둘째, 인터넷 노출과 권한 범위는 “우리 환경에서 피해가 얼마나 커질 수 있는가”를 알려주는 자산 신호야. 둘을 합쳐야 일반적인 목록이 조직의 작업 순서가 돼.

또 하나 빠지기 쉬운 단계가 침해 확인이야. BOD 26-04는 패치 전에 위협 행위자가 시스템을 침해했는지 확인해야 할 때의 기본 기대치도 둔다고 CISA는 설명해.¹ 패치를 설치하는 것과 이미 들어온 공격자를 찾는 것은 같은 작업이 아니야. 전자는 약한 지점을 줄이고, 후자는 과거의 흔적과 남은 접근을 확인하는 일이야.

실제 예시

이번 CISA 발표는 KEV가 단순한 CVE 목록과 어떻게 다른지 보여줘. CISA는 2026년 7월 14일 활성 악용 증거를 근거로 네 취약점을 KEV Catalog에 추가했어. 대상은 SonicWall SMA1000의 서버 측 요청 위조·코드 주입, Microsoft Active Directory Federation Services의 접근 통제 세분성 부족, Microsoft SharePoint Server의 중요 기능 인증 누락이야.¹

CISA가 함께 소개한 BOD 26-04는 이 신호를 자산 맥락과 결합해 읽어. 미국 연방 민간 행정부 기관은 KEV 항목 가운데 공개된 자산에 있고, 악용 뒤 자산을 완전히 통제할 수 있는 고위험 취약점을 우선 처리해야 해. 패치 전에 위협 행위자가 시스템을 침해했는지 확인해야 할 때의 기본 기대치도 포함돼.¹ 여기서 확인되는 구조는 “CVE가 있으니 모두 같은 순서로 처리한다”가 아니라, 활성 악용 증거에 자산 노출과 피해 범위를 겹쳐 대응 우선순위를 좁히는 것이야.

BOD 26-04의 의무는 FCEB 기관에만 적용돼. CISA는 그와 별개로 모든 조직에 위험 기반 취약점 관리와 KEV 취약점의 우선 처리를 권고해.¹ 따라서 다른 조직이 가져갈 수 있는 것은 해당 기관의 의무를 그대로 복사하는 일이 아니라, 악용 증거와 자산 맥락을 함께 기록하는 판단 틀이야.

헷갈리지 말아야 할 점

• KEV 등재는 모든 자산의 즉시 동일 대응을 뜻하지 않아. 자산이 실제로 영향을 받는지와 공개 노출 여부를 확인해야 해.
• CVE 식별자와 악용 증거는 다른 정보야. CVE는 대상을 식별하고, KEV 등재는 악용 증거를 우선순위 신호로 추가해.
• 패치는 침해 대응의 전부가 아니야. 이미 침해됐는지 확인하는 일은 별도로 남을 수 있어.
• BOD 26-04의 의무와 CISA의 일반 권고를 섞으면 안 돼. 전자는 FCEB 기관에 적용되고, 후자는 모든 조직을 향한 권고야.¹
• KEV는 취약점 관리 전체의 대체물이 아니야. 목록 밖의 취약점도 자산의 노출과 권한, 실제 사용 방식에 따라 위험할 수 있어.

관련 문서

• 취약점 경고에서 점수와 실제 공격 증거를 구분하는 방법은 보안 경고에는 증거가 필요하다에서 이어서 볼 수 있어.
• 외부 연구자의 신고를 수정 절차로 연결하는 구조는 취약점 신고 창구를 문서로 만든 CISA·NSA의 국제 지침에서 다뤄.
• 의존성 취약점과 구성요소 목록을 함께 보는 공급망 관점은 AI 코딩과 소프트웨어 공급망 보안과 연결돼.

남은 질문들

• KEV 등재와 자산 노출·권한·침해 흔적을 하나의 우선순위 표로 묶을 때 어떤 필드를 고정해야 할까?
• 패치가 불가능한 공개 자산에서 완화 조치와 침해 확인의 순서를 어떻게 정할까?
• KEV 목록 밖의 취약점이 우리 환경에서는 더 급한지 어떤 증거로 비교할 수 있을까?

각주

1. CISA, 「CISA Adds Four Known Exploited Vulnerabilities to Catalog」(2026-07-14) 공식 경보. ↩︎ ↩︎² ↩︎³ ↩︎⁴ ↩︎⁵ ↩︎⁶ ↩︎⁷ ↩︎⁸