מתקפות שרשרת אספקה: כשהפריצה מגיעה דרך תוכנה שאתם סומכים עליה

תארו לעצמכם עסק שעשה הכול נכון. עדכן את כל המערכות, הפעיל אימות רב-שלבי, הצפין את הגיבויים, הדריך את העובדים לזהות פישינג. ואז, בבוקר אחד, המחשבים ננעלים בכופרה — לא כי מישהו פרץ את החומה שבניתם, אלא כי הכלי שספק ה-IT שלכם משתמש בו כדי לנהל את המחשבים שלכם מרחוק הפך בעצמו לנשק. התוקף לא היה צריך לעבור את ההגנות שלכם. הוא נכנס דרך הדלת שאתם בעצמכם פתחתם לו — עדכון תוכנה חתום, שירות שסמכתם עליו, ספק שנתתם לו מפתחות. זו מתקפת שרשרת אספקה (Supply Chain Attack), והיא אחת הצורות המתסכלות ביותר של פשע סייבר: היא עוקפת בדיוק את הדברים שהשקעתם בהם.

ארבעה מקרים שהגדירו את הבעיה

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

SolarWinds (2020) — כשהעדכון עצמו הורעל

SolarWinds מוכרת תוכנת ניהול רשת בשם Orion לארגונים גדולים ברחבי העולם. בתחילת 2020 חדרו תוקפים (מיוחסים לשירות המודיעין הרוסי, קבוצת APT29) למערכת הבנייה (build) של החברה והחדירו קוד זדוני — Sunburst — לתוך עדכון תוכנה חתום ולגיטימי לחלוטין. בין מרץ ליוני 2020 הופץ העדכון המורעל דרך מנגנון העדכונים הרשמי לכ-18,000 לקוחות של Orion. הגאונות המרושעת: הלקוחות התקינו את העדכון בדיוק כפי שצריך — מקור מהימן, חתימה תקינה, ״עשו הכול נכון״. בפועל, התוקפים ניצלו רק חלק קטן מהקורבנות למתקפה ממוקדת של ריגול, אבל המסר היה ברור: אפשר להרעיל את הצינור שדרכו מגיעים העדכונים שכולנו נשענים עליהם.

Kaseya (2021) — המקרה שנוגע ישירות לעסק הקטן

אם SolarWinds הייתה בעיה של אנטרפרייז, Kaseya היא הסיפור שכל עסק קטן צריך להכיר. Kaseya מייצרת כלי בשם VSA שספקי IT מנוהלים (MSP) משתמשים בו כדי לנהל מרחוק את המחשבים של הלקוחות שלהם — עסקים קטנים ובינוניים. ביולי 2021 ניצלה קבוצת הכופרה REvil פרצת zero-day ב-VSA, ודרך כ-60 ספקי MSP דחפה כופרה לבין 800 ל-1,500 עסקים במורד הזרם. שימו לב לשרשרת: העסקים האלה מעולם לא שמעו על Kaseya. הם שכרו ספק IT מקומי, סמכו עליו לנהל את המחשבים — והכלי שהספק שלהם השתמש בו הפך לצינור שדרכו הגיעה הכופרה ישירות לתחנות שלהם. התוקפים דרשו כופר של 70 מיליון דולר; Kaseya לא שילמה והשיגה כלי פענוח מגורם שלישי.

MOVEit (2023) — שרשרת של העברת קבצים

MOVEit Transfer היא תוכנה להעברת קבצים מאובטחת, שנמצאת בשימוש נרחב אצל ארגונים כדי להעביר מידע רגיש. במאי 2023 ניצלה קבוצת Cl0p פרצת zero-day מסוג SQL injection‏ (CVE-2023-34362) בתוכנה, ותוך זמן קצר גנבה מידע מיותר מ-2,700 ארגונים ומלמעלה מ-95 מיליון בני אדם. המקרה ממחיש וקטור נוסף: לא צריך להריץ קוד זדוני אצל הקורבן. מספיק לנצל פרצה במוצר תוכנה נפוץ שרבים משתמשים בו לאותה מטרה — וכל המשתמשים הופכים בבת אחת לקורבנות פוטנציאליים דרך אותה חולשה.

npm ‏(2025) — כשהחוליה החלשה היא חבילת קוד פתוח

כמעט כל אתר ואפליקציה בעולם בנויים על גבי חבילות קוד פתוח חינמיות. בספטמבר 2025 השתמשו תוקפים בקמפיין פישינג כדי להשתלט על חשבונות של מתחזקי חבילות (maintainers) פופולריות במאגר npm — ביניהן chalk ו-debug, שנספרות יחד בכ-2.6 מיליארד הורדות בשבוע. לחבילות הוזרק קוד שגונב ארנקי מטבעות קריפטו. בהמשך אותה שנה התפשט תולעת בשם Shai-Hulud שהדביקה מאות חבילות נוספות. הדפוס כאן שונה מהקודמים: התוקף לא מרעיל את הספק הגדול, אלא מתחזה או משתלט על מתחזק אחד של רכיב זעיר — שנמצא, בלי שידעתם, בעומק המערכות שאתם מריצים.

