CISA KEV ו-EPSS: תעדוף לפי ראיות לניצול

הסורק מחזיר 400 ממצאים ויש לך שבוע. CVSS יכול למיין אותם לפי חומרה, אבל 9.8 שאף אחד לא מנצל יכול לחכות, ו-7.5 שתוקפים כבר מנצלים לא אמור לחכות. שני מקורות חינמיים מראים אילו חולשות מנוצלות בפועל. קטלוג Known Exploited Vulnerabilities (KEV) של CISA מונה חולשות עם ניצול מאומת. Exploit Prediction Scoring System (EPSS) של FIRST מעריך מה הסיכוי שכל חולשה תנוצל ב-30 הימים הקרובים.

המאמר מסביר את שניהם, מראה איך הם משתלבים עם CVSS, ואז עובר על מעבדה שבה שולפים משני הפידים את אותם CVEs ובונים טבלת עדיפויות קטנה. מה שכדאי לקחת ממנו: חומרה, ראיות לניצול והחשיפה שלך קובעים יחד את סדר התיקונים. כל אחד מהם לבדו נותן סדר שגוי.

למי ש-CVSS חדש לו, כדאי לקרוא קודם מה זה CVSS. ההבדל בין חולשה, איום ואקספלויט מוסבר ב-מה זו חולשה.

#מה CVSS אומר ומה הוא משאיר בחוץ

Common Vulnerability Scoring System מדרג חולשה לפי הווקטור שלה: איך תוקף מגיע אליה, כמה מאמץ זה דורש, אם התוקף צריך הרשאות או פעולה של משתמש, ובמה החולשה יכולה לפגוע. ציון הבסיס הוא מספר מ-0 עד 10 שנבנה מהמאפיינים האלה.

ציון הבסיס עונה על שאלה אחת: כמה זה יכול להיות גרוע אם מישהו ינצל את זה? הוא לא עונה על השאלה אם מישהו מנצל את זה. ל-CVSS יש מדדים זמניים שיכולים לכלול בשלות אקספלויט, אבל רוב לוחות הבקרה מציגים קודם את ציון הבסיס, והמספר הזה לא משתנה אחרי פרסום ה-CVE.

שני CVEs מהמעבדה למטה מראים את הפער. ל-CVE-2021-44228 (Log4Shell) יש ציון בסיס 10.0 ב-NVD. ל-CVE-2023-44487 (HTTP/2 Rapid Reset) יש 7.5. מיון לפי ציון בלבד שם את Log4Shell ראשון, וזה נכון. הבעיה מתגלה ברשימה של ארבעים חולשות עם ציון 9.8 בלי סימן שמישהו ניצל אחת מהן. ציון נותן נקודת התחלה, וסדר הוא לא נותן.

#CISA KEV: ניצול מאומת

קטלוג KEV הוא הרשימה של CISA של חולשות שנוצלו בפועל (in the wild). לדברי CISA, היא מתחזקת את המקור הסמכותי לרשימה הזו, והיא ממליצה לארגונים להשתמש בקטלוג כקלט למסגרת התעדוף שלהם. הכניסה לקטלוג תלויה בראיות אמינות לכך שהחולשה מנוצלת באופן פעיל. רשומות נכנסות כשהראיות מגיעות.

קובץ הקטלוג שהורדתי למאמר הזה (גרסת קטלוג 2026.11.06, פורסם ב-2026-11-06) מכיל 1,769 רשומות. בכל רשומה יש את השדות האלה:

• cveID, vendorProject, product וגם vulnerabilityName
• dateAdded, היום שבו CISA הוסיפה את ה-CVE
• dueDate, המועד האחרון ש-CISA קבעה
• requiredAction, בדרך כלל תיקון של היצרן או הפחתת סיכון
• knownRansomwareCampaignUse, שערכו Known או Unknown
• notes וגם cwes

מתוך 1,769 הרשומות, 361 מסומנות Known לשימוש בכופרה. 285 נוספו ב-2026 עד תאריך הפרסום.

