סריקת אבטחה לקונטיינרים: מה שאתם לא בודקים לפני Deploy

מאת צוות מדיה דיל · 04.07.2026 · אבטחת מידע · 5 דק׳

סריקת Image ב-CI, שכבות Docker, Base Image מינימלי ו-Distroless, הרצה כ-root, Trivy ו-Grype, Runtime Security עם Falco, ו-Admission Control.

כשבונים container image, כל FROM base-image:tag מביא איתו לא רק את הספרייה שרציתם אלא עולם שלם של OS packages, ספריות מערכת וכלים שאתם כנראה אפילו לא יודעים שקיימים בתוך ה-image שלכם. בלי סריקה שיטתית, ה-image שרץ ב-production יכול לכלול עשרות CVE ידועות בגרסאות ישנות של openssl, glibc או bash - חולשות שכבר יש להן patch זמין, פשוט אף אחד לא בדק שהוא לא נמצא בתוך ה-image. סריקת אבטחה לקונטיינרים היא לא שלב אופציונלי, היא תנאי סף לפני כל deploy רציני.

image הוא ערימה של שכבות, לא בלוק אחיד

כל הוראת Dockerfile יוצרת שכבה (layer) חדשה שנוספת מעל הקודמת, ולעיתים קרובות שכבה שנמחקה מאוחר יותר בקובץ עדיין קיימת פיזית בהיסטוריית ה-image ונגישה לכל מי שיריץ docker history או יחלץ את השכבות. זה אומר שאם מישהו הריץ COPY secrets.json ואז RUN rm secrets.json בשלב מאוחר יותר, הקובץ עדיין נמצא בתוך ה-image - רק לא בקובץ המערכת הסופי הנראה לעין. סורקים טובים בודקים כל שכבה בנפרד, בדיוק בשביל לתפוס את זה.

Base Image מינימלי - כל חבילה מיותרת היא משטח תקיפה

image מבוסס ubuntu:latest מגיע עם shell, package manager, ומאות binaries שהאפליקציה שלכם כנראה לא צריכה בכלל, וכל אחד מהם הוא קוד נוסף שיכול להכיל חולשה. Distroless images מסירים לחלוטין package manager, shell ו-utilities מיותרים ומשאירים רק את ה-runtime הנדרש, מה שמצמצם את משטח התקיפה בסדרי גודל ומקשה מאוד על תוקף שכבר השיג execution לבצע recon בתוך הקונטיינר. Alpine, המבוסס על musl libc, הוא פשרה קלה משקל אבל דורש בדיקת תאימות ספריות לפני מעבר אליו.

הרצה כ-root היא סיכון בחינם שקל להימנע ממנו

ברירת המחדל של רוב ה-base images מריצה את התהליך הראשי כ-root בתוך הקונטיינר, ולמרות ש-namespace isolation אמור להגביל את ההשפעה על ה-host, container breakout שמנצל חולשה ב-runtime (כמו runc) הופך משמעותית יותר מסוכן כשהתהליך שנפרץ רץ כ-root. הוספת USER בשורת ה-Dockerfile כדי להריץ עם משתמש לא-פריווילגי היא שינוי של שורה אחת שסוגר קטגוריה שלמה של אסקלציות פוטנציאליות, ו-Kubernetes עם Pod Security Standards יכול אף לאכוף את זה כמדיניות חובה.

Shift-Left - סריקה לפני שה-image בכלל נדחף לרג'יסטרי

הגישה היעילה ביותר היא לסרוק בתוך ה-CI pipeline, מיד אחרי ה-build ולפני push לרג'יסטרי, עם כלים כמו Trivy, Grype או Snyk Container שמשווים את רשימת החבילות ב-image מול מסדי CVE מעודכנים. סריקה בשלב הזה עוצרת את הבעיה כשהיא עדיין זולה לתקן - לפני שה-image הגיע לרג'יסטרי, נמשך לענפים אחרים, ונפרס בסביבות מרובות. מדיניות נפוצה היא לחסום build כולו אם נמצאה חולשה בחומרה CRITICAL עם patch זמין, ולתת אזהרה בלבד על חולשות בחומרה נמוכה יותר.

Runtime Scanning - מה שסטטי לא תופס

סריקה סטטית בודקת מה יש ב-image, אבל לא תופסת התנהגות חריגה בזמן ריצה - קונטיינר שפתאום פותח חיבור רשת יוצא לכתובת לא מוכרת, או מריץ תהליך שלא היה חלק מה-image המקורי בכלל, סימן אפשרי ל-container שנפרץ אחרי ה-deploy. כלי runtime security כמו Falco עוקבים אחרי syscalls בפועל ומתריעים על סטייה מהתנהגות בסיסית, שכבת הגנה משלימה שתופסת גם ניצול של חולשת יום-אפס שאין לה עדיין חתימה במסד נתונים.

אכיפה ב-Admission Control - לא סורקים, חוסמים

הצעד האחרון הוא לחבר את תוצאות הסריקה למדיניות אכיפה אוטומטית ברמת ה-cluster, כך שקונטיינר שלא עבר סריקה או שנמצא בו CVE קריטי פשוט לא יכול להיפרס, גם אם מישהו ניסה לדלג על ה-CI pipeline. זה חלק מהעקרונות שקשורים גם לאבטחת שרשרת האספקה הכללית - וידוא שכל artifact שמגיע ל-production עבר שרשרת אימות שלמה, ולא רק שהוא "נראה בסדר" בזמן שנכתב.

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

תגיות: Container Security · Image Scanning · CVE · Distroless · Trivy · Admission Control

← חזרה לבלוג · צור קשר