"זה עובד כמתוכנן": מה קורה כשספק מסרב לתקן פגיעות?
דמיינו שמצאתם שהמנעול בכניסה לבניין המשרדים שלכם פתוח תמיד. לא תקוע — פשוט פתוח. הודעתם לבעל הבניין, ציפיתם לתיקון. הוא חזר אליכם בתשובה אחת: “זה עיצוב מכוון. אנחנו רוצים שהבניין יהיה נגיש.”
כך בדיוק מרגיש חוקר אבטחה שמקבל תשובת “Working as Intended” מספק שדיווח לו על פגיעות.
מה זה Responsible Disclosure?
Responsible Disclosure — חשיפה אחראית — היא ההסכמה הבלתי-כתובה שמנחה את מערכת היחסים בין חוקרי אבטחה לספקי תוכנה. הכלל פשוט: החוקר מוצא פגיעות, מדווח עליה לספק בסוד, הספק מתקן — ורק אז הפרטים מפורסמים לציבור.
הרעיון הוא שכולם מרוויחים: הספק מקבל הזדמנות לתקן לפני שתוקפים מנצלים את הפגם, החוקר מקבל קרדיט מקצועי לאחר הפרסום, והמשתמשים מוגנים לאורך כל התהליך. זהו מודל שעובד — כשכולם מכבדים את חלקם בו.
הבעיה מתחילה כשהספק מחליט שהפגם אינו פגם.
מקרה אמיתי: OX Security נגד Anthropic על MCP
בתחילת 2026, חברת אבטחה ישראלית בשם OX Security גילתה פגם ארכיטקטוני עמוק ב-MCP — פרוטוקול Model Context Protocol שמאפשר לכלי AI לתקשר עם כלים חיצוניים. הפגם חשף כ-200,000 מופעי AI פעילים לאפשרות של RCE (Remote Code Execution) — ביצוע קוד מרחוק — מבלי שהמשתמש יעשה דבר.
OX דיווחו ל-Anthropic, החברה שעומדת מאחורי Claude ומי שקידמה את MCP. התשובה שקיבלו: הפגם “צפוי ומכוון” — חלק מהאופן שבו הפרוטוקול תוכנן לעבוד. Anthropic לא התכוונה לתקן.
לאחר שהחברה לא התנגדה לפרסום, OX פרסמו את ממצאיהם: 10 CVEs על פני 6 פלטפורמות ייצור פגיעות. פגיעויות שמשתמשים לא ידעו על קיומן, ושאיש לא הגן עליהם מפניהן.
שלוש תוצאות אפשריות — ורק אחת טובה
כשחוקר מדווח על פגיעות, שלושה תרחישים אפשריים:
- הספק מתקן: התרחיש האידיאלי. הפגם נסגר, הציבור מוגן, החוקר מקבל קרדיט. כולם מרוויחים.
- הספק מסרב, החוקר שותק: המשתמשים נשארים חשופים לפגיעות שלא ידעו שקיימת. תוקפים — שמוצאים פגיעויות בכוחות עצמם — יכולים לנצל אותה ללא הגבלת זמן.
- הספק מסרב, החוקר מפרסם: הציבור מודע לסיכון ויכול לנקוט צעדי הגנה. גם תוקפים יכולים לנצל את המידע — אך הם ממילא עשויים לגלות את הפגם בכוחות עצמם. השקיפות, גם אם כואבת, עדיפה על בורות.
הסיבה לכך פשוטה: פגיעות לא מפורסמת אינה פגיעות מוגנת. היא פגיעות שרק התוקפים הממוקדים יכולים לנצל, בעוד המגנים — IT, צוותי Security, משתמשים — עיוורים לגמרי.
מה זה אומר לכם כמשתמשים?
כשספק גדול עונה “Working as Intended” על פגם שחושף אתכם — הוא למעשה אומר שהגנת המשתמשים אינה עדיפות שלו. לא יכולים לסמוך עליו שיגן עליכם מפני פגיעויות שהוא עצמו בחר לא לטפל בהן.
כמה עקרונות הגנה שכדאי לאמץ:
- Sandboxing — בידוד תהליכים: הריצו כלי AI ותוספים בסביבה מבודדת, כך שגם אם ינוצלו — הנזק מוגבל.
- הגבלת חשיפה ציבורית: אל תחברו מופעי AI לנכסים ציבוריים (שרתים, API endpoints) שאינם חייבים להיות חשופים.
- Principle of Least Privilege — עיקרון המינימום: תנו לכל כלי רק את ההרשאות שהוא באמת צריך. כלי שצריך לקרוא קבצים — לא צריך גישת כתיבה, ובטח לא גישה לרשת.
לסיכום
Responsible Disclosure עובד רק כשני הצדדים פועלים בתום לב. כשספק מסרב לתקן ומסתתר מאחורי “זה מכוון” — הוא שובר את ההסכם החברתי שמגן על המשתמשים שלו. חוקרים שבוחרים לפרסם במצב כזה אינם בוגדים בתהליך — הם משלימים אותו כשהצד השני נכשל.
מנעול שבעל הבניין מסרב לתקן — בסופו של דבר מישהו חייב לומר לדיירים שהדלת פתוחה.
תגובות