יש שתי מגבלות חשובות. ראשית, הקטלוג אינו שלם. ניצול מתחיל הרבה פעמים לפני ש-CISA מאמתת אותו, ויש חולשות מנוצלות שאף פעם לא מקבלות רשומה. CVE שלא מופיע ב-KEV הוא CVE לא מאומת, וזה לא אותו דבר כמו בטוח. שנית, KEV לא אומר אם העותק שלך של מוצר מושפע. את התשובה הזו נותן המצאי שלך.

#מאיפה המועדים האחרונים

רוב האנשים מכירים את המועדים של KEV מ-BOD 22-01, הנחיה תפעולית מחייבת ש-CISA פרסמה ב-3 בנובמבר 2021. היא הורתה לסוכנויות הפדרליות בארה״ב לטפל ברשומות KEV בתוך שישה חודשים עבור מזהי CVE שהוקצו לפני 2021, ובתוך שבועיים עבור כל שאר החולשות. השדה dueDate עדיין משקף את המודל הזה ברשומות ישנות.

BOD 22-01 כבר לא בתוקף. בדף שלה ב-cisa.gov כתוב עכשיו שהיא בוטלה והוחלפה ב-BOD 26-04, ש-CISA מציגה תחת 10 ביוני 2026. BOD 26-04 קובעת לוחות זמנים לטיפול לפי ארבעה קלטים:

• סטטוס KEV: האם ה-CVE נמצא בקטלוג?
• חשיפת הנכס: האם משתמשים לא מאומתים ברשתות ציבוריות יכולים להגיע לנכס?
• אוטומציה של האקספלויט: האם יריב יכול להפוך כל שלב באקספלויט לאוטומטי?
• השפעה טכנית: כמה שליטה נותן ניצול מוצלח?

Table 1 ב-BOD 26-04 מכילה את לוחות הזמנים עצמם. ההנחיה סופרת ימים קלנדריים, והיא מגדירה רשומות "& forensic triage", שצריך לטפל בהן בתוך שלושה ימים ואז לבדוק אותן לסימני פריצה. את הערכים המדויקים צריך לקרוא בטבלה בדף ההנחיה, בלי להעתיק מספרים מהמאמר הזה או מפוסטים ישנים.

הקטלוג מראה את שתי התקופות. בקובץ שהורדתי, הפער בין dateAdded לבין dueDate הוא 21 ימים ב-1,025 רשומות, 14 ימים ב-286 רשומות, וכשישה חודשים (181 או 182 ימים) ב-249 רשומות. כמעט לכל הרשומות של שישה חודשים יש מזהי CVE מ-2020 או לפני כן, וזה תואם את הכלל של BOD 22-01. הפערים של 21 ו-14 ימים הם תאריכים ש-CISA קבעה לכל רשומה בנפרד, ולכן הם לא משקפים כלל קבוע אחד. 152 רשומות מזכירות את BOD 26-04 בשדה requiredAction או בשדה notes.

#FIRST EPSS: סבירות ב-30 הימים הקרובים

FIRST, ה-Forum of Incident Response and Security Teams, מתחזק את EPSS. לפי FIRST, זה מודל machine learning שמעריך את ההסתברות ש-CVE שפורסם ינוצל בפועל ב-30 הימים הקרובים. FIRST מפרסם את הציון כל יום לכל CVE. הנתונים חינמיים ולא דורשים רישום.

כל CVE מקבל שני מספרים:

• הציון הוא הסתברות בין 0 ל-1. ציון 0.05 פירושו סיכוי של 5% לניצול בתוך 30 ימים. לפי FIRST, המודל מכויל כך שהציון תואם את השיעור הזה.
• האחוזון הוא הדירוג. אחוזון 0.99 פירושו שה-CVE קיבל ציון גבוה מ-99% מה-CVEs שדורגו באותו יום.

רוב הציונים קרובים לאפס, כי רוב החולשות אף פעם לא מנוצלות. לכן הרבה פעמים קל יותר לקרוא את האחוזון מאשר את הציון הגולמי. ציון 0.909 נראה גבוה בפני עצמו, ואחוזון 0.998 מראה איך הוא עומד מול שאר הרשימה באותו יום.

