שימוש בטוח ב-LLM בעבודת אבטחה

עוזר AI יכול לסכם רשומת CVE בתוך שניות. הוא יכול גם לנקוב בגרסה מתוקנת שגויה באותו טון רגוע שבו הוא נוקב בנכונה. המאמר הזה עוסק בפער הזה: ארבעת הסיכונים החשובים ביותר בעבודת אבטחה, שיטה להקטין אותם ומעבדה שבה בודקים סיכום לדוגמה שכתב AI מול רשומת NVD, קטלוג CISA Known Exploited Vulnerabilities ‏(KEV) ודף האבטחה של Apache Log4j.

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

#מה הסיכונים

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

#עובדות שגויות בביטחון

מודל שפה מפיק את המילים הבאות הסבירות ביותר. לעיתים קרובות התשובה הסבירה גם נכונה. לפעמים היא מספר גרסה שנשמע נכון ואינו. NIST Generative AI Profile, ‏NIST AI 600-1, קורא לזה confabulation: "the production of confidently stated but erroneous or false content." אותו פרופיל מציין ש-confabulation נובעת מהדרך שבה המודלים האלה נבנים, ולא מתקלה נדירה.

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

#נתונים רגישים בפרומפטים

כל מה שמודבק בפרומפט יוצא משליטתך כשהוא מגיע לשירות שאינו בניהולך. מה קורה אחר כך תלוי בשירות, בהגדרות שלו ובתנאים שלו. הטקסט עשוי להישמר, להירשם בלוג או לעבור סקירה. בעבודת אבטחה החומר המסוכן מוכר: שמות לקוחות, שמות מארחים פנימיים וטווחי IP, טוקנים שמופיעים בלוגים, ממצאים שלא פורסמו ונתונים אישיים מאירוע. OWASP מונה את זה תחת LLM02:2025 Sensitive Information Disclosure, שמכסה גם את מה שהמודל חושף וגם את מה שהאפליקציה שסביבו חושפת.

#פעולות כלים לא בטוחות

עוזר עם תיבת טקסט בלבד יכול לתת תשובה גרועה. עוזר עם shell, טוקן API או גישת כתיבה ל-repository יכול לעשות דבר גרוע. LLM06:2025 Excessive Agency של OWASP מתאר את הבעיה: למערכת יש יותר פונקציות, הרשאות או אוטונומיה ממה שהמשימה צריכה. כשהמודל מבין בקשה לא נכון, הנזק תלוי במה שהיה מותר לו לגעת.

#Prompt injection מתוכן לא מהימן

Prompt injection קורה כשתוכן שהמערכת קוראת כנתונים מכיל הנחיות שהמודל מבצע. התוכן יכול להיות דף web שביקשת לסכם, אימייל בתור שלך, שורת לוג עם מחרוזת user agent שנבנתה בכוונה או README ב-repository שביקשת לסקור. OWASP מכסה את זה כ-LLM01:2025 Prompt Injection. הפרופיל של NIST מתאר את הגרסה העקיפה, שבה תוקף שותל הנחיות בנתונים שהעוזר צפוי לאחזר. העוזר עלול לא להבחין בין הבקשה שלך לטקסט שהוא קרא הרגע.

#למה זה חשוב לאנליסטים

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

AI Risk Management Framework של NIST, שפורסם ב-26 בינואר 2023, מארגן את העבודה בארבע פונקציות: GOVERN, ‏MAP, ‏MEASURE ו-MANAGE. לא צריך לנהל תוכנית AI כדי לאמץ את הרעיון. עבור אנליסט אחד זה אומר לדעת לשם מה הכלי, אילו נתונים הוא יכול לראות, כמה פעמים הוא טועה במשימות מהסוג שלך ומי מאשר פעולה. המסגרת וולונטרית, וזה בסדר. השאלות עדיין רלוונטיות.

#השיטה

חמישה כללים, לפי הסדר, בכל פעם.

#1. להחליט מה נכנס לפרומפט

לפני הדבקה של משהו, ממיינים אותו לשלוש קבוצות:

• ציבורי: הודעות ספק, רשומות CVE שפורסמו, תיעוד ציבורי.
• פנימי אבל לא רגיש: נוהל כללי, דפוס קוד מנוקה.
• מוגבל: שמות לקוחות, שמות מארחים, כתובות IP, פרטי התחברות, ממצאים שלא פורסמו, נתונים אישיים.

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

sed -E 's/([0-9]{1,3}\.){3}[0-9]{1,3}/10.x.x.x/g; s/[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+/user@example/g' incident.log > redacted.log

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

#2. לבקש מקורות, ולהפריד בין טענות לניחושים

