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

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

תיאור מקרה קטסטרופלי

רכיבי תוכנה בקוד פתוח נמצאים בכל מקום - אפילו מפתחי קוד קנייניים מסתמכים עליהם כדי להאיץ את תהליכי DevOps. לְפִי הערכה אחת, 96% מכל בסיסי הקוד מכילים רכיבי קוד פתוח, ושלושה רבעים מכילים נקודות תורפה בעלות סיכון גבוה. בהתחשב בכך שמתקרב שבעה טריליון רכיבים הורדו בשנת 2024, זה מהווה סיכון פוטנציאלי עצום למערכות ברחבי העולם.

Log4j הוא מקרה בוחן מצוין של מה יכול להשתבש. זה מדגיש אתגר נראות גדול בכך שתוכנה לא מכילה רק "תלות ישירות" - כלומר, רכיבי קוד פתוח שתוכנית מתייחסת אליהם במפורש - אלא גם תלות טרנזיטיבית. האחרונים אינם מיובאים ישירות לפרויקט אלא משמשים בעקיפין על ידי רכיב תוכנה. למעשה, הם תלות של תלות ישירה. כְּמוֹ הסבירה גוגל בזמנו, זו הייתה הסיבה לכך שכל כך הרבה מקרים של Log4j לא התגלו.

"ככל שהפגיעות עמוקה יותר בשרשרת תלות, כך נדרשים יותר שלבים כדי לתקן אותה", צוין.

ה-CTO של Sonatype, בריאן פוקס, מסביר ש"ניהול תלות לקוי" בחברות הוא מקור עיקרי לסיכון אבטחת סייבר בקוד פתוח.

"Log4j הוא דוגמה מצוינת. מצאנו ש-13% מההורדות של Log4j הן של גרסאות פגיעות, וזה שלוש שנים לאחר התיקון של Log4Shell", הוא אומר ל-ISMS.online. "גם זו אינה בעיה ייחודית ל-Log4j - חישבנו שבשנה האחרונה, ל-95% מהרכיבים הפגיעים שהורדו כבר הייתה גרסה קבועה זמינה."

עם זאת, סיכון בקוד פתוח אינו נוגע רק לנקודות תורפה פוטנציאליות המופיעות ברכיבים שקשה למצוא. גם שחקני איומים שותלים באופן פעיל תוכנות זדוניות בחלק מרכיבי הקוד הפתוח, בתקווה שהם יורדו. Sonatype גילתה 512,847 חבילות זדוניות במערכות האקולוגיות העיקריות בקוד פתוח בשנת 2024, עלייה שנתית של 156%.

אתגרים מערכתיים

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

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

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

מאגר מוגבל של תורמים:

"חלק מפרויקטי OSS בשימוש נרחב מתוחזקים על ידי אדם בודד. כשסקרו את 50 הפרויקטים המובילים שאינם npm, ל-17% מהפרויקטים היה מפתח אחד, ול-40% היה מפתח אחד או שניים שהיוו לפחות 80% מההתחייבויות", אומר מנהל OpenSSF של אבטחת שרשרת האספקה ​​בקוד פתוח, דיוויד ווילר. ISMS.online.

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

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

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

שפות לא בטוחות בזיכרון: האימוץ של שפת Rust בטוחה לזיכרון הולך וגדל, אך מפתחים רבים עדיין מעדיפים C ו-C++, שלעתים קרובות מכילות נקודות תורפה של בטיחות זיכרון.

כיצד ISO 27001 יכול לעזור

As תורם רד האט, הרווה בראו, מציין, היינו צריכים לראות את Log4Shell מגיע מכיוון שתוכנית השירות עצמה (Log4j) לא עברה ביקורת אבטחה רגילה והיא תוחזקה רק על ידי צוות מתנדבים קטן, סיכון שהודגש לעיל. הוא טוען שמפתחים צריכים לחשוב טוב יותר על רכיבי הקוד הפתוח שהם משתמשים בהם על ידי שאילת שאלות לגבי ROI, עלויות תחזוקה, תאימות לחוק, תאימות, התאמה, וכמובן, האם הם נבדקים באופן קבוע לאיתור נקודות תורפה.

מומחים ממליצים גם על כלים לניתוח קומפוזיציה של תוכנה (SCA) כדי לשפר את הנראות של רכיבי קוד פתוח. אלו עוזרים לארגונים לקיים תוכנית של הערכה ותיקון מתמשכים. עדיף, שקול גישה הוליסטית יותר המכסה גם ניהול סיכונים על פני תוכנה קניינית. תקן ISO 27001 מספק מסגרת מובנית כדי לעזור לארגונים לשפר את עמדת האבטחה שלהם בקוד פתוח.

זה כולל עזרה ב:

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

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