הפרק הישראלי — לא רק בעיה של אנטרפרייז אמריקאי

קל להסתכל על SolarWinds ו-MOVEit ולחשוב ״זה קורה לענקיות בחו״ל״. אבל בישראל יש כבר מקרה קלאסי משלנו. בנובמבר 2023, במהלך מלחמת חרבות ברזל, פרצה קבוצת Cyber Toufan (המיוחסת לגורמים איראניים) לחברת אחסון ואתרים ישראלית בשם Signature-IT — ספק אחד. דרך הפריצה הזו נחשף מידע של עשרות חברות ישראליות שהתארחו אצל אותו ספק, ביניהן איקאה ישראל (מידע על מעל 400 אלף משתמשים לפי טענת התוקפים), טויוטה ישראל וגופים ממשלתיים. אף אחת מהחברות האלה לא נפרצה ישירות — הן פשוט בחרו את אותו ספק אחסון.

וזה לא מקרה בודד. עוד ב-2021 קבוצת Black Shadow פרצה לחברת האחסון Cyberserve, וכך פגעה בבת אחת בעשרות לקוחות שהתארחו אצלה — כולל הדלפת מסד הנתונים של אפליקציית ההיכרויות אטרף. ולפי סיכום מערך הסייבר הלאומי לשנת 2025, פגיעויות בשרשרת האספקה נמנות עם שיטות הניצול המרכזיות שנרשמו נגד ארגונים ישראליים באותה שנה, לצד פישינג, נוזקות ומערכות לא מעודכנות. במילים אחרות: זה כבר לא תרחיש תיאורטי מחו״ל, זה חלק מנוף האיומים היומיומי כאן.

למה עסק קטן נמצא בתוך רדיוס הפגיעה, לא מחוצה לו

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

• אתם משתמשים באותם כלים וספקים בדיוק. אותו MSP שמנהל את המחשבים שלכם מנהל עוד עשרות עסקים. אותה חברת אחסון מארחת מאות אתרים. אותו רכיב קוד פתוח רץ במיליוני מערכות. ברגע שהתוקף מרעיל את הצומת המרכזי — אתם בפנים אוטומטית, בלי שעשיתם דבר ״לא נכון״. מקרה Kaseya הוא ההוכחה: קורבנות המתקפה היו בדיוק עסקים קטנים ובינוניים.
• אתם עצמכם שרשרת האספקה של מישהו. אם אתם מספקים תוכנה, שירות או אפילו ייעוץ ללקוחות גדולים יותר — אתם הספק שדרכו אפשר להגיע אליהם. זו הסיבה שלקוחות אנטרפרייז שולחים לכם שאלוני אבטחה של מאות שאלות: הם לא סומכים עליכם בגלל תו תקן, הם צריכים לוודא שלא תהיו החוליה החלשה שדרכה יפרצו אותם. אבטחת המידע שלכם הפכה לתנאי סף עסקי.

מה עסק קטן יכול לעשות באמת — המסגור הכן

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

1. פחות ספקים, יותר בשלים

כל ספק שאתם מוסיפים הוא עוד דלת פוטנציאלית. עסק שעובד עם עשרה ספקי SaaS מקריים, שנבחרו כי היו זולים או נוחים, חשוף יותר מעסק שבחר בקפידה מעטים ובשלים. ההיגיון פשוט: קל יותר להכיר, לנטר ולנהל את הסיכון של חמישה ספקים מרכזיים מאשר של עשרים. בחירת ספק בשל — כזה עם הסמכות אבטחה (ISO 27001,‏ SOC 2), היסטוריה שקופה ומדיניות ברורה לטיפול בפרצות — מורידה את ההסתברות שהוא יהיה החוליה החלשה. את התהליך המסודר לבחירה ולניהול של ספקים פירטנו במדריך נפרד: ניהול סיכוני צד ג׳ לעסק קטן.

2. משמעת עדכונים — עם ניואנס חשוב