מבקשים מהעוזר לפרט כל טענה עובדתית עם המקור שממנו הגיעה, ולכתוב "no source" כשאין מקור. כל טענה בלי מקור היא שאלה שעליך לענות עליה.

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

#3. לאמת מול נתונים ראשוניים

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

#4. להגביל מה הכלי יכול לעשות

מתחילים בגישת קריאה בלבד. אם הכלי יכול להריץ פקודות, נותנים לו חשבון עם ההרשאות המינימליות, מכונה וירטואלית או קונטיינר חד־פעמיים ו-allowlist של פקודות. כל שלב שכותב, שולח, מוחק או קורא למערכת חיה צריך לחכות לאישור. שומרים את הלוג של מה שהוא הריץ. בפעם הראשונה שמשהו לא צפוי קורה, הלוג הזה יהיה נחוץ.

#5. ההחלטה נשארת אנושית

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

#תרגיל מעשי: בדיקת סיכום CVE שכתב AI

המעבדה הזאת משתמשת רק במקורות ציבוריים לקריאה בלבד. לא מריצים כלום מול מערכת חיה. שלוש הבקשות הולכות ל-NVD, ל-CISA ול-Apache Software Foundation, ותו לא.

מה צריך: טרמינל (‏Git Bash ב-Windows מתאים), curl ו-jq. אם jq לא מותקן, מתקינים אותו מאתר הפרויקט. הפקודות בהמשך הורצו ב-Windows 11 עם Git Bash. jq לא היה מותקן במחשב הזה, ולכן הפלטים שמוצגים מגיעים מפקודת Node.js שקוראת את אותם שדות JSON. פקודות ה-jq הן אלה שכדאי להשתמש בהן.

#הסיכום לדוגמה

הנה סיכום שעוזר כתב על CVE-2021-44228, הפגם שמוכר בשם Log4Shell. קוראים אותו לפני שבודקים משהו ומסמנים מה נראה שגוי.

CVE-2021-44228 is a remote code execution flaw in Apache Log4j2. An attacker who controls a logged value can make the server load code from an LDAP server. NVD published the record on 2021-12-09. The flaw affects Log4j 2.13.0 through 2.14.1, and upgrading to 2.14.1 fixes it. The CVSS v3.1 base score is 10.0. CISA added the flaw to the KEV catalog on 2021-12-10. Attackers began scanning within hours of disclosure. The flaw is in log4j-core only.

הסיכום מכיל שתי שגיאות מכוונות. מוצאים אותן בעזרת המקורות הבאים.

#שלב 1: הורדת רשומת NVD

ה-API של NVD מחזיר את רשומת ה-CVE כ-JSON. מריצים את הפקודה הזאת:

curl -s 'https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-44228' | jq '.vulnerabilities[0].cve | {published, descriptions: .descriptions[0].value}'

בדיקה שקולה בלי jq, וזה הפלט שמוצג בהמשך:

curl -s 'https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-44228' -o nvd.json
node -e "const c=JSON.parse(require('fs').readFileSync('nvd.json','utf8')).vulnerabilities[0].cve;console.log(JSON.stringify({published:c.published,descriptions:c.descriptions[0].value},null,2))"

הפלט שהתקבל:

{
  "published": "2021-12-10T10:15:09.143",
  "descriptions": "Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects."
}

מסתכלים על השדה published. בדוגמה נכתב 2021-12-09. ברשומה כתוב 2021-12-10. זו השגיאה הראשונה.

התיאור מוסיף גם תנאי שהדוגמה השמיטה: טעינת הקוד קורית כש-message lookup substitution מופעל. השמטה של זה גורמת לפגם להישמע כאילו הוא פוגע בכל התקנת Log4j, והרשומה לא אומרת את זה.

#שלב 2: הורדת רשומת ה-KEV

CISA מפרסם את קטלוג ה-KEV כקובץ JSON אחד. מורידים אותו ומסננים לפי ה-CVE:

curl -s -L 'https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json' -o kev.json
jq '.vulnerabilities[] | select(.cveID=="CVE-2021-44228")' kev.json

הפלט שהתקבל, מקטלוג בגרסה 2026.11.06 עם 1769 רשומות, שהורד ב-2026-11-08 (מסנן ה-jq רץ דרך Node.js, כמו למעלה):

{
  "cveID": "CVE-2021-44228",
  "vendorProject": "Apache",
  "product": "Log4j2",
  "vulnerabilityName": "Apache Log4j2 Remote Code Execution Vulnerability",
  "dateAdded": "2021-12-10",
  "shortDescription": "Apache Log4j2 contains a vulnerability where JNDI features do not protect against attacker-controlled JNDI-related endpoints, allowing for remote code execution.",
  "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. Temporary mitigations using one of the measures provided at https://www.cisa.gov/uscert/ed-22-02-apache-log4j-recommended-mitigation-measures are only acceptable until updates are available.",
  "dueDate": "2021-12-24",
  "knownRansomwareCampaignUse": "Known",
  "forensicTriage": "No",
  "notes": "https://nvd.nist.gov/vuln/detail/CVE-2021-44228",
  "cwes": [
    "CWE-20",
    "CWE-400",
    "CWE-502"
  ]
}

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

