ספרינט האבטחה של OpenAI: למדוד תיקונים, לא הבטחות

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

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

ב-2 בנובמבר הודיעה OpenAI על ספרינט אבטחה מתוכנן עם Cathedral ועל הגדלת הפרסים בתוכנית ה-bug bounty. שני הצעדים יכולים לעזור. אף הודעה, בפני עצמה, לא מוכיחה שהאבטחה השתפרה.

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

מה השתנה, ומה עדיין בגדר תוכנית

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

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

חולשות קריטיות במוצרי ליבה כמו ChatGPT, ‏Codex ופלטפורמת ה-API עשויות לזכות בפרס של עד 30 אלף דולר. ממצאים קריטיים חריגים עדיין זכאים לעד 100 אלף דולר לפני בונוסים, או כ-172 אלף דולר איתם.

בדוגמה החריגה שפורסמה, מכפילים 100 אלף דולר בבונוסים על איכות, קמפיין ונאמנות, ומגיעים ל-171,925 דולר. OpenAI מציינת במפורש שהתרחישים והפרסים ההיסטוריים בטבלה הם להמחשה. זו אינה ראיה שמישהו קיבל את התשלום הזה.

פרסים שטרם הוענקו יחושבו לפי הטווחים החדשים. פרסים שהוענקו ב-30 הימים שקדמו להודעה עשויים לקבל השלמה, אם פרס הבסיס ובונוס הנאמנות החדשים היו מניבים תשלום גבוה יותר. חוקרים צריכים לבדוק את היקף הבדיקות המותר ואת תנאי התוכנית ב-Bugcrowd. פרס גדול יותר אינו אישור לבדוק כל מערכת.

מה אפשר ללמוד מהספרינט הקודם

יש עבודה קודמת רלוונטית, אבל היא שייכת לקטגוריה אחרת של ראיות.

לפי OpenAI, בספרינט הקודם השתתפו 25% ממהנדסי המוצר שלה. תיאור ה-Defense Factory מדווח על יותר מ-250 אנשים ביותר מ-100 תחומי שירות, ועל סגירת 53 סוגיות דחופות או בעדיפות גבוהה ביום הראשון.

החברה מדווחת גם ש-37% מהממצאים היו כפילויות, 19.5% שוחזרו בזמן ריצה, שיעור ההתראות השגויות אחרי אימות דינמי היה 0.81%, ושיעור התיקונים שהוחזרו לאחור היה 0.53%.

אלה תוצאות תפעוליות ש-OpenAI מדווחת עליהן, לא ביקורת עצמאית או ניסוי מבוקר שמוכיח את הערך הנוסף של AI. שחזור בזמן ריצה אינו תיקון. גם אי אפשר להגדיר אוטומטית את שאר הממצאים כהתראות שגויות; ייתכן שלחלק מהבדיקות חסרה סביבת עבודה תקינה.

והכי חשוב: OpenAI אומרת שבדיקות מעקב חשפו פער בין תיקונים שמוזגו לקוד לבין תיקונים שנפרסו בכל מערכותיה.

ההודאה הזו מגדירה היטב איפה צריך להיות קו הסיום.

מתחילים למדוד מהדיווח, לא מהתיקון בקוד

זו טבלת המדדים שהייתי מבקש. אלה הצעות למדידה, לא תוצאות ש-OpenAI פרסמה על הספרינט החדש.

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

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

להפריד בין יותר חיפוש לבין אבטחה טובה יותר

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

פחות דיווחים יכולים דווקא להעיד על פחות בדיקות או על חוקרים מתוסכלים. מספר הדיווחים לבדו לא יכריע.

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

כדי למדוד את תרומת ה-AI, משווים שירותים ורמות חומרה דומים תחת אותם כללי אימות. מתעדים גרסאות מודל, כיסוי בדיקות, מאמץ מחקרי וכוח אדם.

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

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

תיקון שמחזיק מעמד מטפל בגורם המשותף

נניח שחוקר מגלה שחבר פרויקט עם הרשאת קריאה בלבד יכול להעלות קובץ. זו דוגמה היפותטית לתהליך עבודה, לא חולשה חדשה שנחשפה ב-OpenAI.

עוזר AI מכין תיקון לנקודת הקצה של ההעלאה. הבדיקה עוברת. הטיקט נסגר.

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

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

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

לתגמל ראיות מועילות, ואז לפרסם תוצאות

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

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

הספרינט הבא ראוי לקרדיט על הכוונה. הקודם מספק לקחים מועילים, לפי דיווחי החברה.

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

מקורות

• OpenAI: הכנות לספרינט האבטחה הבא, 2 בנובמבר 2026
• OpenAI: הגדלת פרסים לחוקרי אבטחה, 2 בנובמבר 2026
• OpenAI: ה-Defense Factory, הארכיטקטורה והלקחים המדווחים
• תוכנית ה-Security Bug Bounty של OpenAI ב-Bugcrowd

תמונת פתיחה: Engineers Clean JWST Secondary Reflector with Carbon Dioxide Snow, צילום של Chris Gunn, ‏NASA/Goddard, מ-22 בינואר 2015. נחלת הכלל בארצות הברית לפי עמוד המקור; ראו הנחיות השימוש במדיה של NASA. התמונה הוקטנה מ-4546 על 2989 ל-1920 על 1262 פיקסלים ונדחסה כ-JPEG. זהו צילום ארכיוני להמחשה של מהנדסים שמנקים מראת בדיקה לטלסקופ, לא אנשי OpenAI או Cathedral ולא תיעוד של הספרינט. אין בכך הבעת תמיכה.