CVSS EPSS และ KEV ต่างกันอย่างไร ช่องโหว่ไหนควรแพตช์ก่อน

ทุกเดือนรายงานจาก scanner จะมาถึง และทุกเดือนหน้าตาก็เหมือนเดิม คือรายการ finding ยาวเหยียด และมีจำนวนไม่น้อยที่ติดป้าย critical ถ้าทุกอย่าง critical ก็เท่ากับไม่มีอะไร critical สุดท้ายทีมก็ไล่ทำจากบนลงล่างตามคะแนน หรือไม่ก็นิ่งไปเลยครับ

ทางออกไม่ใช่ spreadsheet ที่ดีกว่าเดิม แต่คือการรู้ว่าตัวเลขแต่ละตัววัดอะไรจริง ๆ CVSS, EPSS และ KEV catalog ของ CISA ตอบคำถามสามข้อที่ต่างกัน คือ ถ้าโดนจะแย่แค่ไหน? มีโอกาสถูกโจมตีเร็ว ๆ นี้แค่ไหน? และ ถูกโจมตีจริงไปแล้วหรือยัง? ถ้าเอามาปนกัน เราก็จะ patch ผิดลำดับครับ

โพสต์นี้รวบรวมความเชื่อผิด ๆ ที่ผมได้ยินบ่อย (และเคยเชื่อเองด้วย) แต่ละข้อตามด้วยสิ่งที่แหล่งข้อมูลต้นทางบอกไว้ ท้ายโพสต์เป็นลำดับ triage แบบง่ายที่ผมใช้เป็นจุดเริ่มต้นสำหรับ firewall, VPN gateway และอุปกรณ์เครือข่ายอื่น ๆ ครับ

                                                                
             ·•                              ▾ new CVEs         
                                                                
                                                                
                      •                                         
        ══════════════════════════════•══════  CVSS  severity   
          \                                /   how bad?         
           \                             /                      
             \             o            ·                       
              ═════════════════════════        EPSS  likelihood 
                \                    /         how likely soon? 
                 \                 /                            
                   \       o      /                             
                    ═════════════              KEV   exploited  
                    │     •     │              seen in the wild?
                   ┌─────────────┐                              
 · stopped =       │  PATCH NOW  │                              
   scheduled later └─────────────┘                              

ความเชื่อที่ 1: "CVSS base score 9.8 แปลว่าความเสี่ยงสูง"

ข้อเท็จจริง: base score วัดความรุนแรง (severity) ไม่ใช่ความเสี่ยง (risk)

FIRST ซึ่งเป็นเจ้าของ CVSS เขียนไว้ชัดเจน ใน CVSS v4.0 User Guide มีหัวข้อชื่อ "CVSS Base Score (CVSS-B) Measures Severity, not Risk" และบอกว่า base metrics ไม่ควรใช้เพียงอย่างเดียวในการประเมินความเสี่ยง ตัว specification อธิบายว่า base score สะท้อนความรุนแรงตามคุณลักษณะในตัวของช่องโหว่เอง คือช่องโหว่นี้ทำอะไรได้บ้าง โดยสมมติว่ามีคนโจมตีสำเร็จ ฝั่ง NVD ของ NIST ก็พูดตรง ๆ ว่า "CVSS is not a measure of risk."

ความเสี่ยงต้องมีอีกสองอย่างที่ base score ไม่มีทางรู้ คือ ผู้โจมตีใช้ช่องโหว่นี้อยู่หรือเปล่า และระบบที่โดนสำคัญกับ เรา แค่ไหน CVSS v4.0 ซึ่งเผยแพร่ครั้งแรกเมื่อ 1 พฤศจิกายน 2566 ทำให้ช่องว่างนี้เห็นชัดขึ้นด้วย metric group สี่กลุ่ม (specification, FIRST v4.0 overview):

User Guide บอกว่าการใส่ Threat และ Environmental metrics เป็นความรับผิดชอบของ CVSS consumer และผู้ให้คะแนนมักเผยแพร่แค่ base score เท่านั้น v4.0 ยังขอให้ระบุด้วยว่าตัวเลขนั้นคิดจาก group ไหนบ้าง คือ CVSS-B, CVSS-BT, CVSS-BE หรือ CVSS-BTE โดย spec บอกว่าควรใช้ชื่อเรียกแบบนี้ทุกที่ที่แสดงค่า CVSS เป็นตัวเลข ถ้า dashboard โชว์ "9.8" เฉย ๆ เกือบแน่นอนว่าเป็น CVSS-B คือตัวเลขความรุนแรงที่ไม่รู้อะไรเกี่ยวกับเครือข่ายของเราเลยครับ

