ניתוח SCA ב-CI: OWASP Dependency-Check עם מטמון והשתקה

OWASP Dependency-Check בבנייה: היכן צוואר הבקבוק

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

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

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

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

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

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

מה משתנה לאחר הטמעת בקרת SCA

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

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

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

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

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

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

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

כיצד המצבים משתלבים

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

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

סדר ההטמעה: מביקורת ועד מסירה

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

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

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

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

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

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

מקרה בוחן: כיצד השתנו זמן הבנייה ומספר ההתראות

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

מה שינו

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

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

מה קרה

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

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

במה Dependency-Check שונה מבדיקת רישיונות?

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

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

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

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

ספקות טכניים: מטמון, רעש, עדכון המסד

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

הבנייה רצה בלי יציאה לרשת החיצונית — האם עדכון אפשרי?

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

לא ניתן לעדכן ספרייה — האם הרעש יישאר לנצח?

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

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

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

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

חשוב במיוחד אופי הפרויקט — מונורפו עם מאות תלויות טרנזיטיביות ושירות קטן עם עשרה ספריות ישירות דורשים מצב הרצה שונה של OWASP Dependency-Check ועומק שונה של מטמון מסד החולשות.

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

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