LLM Security Testing: איך בונים הרנס בדיקות אבטחה אוטומטי למודלי שפה

מאת צוות מדיה דיל · 03.08.2026 · Enterprise AI · 7 דק׳

מדריך ארכיטקטוני לבניית הרנס LLM Security Testing: קטגוריות בדיקה מרכזיות, LLM-as-judge, ואינטגרציה ל-CI/CD שתופסת רגרסיות אבטחתיות לפני פרודקשן.

הבעיה עם "המודל שלנו עבר evaluation, אז הוא בטוח"

אחת מהתפיסות המוטעות הנפוצות ביותר בצוותי מוצר: אם המודל עבר evaluation מקיף על benchmark איכות - MMLU, HumanEval, benchmark פנימי כלשהו - הוא "נבדק" ואפשר להוציא אותו לפרודקשן. LLM Security Testing הוא דיסציפלינה נפרדת לחלוטין, שממוקדת לא בשאלה "האם המודל טוב" אלא "האם ניתן לגרום למודל להתנהג בניגוד למדיניות שהוגדרה לו". אלה שני צירים אורתוגונליים - מודל יכול להיות מדויק ומועיל ב-95% מהזמן, ועדיין להיות פגיע לחלוטין להזרקת פקודות, לחילוץ מידע רגיש, או להטיה שיטתית שרק בדיקת אבטחה ייעודית תחשוף.

למה בדיקת אבטחה ל-RAG שונה מבדיקת המודל הגולמי

רוב מערכות ה-LLM בפרודקשן ב-2026 לא עובדות על ידע גולמי של המודל בלבד - הן משלבות Retrieval-Augmented Generation, שמביא מסמכים רלוונטיים מ-vector store ומזין אותם כ-context. זה יוצר משטח בדיקה נוסף שקל לפספס: אם ניתן להזריק מסמך זדוני לתוך ה-corpus שממנו נשלף המידע (data poisoning), אפשר להשפיע על תשובות המודל בלי לגעת בכלל בפרומפט או במודל עצמו. בדיקת אבטחה ל-RAG צריכה לכלול תרחיש שבו מסמך "מורעל" מוזרק למאגר, ולבחון האם המודל מזהה שהתוכן שמגיע מה-retrieval הוא בעל אמינות שונה מהוראות המערכת המקוריות, או שהוא מתייחס לכל התוכן שמגיע מ-RAG כאמין באותה מידה כמו ה-system prompt - וזו בדיוק ההנחה השגויה שהופכת RAG poisoning לאפקטיבי כל כך.

קטגוריות הבדיקה המרכזיות

Prompt Injection Resilience

בדיקה שיטתית האם הפרדת ההנחיות (instructions) מהתוכן (content) שקוראת המערכת אכן מחזיקה מעמד. הבדיקה כוללת direct injection (המשתמש מזין פקודה ישירות) ו-indirect injection (הפקודה הזדונית "מוסתרת" בתוך מסמך, אימייל, או תוצאת חיפוש שהמודל קורא כחלק מתהליך עבודתו הרגיל). הקטגוריה השנייה מסוכנת יותר בפועל כי המשתמש שמפעיל את המערכת לרוב לא מודע בכלל שהוא "תקף" משהו.

Output Validation ו-Insecure Output Handling

מודל שמייצר פלט שמוזן ישירות לפונקציה רגישה - שאילתת SQL, קוד שמורץ, קריאת API - הוא וקטור תקיפה קלאסי אם הפלט לא עובר sanitization. בדיקה זו למעשה מיישמת עקרונות אבטחת אפליקציות web מסורתיים (never trust user input) על פלט המודל עצמו, שצריך להיחשב כקלט לא מהימן בכל פעם שהוא מוזן למערכת downstream.

Jailbreak ו-Policy Bypass Testing

בדיקת עמידות מדיניות התוכן מול טכניקות עקיפה ידועות ומתפתחות - role-play framing, קידוד (Base64, ROT13, שפות זרות), פיצול payload על פני מספר הודעות, ו-"context flooding" שמנסה להטביע את ההנחיות המקוריות בכמות טקסט גדולה.

PII ו-Data Leakage Testing

בדיקה האם המודל חושף בטעות מידע מזוהה מ-training data, מ-context שהוזן קודם בשיחה, או ממקורות RAG שהוא לא אמור לחשוף למשתמש הנוכחי - בעיה חמורה במיוחד במערכות multi-tenant שבהן "זליגה" של context בין לקוחות שונים היא הפרת פרטיות ישירה.

Behavioral Drift: כשאותה בדיקה מפסיקה לעבור בגלל שהמודל השתנה

