מה קרה: פריצה שהפכה ספריות קוד לפצצות
חברת Red Hat דיווחה כי חשבון GitHub הרשמי שלה נפרץ, ובעקבות הפריצה הודבקו 32 ספריות npm השייכות לארגון @redhat-cloud-services. הספריות הוחדרו בנוזקה שמטרתה גניבת סיסמאות ממשתמשים שמתקינים אותן בסביבות הפיתוח שלהם.
לפי הדיווח, הנוזקה שהוזרקה לספריות מבוססת על קוד שמקורו בקמפיין הידוע בשם Mini Shai Hulud, שפורסם כקוד פתוח על ידי קבוצת TeamPCP. כלומר, התוקפים לא כתבו כלי תקיפה חדש מאפס, אלא עשו שימוש חוזר בכלי קיים ונגיש.
למה המקרה הזה חשוב לכל ארגון שמפתח תוכנה
המקרה של Red Hat ממחיש שורה של סיכוני אבטחה שכיחים שרלוונטיים לכל ארגון שמשתמש בתלויות קוד פתוח:
- שרשרת האספקה של הקוד היא משטח תקיפה. פריצה לחשבון אחד יכולה להפיץ קוד זדוני לעשרות ספריות בו-זמנית.
- ספריות ממקורות מוכרים אינן חסינות. המוניטין של המפרסם אינו ערובה לאבטחה, במיוחד כשחשבון הפצה נפרץ.
- כלי תקיפה פתוחים מנמיכים את רף הכניסה לתוקפים. שימוש בקוד קיים מאפשר לביצוע מהיר ויעיל של מתקפות מורכבות.
כיצד ארגונים יכולים להגן על עצמם
אירועים מסוג זה מחייבים יישום של בקרות אבטחה בשכבת שרשרת האספקה התוכנה:
- ביצוע סריקת אבטחה אוטומטית של ספריות צד שלישי לפני שילובן בסביבת הייצור.
- נעילת גרסאות (version pinning) ומניעת עדכון אוטומטי לספריות שלא עברו בדיקה.
- שימוש ב-Software Bill of Materials (SBOM) לניהול ומעקב אחר כל רכיבי הקוד הפעילים.
- הפעלת אימות דו-שלבי (MFA) על כל חשבונות ניהול הקוד, כולל GitHub ו-npm.
- ניטור פעיל אחר שינויים חריגים בספריות שמשתמשים בהן.
הקשר לפיתוח מערכות ליבה ארגוניות
בארגונים שבונים מערכות ליבה מותאמות אישית, הסיכון גדול אף יותר. שילוב ספרייה נגועה בתוך מערכת ERP, CRM או פלטפורמת ניהול נתונים פנימית עלול לחשוף מידע רגיש, סיסמאות ופרטי גישה של משתמשים רבים בבת אחת. ב-R.A.S Systems, בעת פיתוח מערכות מידע ארגוניות, מובנית בתהליך הפיתוח בדיקת אבטחה שיטתית של כל רכיב חיצוני, בדיוק כדי להימנע מאירועי שרשרת אספקה כגון זה.
המקרה של Red Hat הוא תזכורת שאבטחת קוד אינה נחלתם של ארגוני ענק בלבד. כל עסק שמשתמש בספריות קוד פתוח כחלק מסביבת הפיתוח שלו חייב לשלב בקרות אבטחה על שרשרת האספקה התוכנה כחלק שגרתי ממחזור חיי הפיתוח.