שילוב סריקת אבטחת קונטיינרים ב-CI/CD

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

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

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

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

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

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

מה נותנת בדיקה מוקדמת של אימג'ים בצינור

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מקרה בוחן: איך הוציאו אימג'ים פגיעים מהפריסה

מה היה

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

מה שינו

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

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

במה בדיקת אימג' בסיס שונה מבדיקת שכבות?

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

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

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

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

ספקות טכניים נפוצים לפני הטמעת בדיקות

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

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

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

מה עושים עם אימג'ים שכבר פורסמו?

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

אפשר לבדוק אימג'ים חיצוניים של ספק?

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

נצטרך להחליף את כלי הסריקה שלנו?

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

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

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

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

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

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

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