אתגר ייחודי ל-LLM security testing, שלא קיים בבדיקת תוכנה קלאסית: המודל עצמו יכול להשתנות מתחת לרגליים שלכם בלי שום שינוי בקוד. ספקי מודלים מעדכנים גרסאות באופן שקוף (silent updates), ועדכון כזה יכול לשפר את ההגנה מפני jailbreak מסוים - אבל גם, לפעמים, ליצור התנהגות חדשה שלא נבדקה מעולם. לכן הרנס בדיקת אבטחה צריך לרוץ לא רק כתגובה לשינוי שאתם עשיתם, אלא גם על בסיס תזמון קבוע (למשל יומי), כדי לתפוס רגרסיות שמקורן בצד הספק ולא אצלכם. ארגונים שמסתמכים רק על "run on change" מפספסים את הקטגוריה הזו לחלוטין, ולומדים על הבעיה רק כשמשתמש אמיתי נתקל בה.

ארכיטקטורת הרנס בדיקה: מה בונים בפועל

בדיקת אבטחת LLM איכותית לא מסתכמת בהרצת רשימת prompts זדוניים ידנית - זה לא scalable ולא חוזר על עצמו באמינות. הארכיטקטורה הנכונה כוללת שלושה רכיבים:

• Attack Payload Library - מאגר גדל של payloads מקוטלגים לפי קטגוריה (injection, jailbreak, extraction), עם מקור (ידוע מהספרות, נמצא ב-red team פנימי, דווח על ידי חוקר חיצוני).
• Automated Evaluation Harness - מנוע שמריץ את ה-payloads מול המערכת הנבדקת ומשווה את הפלט מול קריטריון הצלחה/כישלון - לא תמיד binary, לעיתים דורש LLM-as-judge לדרג את חומרת החריגה.
• Regression Gate - שילוב ההרנס ב-CI/CD, כך שכל שינוי במודל, ב-system prompt, או ב-guardrails מריץ אוטומטית את מלוא סט הבדיקות לפני שהשינוי מגיע לפרודקשן.

LLM-as-Judge: היתרון והמלכודת

כשבודקים אם תגובת מודל "הצליחה לעקוף מדיניות", לעיתים קרובות אי אפשר לבדוק זאת עם regex פשוט - צריך שיפוט הקשרי. הפתרון הנפוץ הוא להשתמש במודל שני, "שופט", שמדרג את התגובה הראשונה. זה יעיל וסקיילבילי, אבל טומן בחובו סיכון: השופט עצמו יכול לטעות, להיות מוטה, או אפילו להיות פגיע לאותן טכניקות עקיפה שהוא אמור לזהות. פרקטיקה טובה כוללת כיול תקופתי של השופט מול מדגם שנבדק ידנית על ידי אדם, ומדידת ה-agreement rate בין השופט לבין קונצנזוס אנושי - אם זה נופל מתחת לסף מוגדר (בדרך כלל סביב 85-90%), השופט עצמו זקוק לכוונון מחדש.

Trade-offs: כיסוי מול עלות ריצה

הרצת סוויטת בדיקות אבטחה מלאה (אלפי payloads, לעיתים עם LLM-as-judge שעצמו עולה כסף בכל קריאה) על כל commit היא יקרה מבחינת זמן וכסף. הפתרון המעשי הוא שכבתיות: סט "smoke test" קטן וממוקד (עשרות payloads קריטיים) רץ על כל commit; סט מלא רץ יומית או לפני release; וסט מורחב במיוחד, כולל טכניקות חדשות מהשטח, רץ רק לפני releases גדולים. ההחלטה כמה "עמוק" לרדת בכל שכבה היא איזון ישיר בין עלות תשתית לזמן תגובה לרגרסיות אבטחתיות.

טעויות נפוצות בפרודקשן

הטעות הראשונה: לבדוק רק את המודל הגולמי (base model API call) ולא את המערכת המלאה - כולל guardrails, RAG pipeline, ו-post-processing - למרות שהתוקף האמיתי תמיד תוקף את המערכת השלמה, לא את המודל בבידוד. הטעות השנייה: לבנות ספריית payloads פעם אחת ולא לעדכן אותה - טכניקות jailbreak מתפתחות במהירות (יש קהילות שלמות שמפרסמות payloads חדשים כמעט שבועית), וספרייה שלא מתעדכנת הופכת לא רלוונטית תוך חודשים. הטעות השלישית: להסתמך רק על LLM-as-judge בלי אימות אנושי תקופתי, מה שיכול ליצור false sense of security כשה-judge עצמו מפספס חריגות עדינות.

ניהול ספריית Payloads לאורך זמן