รายละเอียดที่ควรรู้: ถ้าปล่อย Exploit Maturity เป็น "Not Defined" ไว้ spec ของ v4.0 จะถือว่าเท่ากับ Attacked คือสมมติกรณีเลวร้ายที่สุด แปลว่า base score มองโลกในแง่ร้ายเรื่อง threat อยู่แล้ว การใส่ข้อมูล threat จริงเข้าไปจึงทำได้แค่ให้คะแนนเท่าเดิมหรือลดลงครับ

ความเชื่อที่ 2: "คะแนนของ NVD คือคะแนนทางการ"

ข้อเท็จจริง: CVE หนึ่งตัวอาจมีหลายคะแนน และบทบาทของ NVD ก็เปลี่ยนไปแล้ว

NVD เผยแพร่เฉพาะ base metrics โดยระบุว่ายังไม่ได้ประเมิน Temporal หรือ Threat metrics, Environmental metrics หรือ Supplemental metrics ในหน้ารายละเอียด CVE นั้น NVD แสดงผลการ enrichment ของตัวเอง และถ้า CVE Numbering Authority (CNA ซึ่งมักเป็น vendor) ให้คะแนนมาด้วย ก็จะแสดงคะแนนของ CNA ด้วย ถ้าสองคะแนนตรงกัน จะแสดงเฉพาะของ CNA

ทำไมถึงต่างกันได้? ส่วนหนึ่งเป็นเรื่องข้อมูล เมื่อ vendor เปิดเผยรายละเอียดน้อย นักวิเคราะห์ของ NVD จะกำหนดค่า metric แบบ worst case และ CVE ที่ไม่มีรายละเอียดเลยจะถูกประเมินเป็น 10.0 vendor รู้จักโค้ดของตัวเองและอาจให้คะแนนต่ำกว่า ส่วน NVD ซึ่งทำงานจากคำอธิบายสาธารณะอาจให้คะแนนสูงกว่าครับ

การเปลี่ยนแปลงที่ใหญ่กว่านั้นเกิดในปี 2569 ตั้งแต่ 15 เมษายน 2569 NIST ทำ enrichment แบบ risk-based คือ CVE ที่อยู่ใน KEV catalog (ตั้งเป้าภายในหนึ่งวันทำการ) CVE ของซอฟต์แวร์ที่หน่วยงานรัฐบาลกลางสหรัฐฯ ใช้ และ "critical software" ตาม Executive Order 14028 ส่วนที่เหลือจะติดป้าย "Lowest Priority - not scheduled for immediate enrichment" NIST ยังบอกด้วยว่าจะไม่เพิ่มคะแนนความรุนแรงของตัวเองเป็นประจำอีกต่อไปถ้า CNA ให้คะแนนไว้แล้ว เหตุผลคือปริมาณงาน ประกาศเดียวกันระบุว่าจำนวน CVE ที่ส่งเข้ามาเพิ่มขึ้น 263% ระหว่างปี 2563 ถึง 2568 และตัวเลขก็ผิดได้ ในเดือนเมษายน 2569 NVD รายงานว่ามีราว 4,500 record ที่คะแนน CVSS v4.0 เป็นตัวเลขไม่ถูกต้อง จากข้อผิดพลาดในวิธีคำนวณและจัดเก็บตัวเลขนั้น

บทเรียนในทางปฏิบัติคือ อ่าน vector string ไม่ใช่ดูแค่ตัวเลข และเช็ก advisory ของ vendor ด้วยครับ สำหรับ firewall แล้ว advisory มักบอกสิ่งที่คะแนนบอกไม่ได้ คือ bug นั้นต้องเปิด feature ไหนไว้ถึงจะโดน

ความเชื่อที่ 3: "EPSS ก็แค่คะแนนความรุนแรงอีกแบบ"

ข้อเท็จจริง: EPSS ประเมินโอกาส (likelihood) และไม่ได้บอกอะไรเรื่องผลกระทบเลย

