מדוע DAST מופעל באיחור ופגיעויות מגיעות לשלב השחרור
סריקה דינמית של יישומים אצל רוב הצוותים מתקיימת בנפרד מצינור הבנייה והאספקה. היא מופעלת ידנית — לפני שחרור גדול או לאחר שקבלן חיצוני הביא דוח נוסף. הניתוח הסטטי לעומת זאת נמצא בתהליך הבנייה ומעכב מיזוג שינויים, בעוד ש-DAST נשאר הליך חד-פעמי בצד.
הסיבה ברורה: סורק דינמי זקוק לסביבת בדיקה פרוסה, חשבונות משתמש לתפקידים שונים ונתוני בדיקה מלאים. הרמת סביבה כזו על כל שינוי נראית יקרה מדי, ולכן הבדיקה נדחקת לסוף המחזור — כשהאפליקציה כבר בנויה במלואה ו"כמעט מוכנה".
המחיר של חיסכון כזה — פגיעויות בסביבת הייצור. הממצא מגיע כשהקוד כבר נמסר למשתמשים, וצריך לסגור אותו בשחרור לא מתוכנן: תיקון דחוף, בנייה מחדש, הרצה ידנית של התרחישים שנפגעו. החלון בין הופעת הפגם לתיקונו נמתח לשבועות, וחלק מהבעיות כבר נראות מבחוץ בשלב הזה.
ההשפעה השנייה — בדיקת האבטחה לפני שחרור הופכת לאישור חד-פעמי. את הדוח קוראים לאחר הפריסה, סדרי עדיפויות נקבעים לפי אינטואיציה, ופגמים חוזרים עוברים משחרור לשחרור. בהמשך נפרט כיצד זה נסגר: מה נדרש כדי שסריקה דינמית תעבוד בתוך הצינור המשותף ותספק תוצאה לפני הפריסה.
האפקט של חיפוש פגיעויות בכל בנייה של הצינור
סריקה אוטומטית בכל בנייה מקצרת את החלון בין הופעת הפגיעות לגילויה משבועות לשעות. בזמן שסביבת הבדיקה עולה לאחר הפריסה, OWASP ZAP סורק את האפליקציה במצב סריקה אקטיבית ומניח את הדוח באותה הרצה כמו הבדיקות האוטומטיות. המפתח מקבל את הפגם בהקשר של השינוי שלו, ולא כעבור חודש בקבלה.
זה משנה את מבנה הממצאים. שיעור הפגיעויות שנתפסות לפני שחרור עולה בדרך כלל ממחצית לתשע מתוך עשר — השאר נובע מלוגיקת הרשאות שהסורק אינו בודק. סוג הכשלים שנסגר לחלוטין: נתיבים נגישים ללא אימות, כותרות אבטחה חסרות, ספריות מיושנות עם פגמים ידועים.
גילוי מוקדם של פגיעויות מפחית בדיקות ידניות לא על חשבון איכות, אלא הודות לכיסוי שיטתי. המהנדס מפסיק לעבור ידנית על תרחישים טיפוסיים ומתרכז בתפקידים ובמצבי קצה. זמן אספקת השינויים יורד, כי הבדיקה מתבצעת במקביל לבנייה ואינה דורשת שלב אישור נפרד.
מדדים שלפיהם רואים את האפקט: זמן מהשינוי ועד לדוח הסורק הראשון, שיעור הבניות עם ממצאים, יחס בין פגמים שנסגרו לפגמים שנפתחו בשבוע, מספר הבדיקות הידניות לשחרור. אם המספרים האלה לא זזים — הצינור מוגדר פורמלית, וזה הדבר הראשון שאנחנו בוחנים בביקורת.
מצבי הפעלה של DAST: בנייה, לוח זמנים, הרצה ידנית
ניתוח דינמי עובד לא עם קוד המקור, אלא עם אפליקציה פועלת: כל עוד סביבת הבדיקה אינה מגיבה לבקשות ואינה מאפשרת כניסה עם חשבון משתמש, לסורק אין מה לבדוק. לכן מצב ההפעלה נבחר לפי זמינות הסביבה ולפי כמה זמן ההרצה יכולה לתפוס בצינור — ולא לפי נוחות ההגדרה.
| מצב הפעלה | מתי מתאים | מגבלות ומחיר תחזוקה |
|---|---|---|
| לפי אירוע בנייה | נדרש אות מהיר על כל שינוי: סביבת פיתוח, נתיבים מרכזיים, כותרות אבטחה | ההרצה תופסת את הצינור, התראות שווא מעכבות שחרור — נדרשים דוח בסיס ורשימת חריגים |
| לפי לוח זמנים | סריקה עמוקה בלילה של העתק סביבת הייצור, כולל בדיקות אקטיביות | הסביבה חייבת לפעול באופן קבוע, ומישהו מנתח את הדוח בבוקר |
| הרצה ידנית | לפני שחרור גדול, לאחר שינוי בסכימת האימות, בעת חיבור סביבה חיצונית | אין סדירות: בין הרצות הממצאים מצטברים בלי ששמים לב |
| היברידי: הרצה קצרה בבנייה ובנוסף סריקה עמוקה לפי לוח זמנים | שחרורים תכופים בשירותים עם אזור אישי ותשלומים | יקר יותר בהגדרה: שני פרופילים, הפרדה בין סביבות, נקודת ניתוח אחודה לממצאים |
הדרישות לסביבה בכל המצבים זהות: הסורק זקוק לחשבון משתמש עם הרשאת סריקה, סביבה עם נתונים ניתנים לשחזור ודוח בסיס על ממצאים ידועים. בלי זה כל בנייה תהיה אדומה, והצוות יפסיק לפתוח את הדוח — ללא קשר למצב שנבחר.
הסדר המעשי הוא כזה: תחילה מרימים הרצה ידנית וקובעים מה הסורק בכלל רואה באפליקציה שלכם, אחר כך מעבירים אותו ללוח זמנים, ורק לאחר מכן מוסיפים הפעלה לפי אירוע בנייה עם פרופיל מצומצם. מעבר כזה נותן בדיקות סדירות מבלי להפוך את הצינור לצוואר בקבוק.
כיצד אנו מטמיעים DAST בצינור: שלבי העבודה
הטמעת DAST מתחילה לא מהסורק, אלא מהקמת מלאי: אילו שירותים וסביבות אנחנו בודקים, באילו תפקידים אנחנו נכנסים, אילו נתיבים קריטיים לעסק. בלי זה הסורק נתקע בטופס הכניסה ומחזיר דוח על עמוד אחד — בדיקה פורמלית יש, תועלת אין.
- מלאי יעדים. רשימת כתובות, חשבונות בדיקה לכל תפקיד, מגבלות עומס וחלון הפעלה בטוח לסביבה.
- סכימת הפעלה. בדיקה קצרה רצה על כל שינוי לאחר הפריסה, מלאה — לפי לוח זמנים. משוב מגיע בדקות, ולא עד סוף השבוע.
- הגדרת תרחישי סריקה. כניסה למערכת, חידוש סשן, סריקה לפי מפרט API וסריקת ממשק: טפסים, פרמטרים, שדות נסתרים שאינם במפרט.
- סינון רעש. חריגים נרשמים עם נימוק ותאריך בחינה מחודשת, ממצאים מחולקים למאושרים וכזאלה הדורשים בדיקה ידנית. אחרת את הדוח מפסיקים לקרוא כעבור חודש.
- סף איכות הבנייה. חוסמים רק פגיעויות מאושרות ברמה גבוהה בנתיבים קריטיים, השאר עובר כאזהרה. את הסף מתאמים עם הפיתוח: סף קפדני מדי מכבים מהר.
- בדיקה על פגיעויות בקרה. שותלים בסביבה פגיעות מכוונת ומוודאים שהיא נכנסה לדוח. לא נכנסה — מתקנים את התרחיש, ולא את האמון בכלי.
- נוהל טיפול בממצאים. קובעים מי ובאיזה מועד מנתח את הדוח, לאן עוברת המשימה, כיצד מאושר הסגירה. הדוח של כל הרצה נשמר בארטיפקטים של הבנייה.
לאחר מסירת הנוהל הצינור עובד בלעדינו: שירותים חדשים מתווספים לסכימה לפי רשימת תיוג, וסף האיכות נערך במקום אחד.
ארטיפקטים של הטמעה: הגדרות, סכמות, נהלים
לפני הפעלת DAST בצינור אנחנו מתעדים את כל הנדרש לעבודה ניתנת לשחזור: אחרת הסורק מחזיק מעמד עד החלפת הבעלים של הסביבה או עד התראת השווא הראשונה, שאחריה מכבים את הבדיקה. בתום העבודה הלקוח מקבל לא דוח של הרצה חד-פעמית, אלא ערכה עובדת — מקונפיגורציות ועד נוהל טיפול בממצאים.
- קונפיגורציות הפעלה של הסורק: פרופילים נפרדים לבדיקה מהירה בכל בנייה ולהרצה מלאה לפני שחרור, חיבור לשלב בצינור, ספים שבהם הבנייה נעצרת.
- סכימת פריסה: היכן הסורק נפרס, כיצד הוא ניגש לסביבת היעד, אילו חשבונות שירות וכללי רשת נדרשים.
- מדיניות גישה לסביבות: חשבונות לסריקה עם אימות, הגבלת קצב בקשות וחלונות הרצה, כדי שהבדיקה לא תפריע לבדיקות עומס ובדיקות ידניות.
- כללים לסינון התראות שווא: רשימת חריגים עם נימוק ותאריך בחינה מחודשת, סימון ממצאים ידועים — פגמים חדשים לא טובעים ברעש.
- מפת כיסוי: אילו נתיבים ותפקידי משתמשים נבדקים, מה הושאר במודע מחוץ לאזור הסריקה.
- נוהל טיפול בממצאים: רמות חומרה, זמני תגובה, מי מאשר את הפגם ומי סוגר, כיצד הממצא הופך למשימת פיתוח.
- תיעוד והעברה: הוראות הפעלה וניפוי שגיאות, ניתוח שגיאות אופייניות, הדרכת הצוות והעברת הבעלות.
את הנוהל מוסרים יחד עם גישות וביאור בהרצה אמיתית — כדי שפרופילים, חריגים וספים ישתנו בלעדינו.
מקרה בוחן: כיצד ביקורת חד-פעמית הפכה לבדיקה יומית
הלקוח — שירות תשלומים המורכב מעשרה שירותים מאחורי שער משותף. בדיקות אבטחה הוזמנו פעם ברבעון: הביקורת נמשכה שבועיים-שלושה, הדוח הגיע כמסמך נפרד, וחלק מהממצאים — נקודת קצה לניפוי שגיאות פתוחה, כותרות שנשכחו, תלות מיושנת — צפו כבר אחרי השחרור ודרשו פריסה לא מתוכננת.
מה שינו
את הסורק OWASP ZAP פרסו במצב ניתוח אוטומטי והכניסו לצינור הבנייה: ההרצה מתחילה בכל מיזוג לענף הראשי. הסביבה עולה עם אותן מיגרציות כמו בפרודקשן, הסריקה מתבצעת לפי מפת נתיבים, והתוצאה מושווית לקו הבסיס — פגם חדש נראה על רקע הידועים. ממצאים קריטיים עוצרים את הבנייה, השאר עוברים לטרקר עם קישור לקומיט ולמחבר השינוי.
מדדים לפני ואחרי
- בדיקות ידניות: פעם ברבעון → הרצה אוטומטית בכל מיזוג ובבניות לילה.
- זמן מהופעת הפגם ועד גילויו: שבועיים-שלושה → שעות, באותו יום.
- שיעור הממצאים שנסגרו לפני שחרור: 55% → 96%; השאר — חריגים מודעים עם רישום בקו הבסיס.
- התראות שווא: לאחר הגדרת הכללים הרעש פחת פי שלושה בערך, והדוחות הפסיקו להיקרא במלואם.
את הביקורת הידנית לא ביטלו: היא נשארה לתרחישי הרשאה וללוגיקה של פעולות עסקיות שהסורק אינו בודק. ההרצה היומית מכסה את הרקע השוטף, ולכן הבדיקה החיצונית כבר לא מבזבזת זמן על המובן מאליו.
במה DAST שונה מ-SAST ומה להפעיל קודם
ניתוח דינמי וסטטי מסתכלים על מצבים שונים של המערכת, ולכן אינם מחליפים זה את זה, אלא מכסים סוגי פגמים שונים — אלה ש-OWASP מפרט. ניתוח סטטי מנתח קוד מקור וקונפיגורציה כטקסט: אין לו צורך בסביבה פרוסה, הבדיקה מסתיימת בדקות ויכולה לרוץ על כל שינוי.
הניתוח הדינמי שולח בקשות אמיתיות לאפליקציה פועלת ומוצא את מה שלא רואים בקוד: עקיפת אימות על ידי החלפת מזהה, שגיאות בהרשאות תפקידים, כתובות שירות נגישות.
| בדיקה | מקום בצינור | מה מאתר | מה אינו רואה |
|---|---|---|---|
| ניתוח סטטי | בכל שינוי, לפני מיזוג לענף הראשי | מבנים מסוכנים בקוד, דליפות סודות, תלויות פגיעות | לוגיקת החיבור בין שירותים, התנהגות תחת סשן זר ותחת עומס |
| ניתוח דינמי | בסביבת בדיקה: הרצת לילה וצעד לפני שחרור | שגיאות הרשאה, קונפיגורציית סביבה, תגובות אמת של שירותים | ענפי קוד שתרחיש הסריקה לא נגע בהם |
סדר החיבור נקבע לפי מחיר המשוב. הניתוח הסטטי עונה בדקות, לכן שמים אותו ראשון — כבדיקה מחייבת על שינוי בענף. הניתוח הדינמי דורש סביבה פרוסה עם נתוני בדיקה ורץ זמן ארוך יותר, ולכן מוציאים אותו מהמחזור המהיר להרצת לילה ולשלב מחייב לפני שחרור.
עדיפות ההטמעה כשהצוות פנוי רק במידה מוגבלת: תחילה ניתוח סטטי על שינוי, אחר כך ניתוח דינמי לפני כל שחרור, ואחר כך הרחבת התרחישים לתפקידים מאומתים. כל עוד הבדיקות לא מוטמעות בצינור, הן נשארות פעולה חד-פעמית — והרצה סדירה הופכת אותן לתהליך מנוהל.
ספקות טכניים: רעש, כניסה למערכת, סביבות בדיקה
רוב הספקות סביב DAST מצטמצמים לארבע שאלות: כמה התראות שווא יהיה צריך לנתח ידנית, כיצד הסורק עובר את טופס הכניסה, מה הוא רואה בסביבת הבדיקה ובכמה יאריך את הבנייה. תשובות קצרות — בהמשך.
התראות שווא — כמה יהיו?
רעש נוצר מזריקות עיוורות, תבניות עם הזרקות סקריפטים וסכימות אימות עצמאיות. אנחנו מכבים כללים שטועים באופן עקבי בטכנולוגיה מסוימת, ומאשרים כל ממצא בבקשה חוזרת מנקודה אחרת. לדוח נכנסות פגיעויות עם תרחיש ניתן לשחזור, ולא רשימת השערות.
כיצד הסורק עובר אימות?
פרטי החשבון מוזרקים ממאגר סודות, שרשרת ההפניות חוזרת על עצמה, הסשן נשמר, ובפקיעת תוקף הטוקן הכניסה מתבצעת מחדש בלי מגע יד. אנחנו לוקחים תפקידים שונים — אורח, משתמש, מנהל: כך נתפסת גם עקיפת בקרת גישה, ולא רק טפסים פתוחים.
מה יגיע לסביבת הבדיקה?
הסביבה מתמלאת בהעתק מוסווה של מסד הנתונים, הגישה מוגבלת לזמן ההרצה ולכתובות של סוכני הבנייה, לאחר הסריקה הסביבה נוצרת מחדש. הבדיקות נשארות ניתנות לשחזור בין הרצות, ונתונים אישיים לא נכנסים למתחם.
בכמה זה מאריך את הבנייה?
הרצה מלאה ארוכה באופן ניכר מבדיקות מודולריות, ולכן המצבים מופרדים: פרופיל מהיר על נתיבים קריטיים — בכל קומיט, מורחב — לפי לוח זמנים ולפני שחרור. הסריקה מתבצעת במקביל לשלבים אחרים ואינה חוסמת את הבנייה עד לממצא מאושר.
נדון במשימה: נבנה סכימת בדיקות לצינור שלכם
כדי שהשיחה תהיה עניינית, הביאו תיאור של איך בנוי הצינור שלכם כעת. אין צורך במפרט טכני מוכן — די בנתוני פתיחה שמהם רואים היכן הניתוח הדינמי (DAST) ישתלב בלי לעצור שחרורים.
- כיצד הבנייה מופעלת ואילו סביבות עולות אוטומטית — מסביבת בדיקה ועד קדם-ייצור.
- היכן הגיוני להציב את הבדיקה: מיד לאחר פריסה לסביבה, לפי לוח זמנים מחוץ לשעות העבודה או ידנית לפני שחרור.
- אילו שירותים עולים בסביבה מבודדת והאם נדרשות להם תלויות חיצוניות — מסדי נתונים, תורים, שירותי צד שלישי.
- האם יש חשבונות בדיקה ונתונים כדי שהבדיקה תעבור אימות ולא תיתקע בטופס הכניסה.
- באיזה אופן נוח לצוות לקבל את התוצאה — משימה בטרקר, קובץ בארטיפקטים של הבנייה או סיכום בלוח בקרה.
- מי מנתח את הממצאים ולפי איזה סף הבנייה נחשבת לכושלת: ממצא בודד או שיעורם מכלל הנתיבים.
בתגובה אנחנו מביאים תוכנית הטמעה של בדיקות: סכימת מיקום השלבים בצינור, דרישות לסביבה, ספי הפעלה והערכת לוחות זמנים. תארו את המשימה בדרך הנוחה לכם — שיחת זום, התכתבות, גישה למאגר — ונחזור עם הערכה ותוכנית.