ספריית תקיפות היא נכס חי, לא סטטי, וניהול נכון שלה הוא ההבדל בין הרנס שמדביק את קצב האיומים לבין הרנס שנרקב תוך רבעון. כדאי לנהל אותה כמו קוד: כל payload חדש עובר PR review, מתויג לפי קטגוריית תקיפה וחומרה פוטנציאלית, ומקושר למקור (מאמר אקדמי, דיווח red team, hall of fame ציבורי של jailbreaks כמו jailbreakchat או מאגרים דומים). כדאי גם לתעד "תאריך תפוגה" רעיוני לכל payload - טכניקות רבות מפסיקות לעבוד אחרי שספקי המודלים מתקנים אותן, וספרייה שלא מסננת payloads מיושנים מבזבזת זמן ריצה יקר על בדיקות שכבר לא רלוונטיות, ומקשה על זיהוי הממצאים האמיתיים בתוך רעש.

היבט מעשי נוסף: ספריית payloads טובה צריכה לכלול גם "בדיקות שליליות" - תרחישים שבהם המודל אמור להצליח ולא להיכשל, כדי לוודא שהמערכת לא הופכת שמרנית מדי ומתחילה לחסום בקשות לגיטימיות. הרנס שמודד רק false negatives (תקיפות שעברו) בלי לעקוב גם אחרי false positives (בקשות תקינות שנחסמו בטעות) עלול להוביל לכיוונון יתר שפוגע בחוויית המשתמש בלי לשפר משמעותית את הביטחון בפועל.

מתי כן ומתי לא

כל מערכת production שמזינה קלט משתמשים (ישיר או עקיף) למודל צריכה הרנס בדיקת אבטחה בסיסי לפחות. עבור מערכות בסיכון נמוך (כלי פנימי בלי גישה לנתונים רגישים), סוויטה קטנה שמכסה את הקטגוריות הבסיסיות מספיקה. עבור מערכות שחשופות לציבור או מטפלות בנתונים רגישים, נדרש הרנס מלא עם רענון תקופתי של ספריית ה-payloads ו-CI gate שחוסם deploy במקרה של רגרסיה.

הבחנה בין רגישות (Sensitivity) לחוסן (Robustness)

שני מונחים שקל לבלבל ביניהם אבל מתארים שני דברים שונים: sensitivity testing בודק כמה קל להפעיל את המודל למטרה מסוימת (למשל, כמה ניסוחים שונים גורמים לו לחשוף מידע רגיש), בעוד robustness testing בודק כמה יציבה ההגנה מול וריאציות קטנות של אותה תקיפה (שינוי מילה אחת, הוספת רווח, שינוי סדר משפטים). מודל יכול להיות "רגיש נמוך" (קשה למצוא payload שעובד בכלל) אבל "לא חסין" (ברגע שנמצא payload אחד שעובד, וריאציות קלות שלו עדיין עוברות) - וזה בדיוק התרחיש המסוכן ביותר, כי תוקף שמצא נקודת כניסה אחת מקבל בפועל משפחה שלמה של תקיפות דומות שממשיכות לעבוד. הרנס בדיקה טוב מודד את שני הצירים בנפרד, ולא מסתפק במדד יחיד של "אחוז הצלחה כולל".

איך אנחנו ניגשים לזה

במדיה דיל אנחנו בונים הרנס בדיקת אבטחה כחלק אינטגרלי מה-CI/CD בכל פרויקט AI - לא ככלי נפרד שרץ מדי פעם - כדי ששינוי ב-prompt או במודל שמכניס רגרסיה אבטחתית ייתפס לפני שהוא מגיע ללקוחות, לא אחרי.

קשר ל-Threat Modeling ולתוכנית ה-Red Team הרחבה

LLM security testing לא פועל בבידוד ארגוני - הוא הצינור הטכני שמיישם ממצאים מתהליכי threat modeling ו-red teaming כבדיקות אוטומטיות וחוזרות. תרחיש תקיפה שזוהה כרלוונטי בשלב ה-threat modeling (למשל, "תוקף עם גישה לתוכן שמוזן ל-RAG יכול להשפיע על החלטות המודל") צריך להפוך לפריט מוגדר בספריית ה-payloads, כדי שהוא ייבדק בכל release ולא רק פעם אחת בזמן הביקורת המקורית. הקשר הזה - בין השכבה האסטרטגית (מה עלול לקרות) לשכבה הטכנית (איך בודקים שזה לא קורה) - הוא מה שהופך תוכנית אבטחת AI משלוש פעילויות נפרדות למערכת אחת מתואמת.

סיכום

LLM Security Testing הוא ההרחבה הטכנית שממירה עקרונות red teaming לתהליך אוטומטי, חוזר, ובר-CI. ארכיטקטורה נכונה כוללת ספריית payloads מתעדכנת, הרנס אוטומטי עם LLM-as-judge מכויל, ואינטגרציה כשער חובה לפני כל שינוי משמעותי - כדי שבדיקת אבטחה תדביק את קצב השינוי של מערכות AI מודרניות, לא תפגר אחריו.

תגיות: LLM Security Testing · prompt injection · jailbreak testing · LLM-as-judge · CI/CD security · guardrails · AI evaluation

← חזרה לבלוג · צור קשר