תשובה מהירה: מתקפות שרשרת אספקה Npm פועלות על ידי פגיעה בחשבון מתחזק מהימן או CI/CD אסימון, פרסום גרסה זדונית של חבילה שמפתחים כבר סומכים עליה, ונתינה לסקריפטי ההתקנה או לוגיקת התולעת של החבילה לעשות את השאר. בין אוגוסט 2025 לאמצע 2026, דפוס זה יצר את גל התקפות שרשרת האספקה הגדול ביותר של חבילות npm בהיסטוריה של הרישום, כולל חטיפת chalk/debug, ה- תולעת שי-חולודותוכנה זדונית של מדינות לאומיות המוסתרת בחבילה שהורדת 100 מיליון פעמים בשבוע. התיקון אינו סורק קוד לאחר שהוא מגיע. הוא לוכד חבילות זדוניות לפני שהן מותקנות וצופה ב... pipeline עבור ההתנהגות המדויקת שמשתפת התקפות אלו.
כל התקנה היא מעשה של אמון, והתוקפים יודעים זאת
מפתח רץ התקנת npmמאחורי הפקודה הזו יש עץ תלויות עם מאות, לפעמים אלפי, חבילות, שרובן נכתבו ומתוחזקות על ידי אנשים שהמפתח לעולם לא יפגוש. אף אחד לא סוקר את העץ הזה שורה אחר שורה. לאף אחד אין זמן לעשות זאת.
האמון הזה הוא המטרה. זול יותר לתוקף לבצע פישינג על מתחזק npm אחד עם 2.6 מיליארד הורדות שבועיות מאשר למצוא תקיפה של יום אפס בחומת אש של Fortune 500. התקפות שרשרת אספקה של NPM מנצלות בדיוק את האסימטריה הזו, וגל 2025-2026 מראה עד כמה הניצול הזה התרחב: מ... טיפוסקווט מבודד לתולעים המתפשטות מעצמן שמפרסמים את החבילות הזדוניות שלהם מהר יותר מכל אדם שיכול להגיב.
מה נחשב כהתקפת שרשרת אספקה של NPM
מתקפת שרשרת אספקה של npm היא כל אירוע שבו תוקף מכניס קוד זדוני להפצת npm. pipeline במקום לבסיס הקוד של היעד עצמו, כך שהתוכנה הזדונית מגיעה במסווה של עדכון תלות שגרתי. נקודת הכניסה היא בדרך כלל אחת משלושה דברים: אישורים גנובים של מתחזק, פרסום גנוב או CI/CD אסימון, או בנייה שנפגעה pipeline שמושטה לפרסם בשמו של התוקף. מכיוון שחבילות npm מושכות תלויות טרנזיטיביות באופן אוטומטי, חבילה אחת שנפרצה יכולה להגיע ליישומים שמעולם לא הכריזו עליה כתלות ישירה כלל.
ציר זמן: מתקפות שרשרת האספקה הגדולות ביותר של npm בשנים 2025-2026
הדפוס מאחורי כל מתקפת שרשרת אספקה של חבילות NPM
הסירו את הפרטים הקטנים, וכמעט כל אירוע לעיל יבוצע באותם ארבעה שלבים:
- להתפשר על זהות, לא על מערכת. מתחזק שנגרם על ידי פישינג, אסימון npm שדלף, PAT גנוב של GitHub, או אסימון OIDC שנשלף מ- CI/CD זיכרון של רנר. התוקף לא פורץ את הרישום. הוא שואל את המפתח של מישהו אליו.
- פרסם תחת שם שמפתחים כבר סומכים עליו. אין צורך ב-typosquatting כאשר שם החבילה האמיתי עובד. זה מה שהופך את ההתקפות הללו ליעילות כל כך כנגד עדכונים אוטומטיים. pipelineש: העדכון נראה לגיטימי לחלוטין.
- רוץ לפני שמישהו יבצע ביקורת על זה. סקריפטי התקנה זדוניים, מטענים מעורפלים או קוד רדום שמופעל רק בתנאים ספציפיים מבצעים את הרגע התקנת npm פועל, לעתים קרובות על מחשב נייד של מפתח, הרבה לפני שסריקת אבטחה מתוזמנת תראה אותו אי פעם.
- להתמיד, ובהדרגה, להתפשט. שי-חולוד וצאצאיו משתמשים באישורים שהם גונבים כדי לפרסם את החבילה המורעלת הבאה באופן אוטומטי, מה שהופך פשרה בודדת לתגובת שרשרת על פני גרף התלות.
למה ההגנות הרגילות מפספסות את זה
רוב כלי ה-AppSec נבנו כדי לנתח את מה שכבר נמצא במאגר: CVEs ידועים, דפוסי קוד סטטיים, בעיות רישיון. זה הכרחי, אבל מבחינה מבנית זה מגיע מאוחר מדי עבור סוג התקפה זה. עד שסורק רואה תלות, ייתכן שסקריפט ההתקנה כבר בוצע במחשב של המפתח. אנטי-וירוס מסורתי ו-EDR צופים במערכת ההפעלה, לא ברישומי חבילות, כך שאין להם מושג של "מהדורת npm חדשה" כיחידת סיכון. וכפי שמראים אירועי TanStack ו-Red Hat, אפילו אימותי שלמות בנייה כמו... SLSA provenance לא עוזרים כאשר התוקף לכד באופן לגיטימי את הזהות שחותמת עליו: החתימה תקפה, החבילה עדיין זדונית.
הפער שמנצלות התקפות שרשרת האספקה של npm נמצא ספציפית בזמן הפרסום ובהתקנה, לפני שקיימת חתימה עבור הנוזקה ולפני שהחבילה רצה בכל מקום שבו סורק מסורתי היה מחפש.
כיצד לעצור את מתקפת שרשרת האספקה הבאה של npm
חלק מזה הוא משמעת תהליכית שכל צוות הנדסה יכול לאמץ כיום:
- תלויות סיכה ו commit קבצי נעילה, כך שעדכון אוטומטי לא יכול למשוך בשקט גרסה זדונית שזה עתה פורסמה.
- השבת או ארגז חול של סקריפטים לאחר התקנה כברירת מחדל; רוב החבילות אינן צריכות לבצע קוד שרירותי בזמן ההתקנה.
- אכיפת MFA מגובה חומרה עבור חשבונות פרסום npmוסגר את נתיב הפישינג המדויק שפגע ב- chalk, debug ובחשבון של Qix.
- היקף וסיבוב CI/CD אסימונים בצורה אגרסיבית, ולהתייחס לאסימוני OIDC בזיכרון הרצים כאל אישור שכדאי להגן עליו, לא כפרט מימוש.
- שימו לב לדפוס הפתיחה-הזרקה-נעילה מחדש in CI/CDכלל הגנה על ענפים מושבת, א commit דחף, הכלל הופעל מחדש, והכל בחלון זמן מוגבל. זוהי חתימה חוזרת של pipelineפשרה בשרשרת האספקה ברמה -.
היכן שמשמעת התהליך נגמרת
משמעת תהליכית מפחיתה חשיפה. היא לא תופסת חבילה זדונית ברגע שהיא מתפרסמת, והיא לא תופסת תולעת שכבר מתפשטת בגרף מהר יותר ממה שאדם יכול לבחון. זוהי השכבה שלשמה בנויה אבטחת שרשרת האספקה של Xygeni.
קסיגני'ס MEW (אזהרה מוקדמת מפני תוכנות זדוניות) מנתח באופן רציף חבילות חדשות שפורסמו ב-npm, PyPI ו-Maven, לוכד תוכנות זדוניות לפני שחתימה קיימת ולא אחריה, ומזין איומים מאומתים בחזרה לתוכן. קסיגני'ס מנוע גילוי משלו. ה- חומת אש של תלות סורק את npm, PyPI, Maven, NuGet ו-RubyGems בזמן אמת וחוסם התקנות זדוניות לפני שהן מגיעות למחשב של מפתח או לבנייה. CI/CD גילוי חריגות שעונים pipelineבדיוק את דפוס ההתנהגות מאחורי אירועים כמו פשרת TanStack, כולל רצף הפתיחה-הזרקה-הנעילה מחדש, עם נתיב ביקורת מלא. ומכיוון ש-Xygeni מיון ותיקון מבוססי בינה מלאכותית אם יחול גם על ממצאים מסורקים של צד שלישי, צוותים לא צריכים להוציא כלים קיימים כדי לסגור את הפער הזה.
שאלות נפוצות: התקפות שרשרת אספקה npm
מהי מתקפת שרשרת אספקה ב-NPM?
זוהי התקפה שבה קוד זדוני מגיע ליישום יעד דרך תלות npm מהימנה ולא דרך הקוד של היעד עצמו, בדרך כלל משום שתוקף פרץ לחשבון של מתחזק, לטוקן פרסום או ל... CI/CD pipelineהזהות.
מה הייתה מתקפת שרשרת האספקה הגדולה ביותר של NPM?
לפי רדיוס הפיצוץ, חטיפת ה-chalk/debug בספטמבר 2025 היא בין הגדולות ביותר: 18 חבילות עם 2.6 מיליארד הורדות שבועיות יחד נפגעו דרך חשבון מתחזק יחיד. בחידוש טכני, שי-חולוד הייתה נקודת המפנה המשמעותית יותר, כתולעת הראשונה שהתפשטה מעצמה בהיסטוריה של npm.
כיצד מתחילה בדרך כלל מתקפת שרשרת אספקה של חבילות NPM?
כמעט תמיד עם זהות גנובה: מתחזק באמצעות פישינג, אסימון פרסום שהודלף, או זהות גנובה CI/CD אישורים כגון אסימון OIDC שנשלף מזיכרון של רץ, ולא פריצה טכנית ל-npm עצמו.
האם אנטי-וירוס או EDR יכולים לעצור מתקפת שרשרת אספקה של NPM?
לא באופן אמין. EDR מנטר את מערכת ההפעלה ואינו מבין רישומי חבילות, ואנטי-וירוס מבוסס על חתימות, מה שנכשל כנגד תוכנות זדוניות שפורסמו לפני שקיימת חתימה כלשהי. עצירת סוג תקיפה זה דורשת ניטור בנקודת הפרסום וההתקנה, לא רק בנקודת הקצה.
האם SLSA provenance או לבנות אישורים כדי למנוע זאת?
זה מוכיח את pipeline זה לא מוכיח שהזהות שהפעילה את הבנייה לא נפגעה, כפי שהוכיחו תקריות TanStack ו-Red Hat עם אימותים תקפים המצורפים לחבילות זדוניות.
כיצד יכול צוות לזהות חבילת npm זדונית לפני התקנתה?
על ידי הפעלת ניתוח רציף של תוכנות זדוניות לפני חתימה על חבילות שפורסמו לאחרונה, וזה מה שמערכת התרעה מוקדמת מפני תוכנות זדוניות וחומת אש תלויות נועדו לעשות, במקום להסתמך אך ורק על סריקת פגיעויות לאחר מכן של קוד שכבר נמצא במאגר.
איפה להתחיל
מתקפות שרשרת האספקה של NPM אינן מאטות, וקו המגמה מאז שי-חולוד מצביע על יותר אוטומציה, לא פחות. הצוותים הממוצבים בצורה הטובה ביותר לקמפיין הבא הם אלה שהפסיקו להתייחס לכל התקנת NPM כאירוע שגרתי והחלו לעקוב אחר הרישום, ה... pipeline, ונקודת הקצה כמשטח התקפה אחד מחובר.
תוכנית המפתחים של Xygeni כוללת כיסוי של MEW וחומת אש תלויה עבור עד 25 מאגרים ללא עלות. זהו מקום סביר לראות מה כבר נמצא בעץ תלויות.
