זהו הפרק השלישי בסדרה סדרת מאמרים לגבי הסוג הנפוץ ביותר של מתקפות שרשרת אספקה של תוכנה: אלו שמנצלות לרעה את הרישום הציבורי של קוד פתוח רכיבי תוכנה. לאחר ניתוח בפרק הקודם "אנטומיה של חבילות זדוניות: מהן המגמות?"כיצד גורמים זדוניים מזריקים התנהגות זדונית לרכיבים חדשים או קיימים שפורסמו, אנו מוכנים ללבוש את אפודי הכיבוי שלנו ולבחון כיצד נוכל לחסום בהצלחה תוכנות זדוניות המועברות בדרך זו, או לחלופין, להתמודד עם אירוע סייבר שעלול להיות חמור מכיוון שנקטנו בגישה שגויה."
לרוב אנשי המקצוע המודעים לאבטחה יש רעיונות כיצד להתמודד עם איום זה. שמענו מנהלי אבטחה אומרים ללא היסוס ש SCA כלים כבר אומרים לך מתי גרסת חבילה היא תוכנה זדונית. או שהם תלויים ברכיבי תוכנה ידועים שנבדקו היטב, שבהם כל תוכנה זדונית תתגלה ותוסר במהירות. הם משתמשים בגרסאות פתוחות מינוריות/טלאים כדי לקבל תיקוני פגיעויות באופן אוטומטי, וזו הדרך הנכונה והמומלצת להפחית את הסיכון בתלות בקוד פתוח, בהתאם ל-"תיקון מוקדם, תיקון לעתים קרובותעיקרון.
בפרק זה נסקור מדוע רעיונות אלה שגויים, וכיצד תפיסות מוטעות כאלה תורמות לפופולריות של מנגנון תקיפה זה, ולסיכון עצום שחווים ארגונים. נסיים עם מה שכן עובד, ומהם המאמץ והמשאבים הכרוכים בכך.
תפיסות מוטעות נפוצות
במהלך המסע שלנו עם אבטחת תוכנה, ראינו את טכניקות התקיפה מתפתחות ומגוון רחב של רעיונות מצד אנשים בעלי מודעות לאבטחה. ארגונים לעיתים קרובות מבינים לא נכון מה עובד כנגד איום זה, לכן ראשית נבחן מה לא עובד, כפי שיתמצת ברשימה הבאה, שאינה ממצה, של תפיסות מוטעות.
תפיסה מוטעית מספר 1: SCA כלים כבר מדווחים על רכיבים זדוניים
אכן! אבל לאחר מעשה... כאשר כנראה שזה מאוחר מדי אם האלמנט שימש בבניית תוכנה, והגורמים הרעים כבר השיגו דריסת רגל אצל מפתח או CI/CD מארח. ייתכן שסודות נחטפו, תוכנות זדוניות נוספות הורדו והותקנו, ואולי היריב זז הצידה וכבר השיג גישה למקום אחר.
ניתוח הרכב תוכנה (SCAכלים ) נועדו לזהות פגיעויות פוטנציאליות ידועות. כלים מודרניים עושים עבודה מצוינת על ידי הגדלת יחס אות-רעש, וקובעים אם הפגיעות אכן ניתנת להשגה או ניתנת לניצול. אך הם חסרי תועלת כנגד תוכנות זדוניות חדשות. חשבו על רכיב זדוני כפגיעות של יום אפס: רק כאשר מתגלה התנהגותו הזדונית, הרכיב מדווח לרישום המחזיק, אשר לאחר סקירה של צוות אבטחה מאושר כזדוני ומוסר מהרישום. [1].
באותה נקודה, העולם (כולל SCAs) יודע שהתקנה או שימוש ברכיב (או בגרסה/ות של רכיב קיים) אינם דבר טוב. אבל זה קורה כאשר הרכיב אינו זמין מהרישוםלדעת שיש לי פגיעויות ברכיבים של צד שלישי, או אפילו רכיבים שסווגו כזדוניים על ידי הרישום, זה טוב, אבל למרבה הצער. SCA או שכלי ביקורת נפוצים אינם עוזרים בהקשר זה. אלא אם כן ה SCAכלי /audit יכול באמת לדעת מראש שרכיב מסוים זדוני עוד לפני שהוא נמצא בשימוש בארגון שלך..
זכרו, כל פתרון נגד רכיבי קוד פתוח זדוניים חייב לזהות אותם. בדרך, בין מועד פרסום הרכיב ברישום לבין מועד השימוש הראשון ברכיב (גרסה) בארגון שלך. וזה כולל רכיבים טרנזיטיביים.
תפיסה מוטעית מס' 2: שליטה בסקריפטי התקנה בזמן הבנייה מונעת התנהגות זדונית מרכיבי קוד פתוח
מנהלי חבילות שונים מציעים את היכולת להריץ סקריפטים (הכלולים ברכיב tarball [2]), מסיבות לגיטימיות, כגון קומפילציה של פריטים נדרשים בפלטפורמות שונות, יצירת קוד או הרצת בדיקות, וכולנו צריכים לדעת שניתן לרעה אותם על ידי גורמים רעים אם סקריפטים זדוניים כלולים בקובץ ה-tarball, או אם התוקף יכול לגרום לסקריפט זדוני להריץ במקום הסקריפט הטוב.
בידיעה זו, נוכל להגדיר את מנהל החבילות להתעלם מסקריפטים. לדוגמה, עם NPM, –להתעלם מתסריטים דגל (או מאפיין תצורה ב- .npmrc קובץ) מדלג על הסקריפטים במהלך ההתקנה. זה עלול לגרום לבעיות מסוימות מכיוון שהפעלת סקריפטים נפוצה במערכות אקולוגיות רבות: חלק ממנהלי החבילות אפילו לא מאפשרים השבתת ביצוע סקריפטים (רמז: הפקודה "אילו מנהלי חבילות אינם מאפשרים השבתת ביצוע סקריפטי התקנה?"בבינה המלאכותית המועדפת עליך). אבל זה לא מגן באופן כללי (אנחנו צריכים לאכוף שתצורת השבתת הדילוג תהיה בכל מקום).
וכאשר ההתנהגות הזדונית אינה ממוקמת בסקריפטי התקנה אלא בתוכנה לצורך ביצוע בזמן ריצה, אפשרות זו לבדה אינה מגנה עלינו.
תפיסה מוטעית מס' 3: הצמדת גרסה מונעת התקנת רכיבים זדוניים
ישנה פשרה בין תיקון מוקדם לבין תיקון תכוף עם גרסאות פתוחות (מתן אפשרות למנהל החבילות להתקין אוטומטית עדכונים חדשים כאשר הם זמינים עבור תיקוני אבטחה) ו- הצמדת גרסה (כל התלות הישירות והטרנזיטיביות עבור תוכנה בגרסה קבועה). עקרונות האבטחה עקשניים ולפעמים סותרים, כפי שקורה עם "תיקון מוקדם, תיקון לעתים קרובות" ו "אסור להתייחס לשדרוג בקלות ראש"חלק ממנהלי החבילות מבצעים עדכונים אוטומטיים עם טווחי שרתים בדרך המומלצת. נהדר אם אתם רוצים גם לקבל עדכונים זדוניים! כן, יש לעדכן רכיבים כדי לקבל תיקוני אבטחה שסוגרים פגיעויות בהקדם האפשרי, אבל... לעולם אל תתנו למנהל החבילות לעשות זאת באופן אוטומטי.
תפיסה מוטעית מס' 4: שימוש ברכיבים מהימנים הוא בטוח. כל גרסה זדונית תימצא, תיחשף ותוסר במהירות.
מדוע רכיב מסוים מהימן? אולי משום שהוא פופולרי מאוד, עם עיניים רבות המחפשות פגיעויות, מספר רב של תורמים לתחזוקה, ועם מספר רב של מתחזקים מרכזיים שבודקים בקפידה את כל הרכיבים. pull requestsהמציאות שונה למדי. חלק מהרכיבים החיוניים מתוחזקים על ידי מפתח יחיד, שלא מקבל תשלום. מסגרות עבודה נפוצות... כמה תורמים קבועים, עם ירידה מהירה במספר של commitלכל מתחזק (לפרויקטים פופולריים יש זנב ארוך של תורמים שמבצעים פעולות מסוימות commit ולעולם לא לחזור). ופרויקטים פופולריים עם מתחזק יחיד יש בשפע.
דמיינו את עצמכם אומרים "אה, אנחנו משתמשים בתמונות Spring Boot / Angular / React / PyTorch / בסיס רשמי של Docker, אז הסיכון שאתה מדבר עליו די נמוך." אולי זה נכון, אנחנו, ספקי אבטחה, כל הזמן מפחידים ומתערבים בצוותי פיתוח כדי להפחית סיכון שנוי במחלוקת זה שטויות. אולי תתפתו לקפוץ לפסקה על קבלת סיכונים (בסעיף הבא) ולסיים. למרבה הצער, הרכיבים הפופולריים ביותר הם מטרות לשחקנים רעים, ולדוגמה, הפופולרי... ספריית PyTorch הותקפה בעבר.
"נמצא, נחשף והוסר מיד". לוקח ימים עד שרכיב זדוני חדש יוסר מהמרשם הציבורי. מרשמי תוכנה נזהרים לגבי הסרת גרסת רכיב, לטובה. מניסיוננו, לאחר דיווח מצדנו, הזמן החציוני להסרת הגרסה המושפעת מהמרשם הוא 39 שעות, יותר מיום וחצי. ישנם רכיבים זדוניים שמסירים אותם שבוע לאחר הדיווח הראשוני שלנו במרשם. ובמקרים מסוימים, הרכיב מוסר רק לאחר שקורבן או חברת תגובה לאירועים מדווחים על אירוע הקשור לרכיב.
מה לא עובד נגד רכיבים זדוניים
כל גישה לא ספציפית תיכשל כישלון חרוץ. זה ודאי, אינך מספק אמצעי נגד יעילים לסיכון הכרוך באיום זה.
מסורתי SCA כלים מספרים לכם על תוכנות זדוניות ידועות אך בעלי חלון חשיפה גדול. אלא אם כן הם מבצעים זיהוי יזום של תוכנות זדוניות עם חסימה כפויה של רכיבים זדוניים, הם אינם פועלים כנגד איום זה.
השבתת סקריפטי התקנה יכולה לעזור, אך יש לאכוף זאת בכל מקום בו יש להתקין רכיב. אותו דבר לגבי הצמדת גרסאות, מכיוון שלא ניתן להצמיד גרסאות ממצב התחלתי בטוח לנצח.
ההנחה שרכיבים פופולריים מקבלים מספיק תשומת לב כדי שלא ניתן יהיה להזריק להם התנהגות לא מכוונת במתקפת שרשרת אספקה ללא זיהוי כמעט מיידי כדי למנוע כל נזק היא נאיבית ומסוכנת. אתם לא רוצים לחיות על הקצה, נכון?
אם תעצור בנקודה הזו, אז קבלת סיכונים זה הדבר היחיד שאתה יכול לעשות: זה דהcisיש לתעד את המודל האיום/הערכת הסיכונים שלכם, כולל הרציונל לקבלת הסיכון והשלכותיו הפוטנציאליות. העלו את המודעות על ידי העברת המידע להנהלה ולגורמים רלוונטיים אחרים. חלקם מגירה ניתן לתכנן זאת כאשר רכיב זדוני מותקן או כלול בתוכנה שלך, אך הדבר קשה מכיוון שלתוקפים ישנן נתיבים רבים ללכת בהם. פרטי מתקפת שרשרת אספקה המבוססת על שימוש ברכיב זדוני ישנו באופן דרסטי את הגילוי הציבורי של האירוע, שכנראה חובה במסגרת הרגולטורית של הארגון שלך. ייתכן שתתייחס גם בקרות פיצוי or סיכון העברה למשל עם ביטוח.
עם זאת, ישנם בקרות המטפלות באיום ויש לשקול אותן אם אינך מרוצה מקבלת הסיכון. אנא המשך לקרוא.
מה עובד נגד התקפות המשתמשות ברכיבים זדוניים
טיפול בגרסה מוצקה
הצמדת גרסאות עם גיבוי גרסאות מבוקר ומושכל היא הדרך הנכונה, כדי לאזן את הצורך בהסרת פגיעויות מבלי לקבל תוכנות זדוניות. אבל זכרו את תפיסה מוטעית מספר 3: הצמדת גרסאות לבדה אינה מספיקה כדי לחסום קוד זדוני שמגיע מגרסאות חדשות, מכיוון שתצטרכו בעתיד לעדכן גרסאות בכל תלות ישירה או עקיפה. באותו רגע אתם זקוקים לראיות חזקות מספיק לכך שכל הגרסאות המעודכנות אינן מכילות תוכנות זדוניות.
אזהרה מוקדמת
גישה אחת לבעיית הרכיבים הזדוניים היא מערכת התרעה מוקדמת (הנקראת כאן התרעה מוקדמת על תוכנות זדוניות או MEW), כאשר גרסאות חדשות שפורסמו (עבור רכיבים חדשים או קיימים) מנותחות על ידי מנוע זיהוי, אשר כאשר יימצאו מספיק ראיות עשוי לסווג את הגרסה החדשה כזדונית פוטנציאלית.
אוטומציה היא חיונית כאן, מכיוון שאי אפשר לסקור ידנית את כל הרכיבים החדשים בקצב הפרסום הנוכחי. לכן, מנוע הזיהוי צריך לשלב מגוון טכניקות, שאולי כוללות ניתוח סטטי, דינמי וניתוח יכולות, מוניטין משתמש, וראיות הנובעות מפערים בין המטא-דאטה של הרכיב לבין תוכן ה-tarball, או בין ה-tarball לבין מאגר המקור שממנו מגיע הרכיב כביכול.
יש אזור חשוך בין זמן הפרסום לבין זמן ניתוח תוכן הרכיב על ידי המנוע, אך לא יעלה על מספר דקות. ניתן לשנות את הסכימה, למשל על ידי המתנה לניתוח רכיבים חדשים לפני מתן אפשרות להתקנתם ולהשתמש בהם בבניית התוכנה. pipelines, או לנתח אותם לפי דרישה בעת הצורך. רכיב בגרסה נתונה אינו ניתן לשינוי [3], ולכן יש לנתח אותו פעם אחת בלבד.
אוטומציה מלאה אינה אפשרית, ויש צורך בבדיקת אבטחה לאיתור רכיבים שעלולים להיות זדוניים. היזהרו מתומכי פתרונות דיגיטלייםבינה מלאכותית ולמידת מכונה אינן מפותחות מספיק כדי לקבל את המילה האחרונה בכל הנוגע לאישור האם רכיב חשוד מכיל תוכנה זדונית. נכון, למידת מכונה ממלאת תפקיד מפתח במנוע הגילוי בסיווג רכיב הקלט מהראיות הגולמיות שנלכדו, אך לאחר שהרכיב "נכנס להסגר", המילה האחרונה היא על הבדיקה הידנית על ידי צוות אבטחה בעל ניסיון ברכיבים זדוניים. זה מאשר כל תוכנה זדונית פוטנציאלית או מסווג אותה מחדש כבטוחה. ופרק הזמן הוא בטווח השעות.
הרישום מדווח על הגרסה/רכיב הזדוני; לאחר מכן הרישום מבצע את הבדיקה שלו כדי לאשר וממשיך לחשיפה לציבור ולהסרה מהרישום. חלק מהרישומים שומרים חבילת אבטחה. טווח הזמן כאן הוא הימים או השבועות מאז הפרסום, שהוא ה-'זמן להתעכב'או'חלון חשיפה' עבור רוב הרכיבים הזדוניים.
האם ניתן לדעת אם גרסת רכיב היא זדונית?
לכן, לצורך התרעה מוקדמת, עלינו לתת תשובה מספקת לשאלה זו: כיצד אוכל לדעת שספרייה או חבילה הן (לא) זדוניות? כיצד לאסוף מספיק ראיות להתנהגות זדונית? אפשרי, אך קשה, שכן היריבים משתמשים בתושייה רבה כדי להימנע מגילוי. ישנן גישות שונות, לכל אחת יתרונות וחסרונות.
ניתוח סטטי יכול לבחון את כל נתיבי הביצוע, לבדוק טכניקות בהן משתמשים תוקפים מבלי להפעיל את הרכיב, ולבצע משימות עיבוד מקדים כמו הסרת ערפול או פענוח. כאשר תוקפים מנסים להסתיר את שובבותם, ניסיונות ערפול הם אכן עדות לתוכנה זדונית (אך שימו לב שרכיבים לגיטימיים מטשטשים קוד לשימור קניין רוחני, וסותרים "קוד פתוח"). רק מיעוט מהתקפות מתוחכמות ביותר עם ערפול חזק זקוקות ל"ארגז חול", אך ערפול חזק כזה הוא סימן מובהק לרוע. שימו לב כי קונבנציונלי SAST כלים תוכננו עבור פגיעויות לא מכוונות, לא עבור כוונות זדוניות כמו דלתות אחוריות.
ניתוח דינאמי מפעיל את הרכיב ובוחן את התגובה על ידי מדידה של זמן הריצה, בדרך כלל על ידי מתן סביבת ארגז חול. התנהגות זדונית המופעלת בתנאים מסוימים עשויה לעבור מבלי להתגלות: שימו לב שתוכנות זדוניות עשויות להשתמש בטכניקות התחמקות כמו וירטואליזציה/התחמקות מארגזי חול להפעלה רק כאשר אינו נמצא תחת פיקוח, וגם סימן מעיד על פעילות זדונית עבור כל מנוע ניתוח סטטי.
ניתוח יכולות בוחן מה הרכיב עושה: לאן הוא מתחבר, לאילו קבצים הוא ניגש, אילו פקודות או תוכניות מופעלות, ה-I/O של הטרמינל או ההתקן שבוצע, או אילו קריאות מערכת מופעלות. ניתן להשוות טביעת אצבע זו של התנהגות (עבור רכיב קיים) בין גרסאות, כך שכאשר מתגלה התנהגות בלתי צפויה, ראיות אלו עלולות לעורר חשד לפעילות זדונית פוטנציאלית שהוזרקה לגרסה החדשה. גישה זו עוקבת אחר שלבי המיון שאנליסטים של אבטחה מבצעים כאשר הם מתמודדים עם תוכנות זדוניות פוטנציאליות: בדיקה באמצעות מחרוזות או כלים דומים. גישה זו מזהה התנהגות זדונית ללא קשר לתנאי ההפעלה ופועלת כאשר אין קוד מקור זמין.
ניתוח הקשר אוסף מידע על אופן פרסום הרכיב ועל ידי מי. קמפיינים של גורמים רעים משתמשים לעתים קרובות בחשבון/ות משתמש/ים חדש/ים שאינו/ה כפוף/ה לתהליך סינון קפדני. מעקב אחר פעילות קודמת עשוי לתת תובנות לגבי המשתמש הבסיסי, בעיקר עבור אנומליות שעשויות לרמוז על פגיעה אפשרית. מוניטין הוא דבר כל כך קשה לרכישה וקל כל כך לאבד! משתמש ללא פעילות קודמת הוא ניטרלי, אך קארמה רודפת אחר המרושע/ת. יש לעקוב בקפידה אחר האקטיביסטים, או משתמשים רגילים שנגנבו להם פרטי הפרסום.
מידע הקשרי נוסף הוא כל פער בין מאגר המקור שכביכול שימש ליצירת קובץ ה-tarball של הרכיב לבין תוכן ה-tarball עצמו. וגם ביצוע שיטות עבודה מומלצות, כמו יצירת תגיות או גרסאות במאגר המקור התואמות לגרסאות של הרכיב שפורסמו ברישום הציבורי. כאשר מאגר המקור במקום מסוים commit מתויג עם שחרור, ואז פתאום גרסה אחת לא מצליחה לעקוב אחריה, זו לבדה ראיה חזקה לכך שהרכיב עלול להיות מוכתם: ייתכן שהגורם הרע התפשר על החשבון ששימש לפרסום הרכיב, אך אין לו הרשאות כתיבה במאגר קוד המקור). התקפות רבות מזוהות באופן שגרתי באמצעות כללים אלה: לדוגמה, ה- מתקפת ספר חשבונות ניתן לזהות בקלות לאורך המסלולים הללו. לכן, ניתוח הקשר מזהה אנומליות כאלה בתהליך הפרסום.
חומת אש של תלות
גישה שונה היא ליצור רשימה לבנה מקיפה של רכיבים עבור כל גרפי התלות המשמשים בתוכנה שלך, כך שבכל בנייה pipeline ניתן להתקין ולהשתמש רק בגירסאות רכיבים שאושרו בארגון שלך. ה-"חומת אש"נאכף באמצעות רישום פנימי שבו מוגשות קבצי ה-tarball עבור גרסאות הרכיבים המותרות (מאוחדות במטמון או דרך פרוקסי). שימו לב שכל רשימה לבנה לא תעבוד אלא אם כן יש לכם את הטכנולוגיה לסיווג כל גרסה חדשה כבטוחה למדי, כך שניתן יהיה להוסיף אותה לרשימה הלבנה.
שימו לב שיש לשלב התרעה מוקדמת (זיהוי מהיר בהקדם האפשרי לאחר פרסום הגרסה החדשה) עם דרך כלשהי להשתמש במידע זה באופן יזום כדי לחסום את הרכיב המשפיע על הבנייה. pipelineאו מכונות המפתחים [4]אנחנו קוראים לזה "חומת אש של תלות": מנגנון הסגר להגנה על בניות אוטומטיות מחבילות זדוניות. חבילות פנימיות ורישומי תמונות טובים לבידוד ארגונים מפני רוע חיצוני, אך יש צורך בראיות חזקות מספיק כדי להפוך את ההסגר ליעיל.
ארגז חול בזמן ריצה
גישה חלופית לזיהוי בזמן הפרסום היא ניתוח התנהגות בזמן ריצה. הרעיון הוא ללכוד את ההתנהגות הצפויה מהתוכנה ולזהות (או לחסום) כל אנומליה שנמצאת. קו פעולה זה טומן בחובו את הבעיה של הצורך להתאים את זמן הריצה לניטור או חסימה, וזהו רעיון מבטיח שיתווסף למאגר מנגנוני ההגנה מפני רכיבים זדוניים.
קביעת אסטרטגיה מקיפה
האסטרטגיה המומלצת צריכה לשלב טכניקות שונות בתהליך פיתוח התוכנה, תוך לקיחת שליטה על עדכוני הגרסאות כדי לחסום רכיבים זדוניים נכנסים. עלינו להתאים את עצמנו ל"קיבוע גרסאות" כדי למנוע הדבקה אוטומטית עם עדכון גרסאות כדי לקבל תיקונים לפגיעויות החשובות; הערכה מהירה ויעילה של תלות ישירות ועקיפות במהלך עדכוני גרסאות כדי שיהיו מספיק ראיות לכך שהן אינן מוכתמות בתוכנות זדוניות. יש לחסום גרסאות של תוכנה התלויות ברכיבים זדוניים ידועים. ויש לאכוף את כל אלה.
השתמשו בהצמדת גרסאות, במידת האפשר, מכיוון שהיא הופכת את הבניינים לשחזוריים יותר. הצמדת גרסה עם הגברות גרסה מבוקרות שאושרו ידנית, ו בסיוע טכנולוגיית עזר, צריך להעריך אם העדכון מביא תוכנה זדונית או פוגע בתוכנה, וליישב בין עדכון לתיקון פגיעויות לבין מניעת הדבקה בתוכנה זדונית. כלים יכולים לעזור כאן, על ידי (1) קביעת סדרי עדיפויות לאילו פגיעויות באמת חשובות (ניתנות להשגה וניצול, עם סיכון גבוה להיות מטרה על ידי תוקפים), (2) בחירת גרסאות היעד התואמות לשימושים הנוכחיים של הרכיבים ואינן פוגעות בתוכנה, (3) בחירת גרסאות יעד שאינן מכילות התנהגות זדונית, ו-(4) הפיכת עדכון הגרסה עבור תלויות ישירות ועקיפות לקל, על ידי הצעת שינויים בקבצי המניפסט שניתן לאשר במהירות. שלב (3) זקוק למידע ספציפי על רכיבים זדוניים קרוב ככל האפשר לזמן הפרסום שלהם.
תהליך עדכון תלויות זה חייב להיות נאכף ו מְאוּמָת בכל המקומות. יש לתעד את התהליך, ולקבל הכשרה לכל הצדדים המעורבים, שכן לעתים קרובות הפיתוח ובניית/פריסת התוכנה מבוצעים באופן חיצוני. ה- CI/CD pipelineיש לשנות את s בהתאם, כך שאוטומציה לא תאפשר לתלות עקיפה זדונית לחלחל לתוך הבנייה: guardrails חסימת הבנייה אם יש מספיק ראיות לתוכנה זדונית פוטנציאלית בתלות היא הדרך המומלצת לפעול.
אם לארגון שלך יש רישום פנימי המשמש כמתווך אבטחה להחזקת גרסאות הרכיבים המותרות, עליך להשיג מידע מודיעיני על רכיבים זדוניים (בנוסף לקריטריונים אחרים) לצורך בדיקת רכיב מבוקש לפני הוספתו לרשימת ההיתרים.
צריכת תוכנה בקוד פתוח בצורה בטוחה אינה קלה, ויש לקחת בחשבון באופן מלא את גורם התוכנה הזדונית, תוך השקעת מאמץ דומה בטיפול בפגיעויות.
הערה אחרונה אחת: מקור המקור, בצורת אימות תוכנה, שנוצר בזמן בניית הרכיב, הוא חלק מרכזי נוסף במאמץ לאתר את הארטיפקט (tarball של הרכיב) עם המקורות ותהליך הבנייה שיצרו אותו. שימו לב שקישור זה בין תמונת המצב של המקור + סביבת הבנייה לבין ארטיפקט התוכנה המשויך (חתום על ידי מערכת הבנייה המהימנה) אינו מונע כשלעצמו שהרכיב אינו מכיל התנהגות זדונית, אך מקשה על הרעים להחדיר תוכנות זדוניות. והפיכת אימות מקור לדרישה נפוצה לצריכת רכיבי קוד פתוח תיקח זמן רב, ורק... נוסף לאחרונה ל-NPMהפיכת מערכות הבנייה והפריסה המהימנות הללו לחסינות מפני פגיעה, או מתן אפשרות לזיהוי כל פגיעה בבנייה, זה סיפור אחר, מחוץ לתחום של פוסט זה.
לקריאה נוספת
הפרק הבא חבילות זדוניות בקוד פתוח: גישת Xygeni נציג את האסטרטגיה שאנו נוקטים בה ב-Xygeni עבורנו התרעה מוקדמת על תוכנות זדוניות מערכת (MEW). גרסאות חבילות חדשות במאגרי החבילות והתמונות הציבוריים נסרקות ומתקבלות ראיות באמצעות שילוב של ניתוח סטטי, דינמי, יכולות וניתוח הקשרי. הראיות, בשילוב עם מוניטין המשתמש והיסטוריית השינויים במאגרי קוד המקור, מאפשרות סיווג אוטומטי לחלוטין של רכיב לקטגוריות בסיכון גבוה וסביר להניח זדוניות. המערכת לומדת מראיות קודמות שנאספו מחבילות כדי להפחית את התוצאות החיוביות השגויות למינימום.
ארגונים מנויים מקבלים הודעת אזהרה עבור רכיבים שהם משתמשים בהם, באופן ישיר או עקיף, כאשר גרסה זדונית מסווגת. לאחר מכן, האנליסטים שלנו מבצעים ניתוח ידני, המאשר או דוחה את הסיווג. עבור תוכנות זדוניות שאושרו, הרישום הציבורי מקבל הודעה כדי שיוכל לבצע ניתוח משלו ובדרך כלל להסיר את הגרסה הזדונית או לנקוט בפעולות נוספות, כגון חסימה או הסרה של חשבון המשתמש המדובר.
נסביר כיצד אנו עוזרים ל-NPM, PyPI, GitHub ותשתיות מפתח אחרות במערכת האקולוגית של קוד פתוח להפחית את זמן השהייה בו רכיב זדוני חדש שפורסם נשאר פעיל עד שהוא מאומת כנושא זדוני ומוסר מהרישום. וכיצד ארגונים עשויים להפיק תועלת ממערכת MEW כדי לקבל הגנה טובה בהרבה מפני התקפות שרשרת אספקה של תוכנה הכוללות רכיבי קוד פתוח.
- [1] בכל מקרה, משתמשי הרכיב צריכים לבדוק אם קובץ ה-tarball של הרכיב מאוחסן במטמון או רשום איפשהו, למשל ברישום פנימי, כדי שהמחלה תימחק.
- [2] הרכיב הארוז כולל מניפסט המצהיר על תוכנו ומטא-דאטה, קוד מקור או קוד מהודר, סקריפטי התקנה ופריטים נוספים כגון חבילות בדיקה, בהתאם לפורמט אריזה ובדרך כלל בצורה דחוסה. זה נקרא "tarball של רכיב".
- [3] אפילו אם הגורם הזדוני יכול לשנות רכיב שפורסם עקב פרצה ברישום עצמו, תקציר קריפטוגרפי רגיל יכול לזהות כל שינוי בקובץ ה-tarball לאחר סיום הניתוח.
- [4] זכור שחלק מהרכיבים הזדוניים פועלים בזמן ההתקנה, כך שהם יכולים להשפיע על צמתי מפתחים שמריצים בלי משים "npm install X" כאשר X הוא רכיב זדוני.