לפי FIRST, המודל נשען על כ-2,850 מאפיינים מחמש קטגוריות (קוד אקספלויט, שיח, מדדי CVSS, גיל והיקף הפניות, בין היתר), והוא לומד מפעילות ניצול שנצפתה ושותפים מספקים. הציונים זזים כשמגיעים אותות חדשים. ה-API יכול להחזיר היסטוריה של 30 ימים ל-CVE אחד, וזה עוזר כשצריך להסביר למה ציון עלה.

ל-EPSS יש מגבלה ברורה. הוא מנבא פעילות ניצול. הוא לא אומר כמה חולשה גרועה, ולא אומר אם המערכות שלך מריצות את הקוד המושפע. ציון גבוה הוא סיבה להסתכל על הנכס, וצריך לבדוק את הנכס לפני שמניחים שהוא בסיכון.

#איך הם משתלבים עם CVSS

כל מקור עונה על שאלה אחרת:

סדר התיקונים נגזר מהשילוב של הארבעה. זו נקודת התחלה, לא חוק. קודם מה שמאומת ונגיש. אחריו מה שמאומת אבל לא נגיש, ומה שלא מאומת עם EPSS גבוה ונגיש. השאר לפי CVSS ולפי ערך הנכס. BOD 26-04 משלבת את אותם סוגי קלט, כך שהכללים הפדרליים הולכים באותו היגיון.

#מעבדה מעשית: בניית טבלת עדיפויות

צריך:

• shell של Bash. הרצת הייחוס השתמשה ב-Git Bash על Windows 11, עם curl 8.12.1 ו-Python 3.12.
• גישה לאינטרנט אל www.cisa.gov, api.first.org וגם services.nvd.nist.gov.
• jq, לא חובה. jq לא היה מותקן במכונת הייחוס, ולכן לכל פקודת jq למטה יש מקבילה ב-Python 3.12, והפלטים שמוצגים הגיעו מפקודות ה-Python.

השלבים האלה רק קוראים קטלוגים ציבוריים. אף אחד מהם לא סורק מארח. אם בהמשך בודקים את עמודת החשיפה מול שירותים חיים, עושים את זה רק על מערכות בבעלותך או כאלה שיש לך הרשאה בכתב לבדוק.

#שלב 1: להוריד את קטלוג KEV

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json -o kev.json
ls -l kev.json

ההורדה שקטה. בהרצת הייחוס הקובץ היה בגודל 1,832,349 בתים. לפני שסומכים על הספירות, צריך לפתוח את תחילת הקובץ ולבדוק את catalogVersion ואת dateReleased.

#שלב 2: לספור את הרשומות

jq '.vulnerabilities | length' kev.json

במכונת הייחוס זה החזיר command not found, כי jq היה חסר. המקבילה ב-Python החזירה:

python -c "import json; d=json.load(open('kev.json')); print(len(d['vulnerabilities']))"

1769

השדה count ברמה העליונה אמור להציג את אותו מספר.

#שלב 3: לחפש CVE אחד ב-KEV

jq '.vulnerabilities[] | select(.cveID=="CVE-2021-44228") | {cveID, dateAdded, dueDate, requiredAction}' kev.json

המקבילה ב-Python הדפיסה את זה, עם requiredAction מקוצר כאן:

{
  "cveID": "CVE-2021-44228",
  "dateAdded": "2021-12-10",
  "dueDate": "2021-12-24",
  "requiredAction": "For all affected software assets for which updates exist, the only acceptable remediation actions are: 1) Apply updates; OR 2) remove affected assets from agency networks. ..."
}

אותה שאילתה עבור CVE-2023-4863 מחזירה dateAdded 2023-09-13 וגם dueDate 2023-10-04. התאריכים הם הסיבה לשמור את קובץ הקטלוג: הם מתעדים מתי CISA פעלה ולא רק אם פעלה.

#שלב 4: לשאול את EPSS על אותם CVEs

curl -s 'https://api.first.org/data/v1/epss?cve=CVE-2021-44228,CVE-2023-4863' | jq '.data'

התשובה הגולמית מהרצת הייחוס:

