הגדרת סריקת אימג'ים של Docker באמצעות Grype/Syft

סריקת אימג'ים באמצעות Grype: היכן אובדות הפגיעויות

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

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

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

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

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

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

מה נותנת סריקה סדירה של אימג'י Docker

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

חלון הפגיעות מתכווץ למחזור בנייה אחד

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

קבלת מהדורה ידנית נעלמת

מדיניות לפי רמות חומרה («קריטיות — עצירת בנייה, גבוהות — אזהרה ורישום בדוח») נותנת הכרעה פורמלית במקום סקירת הרשימה בעיניים. המהדורה либо עוברת, либо נופלת עם ציון החבילה והשכבה המדויקות — קבלת המהדורה מפסיקה להיות צוואר בקבוק ואינה תלויה במי שתורן היום.

רשימת ממצאים אחודה בכל הרישומים

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

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

גישות לסריקת אימג'ים: השוואת אפשרויות

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

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

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

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

הטמעת Grype בצינור בניית האימג'ים: שלבי העבודה

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

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

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

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

מדיניות סריקה, נהלים וספי חסימה

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

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

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

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

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

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

מה היה לפני ההטמעה

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

מה שינו

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

מה נהיה

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

במה נבדלת סריקת שכבות מבדיקת מערכת הקבצים?

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

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

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

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

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

מגבלות טכניות ושאלות בנושא סריקת אימג'ים

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

מה לעשות עם פגיעויות שאין להן תיקון?

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

כיצד לחתוך התראות שווא?

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

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

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

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

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

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

לאחר התחקיר תקבלו:

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

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