שלושה חודשים עברו מאז שדווחה חולשת האבטחה החמורה בפרויקט Log4j (הקרויה CVE-2021-44228). מאז נרשמו יותר מ-32 מיליון הורדות חדשות של Log4j מהמאגר של Maven. כ-15 מיליון מתוכן בגרסה עם החולשה החמורה. על פי נתונים של חברת Sonatype המנהלת את המאגר של Maven כ-46% מכלל ההורדות החדשות של Log4j הן עדיין בגרסאות עם חולשת האבטחה החמורה.
מדוע ארגונים ומפתחים מורידים גרסה של Log4j עם פרצת אבטחה ידועה? הסיבה העיקרית היא, ככל הנראה, חוסר מודעות וניהול חסר של חברות רבות את תחום הקוד הפתוח. זה לא סוד שקוד פתוח הפך לאבן יסוד בפיתוח תוכנה. בתוך מחצית עשור, שיעור השימוש בקוד פתוח בתוכנה מסחרית הכפיל עצמו ומונה כיום מעל ל-75% מהתוכנה המסחרית, ורק כ-25% מהקוד נכתב על ידי החברה עצמה. עם זאת, נראה שתרבות הניהול של הקוד הפתוח לא הדביקה את הקצב.
הנטייה בטבע היא לאנטרופיה – אי סדר. כדי להקטין את האי סדר צריך להשקיע אנרגיה – לבצע עבודה. אף שישנם תקנים בתחום ניהול הקוד הפתוח וכלי אוטומציה, יש חברות רבות שבוחרות שלא לנהל את התחום הזה. בהיעדר מודעות, כלי אוטומציה ונהלי עבודה – אין לארגון נראות של רכיבי הקוד הפתוח שמאפשרת לענות על השאלה הפשוטה: "האם אני משתמש ב-Log4j ובאיזו גרסה?" וזה במקרה שהשאלה בכלל עולה.
פעמים רבות משתמשים ברכיבים שתלויים (תלות לא ישירה) ברכיב הקוד מפתוח שבו קיימת החולשה – וזה באמת עשוי להקשות על הגילוי והתיקון של הרכיב. אבל אפשר לומר שמי שטרם תיקן את החולשה ברכיב Log4j אחרי שלושה חודשים – לא נמנע מכך בשל האתגרים שבתיקון אלא בשל חוסר מודעות וחוסר ניהול.
הבחירה של Sonatype היא בין אפשרויות רעות: אם מסירים את Log4j הדבר ייגרור תקלות בבניה של מיליוני פרויקטים. אם משאירים את הגרסאות עם החולשה – מיליוני פרויקטים ייוותרו עם פגיעות ברמת חומרה שכמותה לא נראה מזה כעשור
סיבה נוספת למספרים אלו יכולה להיות השימוש הרב בפיתוח תוכנה על ידי צד ג' – חברה קבלנית אשר מפתחת תוכנה בשם בעל התוכנה. במקרה זה בעל התוכנה אינו מי שמפתח את התוכנה בפועל, ומי שמפתח בפועל לא משקיע מאמץ מעבר למה שהוגדר לו באופן מפורש בחוזה העבודה. האחריות היא בראש ובראשונה על מזמין העבודה. עליו להגדיר דרישות סף ברורות בקשר לשימוש ברכיבי קוד פתוח. עד לפני זמן לא רב, תסריטים כאלו היו בשוליים של פיתוח התוכנה, אך עם הקושי במציאת עובדים – יש יותר ויותר פרויקטים שמבצעות חברות קבלניות. לרוב ללא כל התייחסות לניהול הקוד הפתוח.
לקושי זה אפשר לצרף גם את העובדה שהחוזה הסטנדרטי של חברות כלי האוטומציה לניהול קוד פתוח אינו מאפשר שימוש בתוכנה לצורך מתן שירותים לצד ג'. זהו נושא שמקשה עוד יותר על חברות קבלניות לפתח תוכנה תוך ניהול הקוד הפתוח.
אם כבר יודעים על הבעיה, מדוע גרסאות עם חולשות אבטחה עדיין זמינות להורדה?
לכאורה הדבר האחראי היה להסיר את הגרסאות הבעייתיות כדי שלא תהיינה זמינות להורדה. הבעיה, על פי חוקרים של גוגל, היא שישנם כ-7,000 פרויקטים ב-Maven בלבד שתלויים באופן ישיר ב-Log4j. מעל ל-35,000 פרויקטים אשר תלויים ב-Log4j ברמה כלשהי. הסרה של Log4j תגרום למעשה לקריסה של הבניה של כל אחד מהפרויקטים הללו ושל כל אפליקציה שהבניה שלה תלויה באחד מהפרויקטים האלו.
לצורך השוואה, ב-2016 היה מקרה של מפתח אשר הסיר מהמאגר של npm רכיב קוד פתוח אותו כתב. אז היה מדובר ברכיב של 11 שורות קוד בלבד, בשם left-pad. הסרתו גרמה למספר כה רב של תקלות ששעתיים וחצי לאחר שהוסר, npm נאלצו לשחזר את הרכיב. תארו לכם מה היה קורה אילו יום בהיר אחד Maven היו פשוט מסירים את Log4j.
היכן האחריות של Sonatype, כמי שמנהלת את מאגר Maven, כלפי כל מי שמוריד גרסה עם חולשה?
תנאי השימוש של מאגר Maven ברורים באופן שאינו משתמע לשני פנים. בין אם Sonatype היו מסירים את הגרסאות ובין אם משאירים אותן זמינות – האחריות המלאה והבלעדית היא על המשתמש. בכל מקרה הבחירה של Sonatype היא בין אפשרויות רעות: אם מסירים את Log4j הדבר ייגרור תקלות בבניה של מיליוני פרויקטים, ואם משאירים את הגרסאות עם החולשה – מיליוני פרויקטים ייוותרו עם פגיעות ברמת חומרה שכמותה לא נראה מזה כעשור.
בהיעדר מודעות, כלי אוטומציה ונהלי עבודה – אין לארגון נראות של רכיבי הקוד הפתוח שמאפשרת לענות על השאלה הפשוטה: "האם אני משתמש ב-Log4j ובאיזו גרסה?" וזה במקרה שהשאלה בכלל עולה
חשוב לציין כי מרבית השוק פועל באחריות. כ-54% אחוז מההורדות של Log4j הן בגרסאות מתוקנות. אך המיעוט שאינו מנהל זאת גדול מדי מכדי להישאר אדישים. ואכן בעולם לא נותרו אדישים לעובדה זו, כבר בינואר השנה ועדת הסחר הפדרלית של ארצות הברית פרסמה אזהרה הקוראת לחברות לתקן את החולשה של Log4j. ועדת הסחר אף הזהירה בהודעה כי תנקוט בהליכים משפטיים כנגד מי שיכשל בתיקון החולשה של Log4j וחולשות דומות בעתיד.
ללא ספק טרם נאמרה המילה האחרונה במקרה של Log4j. כעת רק נותר לראות כמה עוד יפגעו מחולשה זו עד שנראה הליכים משפטיים כנגד חברות מצד ועדת הסחר הפדרלית והאם אנו לקראת רגולציה בתחום.
כותב: יניב אוזרזון, עו"ד, שותף בחברת FOSSAWARE, מומחה לניהול סיכוני שימוש בקוד פתוח