שרשרת האמון רחבה יותר מקובץ התוסף
מפו מקור רכישה והורדה, יצרן, גרסה, מנגנון עדכון ותלות בשירותים נוספים. רשמו מי מורשה להתקין ולשנות מקור ומי מחזיק גישה לחשבון הספק. רכיב יכול לכלול ספרייה נוספת שאינה מופיעה בשם המוצר הראשי, ולכן רשימת שמות בלבד אינה תמיד מספיקה להבנת הכיסוי.
OWASP Top 10:2025 מתארת כשלי שרשרת אספקה בבנייה, בהפצה ובעדכון, מעבר לרכיב עם חולשה ידועה בלבד. ההבחנה עוזרת לבחון גם תהליך והרשאות. היא אינה קובעת שתוסף מסוים נפגע, ואינה סיבה לייחס כל תקלה לאחר עדכון לתקיפה.
הבחינו בין חולשה, זיוף וכשל בתהליך
הטבלה היא כלי אבחון מקורי. התרחישים אינם מתארים אירוע אמיתי או ספק מסוים. לכל תרחיש יש ראיות שונות והמשך טיפול אחר, ולכן לא מחילים אותה תגובה על כל עדכון. אם אין התאמה למקרה, מתעדים מה דורש בירור נוסף.
| תרחיש | מה צריך לברר | משמעות לטיפול |
|---|---|---|
| רכיב עם חולשה מפורסמת | התאמת גרסה וחשיפה | תיקון ותעדוף לפי הקשר |
| חבילה ממקור לא מוכר | מקור, הרשאה ותוכן | בירור אמון לפני התקנה |
| מקור רשמי שנפגע | הודעה וראיות רלוונטיות | הנחיית ספק ובירור אירוע |
| ספרייה תלויה פגיעה | איזה רכיב כולל אותה | עדכון שתואם למערכת |
| חשבון פרסום רחב | מי יכול לשנות מה נפרס | צמצום סמכות ובדיקת שינוי |
| עדכון תקין ששבר תפקוד | תאימות ותלות עסקית | תיקון תהליך ולא הכרזת תקיפה |
מקור מוכר הוא התחלה ולא בדיקת סיום
הנחיות WordPress מדגישות תחזוקת רכיבים ושימוש בתוכנה ממקורות מתאימים. בדקו שהמקור ומסלול העדכון הם אלה שהעסק אישר, ושאין החלפת קובץ ממקור אקראי לצורך עקיפת בעיית רישוי. מחיר נמוך או שם דומה אינם ראיה לתוכן שקול למוצר שהוגדר.
גם בדיקת שלמות או חתימה עונה על שאלה מוגדרת, ולא מאשרת את כל התנהגות הקוד או שוללת חולשה. המטרה היא לשלב מקור ותהליך אמינים עם בדיקת התאמה למערכת. יש לרשום גם רכיב שלא ניתן לעדכן או שהמקור שלו אינו ברור.
קבלת עדכון כוללת אבטחה ותפקוד יחד
בדקו מה השתנה, אם פורסמה הנחיית אבטחה ומהן התלויות. הכינו גיבוי ודרך חזרה מתאימים ובחנו בסביבה מתאימה פעולות עסקיות נבחרות. תכנון תחזוקה צריך לאפשר תגובה לחשיפה משמעותית, ולא להמתין תמיד למועד שגרה אם יש סיבה לטיפול מוקדם.
מי שמאשר שינוי צריך לראות גרסה, מקור, בדיקות ותוצאה, ולא רק הודעה שההתקנה הסתיימה. אם קוד נטען מרחוק דרך רכיב, בחנו גם אותו כחלק מהתלות. הגנה ברכיב אחד אינה ראיה שכל מסלול ההפצה והטעינה נבדק.
דוגמה: קובץ תיקון נשלח מחוץ לערוץ הספק
התרחיש להמחשה בלבד. לאחר תקלה מתקבל קובץ שנחזה לעדכון מהיר. לפני התקנה הצוות בודק את הבקשה בערוץ הספק המוכר, את הגרסה ואת סמכות המפרסם. לא מריץ את הקובץ כדי לברר אם הוא אמיתי ולא מעלה אותו לאתר חי כדי לחסוך זמן.
אם יש חשד לשינוי לא מורשה שכבר הותקן, עוברים למסלול אירוע ושומרים מידע נחוץ. אם מדובר בחוסר תאימות רגיל, מתעדים אותו ומתקנים לפי תהליך השינוי. בשני המצבים אין להחליף בירור מקצועי ברשימה גורפת של תוספים בטוחים או מסוכנים בלי ראיה.
סגרו את שרשרת הבעלות גם להמשך
המסירה כוללת מקור, גרסה, אחראי רישוי, גורם מאשר ותנאי בדיקה חוזרת. עדכנו את המיפוי בהחלפת ספק, מקור עדכון או כלי פריסה. אם הוחלט להמשיך עם חריגה, רשמו נימוק, השפעה ואחראי למעקב. הסרת רכיב דורשת בדיקת תלות ולא רק מחיקת שם מהרשימה.
ב-CyberFixCrew אפשר לתאם סקירת רכיבים, תחזוקה והקשחה לפי שירותי האתר הקיימים. אין במדריך הבטחה לבדיקת קוד מלאה של כל ספק או למניעת כל פגיעה בשרשרת אספקה. התוצר צריך להראות מה אומת, מה לא ידוע ואיך מצמצמים את הפער.