Exploit Prediction Scoring System ดูแลโดย special interest group ของ FIRST เป็นโมเดลที่ขับเคลื่อนด้วยข้อมูล ประเมินความน่าจะเป็นที่ CVE ที่เผยแพร่แล้วจะถูก exploit ในโลกจริงภายใน 30 วันข้างหน้า โดยเผยแพร่คะแนนระหว่าง 0 ถึง 1 ให้ทุก CVE ทุกวัน

               one CVE, two gauges, two questions               
                                                                
            ·········                       ·········           
        ····         ····               ····         ····       
     ···                 ··•         ···                 ··•    
    ··                     ••       ··                     ••   
   ··                       ••     ··                       ••  
  ··                         ••   ··                         •• 
  ·                   /////●  •   ·  ●\\\\\                   • 
  ·             ◉/////        •   ·        \\\\\◉             • 
 0                            10 0                           1  
            SEVERITY                       LIKELIHOOD           
         CVSS · how bad?               EPSS · next 30 days      
                                                                
            critical                           low              
                                                                
                    example A (illustrative)                    

EPSS FAQ เขียนไว้ชัดเจนผิดปกติว่าโมเดลนี้ ไม่ใช่ อะไร (FIRST EPSS FAQ):

• ไม่ได้วัดความเสียหาย EPSS เป็นส่วน threat likelihood ของการตัดสินใจเรื่องความเสี่ยง ไม่ใช่ทั้งหมด
• ไม่รู้จักสภาพแวดล้อมของเรา ไม่รู้ว่าอะไร exposed และไม่รู้เรื่อง compensating controls
• อย่าเอา EPSS คูณ CVSS FAQ บอกว่าผลลัพธ์จะไม่ใช่ความน่าจะเป็นที่มีความหมายอีกต่อไป
• FAQ บอกว่า CVSS กับ EPSS empirically uncorrelated ดังนั้น CVSS 9.8 คู่กับ EPSS ต่ำจึงไม่ได้ขัดแย้งกัน แต่เป็นคำตอบที่ตรงไปตรงมาสองข้อ ต่อคำถามสองข้อที่ต่างกัน

มีอีกสองเรื่องที่คนสับสนบ่อย เรื่องแรก probability เป็นค่าสัมบูรณ์ ส่วน percentile เป็นค่าเปรียบเทียบ เพราะ CVE ส่วนใหญ่ได้คะแนนต่ำมาก ความน่าจะเป็นที่ดูน้อยก็อาจอยู่ในอันดับต้น ๆ ได้ FIRST แนะนำให้แสดงทั้งสองค่าคู่กัน ในรูปแบบอย่าง "15.3% (92nd)" เรื่องที่สอง "exploitation activity" หมายถึงพาร์ตเนอร์ด้านข้อมูลตรวจพบ บันทึก และแบ่งปันหลักฐานนั้น โมเดลจึงเห็นเฉพาะสิ่งที่ sensor ของพาร์ตเนอร์ตรวจพบและรายงานเท่านั้นครับ

ความเชื่อที่ 4: "ถ้าไม่อยู่ใน KEV แปลว่าไม่มีใครโจมตี"

ข้อเท็จจริง: KEV คือรายการการโจมตีที่ยืนยันแล้วซึ่งมีเกณฑ์สูง ไม่ใช่รายการของทุกอย่างที่อันตราย

CISA จะเพิ่มช่องโหว่เข้า Known Exploited Vulnerabilities catalog ก็ต่อเมื่อครบสามเงื่อนไข คือ มี CVE ID มีหลักฐานที่เชื่อถือได้ว่าถูก exploit ในโลกจริงแล้ว และมีวิธีแก้ที่ชัดเจน เช่น อัปเดตจาก vendor คำว่า "active exploitation" หมายถึงหลักฐานว่ามีการรันโค้ดอันตรายบนระบบโดยเจ้าของไม่ได้อนุญาต การรันโค้ดอันตรายบน honeypot ถือเป็นความพยายามโจมตี (attempted exploitation) และนับด้วย แต่การ scan งานวิจัยด้านความปลอดภัย และโค้ด proof-of-concept ไม่นับ

ดังนั้น KEV เป็นหลักฐานที่หนักแน่นเมื่อ CVE อยู่ในรายการ แต่เป็นหลักฐานที่อ่อนเมื่อไม่อยู่ ช่องโหว่ใหม่เอี่ยมอาจถูก exploit ไปก่อนที่หลักฐานจะไปถึง CISA และช่องโหว่ที่ยังไม่มี CVE หรือยังไม่มีวิธีแก้ก็ยังเข้ารายการไม่ได้ ตอนที่ผมดาวน์โหลด JSON feed มาเขียนโพสต์นี้ (catalog version 2026.10.23) มี 1,756 รายการ ในจำนวนนี้ 361 รายการติดป้าย "Known" ว่าถูกใช้ใน ransomware campaign ถือเป็นรายการที่เล็กและคมเมื่อเทียบกับจำนวน CVE ที่เผยแพร่ในแต่ละปี และนั่นคือเหตุผลที่มันใช้เป็นตัวกรองชั้นแรกได้ดีครับ

