ככל שפיתוח תוכנה מתקדם לאורך מחזור החיים של שרשרת האספקה של התוכנה, שלב החבילה מתגלה כצומת מרכזי, בהמרת קוד מקור לפריטים ניתנים לביצוע המוכנים להפצה. עם זאת, שלב קריטי זה אינו חסין מפני פגיעויות, מה שהופך אותו למטרה עיקרית עבור גורמים זדוניים המבקשים לערער את שלמות התוכנה ואבטחתה. פוסט זה בבלוג מתעמק באיומים הנפוצים שיכולים להתעורר במהלך שלב זה ומתאר אסטרטגיות יעילות לצמצוםם. תוכן זה משמש כהמשך לסדרת הבלוגים שלנו, הבוחנת... software supply chain security מעבר SDLC.
שלב החבילה במחזור חיי פיתוח התוכנה
שלב האריזה במחזור החיים של שרשרת האספקה של התוכנה כולל את תהליך האריזה וההכנה של התוכנה להפצה למשתמשים. שלב זה כולל יצירת חבילות התקנה, ניהול תלויות ויצירת מטא-דאטה עבור התוכנה.
איומי שלמות בנייה (Build Integrity) הם פגיעויות שעלולות לאפשר לתוקפים לבצע שינויים לא מורשים בתוכנה במהלך תהליך האריזה. איומים אלה יכולים להופיע באמצעות שיטות שונות, כגון פגיעה ברישום החבילות, ניצול פגיעויות בכלי אריזה או מניפולציה של תלויות של צד שלישי.
התלות המוחלטת ברכיבי קוד פתוח בתוכנה מודרנית הפכה את השלב הזה לשלב הנפוץ ביותר של SSCA מטרה. הכנסת תוכנות זדוניות חמקניות לרכיב קוד פתוח פופולרי היא חלום עבור פושעי סייבר רבים. זו הסיבה שיותר מ 245,000 חבילות זדוניות נמצאו במהלך 2023.
דוגמאות של Software Supply Chain Security איומים בשלב החבילה
השתמש בחבילה שנפגעה
זה מתייחס לפעולה של פריסה או שימוש בחבילת תוכנה אשר טופלה או שונתה על ידי יריב.
זה יכול לקרות לאחר שהחבילה עזבה את רישום החבילות הרשמי, בין אם באמצעות גישה ישירה למערכת של המשתמש ובין אם באמצעות טקטיקות של הנדסה חברתית שמטעות את המשתמש להוריד או להתקין חבילה זדונית. דוגמה לווקטור זה הייתה דפדפן קלקול הקלדה לִתְקוֹף.
תוקף, שביקש לפגוע במערכות לינוקס ומק, חדר לתהליך הפיתוח של ספריית Node.js פופולרית בשם Browserify. התוקף החליק קוד זדוני לקוד המקור של הפרויקט, מתוך כוונה להפיץ אותו דרך רישום החבילות של NPM. לאחר שחבילת Browserify המוכתמת הועלתה ל-NPM, מפתחים תמימים היו מורידים ומתקינים אותה, מתוך אמונה שזו הגרסה הלגיטימית. הקוד הזדוני, המוטמע בתוך החבילה, היה פועל בשקט, ויפגע בשלמות המערכות שהדביק. הדבר עלול להוביל לגניבת נתונים, חוסר יציבות במערכת או אפילו גישה מרחוק עבור התוקף.
רישום חבילות פגיעה
רישום חבילות פרוץ הוא מאגר תוכנה שחודר על ידי יריב שקיבל גישה בלתי מורשית לממשק הניהולי או לתשתית של הרישום.
זה מאפשר ליריב לשנות או להחליף חבילות תוכנה לגיטימיות בתוכנות זדוניות, אותן ניתן לאחר מכן להפיץ למשתמשים שהותקנו באופן תמים. דוגמה לסוג זה של איום הייתה התקפה על מראות חבילה: חוקר, במטרה לקדם תוכנות קוד פתוח, פרץ למספר מאגרי מידע פופולריים, כולל Maven Central, NPM ו-RubyGems. באמצעות גישה למאגרים אלו, החוקר הצליח ליצור מראות והעתקים של המאגרים המקוריים, שסיפקו אלטרנטיבה נוחה למפתחים להורדת חבילות.
עם זאת, למראות אלו הייתה מטרה זדונית. המראות שנפרצו שימשו כצינורות עבור החוקר להפצת חבילות זדוניות. חבילות אלו החליפו חבילות לגיטימיות, שלא זוהו על ידי הרישומים הראשוניים, ומפתחים תמימים הורידו והתקינו אותן מבלי דעת. לאחר ההתקנה, חבילות זדוניות אלו שחררו את המטען שלהן, ביצעו קוד שרירותי, גנבו מידע רגיש או שיבשו פעולות.
העלאת חבילה שונה
גורם יריב מעלה חבילה שעברה שינוי למאגר או לערוץ הפצה המכילה קוד זדוני או מטענים. ניתן לעשות זאת על ידי שינוי קוד המקור, האריזה או המטא-דאטה של החבילה.
אחד האיום הידוע לשמצה ביותר מסוג זה היה מתקפת CodeCov בשנת 2021. תוקף, המבקש לפגוע בפרויקטים של תוכנה באמצעות CodeCov, שיטת אינטגרציה רציפה ומסירה רציפה פופולרית (CI/CDכלי ) השתמש בפרטי גישה שדלפו כדי לקבל גישה לא מורשית לדלי Google Cloud Storage (GCS) של פרויקט. לאחר שהתוקף קיבל גישה לדלי GCS, הוא העלה חפץ זדוני, גרסה שונה של חבילת CodeCov, אשר הופצה לאחר מכן למשתמשים דרך שירות CodeCov. מפתחים תמימים, שהסתמכו על תכונת העדכונים האוטומטיים, היו מורידים ומתקינים את החבילה הזדונית, מתוך אמונה שזו החבילה הלגיטימית. לאחר ההתקנה, הקוד הזדוני היה פועל בשקט, ויפגע בשלמות המערכות שהוא הדביק. זה עלול להוביל לגניבת נתונים, חוסר יציבות במערכת או אפילו גישה מרחוק עבור התוקף.
התקפות על רישומי החבילות הן כה נפוצות עד שכמה דפוסי תקיפה קיבלו שם:
In Tposposquatting, הגורם הרע מעלה לרישום מספר חבילות זדוניות עם שגיאות הקלדה קלות או שמות דומים לחבילות לגיטימיות ופופולריות, בתקווה שהמפתחים יטעו את שם החבילה המיועד עם שם זדוני. לעתים קרובות החבילה הזדונית מתחזה לחבילה לגיטימית ועוברת מבלי להתגלות, מה שמגדיל את הסבירות להיפגע מצפייה בכוכבים.
בלבול תלות ממנף את האופן שבו מנהלי חבילות מסוימים פותרים את החבילות המבוקשות ממספר רישומים. כאשר ארגון משתמש ברכיבים פנימיים שפורסמו ברישום פנימי, תוקף שיודע זאת עלול לפרסם רכיב זדוני בעל אותו שם ברישום ציבורי. אם השם בו נעשה שימוש עבור הרכיב הפנימי אינו מוגדר, מנהלי חבילות מסוימים יאחזרו את הרכיב הזדוני במקום את הרכיב הפנימי.
עם B&B בטרויאן, פושע הסייבר מסווה תוכנה זדונית בין קוד תקין ושימושי. קוד זה יכול לשמש את המחבר האמיתי, או את תורם המציע את עצמו לתחזק את החבילה. זה ידוע גם כ חטיפת חבילותתוקפים השתמשו בטכניקות רבות כדי לחטוף חבילה קיימת, כמו השתלטות על דומיין כאשר דומיין נטוש שפג תוקפו נלקח על ידי התוקף, שיצר מחדש את כתובת הדוא"ל הישנה של המתחזק וביצע שחזור סיסמה כדי להשתלט על חשבון המתחזק.
הערות אחרונות
ככל שארגונים מאמצים יותר ויותר מתודולוגיות פיתוח תוכנה המעניקות עדיפות לאוטומציה ומסירה רציפה, החשיבות של אבטחת שלב חבילת התוכנה מעולם לא הייתה חשובה יותר. על ידי יישום אמצעי אבטחה חזקים לאורך שלב קריטי זה, ארגונים יכולים להפחית באופן משמעותי את הסיכון להיכנע להתקפות זדוניות שעלולות לפגוע בשלמות ובאבטחה של התוכנה שלהם.
האסטרטגיות המתוארות בפוסט זה בבלוג, יחד עם הדוגמאות שסופקו, משמשות תזכורת חדה לכך ששלב האריזה מייצג נקודה פגיעה בשרשרת אספקת התוכנה. ארגונים חייבים לשים לב לאיומים אלה וליישם את אמצעי האבטחה הדרושים כדי להגן על התוכנה שלהם מפני תקיפה. בכך, הם יכולים להבטיח את שלמותה, אבטחתה ואמינותה של התוכנה שלהם עבור המשתמשים והלקוחות שלהם.
הצטרפו למסע שלנו לעבר מערכת תוכנה מאובטחת
אל תפספסו את ההזדמנות להישאר צעד אחד קדימה בתחום software supply chain securityהירשמו לבלוג שלנו עוד היום והיו בין הראשונים לקבל את התובנות האחרונות שלנו, כדי להבטיח שהארגון שלכם יישאר עמיד ומאובטח אל מול איומים מתפתחים. יחד, נוכל לבנות מערכת אקולוגית תוכנה חזקה ומאובטחת יותר עבור כולם.
זכור, software supply chain security הוא מסע מתמשך, לא יעד. על ידי הערכה מתמדת והתאמה של נהלי אבטחה כדי להתמודד עם איומים מתעוררים, ארגונים יכולים להגן על שרשרת אספקת התוכנה שלהם ולספק תוכנה אמינה למשתמשים שלהם.
צפו בהדגמת הווידאו שלנו
