OWASP ZAP: DAST ב-CI/CD עם סינון התראות שווא

OWASP ZAP בצינור: מדוע הסורק שוקע בהתרעות שווא

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

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

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

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

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

ניתוח דינמי בצינור: אפקט מדיד

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

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

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

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

מצבי הרצה של הסורק הדינמי: מתי מה מתאים

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

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

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

הגדרת בדיקות בצינור: מביקורת ועד מסירה

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

1. ביקורת הצינור. בוחנים שלבי בנייה ופריסה, זמן כל אחד והנקודות שבהן מוקם מעמד הבדיקות; מחפשים מקום לסריקה בלי לגדול זמן ההרצה.
2. היקף הסריקה. קובעים כתובות ותפקידים בהיקף, מה מוחרג (סטטי, שירותי צד שלישי), אילו חשבונות מקבל הסורק.
3. הגדרת כללי הסורק. מתאימים סט כללים וספים לסוג האפליקציה, מפעילים הקשר וכניסה תחת חשבון — נבדקים מדורים סגורים ולא רק טופס הכניסה.
4. סינון התרעות שווא. מסמנים רעש מאושר ומנהלים קובץ חריגים עם נימוק; מחזירים כלל אם התנאים השתנו.
5. מצבי הרצה. סט מהיר — על כל שינוי ענף, סריקה מלאה — לפי לוח זמנים; הבנייה נופלת רק על ממצאים חדשים ברמה גבוהה.
6. בדיקת התוצאה. מריצים את הסכמה על מעמד עם פגיעות שהוחדרה במכוון: בעיה ידועה נתפסת, רעש מוחרג אינו צף.
7. מסירה לצוות. מוסרים קונפיגורציה, נוהל עדכון כללים וסדר ניתוח: מי בוחן את הדוח, בתוך אילו זמנים סוגר ממצאים, כיצד משנה ספים.

כללי סינון התרעות שווא ותצורה בסיסית

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

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

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

מקרה בוחן: כיצד הוסר הרעש מדוחות הסורק

לפני ההטמעה OWASP ZAP הורץ ידנית פעם בשבועיים, והדוח נשמר בתיקייה משותפת. הרצה טיפוסית הניבה כ-400 ממצאים, לאחר ניתוח ידני נותרו 25–30 אמיתיים — שיעור התרעות השווא עמד על 85%. המהנדסים השקיעו בניתוח יומיים, השחרור נדחה, והתרגלו לא להסתכל בדוח: "שוב אותה רשימה".

מה הוגדר

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

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

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

תוצאה

שיעור התרעות השווא — כ-10%, בדוח 25–35 ממצאים במקום 400. הניתוח נמשך שעה וחצי עד שעתיים במקום יומיים, הסריקה על מיזוג נכנסת לדקות ואינה מאטה את הצינור. פגיעויות מאושרות נסגרות לפני שחרור: במשך רבעון אף ממצא ברמה גבוהה לא הגיע לפרודקשן.

במה OWASP ZAP שונה מניתוח קוד מקור

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

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

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

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

בחירת שיטת הבדיקה נקבעת לפי השלב: בדיקת קוד — בכניסה לצינור הבנייה, בדיקת אפליקציה — לפני שחרור. אם נדרשת תשובה לשאלה "האם החור מנוצל", אותה נותן OWASP ZAP; אם "מדוע הוא הופיע" — ניתוח קוד המקור.

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

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

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

האם נדרש מעמד נפרד לבדיקות?

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

כיצד לבדוק מדורים מאחורי אימות?

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

אצלנו כבר פרוס סורק — מה ישתנה?

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

נדון במשימה: מה לשלוח להערכה

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

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

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