TL;DR: אבטחת שרשרת אספקה של npm מעבר לסורק הפגיעויות
אבטחת שרשרת אספקה של npm היא נוהג של לוודא שכל חבילה שמתקינים בפרויקטי ה-JavaScript שלך היא לגיטימית, ללא שינוי ובטוחה. לא רק נקי מפגיעויות ידועות.
- הפער: סורק פגיעויות קלאסי של npm מתאים חבילות לבסיסי נתונים של CVE. לחבילה זדונית אין CVE, ולכן היא עוברת.
- ההוכחה: במרץ 2026, חשבון מתחזק שנחטף הפך את axios, עם למעלה מ-100 מיליון הורדות שבועיות, לערוץ העברת תוכנות זדוניות למשך כשלוש שעות.
- נקודת הכניסה: רוב התקפות ה-npm פועלות דרך סקריפטי התקנה, אשר מבוצעים ברגע שאתה מקליד
npm install. - התיקון: לזהות התנהגות זדונית בעת פרסום חבילות, לא לאחר הופעת CVE, ולהקשח את אופן ביצוע ההתקנות.
ב-31 במרץ 2026, אלפי מפתחים הריצו את הפקודה הכי רגילה ב-JavaScript: npm installחלקם משכו גרסה חדשה של axios, לקוח ה-HTTP שיושב בחלק עצום מיישומי האינטרנט בעולם. סורקי התלות שלהם נשארו ירוקים. הבניות שלהם עברו את התקדמותן. וטרויאן גישה מרחוק נחת בשקט על המכונות שלהם.
שום דבר בסיפור הזה לא כלל פגיעות. זו בדיוק הסיבה שכל כך הרבה תוכניות אבטחה של npm החמיצו אותה.
מה קרה לאקסיוס
ההתקפה הייתה פשוטה וסבלנית. לדברי ניתוח שלאחר המוות של מתחזקי axios, שתי גרסאות זדוניות, 1.14.1 ו-0.30.4, פורסמו דרך החשבון הפרוץ של מנהל המערכת. התוקף לא נגע בשורת קוד אחת של axios. הם הוסיפו תלות חדשה אחת, plain-crypto-js, אשר ניהל א postinstall סקריפט שהביא מטען של שלב שני.
מודיעין האיומים של מיקרוסופט ייחס את התשתית לספיר סליט, שחקן מדינה צפון קוריאני. הגרסאות המורעלות היו זמינות במשך כשלוש שעות לפני ש-npm הסירה אותן. עבור כל CI pipeline או מחשב נייד שהותקן במהלך חלון הזמן הזה, שלוש שעות הספיקו.
זה לא היה מקרה בודד. בספטמבר 2025, תולעת שי-חולוד התפשטה על פני מאות חבילות npm על ידי גניבת טוקנים של מתחזקים ופרסום מחדש של עצמה. טכניקה שונה, אותו לקח: ב-npm, אמון עובר בירושה באופן אוטומטי, והתוקפים יודעים זאת.
למה סורק הפגיעויות של ה-npm שלך לא אמר כלום
רוב הצוותים מתייחסים לאבטחת שרשרת האספקה של npm כבעיית פגיעות. הם מפעילים סורק פגיעויות npm, הוא משווה את עץ התלות שלהם לבסיסי נתונים של פגמים ידועים, והם מתקנים את מה שהוא מדווח. עבודה זו חשובה. היא פשוט עונה על שאלה אחרת.
| מֵמַד | חבילה פגיעה | חבילה זדונית |
|---|---|---|
| מה זה | קוד לגיטימי עם באג | קוד שנכתב כדי לפגוע בך |
| יש לו CVE? | בדרך כלל, בסופו של דבר | כמעט אף פעם |
| כשזה מסוכן | כאשר הפגם ניתן להשגה ומנוצל | ברגע שהוא מותקן |
| מה תופס את זה | חיפוש מסד נתונים של פגיעויות | ניתוח התנהגות של החבילה עצמה |
| זמן תגובה טיפוסי נדרש | ימים עד שבועות | דקות עד שעות |
מסד נתונים של פגיעויות יכול לתאר רק משהו שמישהו כבר ניתח וקטלג. חבילה זדונית שפורסמה לפני שעה לא מקבלת כניסה לשום מקום. לכן, הסורק מחזיר קביעה נקייה, והקביעה "נקייה" נקראת כבטוחה.
זהו השינוי המרכזי באבטחת שרשרת האספקה של npm: השאלה אינה עוד "האם לחבילה הזו יש פגם ידוע?" אלא "האם החבילה הזו עושה משהו שהיא לא אמורה לעשות?"
ארבע דרכים בהן תוקפים חודרים ל-node_modules שלכם
- השתלטות על חשבון. לגנוב את פרטי ההרשאות או הטוקן של מתחזק ולפרסם גרסה מורעלת של חבילה שאנשים כבר סומכים עליה. זהו ספר ההדרכה של axios, והוא הקשה ביותר לזיהוי, כי שם החבילה הוא בדיוק נכון.
- Tposposquatting. לפרסם
axoisorreqeustsולחכות לשגיאת הקלדה, העתקה-הדבקה ממדריך גרוע, או עוזר קידוד של בינה מלאכותית שיציע את השם הלא נכון. - בלבול תלות. פרסם חבילה ציבורית עם אותו שם כמו אחת החבילות הפנימיות שלך. אם הגדרת הרישום שלך מעדיפה את החבילות הציבוריות, עליך להתקין את הקוד של התוקף.
- התקנת סקריפטים. החוט המשותף כמעט בכל האמור לעיל. npm מאפשר לחבילות לרוץ
preinstallוpostinstallסקריפטים באופן אוטומטי, כך שקוד זדוני יבוצע לפני שמישהו ייבא משהו. CISההנחיות של A לגבי פשרת האקסיוס ממליץ על הגדרהignore-scripts=trueעבור טרוםcisבגלל הסיבה הזו.
כיצד נראית אבטחת שרשרת האספקה של npm בפועל
לא תעצור כל התקפה בעזרת שליטה אחת. אתה יכול להפוך את עצמך למטרה קשה הרבה יותר בעזרת כמה הרגלים:
- Commit קובץ הנעילה שלך והתקן אותו עם
npm ci. גרסאות בנייה צריכות להתקין בדיוק את מה שנבדק, לעולם לא את מה שהוגדר ברישום באותו בוקר. - השבת סקריפטים להתקנה כברירת מחדל. לקבוע
ignore-scripts=trueולאפשר סקריפטים רק עבור החבילות שבאמת זקוקות להם. - הגדרת היקף החבילות הפנימיות שלך שמות פנימיים לא מוגדרים הם הזמנה פתוחה לבלבול בין תלויות.
- בדוק את המקור. תומכי npm הצהרות מקור שמקשרים חבילה שפורסמה למקור ולגרסה שלה. שחרור פתאומי בלעדיהם, מפרויקט שבדרך כלל מכיל אותם, הוא דגל אדום שכדאי להפוך לאוטומטי.
- שלבו סריקת פגיעויות עם זיהוי תוכנות זדוניות. שמרו על סורק הפגיעויות של npm שלכם לאיתור פגמים ידועים, והוסיפו זיהוי שמנתח מה חבילות חדשות באמת עושות.
ההרגל החמישי הוא זה שרוב הקבוצות מדלגות עליו, והוא זה שחשפה מתקפת האקסיוס.
תפוס את החבילה הזדונית לפני שיהיה לה שם
קסיגני'ס התרעה מוקדמת מפני תוכנות זדוניות (MEW) סורק חבילות חדשות ברישומים ציבוריים, כולל npm, מיד עם פרסומן, ומנתח את התנהגות הקוד שלהן במקום להמתין לחתימה ידועה. כאשר חבילה מסומנת, משתמשים מושפעים מקבלים הודעה באמצעות דוא"ל, פלטפורמות העברת הודעות או אינטרנט.hooksוהחבילה נמצאת בבידוד, כך אתה יכול לעצור את זה במקום שלך CI/CD guardrails.
סביבו, קסיגני'ס open source security לוכד את שאר הדברים שעליהם מסתמכים ארבעת נתיבי ההתקפה הנ"ל: typosquatting, בלבול תלויות, סקריפטי התקנה חשודים ורכיבי npm פנימיים לא מוגדרים. הוא מכסה גם פגיעויות ידועות מייעוץ NVD, OSV ו-GitHub, עם עדיפות לפי נגישות כך שתוכל לתקן את מה שבאמת ניתן לניצול, עם גישה אוטומטית. pull requests עבור התיקונים.
MEW כלול בתוכנית החינמית למפתחים. התחל בחינם וסרוק את פרויקטי ה-npm הראשונים שלך תוך דקות.
שאלות נפוצות
מהי אבטחת שרשרת אספקה של NPM?
אבטחת שרשרת האספקה של npm מכסה כל סיכון שמוצג דרך החבילות שעליהן תלויים פרויקטי ה-JavaScript שלך: פגיעויות ידועות, חבילות זדוניות, חשבונות מתחזקים שנפגעו, typosquatting ובלבול תלויות. זה הולך מעבר לסריקת פגיעויות כדי לוודא שמה שאתה מתקין הוא לגיטימי.
האם סורק פגיעויות של npm מזהה תוכנות זדוניות?
בדרך כלל לא. סורק פגיעויות מסורתי של npm בודק חבילות מול מסדי נתונים של פגיעויות ידועות. חבילה זדונית שפורסמה לאחרונה אינה מכילה ערך מסד נתונים, ולכן היא עוברת אלא אם כן הכלי מנתח גם את התנהגות החבילה.
Is npm audit מספיק?
npm audit הוא בסיס חינמי ושימושי עבור פגיעויות ידועות. הוא אינו מזהה תוכנות זדוניות שפורסמו לאחרונה, typosquats או בלבול תלויות, והוא אינו אומר לך אם פונקציה פגיעה אכן ניתנת לגישה מהקוד שלך.
איך אני יודע אם חבילה היא זדונית?
סימני אזהרה כוללים סקריפטים להתקנה שמורידים או מבצעים קוד מרחוק, קוד מעורפל, קריאות רשת שאינן קשורות למטרת החבילה, תלות חדשה שמאגר המקור לעולם לא מפנה אליה, וגרסה ללא המקור שהפרויקט מפרסם בדרך כלל.