{"status":"OK","status-code":200,"version":"1.0","access":"public","total":2,"offset":0,"limit":100,"data":[{"cve":"CVE-2023-4863","epss":"0.999790000","percentile":"0.999800000","date":"2026-11-07"},{"cve":"CVE-2021-44228","epss":"0.999990000","percentile":"1.000000000","date":"2026-11-07"}]}

בקוד חשובים שני פרטים. השורות חוזרות בסדר שונה מהבקשה, ולכן צריך להתאים לפי cve ולעולם לא להסתמך על המיקום. הערכים הם מחרוזות, ולכן צריך להמיר אותם למספרים לפני מיון או השוואה.

#שלב 5: לבנות את הטבלה עם סקריפט

לשמור את זה בקובץ priority.py. הוא צריך רק את הספרייה הסטנדרטית של Python.

import json, sys, time, urllib.request

KEV_FILE = sys.argv[1]
CVES = sys.argv[2:]

def get(url):
    with urllib.request.urlopen(url, timeout=60) as r:
        return json.load(r)

kev = {v["cveID"]: v for v in json.load(open(KEV_FILE))["vulnerabilities"]}
epss = {row["cve"]: row for row in get(
    "https://api.first.org/data/v1/epss?cve=" + ",".join(CVES))["data"]}

print("| CVE | CVSS 3.1 base | In KEV | EPSS | Percentile |")
print("|---|---|---|---|---|")
for cve in CVES:
    nvd = get(f"https://services.nvd.nist.gov/rest/json/cves/2.0?cveId={cve}")
    metrics = nvd["vulnerabilities"][0]["cve"].get("metrics", {})
    cvss = metrics.get("cvssMetricV31", [{}])[0].get("cvssData", {}).get("baseScore", "n/a")
    e = epss.get(cve, {})
    print(f"| {cve} | {cvss} | {'yes' if cve in kev else 'no'} | "
          f"{float(e.get('epss', 0)):.5f} | {float(e.get('percentile', 0)):.5f} |")
    time.sleep(7)  # the NVD API rate-limits requests without a key

להריץ אותו על שישה CVEs: שניים מדוגמאות הקטלוג וארבעה שנבחרו כדי ליצור ניגוד אליהם.

python priority.py kev.json CVE-2021-44228 CVE-2023-4863 CVE-2024-3400 CVE-2023-44487 CVE-2023-38545 CVE-2024-3094

הפלט מהרצת הייחוס:

| CVE | CVSS 3.1 base | In KEV | EPSS | Percentile |
|---|---|---|---|---|
| CVE-2021-44228 | 10.0 | yes | 0.99999 | 1.00000 |
| CVE-2023-4863 | 8.8 | yes | 0.99979 | 0.99980 |
| CVE-2024-3400 | 10.0 | yes | 0.99999 | 1.00000 |
| CVE-2023-44487 | 7.5 | yes | 0.99999 | 0.99998 |
| CVE-2023-38545 | 9.8 | no | 0.78689 | 0.99591 |
| CVE-2024-3094 | 10.0 | no | 0.90900 | 0.99808 |

הסקריפט לא ממלא את עמודת החשיפה, כי רק לך יש את המצאי שלך. כך מילאה אותה הרצת הייחוס, ומה כל בדיקה כיסתה:

• CVE-2021-44228: חיפוש find אחר log4j-core*.jar תחת פרופיל המשתמש והמאגר לא החזיר כלום. תוצאה: לא.
• CVE-2023-4863: חיפוש של libwebp* תחת /mingw64, /usr ופרופיל המשתמש לא החזיר כלום. תוצאה: לא.
• CVE-2023-38545: הפקודה curl --version מדווחת על 8.12.1. טווח ה-libcurl המושפע לפי NVD הוא מ-7.69.0 ועד 8.4.0, לא כולל. תוצאה: לא, עבור libcurl של upstream. ההסתייגות מופיעה למטה.
• CVE-2024-3094: הפקודה xz --version מדווחת על 5.6.4. לפי NVD, הגרסאות 5.6.0 ו-5.6.1 מושפעות. תוצאה: לא.
• CVE-2024-3400 ו-CVE-2023-44487: לא נבדקו במכונה הזו.

