אינטגרציה של SAST (בדיקת אבטחה סטטית של יישומים) בצינור CI/CD

SAST בצינור הבנייה: מדוע פגיעויות מגיעות עד לשחרור

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

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

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

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

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

מה משתנה לאחר הטמעת הבדיקות בבנייה

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

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

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

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

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

אפשרויות הרצה של SAST: בנייה, שינויים, לוח זמנים

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

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

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

הטמעה שלב אחר שלב: ממלאי ועד מסירה

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

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

קונפיגורציות, כללים ונהלים: מה מוסרים

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

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

מקרה בוחן: בדיקות בבנייה קיצרו את ניתוח הפגמים פי שלושה

מה היה לפני בדיקות הבנייה

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

כיצד הוגדרו הספים

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

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

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

SAST או ניתוח דינמי: מה לבחור בהתחלה

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

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

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

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

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

ספקות נפוצות: התרעות שווא ומהירות הבנייה

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

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

בכמה תאט הבדיקה?

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

יש לנו אלפי הערות ישנות — מהיכן להתחיל?

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

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

נדון במשימה: נקודות הטמעה וסדר השלבים

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

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

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