בדצמבר 2021 גילה העולם שספריית רישום לוגים אנונימית בשם Log4j, שרצה בתוך מאות אלפי מערכות, מאפשרת לכל תוקף להריץ קוד מרחוק באמצעות שורת טקסט אחת. הפגיעות, שקיבלה את השם Log4Shell ואת הציון המקסימלי 10.0, הפכה לאירוע האבטחה המשמעותי של העשור – אבל הלקח האמיתי שלה אינו על ספרייה אחת. הוא על שאלה שרוב הארגונים עדיין לא יודעים לענות עליה: איזה קוד בכלל רץ אצלכם? מי שלא ידע לענות אז חיפש את Log4j בעיוורון במשך שבועות. מי שלא יודע לענות היום – יחזור על זה ב-CVE הקריטי הבא.
עיקרי הדברים
- ✓ Log4Shell (CVE-2021-44228) – פגיעות הרצת קוד מרחוק בספריית Log4j, עם ציון CVSS של 10.0, שסריקות ממשיכות לאתר גם שנים אחרי הגילוי
- ✓ הבעיה האמיתית היא שקיפות – הספרייה ישבה עמוק בתוך תלויות של תלויות, וארגונים לא ידעו בכלל שהיא אצלם
- ✓ SBOM הוא רשימת המרכיבים של התוכנה – מלאי מתועד של כל ספרייה ורכיב, שהופך חיפוש של שבועות לשאילתה של דקות
- ✓ סורק תלויות לא סוגר את התמונה – הוא מזהה רכיבים פגיעים, אבל לא מוכיח ניצול בפועל ולא רואה את הקוד שלכם ואת התצורה
מה קרה ב-Log4Shell ולמה זה עדיין רלוונטי
Log4j היא ספריית קוד פתוח של Apache לרישום לוגים ביישומי Java – אחת הספריות הנפוצות בעולם, שמוטמעת בשרתי אפליקציות, במוצרי אבטחה, במערכות ענן ובתוכנות מדף. הפגיעות CVE-2021-44228[1], שנחשפה ב-10 בדצמבר 2021, נבעה ממנגנון JNDI Lookup: הספרייה ידעה לפרש מחרוזות מיוחדות בתוך הודעות הלוג ולפנות לשרתים חיצוניים בעקבותיהן. תוקף שהצליח לגרום למערכת לרשום בלוג מחרוזת בפורמט מסוים – למשל דרך שדה חיפוש, כותרת User-Agent או שם משתמש – יכול היה לגרום לשרת להוריד ולהריץ קוד זדוני מרחוק, ללא כל אימות.
השילוב היה חסר תקדים: ניצול פשוט ברמת שורת טקסט אחת, תפוצה של מאות אלפי מערכות, והרשאות מלאות בצד הפגוע. סוכנות הסייבר האמריקאית CISA פרסמה הנחיות חירום וכינתה את הפגיעות אחת החמורות שנראו אי פעם[2], והיא מופיעה עד היום בקטלוג החולשות המנוצלות (KEV) שלה. תיקונים שוחררו בתוך ימים (Log4j 2.15.0 ומעלה, וגרסאות המשך שסגרו פגיעויות נלוות), אבל התיקון היה החלק הקל.
למה זה רלוונטי גם היום? משתי סיבות. הראשונה: Log4j עדיין כאן. הספרייה מוטמעת בתוך מוצרים סגורים, מערכות legacy ותלויות עקיפות, וסריקות אבטחה – כולל כאלה שאנחנו מבצעים במבדקים – ממשיכות לאתר מופעים פגיעים שנים אחרי הגילוי, בעיקר במערכות פנימיות ש"אף אחד לא זוכר מה רץ עליהן", מאותו סוג שמתואר במדריך שלנו על חולשות ברשת הארגונית. השנייה והחשובה יותר: התרחיש יחזור. פגיעות קריטית בספריית תשתית נפוצה אינה אירוע חד-פעמי אלא דפוס – והשאלה היחידה היא כמה מהר תדעו אם אתם חשופים.
הבעיה האמיתית: אתם לא יודעים איזה קוד רץ אצלכם
בשבועות שאחרי הגילוי, שאלת "האם יש לנו Log4j?" התבררה כקשה להפתיע. הספרייה כמעט אף פעם לא הותקנה ישירות על ידי הארגון: היא הגיעה כתלות של תלות – ספרייה שספרייה אחרת שהמפתחים בחרו משתמשת בה, קבורה בתוך קובצי JAR דחוסים, בתוך אימג'ים של קונטיינרים, בתוך מוצרי מדף שהספק שלהם עצמו לא ידע לענות מהר. ארגונים גדולים גילו מופעים פגיעים במשך חודשים, כל פעם במקום חדש.
תוכנה מודרנית ממוצעת מורכבת ברובה מקוד פתוח של אחרים – והקוד שהצוות שלכם כתב הוא לרוב המיעוט. כל תלות כזו מביאה איתה את התלויות שלה, וכך נבנה עץ שלם של רכיבים שאיש בארגון לא בחר במודע ואיש לא עוקב אחריהם. בלי מלאי מסודר של העץ הזה, כל CVE קריטי חדש מתחיל בשאלה הכי בסיסית ובזבזנית שיש: חיפוש ידני של "איפה זה בכלל אצלנו".
זו בדיוק הבעיה ש-SBOM נועד לפתור.
מה זה SBOM ואיך הוא נראה בפועל
SBOM – Software Bill of Materials – הוא בדיוק מה שהשם אומר: רשימת מרכיבים של תוכנה, כמו רשימת הרכיבים על אריזת מזון. לכל יישום או מוצר, ה-SBOM מפרט אילו ספריות ורכיבים נכללים בו, באילו גרסאות, מאיזה מקור, תחת איזה רישיון, ואילו תלויות יש לכל רכיב בעצמו. כשמתפרסם CVE חדש, השאלה "האם אנחנו חשופים" הופכת משבועות של חיפוש לשאילתה של דקות מול המלאי.
בפועל, SBOM הוא קובץ מובנה (לרוב JSON או XML) באחד משני פורמטים מקובלים: CycloneDX של קרן OWASP[3], ו-SPDX של קרן לינוקס, שאף עוגן כתקן בינלאומי ISO/IEC 5962[4]. רשומה טיפוסית בקובץ נראית כך: שם הרכיב (למשל log4j-core), גרסה (2.14.1), מזהה ייחודי (purl), ערך גיבוב לאימות, ורישיון (Apache-2.0). כלים אוטומטיים יודעים להצליב את הרשימה הזו מול מאגרי פגיעויות באופן רציף – כך שהארגון מקבל התראה כשרכיב שכבר נמצא אצלו הופך מחר לפגיע.
הדרישה ל-SBOM כבר אינה המלצה תיאורטית: בעקבות Log4Shell ואירועי שרשרת אספקה נוספים, הצו הנשיאותי האמריקאי 14028 הפך את ה-SBOM לדרישה מספקי תוכנה לממשל הפדרלי, ורגולציות ותקנים נוספים בעולם מאמצים את העיקרון. גם בישראל, ארגונים שמחזיקים מאגרי מידע רגישים מגלים שהיכולת להציג מלאי רכיבים מעודכן היא בדיוק סוג הראיה שסוקרי סיכונים ומבקרים מבקשים – חלק ממיפוי הנכסים שנדרש ממילא בכל סקר סיכוני סייבר מקצועי.
איך מייצרים SBOM בצינור הפיתוח
החדשות הטובות: יצירת SBOM היום היא כמעט חינמית מבחינת מאמץ. כלים כמו Syft ו-Trivy מייצרים SBOM מקונטיינרים ומספריות קוד בפקודה אחת; לכל מנהלי החבילות המרכזיים (Maven, Gradle, npm, pip, NuGet) יש תוספים שמפיקים CycloneDX או SPDX ישירות מתהליך הבנייה; ופלטפורמות ניהול הקוד המובילות יודעות להפיק גרף תלויות מובנה. השאלה אינה "איך מייצרים" אלא "איפה בתהליך".
העיקרון החשוב: SBOM חייב להיווצר אוטומטית בכל בנייה (build), כחלק מצינור ה-CI/CD – לא כמסמך שמישהו מתחזק ידנית. מלאי ידני מיושן כבר ביום שנכתב. התהליך המומלץ: הפקת SBOM בכל build, שמירתו כארטיפקט לצד גרסת התוכנה שהוא מתאר, הצלבה אוטומטית מול מאגרי פגיעויות בכל בנייה וגם באופן מתוזמן על גרסאות שכבר בייצור, ודרישת SBOM מספקי תוכנה חיצוניים כחלק מתנאי ההתקשרות – כי החשיפה שלכם כוללת גם את הקוד שקניתם, לא רק את זה שכתבתם.
💡 טיפ מקצועי
התחילו מהמערכות החשופות לאינטרנט ומהמערכות שמחזיקות מידע רגיש – לא מכל הארגון בבת אחת. SBOM לעשרת היישומים הקריטיים, עם הצלבה אוטומטית מול מאגרי פגיעויות, נותן 80% מהערך בשבועות ספורים. את הזנב הארוך של מערכות פנימיות מוסיפים בהדרגה.
SCA וסריקת תלויות – ומה הן לא תופסות
SBOM הוא המלאי; SCA – Software Composition Analysis – הוא השימוש בו. כלי SCA סורקים את התלויות, מצליבים מול מאגרי CVE, ומתריעים על רכיבים פגיעים, גרסאות מיושנות ובעיות רישוי. בשילוב עם SBOM עדכני, זו שכבת הגנה שהייתה מקצרת את תגובת ה-Log4Shell של רוב הארגונים מחודשים לשעות. מי שרוצה להכיר את הכלים הנפוצים בתחום ימצא סקירה במדריך שלנו על כלים למבדקי חדירות, שחלקם משמשים גם לסריקות הרכב תוכנה.
אבל חשוב להבין מה SCA לא עושה. ראשית, הוא מזהה נוכחות של רכיב פגיע – לא ניצוּליות: העובדה ש-log4j-core 2.14.1 קיים בשרת אינה אומרת שהפונקציה הפגיעה נגישה לקלט של תוקף, והעובדה שהוא "לא אמור להיות נגיש" אינה אומרת שהוא באמת לא. שנית, SCA עיוור לקוד שלכם: פגיעויות בלוגיקה העסקית, בניהול ההרשאות ובממשקים שהצוות כתב אינן CVE במאגר ולא יופיעו בשום סריקת תלויות. שלישית, הוא לא רואה תצורה: Log4Shell עצמה הייתה ניתנת למיתון בהגדרות, ושרתים רבים נפרצו דווקא בגלל שילוב של רכיב פגיע עם תצורה מתירנית – שילוב שאף סורק סטטי לא מזהה.
⚠️ עצור – רשימת רכיבים פגיעים אינה תמונת סיכון
סריקת SCA על ארגון ממוצע מחזירה מאות ממצאים, שרובם אינם ניתנים לניצול בסביבה הספציפית. בלי שכבה שמאמתת מה מהם נגיש בפועל לתוקף, צוות האבטחה טובע ברעש – ומתקן לפי מספרי CVSS במקום לפי חשיפה אמיתית. זה בדיוק הפער שבין "יש לנו רכיב פגיע" לבין "יש לנו בעיה".
איפה מבדק חדירה נכנס לתמונה
כאן נסגר המעגל. SBOM אומר לכם מה רץ אצלכם; SCA אומר מה מזה פגיע על הנייר; מבדק חדירות לארגון מוכיח מה מזה תוקף אמיתי יכול לנצל בפועל. בודק מיומן לוקח בדיוק את הפער שהכלים האוטומטיים משאירים פתוח: הוא בוחן אם הרכיב הפגיע נגיש מבחוץ, אם אפשר להגיע אליו דרך הלוגיקה של האפליקציה, אם התצורה חושפת אותו, ואם שילוב של כמה ממצאים "בינוניים" בונה שרשרת תקיפה שמגיעה למידע הרגיש – כפי שקרה בפועל באינספור ארגונים עם Log4Shell.
המבדק גם בוחן את מה שאף מלאי רכיבים לא יכסה: הקוד הייחודי שלכם, ניהול ההרשאות, מנגנוני האימות וההגנות ההיקפיות. הגנה כמו WAF, למשל, סיננה חלק ניכר ממתקפות ה-Log4Shell הראשונות – אבל תוקפים פיתחו עקיפות בתוך ימים, ורק בדיקה אקטיבית מגלה אם ההגנה שלכם עומדת בהן; על תפקידו ומגבלותיו הרחבנו במדריך מה זה WAF. שלוש השכבות – מלאי (SBOM), סריקה (SCA) ואימות התקפי (מבדק חדירה) – אינן חלופות זו לזו אלא שרשרת אחת: כל אחת מכסה בדיוק את מה שהקודמת משאירה פתוח. ומכיוון שהתמונה משתנה עם כל גרסה וכל CVE חדש, גם המבדק אינו אירוע חד-פעמי – המסגרת לקביעת הקצב מפורטת במדריך על כל כמה זמן צריך לבצע מבדק חדירות.
צ'קליסט: מה לעשות כשמתפרסמת פגיעות קריטית חדשה
Log4Shell היה תרגיל כפוי בתגובה לפגיעות קריטית – וארגונים שהפיקו ממנו נוהל מסודר הגיבו ל-CVE-ים הבאים בשעות במקום בשבועות. זה הנוהל, שלב אחר שלב:
✅ נוהל תגובה ל-CVE קריטי – מהתראה ועד סגירה
- שעה 0 – זיהוי חשיפה: שאילתה מול ה-SBOM וסריקת SCA ממוקדת. אין SBOM? מתחילים מהמערכות החשופות לאינטרנט ומתעדים את הפער כלקח
- הערכת דחיפות: בדיקה האם ה-CVE מופיע בקטלוג ה-KEV של CISA ומה ציון ה-EPSS שלו – ניצול פעיל בעולם משנה את כל לוח הזמנים
- מיתון מיידי: עוד לפני עדכון – חסימה ב-WAF, כיבוי הפיצ'ר הפגיע בתצורה, בידוד רשתי של מערכות שאי אפשר לעדכן מיד
- עדכון מסודר: קודם מערכות חשופות לאינטרנט ומערכות עם מידע רגיש, אחר כך פנימיות – עם תיעוד מה עודכן ומתי
- בדיקה רטרואקטיבית: חיפוש סימני ניצול בלוגים ובמערכות הניטור מהתקופה שלפני העדכון – ההנחה חייבת להיות שמישהו ניסה
- אימות: בדיקה אקטיבית שהעדכון והמיתונים אכן סוגרים את החולשה, ולא רק מסתירים אותה
- סגירה ולקחים: עדכון ה-SBOM והנוהל, ותיעוד ההחלטות – גם לביקורת הבאה וגם ל-CVE הבא
שימו לב שהנוהל כולו נשען על תשתית שנבנית מראש: SBOM עדכני, יכולת סריקה, הגנות שאפשר לכוון במהירות, ולוגים שנשמרים מספיק זמן אחורה. ארגון שמנסה לאלתר את התשתית הזו ביום שבו מתפרסם ה-CVE כבר איחר – וזה, יותר מכל פרט טכני על JNDI, הלקח של Log4Shell.
שאלות נפוצות
מה זה Log4Shell?
Log4Shell הוא הכינוי לפגיעות CVE-2021-44228 בספריית רישום הלוגים Log4j 2 של Apache, שנחשפה בדצמבר 2021 וקיבלה את ציון החומרה המקסימלי, CVSS 10.0. הפגיעות אפשרה לתוקף להריץ קוד מרחוק (RCE) ללא אימות, באמצעות שתילת מחרוזת JNDI זדונית בכל קלט שנרשם ללוג – שדה חיפוש, כותרת HTTP או שם משתמש. בשל התפוצה העצומה של הספרייה, זהו אחד מאירועי האבטחה המשמעותיים שנרשמו.
האם עדיין יש שרתים פגיעים ל-Log4j?
כן. גם שנים אחרי הגילוי, סריקות אבטחה ומבדקי חדירות ממשיכים לאתר מופעים פגיעים – בעיקר במערכות פנימיות, במוצרי מדף שלא עודכנו ובתלויות עקיפות שהארגון לא ידע על קיומן. הפגיעות עדיין מופיעה בקטלוג החולשות המנוצלות (KEV) של CISA, ותוקפים ממשיכים לסרוק אחריה באופן שגרתי – דווקא משום שהיא ותיקה וקל לבדוק אותה.
מה זה SBOM ומי חייב אותו?
SBOM (Software Bill of Materials) הוא קובץ מובנה שמפרט את כל הרכיבים והספריות שמהם בנויה תוכנה, כולל גרסאות ותלויות עקיפות, בפורמטים מקובלים כמו CycloneDX ו-SPDX. בארה"ב, הצו הנשיאותי 14028 דורש SBOM מספקי תוכנה לממשל הפדרלי, ורגולציות נוספות בעולם מאמצות את העיקרון. גם היכן שאין חובה פורמלית, לקוחות עסקיים, מבטחי סייבר וסוקרי סיכונים מבקשים אותו יותר ויותר כראיה לניהול שרשרת אספקה אחראי.
האם סורק תלויות מספיק?
לא. סורק תלויות (SCA) מזהה רכיבים פגיעים על הנייר, אבל אינו בודק אם הם נגישים לתוקף בפועל, אינו רואה פגיעויות בקוד הייחודי שלכם, ואינו בוחן תצורה והגנות היקפיות. התמונה המלאה דורשת שלוש שכבות משלימות: SBOM כמלאי, SCA כסריקה שוטפת, ומבדק חדירות תקופתי כאימות התקפי של מה שבאמת ניתן לניצול.
איך מגיבים ל-CVE קריטי חדש?
לפי נוהל מוגדר מראש: זיהוי חשיפה מיידי מול ה-SBOM, הערכת דחיפות לפי KEV ו-EPSS, מיתון מיידי (WAF, תצורה, בידוד) עוד לפני העדכון, עדכון מסודר לפי סדר חשיפה, בדיקה רטרואקטיבית של סימני ניצול בלוגים, אימות שהתיקון עובד, ותיעוד לקחים. המפתח הוא שהתשתית – מלאי רכיבים, יכולת סריקה ולוגים – נבנית לפני האירוע, לא במהלכו.
מקורות שצוטטו במאמר (4)
- [1] CVE-2021-44228 Detail – NVD, NIST
- [2] Apache Log4j Vulnerability Guidance – CISA
- [3] CycloneDX – Bill of Materials Standard – OWASP Foundation
- [4] SPDX – Software Package Data Exchange – Linux Foundation
מילון מושגים
פגיעות הרצת קוד מרחוק בספריית Log4j 2 של Apache, שנחשפה בדצמבר 2021 עם ציון CVSS מקסימלי של 10.0.
Software Bill of Materials – קובץ מובנה שמפרט את כל הרכיבים, הספריות והתלויות שמהם בנויה תוכנה, כולל גרסאות ורישיונות.
Software Composition Analysis – סריקה אוטומטית של רכיבי התוכנה והצלבתם מול מאגרי פגיעויות, לזיהוי רכיבים פגיעים וגרסאות מיושנות.
ספרייה שמגיעה לפרויקט לא בבחירה ישירה של המפתחים, אלא כתלות של ספרייה אחרת. כך Log4j הגיעה לרוב המערכות שנפגעו.
Java Naming and Directory Interface – ממשק Java לפנייה לשירותי שמות וספריות חיצוניים. מנגנון ה-Lookup שלו בתוך Log4j היה הבסיס לניצול Log4Shell.
קטלוג Known Exploited Vulnerabilities של CISA – רשימת חולשות שידוע בוודאות שנוצלו בתקיפות אמיתיות, וכלי מרכזי לתעדוף תיקונים.
Remote Code Execution – הרצת קוד מרחוק: היכולת החמורה ביותר שתוקף יכול להשיג, שליטה בהרצת פקודות על המערכת הפגועה.
המאמר עודכן לאחרונה: ספטמבר 2026 ומשקף את תמונת המצב העדכנית של הפגיעות ושל תקני ה-SBOM. המידע המובא הוא כללי ואינו מהווה ייעוץ אבטחה פרטני.
רוצים לדעת אם ה-CVE הבא ימצא אתכם מוכנים?
מומחי RedEntry יבדקו מה באמת חשוף אצלכם – מהתלויות ועד הקוד. שיחת ייעוץ ראשונית ללא עלות.
