בנק אוף אמריקה צירף כ־1,000 קבלנים לתיקון חולשות שחשף AI
מנכ״ל Bank of America חשף כי הבנק צירף ברבעון השני כ־1,000 קבלנים לתיקון חולשות בתוכנות פנימיות ובתוכנות ספקים, שהתגלו בעזרת AI.
Bank of America צירף ברבעון השני כ־1,000 קבלנים חיצוניים לתיקון חולשות בתוכנות פנימיות ובתוכנות ספקים, שהתגלו באמצעות מודלים מתקדמים של AI, ובהם Mythos של Anthropic. את ההיקף חשף מנכ״ל הבנק, בריאן מויניהן, ב־14 באוקטובר, לפי דיווח The Next Web. זהו מקרה מוחשי שבו יכולת הגילוי של AI מתורגמת לצורך בעבודת תיקון אנושית נרחבת, ולא להיעלמותה.
מה נחשף: כוח האדם לתיקון, לא גיוס חדש השבוע
החידוש בדיווח הוא חשיפת היקף כוח האדם שהבנק צירף, ולא הודעה על גיוס שמתרחש כעת. ההבחנה חשובה: נכון ל־18 באוקטובר, מדובר בתיאור של מהלך שבוצע ברבעון השני. לפי דברי המנכ״ל כפי שדווחו, העבודה נגעה גם לתוכנות שהבנק מפעיל בעצמו וגם לתוכנות ספקים, כך שהטיפול אינו מוגבל לקוד שנמצא בשליטתו הישירה.
גם את תפקידו של Mythos צריך לתאר בזהירות. המודל של Anthropic מוזכר כאחד המודלים ששימשו לחשיפת החולשות, ולא ככלי היחיד שאחראי לכל הממצאים. הנתון על הקבלנים אינו מאפשר לחשב את התפוקה של מודל מסוים, את מספר החולשות שכל קבלן תיקן או את שיעור הממצאים שהתבררו כבעיות המחייבות טיפול.
מה הנתון לא אומר: כ־1,000 קבלנים אינם כ־1,000 חולשות, ואינם מדד לעלות השימוש ב־Mythos. אין לייחס למודל לבדו הוצאות תיקון וציות משותפות, או להסיק מהיקף כוח האדם כמה מהחולשות כבר תוקנו.
למה מציאת חולשה אינה סוף העבודה
כלי שמצביע על קוד חשוד מספק נקודת פתיחה לחקירה. בארגון שמפעיל מערכות פיננסיות, צריך לברר אם הממצא אכן ניתן לניצול, באילו תנאים הוא רלוונטי ומה עלול להיפגע. רכיב פגיע שמבודד מהרשת אינו בהכרח שקול לרכיב דומה שמקבל בקשות מבחוץ. כדי לקבוע סדר עדיפויות נדרש ההקשר של המערכת, לא רק ניתוח של קטע קוד.
לאחר האימות מגיע השינוי עצמו. תיקון יכול לדרוש עדכון ספרייה, שינוי בהרשאות, התאמה בממשק או החלפה של רכיב. כל אחת מהפעולות האלה עלולה להשפיע על תהליכים תקינים. לכן צריך לבדוק לא רק שהחולשה נסגרה, אלא גם שהתוכנה ממשיכה לבצע את עבודתה ושאפשר להחזיר את המצב לקדמותו אם ההטמעה נכשלת.
- אימות: לבדוק שהממצא אמיתי ולהגדיר באילו תנאים אפשר לנצל את החולשה.
- תעדוף: לשקלל חשיפה, רגישות מידע וחשיבות עסקית, ולא להסתפק בדירוג חומרה.
- שיוך אחריות: לקבוע אם צוות פנימי, קבלן או ספק חיצוני צריך לבצע את השינוי.
- בדיקה והטמעה: לוודא שהתיקון עובד, אינו שובר תהליכים ונכנס לסביבה הפעילה באופן מבוקר.
- סגירה מתועדת: לשמור ראיות לבדיקה ולוודא שהרכיב הפגיע אינו נשאר פעיל במקום אחר.
גילוי אוטומטי של חולשה אינו תיקון אוטומטי של מערכת. המבחן הוא מה נסגר בפועל, לא כמה התראות נפתחו.
מה אפשר ללמוד מהמספר, ומה עדיין לא
המספר שחשף מויניהן מצביע על היקף משמעותי של עבודה אנושית במקרה הזה. הוא אינו מוכיח ש־AI הגדיל את מספר החולשות בתוכנה: גילוי של בעיה קיימת אינו יצירה של בעיה חדשה. באותה מידה, אי אפשר לקבוע מהנתון לבדו שהכלים חסכו כסף או שהשימוש בהם היה יקר מהחלופה. לשם כך נדרשת השוואה בין עלויות, זמני טיפול ותוצאות.
השאלה התפעולית היא מה קורה כאשר קצב הגילוי עולה על יכולת התיקון. זהו סיכון שארגונים צריכים לבחון, לא מסקנה שאפשר לקבוע על מצבו של הבנק מתוך הנתון שפורסם. יותר ממצאים עשויים לשפר את תמונת הסיכון, אבל ללא בעלי תפקידים, זמן בדיקה וגישה לקוד, הם עלולים להישאר בתור עבודה מתארך.
גם המילה ״קבלנים״ אינה מלמדת לבדה כיצד חולקה העבודה. אין בסיס להסיק שכל אחד מהם כתב תיקונים ישירות, או שהיקף כוח האדם יישאר קבוע. מבחינת מנהלי אבטחה ופיתוח, הנתון שימושי בעיקר כתזכורת לתקצב את כל תהליך הטיפול, ולא רק את הכלי שמפיק את הדוח הראשון.
המשמעות לישראל: לתכנן גם את יכולת התיקון
לבנק, לחברת ביטוח או לחברת פינטק בישראל ששוקלים כלי AI לגילוי חולשות, המקרה מציע שאלת רכש קונקרטית: מי יטפל בממצאים ביום שאחרי הבדיקה? במקום לבחון רק הדגמה שמאתרת בעיה מרשימה, כדאי לבקש ניסוי מוגבל שמסתיים בתיקון מאומת. כך אפשר להעריך את העבודה הנדרשת מצוותי הפיתוח, האבטחה והתפעול לפני הרחבת השימוש.
בתוכנת ספקים, יש לברר מראש מי מקבל את הממצא, מי רשאי לבדוק אותו ואיך מתקבל עדכון שניתן להתקין. למשל, חברה ישראלית שמפעילה מערכת תשלומים מספק חיצוני לא בהכרח יכולה לשנות בעצמה את הקוד הפגיע. במקרה כזה, איש קשר מוסכם, מסלול הסלמה ותהליך בדיקת עדכונים עשויים להיות חשובים לא פחות מיכולת הגילוי.
לצד זאת, בדיקה בעזרת כלי AI צריכה להתאים למדיניות הארגון לגבי קוד ומידע רגיש. לפני העברת מאגר קוד או תיעוד מערכת לשירות חיצוני, יש לבדוק הרשאות, תנאי שימוש וטיפול בסודות כגון מפתחות API. אלה שיקולי יישום כלליים, לא פרטים שנמסרו על אופן עבודתו של Bank of America.
מה הלאה: למדוד סיכון שנסגר
כדי להעריך את הצלחת המהלך בבנק, הנתונים המעניינים בהמשך יהיו זמני הטיפול, שיעור התיקונים שאומתו והיקף הבעיות שנותרו פתוחות. מספר הממצאים לבדו אינו מספיק, וגם מספר העובדים אינו תחליף לתוצאה. ארגון יכול לגלות יותר חולשות ובו בזמן לשפר את האבטחה, אם הוא מצליח לטפל בממצאים החשובים באופן עקבי.
המסר לצוותים בישראל אינו להימנע מגילוי בעזרת AI, אלא לחבר אותו ליכולת ביצוע. החשיפה של Bank of America מדגישה שהשיחה על אוטומציה באבטחה צריכה לכלול גם את האנשים שמאמתים, מתקנים ומאשרים שינויים. כלי שמוצא בעיה מספק מידע חשוב; הערך האבטחתי מתממש כשהבעיה מטופלת במערכת הפעילה.
שאלות נפוצות
למה Bank of America צירף כ־1,000 קבלנים בעקבות גילוי חולשות ב־AI?
לפי דיווח The Next Web על דברי מנכ״ל הבנק, הקבלנים צורפו ברבעון השני לתיקון חולשות בתוכנות פנימיות ובתוכנות ספקים, שנחשפו בעזרת מודלים מתקדמים. גילוי חולשה אינו משלים את הטיפול בה: נדרשים גם אימות, שינוי קוד, בדיקות והטמעה.
מה התפקיד של Mythos של Anthropic בסיפור של Bank of America?
לפי הדיווח, Mythos היה בין המודלים המתקדמים שבאמצעותם נחשפו החולשות. אין להסיק מכך שכל הממצאים התגלו באמצעותו או שכל עבודת הקבלנים נבעה מהשימוש בו בלבד.
האם AI שמגלה חולשות יכול גם לתקן אותן אוטומטית?
גילוי חולשה והפקת הצעת תיקון אינם שקולים לתיקון מאומת במערכת פעילה. גם כשכלי מציע שינוי קוד, צריך לבדוק שהוא מטפל בבעיה, אינו פוגע בתפקוד המערכת ועומד בדרישות הארגון.
דרגו את הכתבה
הדירוג עוזר לנו לדעת מה שווה לכם.
תגובות