הגדרת סריקת תמונות Docker באמצעות Snyk Container

סריקת תמונות Docker: היכן נשברת אבטחת הבנייה

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

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

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

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

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

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

מה מודדים: זמן עד תיקון ושיעור בניות נקיות

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

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

סוגי פגיעויות שיוצאים מזרימת המהדורה

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

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

מאגר ממצאים במקום דוחות מפוזרים

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

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

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

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

איך מצבים משתלבים בצינור אחד

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

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

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

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

ביקורת הצינור ומיפוי שכבות הבסיס

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

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

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

קונפיגורציות, מדיניות חסימה ותיעוד לתמונות

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

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

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

נוהל תגובה לממצאים בסביבת הייצור

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

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

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

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

מדדים לפני ואחרי ההטמעה

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

במה שונה Snyk Container מבדיקות מובנות במאגר?

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

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

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

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

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

מגבלות הגישה וספקות נפוצים לפני התחלה

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

איזו גישה נדרשת למאגרים?

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

מה עושים עם התראות שווא?

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

מה עושים עם שכבות בסיס של אחרים?

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

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

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

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

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

אחרי הדיון נשלח:

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

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