האבטחה מתחילה לפני ה-SOC: הפגיעות החדשה חבויה בקוד ש-AI כותב

כולם מסתכלים על התוקף. הסכנה האמיתית נמצאת אצלנו בבית

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

כי בזמן שאנחנו עסוקים בשאלה איך ה-AI מחמש את היריב, הוא כבר שינה מהיסוד את האופן שבו נכתב הקוד שלנו. לפי גוגל, יותר מרבע מהקוד החדש בחברה נכתב כיום על ידי בינה מלאכותית. סקר המפתחים של Stack Overflow לשנת 2025 מצא ש-84% מהמפתחים כבר משתמשים בכלי AI או מתכננים לעשות זאת — זינוק מ-76% בשנה שקדמה לה. הקוד שמריץ את המוצרים שלנו כבר אינו נכתב רק בידי אדם. והשאלה שכמעט אף אחד לא שואל בשבוע הסייבר היא לא “איך נתגונן מפני AI”, אלא “מי בודק את הקוד ש-AI כותב לנו”.

משטח התקיפה לא גדל. הוא זז פנימה

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

כשהקוד נכתב מהר יותר משאנחנו מסוגלים לקרוא אותו, נוצר פער. כל שורה שהתקבלה כי “היא עבדה”, בלי שאיש באמת הבין מדוע היא עובדת, היא נקודת כניסה פוטנציאלית. וזו לא אזהרה תיאורטית. מחקר של חברת האבטחה Veracode משנת 2025, שבחן יותר ממאה מודלי שפה על פני 80 משימות פיתוח, מצא שכמעט מחצית — 45% — מהקוד שנוצר על ידי AI הכיל פגיעות אבטחה שמופיעה ברשימת OWASP Top 10. בחלק מהקטגוריות התמונה חמורה בהרבה: בהגנה מפני Cross-Site Scripting המודלים נכשלו ב-86% מהמקרים, ובהגנה מפני Log Injection ב-88%. בשפות מסוימות, כמו Java, שיעור הכשל עבר את ה-70%.

במילים אחרות: הקוד נראה תקין, רץ, עובר את הבדיקות הפונקציונליות — ועדיין פתוח לרווחה. משטח התקיפה החדש אינו בקצה הרשת. הוא בשורה 240 של הפונקציה שאף אחד לא עצר לקרוא.

הממצא שצריך להדאיג כל CTO

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

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

איך חולשה כזו מחליקה דרך הסדקים

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

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

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

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

הפרדוקס: AI לא מייתר מפתחים — הוא מייקר את השיפוט

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

המפתחים עצמם מרגישים את זה. אותו סקר של Stack Overflow מצא ש-46% מהמפתחים אינם סומכים על דיוק הפלט של כלי ה-AI — עלייה חדה מ-31% בשנה הקודמת — ו-45% מצביעים על דיבאג של קוד שנכתב בידי AI כאחד התסכולים הגדולים שלהם, כי הוא גוזל זמן. הזמן שנחסך בכתיבה לא נעלם. הוא נודד הלאה בשרשרת — לאימות, לבדיקה, לתיקון. וככל שהארגון מתבגר בשימוש ב-AI, כך הוא מגלה שהצוואר בקבוק אינו המקלדת, אלא העין הביקורתית שמאחוריה.

למה כלים לא סוגרים את הפער

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

מכאן נגזרת המסקנה הארגונית החשובה ביותר: אבטחה כבר לא יכולה להיות שלב בסוף תהליך הפיתוח — ביקורת שעוברים לפני שחרור לייצור. היא חייבת להיות חלק מה-DNA של צוות הפיתוח, מהשורה הראשונה. וזו, בראש ובראשונה, שאלה של גיוס. לא של אילו כלים קניתם, אלא של מי יושב מול המסך כשהמודל מציע פתרון, ושואל את השאלה הנכונה לפני שהוא לוחץ Enter.

המיומנות שנעשתה נדירה: קריאה ביקורתית של קוד מכונה

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

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

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

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

מה אנחנו רואים בשטח

מנקודת המבט שלנו, שעובדים עם חברות טכנולוגיה שבונות צוותי פיתוח, ההבדל כבר ניכר. החברות ששואלות את השאלות הנכונות מגייסות אחרת. הן כבר לא מחפשות בעיקר את מי שכותב הכי מהר — כי מהירות הפכה למצרך זול. הן מחפשות את מי שיודע לזהות: מהנדס שקורא קוד של מכונה במבט ביקורתי, שחושב ב-threat modeling כברירת מחדל, שמבין שהתפקיד שלו השתנה מ”יצרן קוד” ל”עורך ואחראי” על קוד שמקורו מעורב.

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

מה הפער הזה עולה לארגון — מעבר לאירוע האבטחה

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

ואז יש את עלות התיקון. פגיעות שנתפסת ב-code review עולה שבריר ממה שהיא עולה כשהיא מתגלה בייצור, ושבריר נוסף ממה שהיא עולה אחרי שנוצלה בפועל. כשחברה מגלה שחלק ניכר מהקוד שלה נכתב מהר אך לא נבדק לעומק, היא אינה מתמודדת עם באג בודד אלא עם סיכון מערכתי שפרוס על פני כל בסיס הקוד — וההתמודדות איתו דורשת בדיוק את סוג המהנדסים המנוסים שהכי קשה לגייס, בדיוק ברגע שבו הלחץ הכי גבוה.

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

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

השורה התחתונה: ההגנה החזקה ביותר היא אנשים שיודעים מתי לא לסמוך

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

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