מתקפת שרשרת אספקה ב-npm: כשהאמון בקוד פתוח הופך לנשק

פורסם ב-9 בספטמבר 2025

מבוא

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

תוקפים פרצו לחבילות npm בשימוש נרחב, ובהן chalk ו-debug, שיחד מגיעות ל-יותר מ-2.6 מיליארד הורדות בכל שבוע. ההשלכות עצומות: כל מפתח, כל pipeline וכל ארגון שמושכים את התלויות האלה עלולים להיות בסיכון.

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

מה קרה: פירוט צעד אחר צעד

1. הפישינג

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

2. השתלטות על החשבון

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

3. הרעלת החבילות

התוקפים העלו גרסאות זדוניות חדשות של חבילות פופולריות מאוד כמו chalk ו-debug. מיליוני מפתחים ו-pipelines של CI/CD משכו אוטומטית את הגרסאות האלה במהלך בניות רגילות.

4. הפצה שקטה

בניגוד לקמפיינים רגילים של נוזקות, לא היה צורך “להפיץ” את ה-payload. מנהל החבילות של npm עשה את זה בשבילם. זה הכוח, והסכנה, של קוד פתוח: ספרייה מורעלת אחת יכולה להתפשט בכל המערכת הגלובלית בתוך שעות.

5. הרצת ה-payload

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

6. השפעה גלובלית

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

מי נמצא בסיכון?

מפתחים: שמושכים חבילות npm ישירות או דרך תלויות עקיפות.
Build pipelines: תהליכי CI/CD אוטומטיים שסומכים באופן מובלע על מאגרי npm.
ארגונים: ארגונים שהאפליקציות או הכלים הפנימיים שלהם נשענים על ספריות שנפרצו.
משתמשי קצה: הקורבנות האחרונים בשרשרת, כשאפליקציות מורעלות נפרסות לייצור.

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

למה זה חשוב: לקחים מהמתקפה

1. אמון הוא החוליה החלשה ביותר. כל מערכת npm בנויה על אמון במתחזקים. כשמתחזק אחד נפרץ, אפשר להפוך מיליארדי הורדות לנשק.

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

3. אוטומציה מגדילה את הסיכון. מערכות CI/CD נועדו למהירות ולא לבדיקה מדוקדקת. כשהן מושכות אוטומטית תלויות מורעלות, רדיוס הנזק גדל מיד.

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

מה כדאי לעשות עכשיו

פעולות מיידיות:

בצעו audit לתלויות: בדקו אם הארגון שלכם משתמש ב-chalk, ב-debug או בחבילות אחרות שנפרצו.
עדכנו ותקנו: משכו את הגרסאות הנקיות העדכניות ונעלו את התלויות לגרסאות מאומתות.
החליפו סודות (rotate secrets): אם מערכות בנייה או אפליקציות השתמשו בספריות מורעלות, החליפו מפתחות API ופרטי גישה.
חזקו את חשבונות המפתחים: חייבו MFA עמיד בפני פישינג בחשבונות npm ו-GitHub.
סקרו את לוגי ה-pipeline: חפשו משיכות חבילות חריגות, בניות חריגות או תעבורה הקשורה לקריפטו.

אסטרטגיות לטווח ארוך:

Code Signing ו-Sigstore: אמצו טכנולוגיות שמבטיחות את שלמות החבילות.
ניטור metadata: סמנו חריגות כמו קפיצות פתאומיות בגרסאות או החלפת מתחזקים.
דירוג סיכון ספקים: הערכו תלויות לפי פעילות המתחזק, הממשל והמצב האבטחתי.
נראות בשרשרת האספקה: הטמיעו כלים שממפים את עץ התלויות שלכם ומנטרים אותו באופן רציף.
מודעות מפתחים: אמנו מפתחים לזהות מיילי פישינג שמכוונים למתחזקי חבילות.

מילות סיכום

מתקפת ה-npm של ספטמבר 2025 היא לא האחרונה, היא הנורמה החדשה. כשתוקפים עוברים “שמאלה” אל שרשרת האספקה של התוכנה, המגינים חייבים לעשות את אותו הדבר.

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

עכשיו הזמן לפעול. בצעו audit לתלויות, חזקו את ה-pipelines, והשקיעו בכלים ובתהליכים שנותנים לכם נראות בכל שרשרת האספקה של התוכנה.

קריאה נוספת

נסו את Griffin31

הגדרות עוגיות · מדיניות פרטיות