אבטחת קונטיינרים: הטמעת Trivy ב-CI/CD

פגיעויות בתמונות קונטיינר: היכן נשבר Trivy CI/CD

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

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

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

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

מה נותנת סריקת תמונות ב-Trivy CI/CD

שליטה בפגיעויות בכל קומיט

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

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

הבנייה מתארכת בשניות, לא בדקות

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

חסימת הפצה לפי סף

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

הרג'יסטרי מפסיק לגדול

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

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

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

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

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

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

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

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

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

חבילת מסירה: מדיניות, תצורות ותיעוד

לאחר המסירה נשארת במאגר כל התשתית סביב Trivy: לא רק בדיקות שמופעלות ב-CI/CD, אלא גם תצורה, מדיניות ונהלים. כל זה מנוהל בגרסאות לצד הקוד ומשתנה דרך ביקורת שינויים רגילה, ולא דרך התכתבות עם הספק.

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

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

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

מה שינו

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

מה קרה בפועל

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

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

במה שונה בדיקה ברג'יסטרי מבדיקה בבנייה?

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

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

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

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

ספקות טכניים של מהנדסים: מפרקים התנגדויות

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

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

כיצד מנוסחים חריגים בכללים?

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

האם זה עובד בסביבה סגורה?

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

היכן גבול האחריות?

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

נדון במשימה ונחזור עם אומדן ותוכנית עבודה

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

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

בהמשך נחזור לא עם «צריך ליישם Trivy» כללי, אלא עם תוכנית שבה כל סעיף ניתן לבדוק ולאשר:

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

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