ความเชื่อที่ 5: "BOD 22-01 บอกว่าสองสัปดาห์ เราก็มีเวลาสองสัปดาห์"

ข้อเท็จจริง: BOD 22-01 ถูกยกเลิกไปตั้งแต่มิถุนายน 2569 และฉบับที่มาแทนใช้ decision factors ไม่ใช่ deadline เดียว

directive ที่สร้าง KEV ขึ้นมา คือ BOD 22-01 (3 พฤศจิกายน 2564) ให้เวลาหน่วยงานรัฐบาลกลางสหรัฐฯ สองสัปดาห์ ในการแก้ช่องโหว่ที่อยู่ในรายการ หรือหกเดือนสำหรับ CVE ที่ออกก่อนปี 2564 และกำหนดเวลาตั้งต้นนี้ปรับได้ในกรณีที่มีความเสี่ยงร้ายแรงต่อหน่วยงานรัฐบาลกลาง ตัวอย่างเช่น PAN-OS CVE-2024-3400 ถูกเพิ่มเมื่อ 12 เมษายน 2567 โดยมี due date เป็น 19 เมษายน 2567 คือหนึ่งสัปดาห์ถัดมา

วันที่ 10 มิถุนายน 2569 CISA ออก BOD 26-04 "Prioritizing Security Updates Based on Risk" ซึ่งยกเลิก BOD 22-01 และ BOD 19-02 โดยยังคงเกณฑ์ของ KEV ไว้ Table 1 ของ directive กำหนด deadline การแก้ไขสำหรับหน่วยงานรัฐบาลกลางจากคำถามสี่ข้อ คือ asset นั้น publicly exposed หรือไม่ CVE อยู่ใน KEV หรือไม่ ผู้โจมตี automate การ exploit ได้หรือไม่ และการ exploit ทำให้ได้ control บางส่วนหรือทั้งหมด ตัวอย่างบางแถวจากตารางนั้น:

directive ระบุว่าตารางนี้อ้างอิงแนวคิดจาก SSVC และนับเวลาตั้งแต่ CISA เพิ่ม CVE เข้า KEV หรือตั้งแต่หน่วยงานตรวจพบ แล้วแต่อย่างไหนเกิดก่อน BOD 26-04 มีผลบังคับเฉพาะหน่วยงานพลเรือนของรัฐบาลกลางสหรัฐฯ สำหรับคนอื่น ๆ นี่คือ template ที่ใช้ได้ฟรีและคิดมาอย่างดี สังเกตว่าบางครั้งคำว่า "patch" มาพร้อมกับ "ตรวจด้วยว่าเราถูกเจาะไปแล้วหรือยัง" ด้วยครับ

ความเชื่อที่ 6: "เราต้องมีตัวเลขตัวเดียวไว้ sort"

ข้อเท็จจริง: decision tree อาจดีกว่าตัวเลข

SSVC (Stakeholder-Specific Vulnerability Categorization) สร้างโดย Software Engineering Institute ของ Carnegie Mellon University ในปี 2562 โดยร่วมมือกับ CISA แทนที่จะให้คะแนน SSVC จะไล่ผ่าน decision point ต่าง ๆ แล้วจบที่การกระทำ เวอร์ชันของ CISA จบที่ Track, Track*, Attend หรือ Act ส่วน deployer model ของ CERT/CC จบที่ Defer, Scheduled, Out-of-cycle หรือ Immediate โดยมีค่าอย่าง Exploitation (None, Public PoC, Active), Automatable (Yes/No), Technical Impact (Partial/Total) และ System Exposure

มีประเด็นละเอียดจาก SSVC guide ของ CISA ว่า decision point เรื่อง Exploitation บันทึกสถานะปัจจุบัน และไม่ได้ทำนายการ exploit ในอนาคต ซึ่งเป็นช่องว่างที่ EPSS เข้ามาเติม และตั้งแต่ 17 มิถุนายน 2569 CVE record ใน data feed และ API ของ NVD มีข้อมูล SSVC จาก CISA Authorized Data Publisher ควบคู่กับ CVSS ทำให้หา input ของ tree ได้ง่ายกว่าเดิมครับ

รวมทั้งหมดเข้าด้วยกัน: ลำดับ triage สำหรับอุปกรณ์เครือข่าย