כאן צריך זהירות, כי המסקנה האינטואיטיבית מ-SolarWinds — ״אז אולי כדאי להפסיק לעדכן?״ — היא מסוכנת ושגויה. הרוב המוחלט של הפריצות מגיע דווקא ממערכות שלא עודכנו ומפרצות מוכרות, לא מעדכונים מורעלים. עדכונים הם עדיין נטו חיוביים, ואסור להפסיק לעדכן. הניואנס הנכון: עבור עדכונים לא-קריטיים אפשר לאמץ הטמעה מדורגת — לא להיות הראשונים שמתקינים גרסה חדשה ביום שהיא יוצאת, אלא להמתין ימים ספורים ולראות שלא צצו דיווחים על בעיה. במקביל, כדאי לעקוב אחר הודעות אבטחה (advisories) של הספקים המרכזיים שלכם, כדי לדעת מיד כשמתגלה פרצה בכלי שאתם משתמשים בו. אבל עדכוני אבטחה קריטיים — מתקינים מהר.

3. בדיקת ספק ה-IT שלכם — הגישה שלו היא מפתח-אב

אם יש לכם ספק IT או MSP שמנהל את המערכות שלכם מרחוק, הגישה שלו היא למעשה מפתח-אב לעסק. מקרה Kaseya מלמד בדיוק כמה מסוכן זה יכול להיות. שאלו את הספק שלכם שאלות ישירות: האם הגישה שלהם אליכם מוגנת ב-אימות רב-שלבי? מי אצלם יכול להתחבר למערכות שלכם, ומתי? האם יש להם נוהל ברור למקרה שהכלי שלהם ייפרץ? ספק שמתחמק מהשאלות האלה או מתייחס אליהן כטרחה — הוא בעצמו סימן אזהרה. ספק טוב יעריך את השאלות ויענה עליהן בשקיפות.

4. מנטליות של גילוי — כי חלק מהמתקפות תמיד יעברו

אם ההנחה היא שאי-אפשר למנוע 100% מהמתקפות, ההיגיון מחייב יכולת לגלות התנהגות חשודה אחרי שהחדירה כבר קרתה. כאן נכנסים כלי הגנת תחנות הקצה מסוג EDR ולוגים: גם אם הכופרה הגיעה דרך עדכון לגיטימי או דרך הכלי של ה-MSP, ההתנהגות שלאחר החדירה — הצפנת קבצים, תקשורת חריגה לשרתי שליטה, ניסיון להשתלט על חשבונות — היא בדיוק מה שכלים אלה נועדו לתפוס. אתם לא תמנעו את הכניסה דרך הצינור המהימן, אבל תוכלו לתפוס את מה שקורה אחריה לפני שהנזק מתפשט.

5. מוכנות לאירוע שמקורו בספק

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

צ׳ק-ליסט: מה לעשות השבוע

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

1. מפו את הספקים הקריטיים. רשמו מי בעל גישה למערכות או למידע שלכם — ספק IT/MSP, אחסון, SaaS מרכזי, קבלני משנה. בלי המפה הזו אין ניהול סיכון.
2. שאלו את ספק ה-IT שלכם על MFA. ודאו שהגישה שלו אליכם מוגנת באימות רב-שלבי, ושיש לו נוהל למקרה שהוא ייפרץ.
3. אל תפסיקו לעדכן — סדרו את זה. עדכוני אבטחה קריטיים מיד; עדכונים אחרים בהטמעה מדורגת אחרי כמה ימים.
4. הירשמו להודעות האבטחה של הספקים והכלים המרכזיים שלכם, כדי לדעת מיד כשמתגלה פרצה.
5. ודאו שיש לכם יכולת גילוי. EDR ולוגים בתחנות ובשרתים הקריטיים — כדי לתפוס התנהגות חשודה אחרי חדירה.
6. הוסיפו סעיפי דיווח לחוזי הספקים. חובת הודעה מיידית על אירוע אבטחה וזמני תגובה מוגדרים.
7. בדקו אם אתם החוליה החלשה של מישהו. אם יש לכם גישה למערכות לקוחות — התייחסו לאבטחה שלכם כאל אחריות כלפיהם, לא רק כלפי עצמכם.
8. צמצמו ספקים לא-נחוצים. כל SaaS שאינכם משתמשים בו באמת הוא דלת מיותרת — סגרו חשבונות ישנים ובטלו הרשאות מיושנות.

השורה התחתונה

מתקפת שרשרת אספקה היא הזכורת הכי לא-נעימה לכך שאבטחת מידע אף פעם לא נגמרת בגבולות הארגון שלכם. אתם יכולים לבנות חומה מושלמת, ועדיין להיפרץ דרך עדכון שסמכתם עליו או ספק ששכרתם. אבל חוסר-שליטה מוחלט הוא אשליה בכיוון השני: בחירה מושכלת של ספקים, משמעת עדכונים חכמה, בדיקת ה-MSP שלכם, יכולת גילוי ומוכנות חוזית — כל אלה מזיזים אתכם מ״קורבן מזדמן שעשה הכול נכון״ ל״עסק שמנהל את הסיכון בעיניים פקוחות״. וכשלקוח אנטרפרייז ישאל אתכם על אבטחת שרשרת האספקה — יהיו לכם תשובות.

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