ההיגיון של אבטחת מידע בנוי על היררכיית אמון: אתה לא בודק כל שורת קוד בעצמך, אלא מריץ עליה סורק. אתה לא מנתח כל תמונת Container ידנית, אלא נותן לכלי סריקה לעשות זאת. הכלים האלה מקבלים גישה עמוקה - למאגרי הקוד, לסודות ה-CI/CD, למשתני הסביבה, למפתחות הענן. זו בדיוק הגישה שהופכת אותם, כשהם עצמם נפרצים, לוקטור התקיפה האידיאלי. במרץ 2026 זה הפסיק להיות תרחיש תיאורטי.[1][2]
קבוצת תקיפה המכונה TeamPCP (מזוהה גם כ-UNC6780) הריצה קמפיין מתואם שהרעיל שורה של כלי אבטחה ותשתיות פיתוח בקוד פתוח: סורק הפגיעויות Trivy של Aqua Security, כלי סריקת ה-Infrastructure-as-Code KICS של Checkmarx, וספריית שער ה-LLM בשם LiteLLM. המשותף לשלושתם: הם לא נפרצו דרך פגם בקוד המוצר, אלא דרך שרשרת האספקה של הבנייה שלהם - GitHub Actions, סודות CI/CD גנובים ומפתחות חתימה. המאמר הזה לא עוסק ב"עוד פרצה", אלא בשאלה הצרה והמסוכנת: מה קורה כשהכלי שאמור למצוא את הפגיעויות הוא זה שמזריק אותן, ואיך ארגון - במיוחד בסביבה ביטחונית - מאמת את שלמות שרשרת הכלים שהוא סומך עליהם בעיניים עצומות.
מה בדיוק קרה - כרונולוגיה מאומתת
הקמפיין התגלגל תוך ימים ספורים, כשכל פגיעה שירתה את הבאה בתורה: סודות שנגנבו ממטרה אחת שימשו לפריצת המטרה הבאה. זהו הדפוס שהופך שרשרת אספקה של תוכנה מ"נקודת כשל בודדת" לאפקט מפל.[1][3]
למה פגיעה בספק אבטחה חמורה מפגיעה בספק רגיל
כל פגיעת שרשרת אספקה מסוכנת, אבל כשהחוליה שנפרצת היא כלי אבטחה, נוספים שלושה מכפילי נזק שאין להם מקבילה בפגיעה בספריית תוכנה "רגילה":
הרשאות-על מובנות
סורק פגיעויות רץ בליבת ה-CI/CD עם גישה למשתני סביבה, אסימוני ענן, מפתחות SSH וסודות Kubernetes - בדיוק המקומות שנוזקה גונבת-אישורים מחפשת. הכלי מקבל את המפתחות מרצון, כי בלעדיהם הוא לא יכול לעשות את עבודתו. פגיעה בו היא פגיעה בכספת.
אמון שמדכא חשד
כלי אבטחה נהנה מ"חסינות פסיכולוגית": פלט חריג ממנו מתפרש כאזהרת אמת, לא כתסמין של הכלי עצמו. צוותי SOC מכוונים לחפש איום דרך הכלי, לא בתוך הכלי. הווקטור הזה עוקף לא רק בקרה טכנית אלא גם את תשומת הלב של המגן.
הפצה בקנה מידה של המוצר
גרסה מורעלת של סורק בשימוש רחב אינה נשארת אצל קורבן אחד - היא מתפשטת לכל צינור בנייה שמושך אותה אוטומטית. הרעלה של תמונת Docker אחת ב-Docker Hub מגיעה תוך שעות לאלפי סביבות. כאן ~1,000 סביבות SaaS נכנסו לרשימת הסיכון.
המכניקה: לא באג במוצר - פגיעה בקו הייצור
הנקודה הטכנית שמבדילה את הקמפיין הזה ממתקפות "קלאסיות" היא שאף אחד מהמוצרים לא נפרץ דרך פגם בקוד שהם מריצים. התוקף נכנס דרך שרשרת הבנייה וההפצה - אותה תשתית CI/CD שהופכת קוד מקור לחבילה מופצת. זהו בדיוק אותו דפוס שכיסינו בסקירת מתקפות שרשרת האספקה של 2026, ומקביל למנגנון של מתקין חתום שהופך לנשק.[2][4]
🟠 נקודת הכניסה: סודות CI/CD ומפתחות חתימה גנובים
התוקף לא "פרץ" את המוצר - הוא השיג אסימוני GitHub Actions ומפתחות חתימת גרסאות. עם אלה בידיו, הוא יכול לשנות תהליכות בנייה, להזריק קוד בזמן ה-CI ולדחוף ארטיפקטים חתומים כביכול-לגיטימיים. משם המפל: סודות שנגנבו מ-Trivy שירתו את הפגיעה ב-Checkmarx.
🔴 המטען: גונב-אישורים עם יכולת התפשטות
הנוזקה שהוזרקה היא infostealer שקוצר משתני סביבה, אסימוני ענן, מפתחות SSH, סודות Kubernetes וסיסמאות מסדי נתונים מסביבת הבנייה - וכן דלת אחורית לגישה מתמשכת. חלק מהמימושים כללו התפשטות תולעתית דרך מפתחות SSH חשופים ו-API לא מאובטח, כך שקורבן אחד הופך למקפצה לבא.
הטריק של LiteLLM: הרצה בלי import
ב-LiteLLM המטען הסתמך על קובצי .pth של פייתון - מנגנון שמריץ קוד אוטומטית עם עליית המפרש. המשמעות: מספיק שהחבילה המורעלת מותקנת בסביבה, גם כתלות עקיפה (transitive), כדי שהקוד ירוץ - בלי שאף שורת קוד ייבאה אותה במפורש. זו סיבה שפגיעה במרכיב תשתית עמוק כמו שער LLM מסוכנת במיוחד לסביבות שמשלבות סוכני AI ותשתית LLM.
ההסתייגות שאסור לדלג עליה: מה מאומת ומה לא
בדיווחים המוקדמים נקשרו לקמפיין אירועים נוספים, ולא כולם עומדים באותה רמת ודאות. אמינות מקצועית מחייבת להפריד בין העובדה למה שעדיין בגדר השערה:
פריצת Trellix — קשר משוער, לא מאושר
פריצת מאגר קוד המקור של ספקית האבטחה Trellix אכן דווחה ואושרה על ידי החברה (חלק ממאגר הקוד נגיש לגורם לא מורשה; לפי החברה לא נמצאה עדות לפגיעה בתהליך ההפצה). אולם שיוך הפריצה ל-TeamPCP הוא ספקולטיבי בלבד - הדיווחים מציינים שהיא "עשויה להיות קשורה" לקמפיין הרחב, ומקורות אחרים קשרו את האירוע לקבוצת סחיטה אחרת. במאמר זה Trellix מובאת כמקרה מקביל הממחיש את אותה תבנית - ספק אבטחה כמטרה - ולא כפעולה מוכחת של TeamPCP. זו בדיוק אבחנת השלמות שהמאמר קורא לארגון לאמץ: לא כל קישור זמני הוא שרשרת סיבתית.
איך ארגון ביטחוני מאמת את שלמות שרשרת הכלים
המסקנה אינה "להפסיק להשתמש בכלי אבטחה" - זו לא אופציה. המסקנה היא שכלי אבטחה חייב לעבור את אותה בקרת שלמות שרשרת אספקה שהיינו דורשים מכל רכיב אחר בקו הייצור. בסביבה ביטחונית, שבה עלות ההזנחה של שרשרת האספקה נמדדת בחשיפת מידע מסווג ולא רק בזמן השבתה, ההיערכות היא רב-שכבתית:
- נעילת גרסאות לפי Hash, לא לפי תג: תלות ב-GitHub Actions וב-Container צריכה להיות מקובעת ל-digest/SHA מלא, לא ל-tag נייד כמו
@v1. תג ניתן להסטה שקטה אל גרסה מורעלת; digest לא. זהו הבלם היחיד שהיה עוצר את הרעלת trivy-action מלהתגלגל אוטומטית. - אימות חתימות ו-checksum מהיצרן: כל בינארי ותמונת Container מאומתים מול checksum וחתימה שהמתחזק פרסם - ולא נמשכים "כמו שהם". בקמפיין הזה, אימות מול הערכים המקוריים היה חושף את הבינארי המורעל של Trivy מגרסה v0.69.4.
- SBOM ומעקב תלות עקיפה: מפת רכיבים (SBOM) שחושפת גם תלות עקיפה כמו LiteLLM - כי הסכנה הייתה דווקא בשכבת ה-transitive dependency, לא בחבילה שנבחרה ידנית.
- הפרדת הרשאות של הכלי (least privilege ל-CI): סורק לא צריך אסימון עם הרשאות כתיבה לכל הארגון. צמצום היקף הסודות שכל שלב בנייה נחשף אליהם מקטין את השלל שנוזקה גונבת-אישורים יכולה לקצור.
- רוטציה יזומה של סודות ומפתחות חתימה: לאחר כל אירוע בשרשרת - ואפילו כשגרה - סיבוב אסימוני GitHub Actions, מפתחות API ומפתחות חתימה. במפל TeamPCP, סוד שלא סובב הוא שאיפשר את המעבר בין קורבן לקורבן.
- ניטור יומני בנייה ועצי תלות לשינוי לא מורשה: חריגה בזמן ה-CI - הרצת קוד לא צפויה, קריאת רשת יוצאת מסורק - צריכה להדליק התרעה, גם כשמקורה בכלי "אמין".
העיקרון המנחה
אמון בכלי אבטחה אינו פטור מאימות - הוא הסיבה לאימות מחמיר יותר. ככל שלרכיב יש יותר הרשאות והשפעה, כך גובר הצורך להוכיח את שלמותו מחדש בכל בנייה. "זה כלי אבטחה, אז הוא בטוח" היא בדיוק ההנחה ש-TeamPCP ניצלה.
צ'קליסט אימות שרשרת הכלים
- מיפוי כל כלי אבטחה וכלי CI/CD בשימוש - כולל תלות עקיפה - ל-SBOM מתוחזק.
- קיבוע כל GitHub Action ותמונת Container ל-digest/SHA מלא, לא ל-tag נייד.
- אימות checksum וחתימת יצרן לכל בינארי ותמונה לפני משיכה לצינור.
- הגבלת הרשאות אסימוני CI לפי עקרון ההרשאה המזערית לכל שלב בנייה.
- רוטציה מתוזמנת של אסימוני Actions, מפתחות API ומפתחות חתימה.
- ניטור יומני בנייה לזיהוי הרצת קוד או תעבורת רשת יוצאת חריגה מכלים.
- בדיקה יזומה מול התרעות היצרן (Aqua, Checkmarx) ומול RHSB-2026-001/OSV.
- נוהל תגובה: החזרה מיידית לגרסה שלפני הפגיעה + רוטציית סודות בכל אירוע.
- הפרדת בירור סיבתי מקישור זמני - לא לשייך אירוע לתוקף בלי ראיה.
השורה התחתונה
קמפיין TeamPCP הוכיח במרץ 2026 שכלי האבטחה - Trivy, Checkmarx KICS, LiteLLM - אינם מחוץ למשוואת האיום; הם יעד מועדף דווקא בגלל ההרשאות והאמון שהם נהנים מהם. הפגיעה לא נעשתה דרך באג במוצר אלא דרך קו הייצור: GitHub Actions, סודות CI/CD גנובים ומפתחות חתימה - כלומר, אותה שרשרת אספקה של תוכנה שכל ארגון סומך עליה בעיוורון.
לארגון ביטחוני, המסקנה אינה להימנע מכלי אבטחה אלא להחיל עליהם בקרת שלמות מלאה: קיבוע לפי Hash, אימות חתימות, SBOM, הרשאה מזערית ורוטציית סודות. KPLNS מלווה ארגונים במיפוי שרשרת כלי הפיתוח והאבטחה, בהקשחת צינור ה-CI/CD ובבניית נוהל אימות שלמות - כדי שהכלי הבא שאתם מושכים אוטומטית לא יהיה הדלת שדרכה נכנס התוקף.
מקורות
- Arctic Wolf — TeamPCP Supply Chain Attack Campaign Targets Trivy, Checkmarx (KICS), and LiteLLM (dates, mechanism, ~1,000 SaaS environments)
- Red Hat — RHSB-2026-001: Multiple supply chain compromises of open source projects (affected projects, CVE-2026-33634)
- The Register — Ongoing supply-chain attack targets security, dev tools
- Kaspersky — Trojanization of Trivy, Checkmarx, and LiteLLM solutions (.pth technique, CI/CD secrets)
- Palo Alto Networks — When Security Scanners Become the Weapon: Breaking Down the Trivy Supply Chain Attack
- Checkmarx — Update: Ongoing Checkmarx Supply Chain Security Incident (KICS / ast-github-action)
- Docker — Trivy, KICS, and the shape of supply chain attacks so far in 2026
- SecurityWeek — Trellix Source Code Repository Breached (attribution to TeamPCP is speculative)
- Help Net Security — TeamPCP breached GitHub's internal codebase via poisoned VS Code extension (~3,800 repos)