นี่คือจุดเริ่มต้นของผมเอง ไม่ใช่มาตรฐาน ยืมโครงมาจาก BOD 26-04 และ SSVC และเหมาะกับ firewall, VPN gateway และ load balancer เพราะอุปกรณ์พวกนี้จำนวนมากอยู่บน internet ครับ

1. อยู่ใน KEV และเข้าถึงได้จาก internet (VPN portal, management interface หรือ service ใด ๆ ที่ exposed): ลงมือทันที ถ้า fix ยังไม่พร้อมให้ mitigate วันนี้ และหาร่องรอยการถูกเจาะ ไม่ใช่แค่ดูว่าขาด patch
2. ไม่อยู่ใน KEV แต่ EPSS สูง หรือ vendor บอกว่ากำลังถูก exploit และอยู่บน interface ที่ exposed: ทำ out-of-cycle change ภายในสัปดาห์นี้
3. CVSS-B ระดับ critical หรือ high, automatable, เข้าถึงได้จากเครือข่ายที่ไม่น่าไว้ใจ และ configuration ของเราโดน: change window ครั้งถัดไป
4. ที่เหลือทั้งหมด: maintenance ตามปกติ และเช็กใหม่เมื่อ KEV, EPSS หรือ advisory ของ vendor เปลี่ยน

ตัวอย่างจริงที่ทุกสัญญาณตรงกันหมด: CVE-2024-3400 ใน PAN-OS GlobalProtect vendor ให้คะแนน CVSS-B 10.0 พร้อม Automatable YES และ Urgency HIGHEST KEV ระบุว่าถูกใช้ใน ransomware แล้ว (Known) และคะแนน EPSS อยู่ที่ 0.99999 เมื่อ 24 ตุลาคม 2569 แบบนี้ตัดสินใจง่าย เคสที่ยากคือเคสที่สัญญาณขัดกัน และตรงนั้นแหละที่การรู้ว่าแต่ละสัญญาณวัดอะไรจะคุ้มค่าครับ

ข้อจำกัดที่ต้องพูดกันตรง ๆ

• CVSS ดีได้เท่ากับข้อมูลที่อยู่เบื้องหลัง ค่า default แบบ worst case ทำให้คะแนนสูงเกินจริงเมื่อขาดรายละเอียด และ base score ไม่รู้อะไรเกี่ยวกับเครือข่ายของเราเลย
• EPSS เป็นโมเดล ขึ้นกับสิ่งที่พาร์ตเนอร์ด้านข้อมูลมองเห็น ครอบคลุมเฉพาะ CVE และเปลี่ยนได้ทุกวัน จึงควรจดวันที่ไว้คู่กับคะแนน
• KEV ออกแบบมาให้อนุรักษนิยม การไม่อยู่ในรายการไม่ได้แปลว่าปลอดภัย และรายการสะท้อนเฉพาะสิ่งที่ไปถึง CISA
• SSVC และ BOD 26-04 ต้องการให้เรารู้จัก asset ของตัวเอง ว่าอะไร exposed และแต่ละตัวทำหน้าที่อะไรให้ธุรกิจ inventory นี้คืองานที่ไม่มีคะแนนตัวไหนทำแทนเราได้

ปัญหาไม่ได้อยู่ที่คะแนน แต่อยู่ที่การให้ตัวเลขตัวเดียวตอบคำถามสามข้อครับ

แหล่งอ้างอิง

• FIRST: CVSS v4.0 Specification Document
• FIRST: CVSS v4.0 User Guide
• FIRST: CVSS v4.0 overview
• NIST NVD: Vulnerability Metrics (CVSS)
• NIST NVD: Understanding Vulnerability Detail Pages
• NIST: NIST Updates NVD Operations to Address Record CVE Growth (เมษายน 2569)
• NIST: National Vulnerability Database news updates
• FIRST: Exploit Prediction Scoring System (EPSS)
• FIRST: EPSS FAQ
• FIRST: EPSS probability, percentiles and binning
• FIRST EPSS API: CVE-2024-3400
• CISA: Known Exploited Vulnerabilities (เกณฑ์)
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: KEV catalog JSON feed
• CISA: BOD 22-01, Reducing the Significant Risk of Known Exploited Vulnerabilities (ยกเลิกแล้ว)
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA: Stakeholder-Specific Vulnerability Categorization (SSVC)
• CISA: SSVC Guide (PDF, พฤศจิกายน 2565)
• CERT/CC: SSVC overview
• Palo Alto Networks: CVE-2024-3400 security advisory