בעמודת החשיפה טועים הכי הרבה. הפצות Linux ויצרנים עושים הרבה פעמים backport לתיקונים, ולכן מספר גרסה לבדו יכול להטעות. לפני שסוגרים שורה כבטוחה, צריך לבדוק את ההודעה של היצרן עבור ה-build שלך.

#שלב 6: לקרוא את הטבלה

לסדר את השורות לפי סדר התיקונים, בעזרת הכלל מהסעיף הקודם. אם CVE-2021-44228, CVE-2023-4863 או CVE-2024-3400 היו נגישים ברשת שלך, הם היו התיקונים הראשונים של השבוע, לא משנה מה אומרת שאר הרשימה.

ל-CVE-2023-44487 יש ציון CVSS נמוך מזה של CVE-2023-38545, אבל הוא מאומת וציון ה-EPSS שלו הוא 0.99999. ברשימה שבה שניהם נגישים, הוא הולך ראשון. ה-9.8 ש-CISA לא אימתה יורד למטה.

CVE-2024-3094 הוא המקרה ששובר כלל פשוט. הוא לא מופיע בנתונים של CISA, אבל ציון ה-EPSS שלו הוא 0.909 וציון ה-CVSS שלו הוא 10.0. במכונה הזו הגרסה לא מושפעת, ולכן השורה נסגרת. במארח שמריץ xz 5.6.1 אותה שורה עולה לראש הרשימה, כי הציון אומר שפעילות ניצול סבירה מאוד והחולשה קריטית.

#טעויות נפוצות

• למיין לפי CVSS בלבד. הציון מודד השפעה ולא שימוש. צריך לשים לידו את העמודות של KEV ו-EPSS.
• להתייחס ל-KEV כרשימה מלאה. רשומה חסרה אומרת ש-CISA לא אימתה ניצול. היא לא אומרת שהחולשה לא מזיקה.
• לקרוא את EPSS כהשפעה או כהוכחה. EPSS מעריך פעילות ניצול. הוא לא אומר שהחולשה נמצאת ברשת שלך.
• להעתיק מועדים פדרליים. BOD 22-01 בוטלה. BOD 26-04 חלה על סוכנויות פדרליות. מחוץ לתחולה הזו, לוחות הזמנים שלה הם מודל, ואת הלוחות שלך צריך לקבוע לפי הסיכון שלך.
• לשלוח שאילתות המוניות ל-API. FIRST בנה את ה-API של EPSS לחיפושים נקודתיים. בשביל מערך הנתונים המלא, להוריד את ה-CSV היומי.
• לשכוח את התאריך. ציוני EPSS משתנים מדי יום, ו-KEV גדל כל שבוע. צריך לכתוב את התאריך ליד כל טבלה.
• לסמוך על מספרי גרסה בלי ההודעה של היצרן. backports ואפשרויות build משנים מה מושפע.
• לדלג על עמודת החשיפה. טבלה בלי נתוני נכסים היא דעה על החולשות ולא רשימת עדיפויות למערכות שלך.

#איך ממשיכים

• לקרוא את דף המתודולוגיה של EPSS בכתובת https://www.first.org/epss/how-it-works, שמכסה כיול ומגבלות.
• להשתמש ב-CSV היומי של EPSS בכתובת https://epss.empiricalsecurity.com/epss_scores-current.csv.gz ולחבר אותו לקובץ KEV לפי cveID. כך בודקים מאות CVEs במעבר אחד.
• לקרוא את BOD 26-04 ואת Table 1 שלה. ההנחיה מציינת את תוכנית Vulnrichment של CISA כמקור לסטטוס KEV, לאוטומציה של אקספלויט ולהשפעה טכנית של CVEs.
• להוסיף שתי עמודות מהרשומות שלך: אם הנכס חשוף לאינטרנט, ומה הערך שלו עבורך. שתי העמודות האלה בדרך כלל משנות את סדר הרשימה יותר מהציונים.

#מקורות

הנתונים במאמר הזה נקראו ב-2026-11-08 מהמקורות שמופיעים במטא־דאטה של המאמר. ספירות KEV וציוני EPSS משתנים עם הזמן, ולכן צריך לבדוק את התאריך בהרצה שלך.