#שלב 3: פתיחת הדף של Apache וסימון כל טענה

רשומת ה-NVD מקשרת לדף האבטחה של Apache Log4j. פותחים אותו ומאתרים את הסעיף של CVE-2021-44228. קוראים ארבעה שדות: Versions affected, ‏Versions fixed, ‏Components affected והתיאור. בגרסת הדף שהורדה ב-2026-11-08, הסעיף הציג את הערכים האלה:

• Versions affected: ‏[2.0-beta9, 2.3.1), ‏[2.4, 2.12.2) ו-[2.13.0, 2.15.0). הסוגריים הם כתיב קטעים: הקצה השמאלי כלול והימני לא, כך ש-2.15.0 עצמה מחוץ לטווח.
• Versions fixed: ‏2.3.1 עבור Java 6, ‏2.12.2 עבור Java 7 ו-2.15.0 עבור Java 8 ואילך.
• Components affected: ‏log4j-core.

צריך לקרוא את הדף בעצמך, כי הוא משתנה. בדף יש גם סעיף נפרד על CVE-2021-45046, בעיית המשך, שאומר שהתיקון ב-2.15.0 לא היה שלם בחלק מהקונפיגורציות ומפנה ל-2.16.0 עבור Java 8 ואילך.

#הפסיקות

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

שתי טענות שגויות, אחת בלתי ניתנת לאימות, והשאר נבדקו ונמצאו תקינות. שתי הטענות השגויות הן שתי השגיאות המכוונות בדוגמה.

#מה הבדיקה מלמדת

הטקסט של NVD וטווחי הגרסאות לא מסכימים במשהו קטן. התיאור אומר "through 2.15.0", בעוד שהטווח הקריא למכונה מסתיים לפני 2.15.0. גם הקונפיגורציה של NVD וגם דף Apache אומרים ש-2.15.0 לא מושפעת מה-CVE הזה ב-Java 8 ואילך. כשמקורות לא מסכימים, רושמים את חוסר ההסכמה ומצטטים את המקור שמגדיר את הטווח. לא בוחרים בגרסה שנשמעת טוב יותר.

הגרסה המתוקנת תלויה בגרסת ה-Java וב-CVE. מספר "fixed in" יחיד מסתיר את שניהם. מבקשים את ה-CVE המדויק, המוצר, הרכיב והפלטפורמה, וקוראים את הטבלה של הספק.

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

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

• אמון בצורה של ציטוט. קישור מסודר עם כותרת סבירה יכול להפנות לדף שאומר משהו אחר. פותחים אותו.
• הדבקת אירוע שלם כדי לקבל "מבט מהיר". קודם מצנזרים, ומדביקים רק את הקטע שהשאלה צריכה.
• בקשה לגרסה העדכנית בלי תאריך. מודל עלול לא לדעת על גרסאות שיצאו אחרי סוף נתוני האימון שלו. נותנים לו את הערות הגרסה או את ההודעה ומבקשים ממנו לקרוא אותן.
• קבלת patch שנוצר בלי להריץ את הבדיקות או לקרוא את ה-diff.
• בדיקה של הדרך שבה העוזר מטפל בנתוני לקוח אמיתיים "רק כדי לראות". הבדיקה עצמה היא הדליפה.
• מתן פרטי התחברות לפרודקשן לסוכן כי ההדגמה הייתה צריכה אותם.
• סיכום דף web בלי לחשוב מי כתב אותו. הדף יכול לשאת הנחיות. מתייחסים לטקסט שלו כנתונים לקריאה, ולא כהוראות לביצוע.

#איך ממשיכים

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

קוראים את הערכים של OWASP עבור LLM01, ‏LLM02, ‏LLM06 ו-LLM09. הם נותנים אוצר מילים משותף ל-prompt injection, לחשיפת נתונים, להרשאות עודפות ולמידע מטעה. אחר כך קוראים את סעיף 2 של NIST AI 600-1, שמגדיר את הסיכונים שהפרופיל מכסה.

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

#מקורות

• NIST AI Risk Management Framework
• NIST AI 600-1, Generative AI Profile (July 2024)
• OWASP Top 10 for LLM and GenAI Applications, 2025
• NVD Vulnerability API documentation
• NVD record for CVE-2021-44228
• CISA Known Exploited Vulnerabilities catalog (JSON feed)
• Apache Log4j Security Vulnerabilities