קוד שנכתב על ידי AI ו-OWASP: דפוסי פגיעויות שמודלי שפה מייצרים ב-2026
יש בטחון מיוחד בקוד שנוצר על ידי AI. הוא תקין תחבירית, לעתים קרובות מתועד היטב, ומטפל בנתיב המוצלח ללא רבב. אבל הוא גם שגוי בדרכים שהן סדרתיות, צפויות — וניתנות לחלוטין למניעה כשיודעים מה לחפש.
ה-OWASP Top 10 הוא הקנה-מידה המקובל לפגיעויות אבטחה בישומי ווב. מה שפחות מובן הוא שכלי AI לכתיבת קוד נכשלים מול ה-OWASP Top 10 בדפוסים השונים מהדרך שבה מפתחים אנושיים נכשלים. דפוסי הכישלון שונים מפני שהסיבה שונה: מפתח אנושי טועה עקב לחץ זמן, עייפות, או פערי ידע. מודל AI טועה בגלל אופן האימון שלו — על קוד שהיה שכיח בנתוני האימון, ללא קשר לשאלה האם הקוד היה מאובטח.
הבנת הדפוסים הללו היא הצעד הראשון למניעתם. מדריך זה ממפה את ה-OWASP Top 10 לדרכים הספציפיות שבהן קוד שנוצר על ידי AI נכשל, מסביר מדוע כל כישלון מתרחש, ונותן לכם את הוריות הסקירה לאיתורו.
מדוע ל-AI יש נקודות עיוורון אבטחה סדרתיות
לפני הפרטים, הסיבה השורשית. מודלי שפה גדולים לומדים לייצר קוד על ידי חיזוי מה יבוא בהמשך, בהתבסס על דפוסים בנתוני האימון שלהם. נתוני האימון הללו הם אוסף עצום של קוד מהעולם האמיתי — מאגרי GitHub, תשובות Stack Overflow, דוגמאות תיעוד, פוסטים בבלוגים.
הבעיה היא שנתוני האימון משקפים את איכות הקוד בעולם האמיתי, שהיא מעורבת. תשובות Stack Overflow מעדיפות עובד על פני מאובטח. קוד מדריכים מדגים מושגים, לא הקשחה לסביבת ייצור. קוד ישן משקף את חשיבת האבטחה של תקופתו. והמודל ייצג קוד שעובד באופן שגוי אך לא מייצר שגיאה מיידית בתדירות שווה לקוד שעובד נכון.
OWASP A01: בקרת גישה שבורה
כיצד AI נכשל כאן: בקרת גישה היא פגיעות ה-OWASP השכיחה ביותר בקוד שנוצר על ידי AI. דפוס הכישלון עקבי: ה-AI מממש נכון את לוגיקת הפיצ'ר אך משמיט את בדיקת ההרשאות שצריכה לשמש שומרת סף.
AI שהתבקש להוסיף endpoint של "קבל פרופיל משתמש" ל-REST API יייצר endpoint שמאחזר ומחזיר את נתוני המשתמש. מה שהוא בדרך כלל לא יעשה הוא להוסיף את הבדיקה שמוודאת שהמשתמש המבקש מורשה לגשת לנתוני אותו משתמש — לא לנתונים של כל משתמש.
מה לחפש: כל endpoint חדש, מטפל נתיב, או פונקציה שמחזירה נתונים צריכים לכלול בדיקת הרשאה מפורשת. בסקירת קוד, השאלה הראשונה שלכם על כל endpoint API שנוצר על ידי AI צריכה להיות: מי יכול לקרוא לזה, והיכן זה אוכף?
OWASP A02: כשלי הצפנה
כיצד AI נכשל כאן: מודלי AI אומנו על קוד ממספר עשורים, מה שאומר שהם ספגו שיטות הצפנה מתקופות שבהן MD5 נחשב מספיק, ECB mode היה בחירה תקפה, ואחסון סיסמאות בהצפנה הפיכה היה סטנדרטי.
הדפוס השני הוא מפתחות hardcoded. מודלי AI מייצרים לעתים קרובות ערכי placeholder לסודות — מפתחות API, מפתחות הצפנה, סיסמאות מסדי נתונים — שהם מחרוזות תקינות תחבירית. אם ה-placeholder הללו לא נתפסות בסקירה ומוחלפות לפני הפריסה, הן מגיעות לייצור.
מה לחפש: כל שימוש ב-MD5, SHA1, ECB mode, DES, או RC4 למטרות אבטחה. מחרוזות ליטרל שנראות כמו מפתחות API או סודות. יישום כלשהו של הצפנה שאינו משתמש בספרייה עדכנית ומבוקרת היטב.
OWASP A03: הזרקה
כיצד AI נכשל כאן: SQL injection היא אחת הפגיעויות הוותיקות והמתועדות ביותר, ומודלי AI ספגו כמויות עצומות של נתוני אימון על הסיבות שהיא רעה ואיך למנוע אותה. לשאילתות פשוטות, קוד שנוצר על ידי AI בדרך כלל עושה את הדבר הנכון.
הכישלון מתרחש עם מורכבות. כשצריכים סינון דינמי, joins רב-טבלאיים, או שמות עמודות שנקבעים בזמן ריצה, הדפוס הופך לקשה יותר. מודלי AI מייצרים קוד שבונה את השאילתות המורכבות הללו באמצעות שרשור מחרוזות.
מה לחפש: כל מחרוזת הכוללת משתנה ומועברת למסד נתונים, מעטפת, מנוע תבניות, או פונקציית eval.
OWASP A04: עיצוב לא מאובטח
כיצד AI נכשל כאן: זהו דפוס הכישלון הפילוסופי ביותר. כלי AI לכתיבת קוד מממשים כל עיצוב שהם מתבקשים לממש. הם לא דוחים החלטות עיצוב לא מאובטחות — הם מבצעים אותן היטב.
אם תבקשו מ-AI לבנות תהליך איפוס סיסמה שמשלח את הסיסמה הזמנית בטקסט גלוי, הוא יבנה זאת. הבעיה העמוקה יותר היא שסוכני AI אינם מעלים בפרואקטיביות חששות אבטחה לגבי הארכיטקטורה שהם מממשים.
מה לחפש: זוהי בעיית סקירת עיצוב, לא בעיית סקירת קוד. לפני העברת מפרט פיצ'ר לסוכן AI, בדקו את המפרט לאיתור השלכות אבטחה.
OWASP A05: קונפיגורציה לא מאובטחת
כיצד AI נכשל כאן: סוכני AI מייצרים קונפיגורציות שעובדות. הדפוסים עקביים להפליא בין פרויקטים: CORS מוגדר עם מקורות wildcard, מצב debug מופעל בקבצי קונפיגורציה, אישורי ברירת מחדל לאדמין בסקריפטי הגדרת מסד נתונים, כותרות תגובה שגיאה מדברות מדי שחושפות נתיבי קבצים או מידע על סכמת מסד הנתונים.
מה לחפש: התייחסו לכל קובץ קונפיגורציה שנוצר על ידי AI כקונפיגורציית פיתוח הדורשת הקשחה לפני ייצור.
OWASP A06–A10: שאר הפגיעויות
רכיבים פגיעים ומיושנים (A06). מודלי AI מציעים חבילות מנתוני האימון שלהם, שיש להם תאריך חתך. חבילות שהיו בחירה נכונה בזמן האימון עלולות להיות מיושנות, נמצאות כמכילות פגיעויות, או שהוחלפו על ידי חלופות מאובטחות יותר.
כשלי זיהוי ואימות (A07). AI מייצר תהליכי אימות שמטפלים בנתיב הראשי נכון. שלבי ההקשחה — הגבלת קצב, נעילת חשבון, אכיפת מורכבות סיסמה — דורשים הוראה מפורשת.
כשלי רישום ומעקב אבטחה (A09). זהו האלמנט הנעדר ביותר בעקביות בקוד שנוצר על ידי AI. AI כמעט אינו מוסיף רישום אבטחה אלא אם כן מתבקש במפורש. הוסיפו דרישות רישום אבטחה לכל בקשת פיצ'ר שאתם נותנים לסוכן AI.
זיוף בקשות בצד השרת (A10). כל פיצ'ר שמגיש בקשות HTTP המבוססות על URLs שסופקו על ידי משתמש הוא מועמד ל-SSRF. AI מייצר פיצ'רים אלה נכון מבחינה פונקציונלית ושגוי מבחינת אבטחה: אין אימות URL, אין allowlisting, אין חסימה של כתובות רשת פנימיות.
בניית רשימת ביקורת סקירת קוד ספציפית ל-AI
רשימת ביקורת ממוקדת לקוד שנוצר על ידי AI:
- האם יש בדיקת הרשאה מפורשת בכל endpoint שמחזיר או משנה נתונים?
- האם כל שאילתות מסד הנתונים מפורמטות עם פרמטרים, כולל השאילתות הדינמיות המורכבות?
- האם כל התלויות אומתו כאמיתיות, עדכניות ונקיות מפגיעויות?
- האם קבצי קונפיגורציה מוקשחים לייצור, לא רק לפיתוח?
- האם כל נקודות קצה האימות מוגבלות בקצב?
- האם פעילות רלוונטית לאבטחה נרשמת (כשלי אימות, דחיות הרשאה, גישה לנתונים)?
- האם בקשות HTTP יוצאות מוגנות מפני SSRF?
סיכום
דפוסי הפגיעות שכלי AI לכתיבת קוד מכניסים אינם אקראיים — הם סדרתיים. זה אומר שניתן לאתרם ולמנוע אותם. צוות שמבין כיצד AI מייצר קוד לא מאובטח יכול לבנות תהליכי סקירה שיתפסו זאת לפני שליחתו.
הצוותים שנפגעים הם אלה שמתייחסים לקוד שנוצר על ידי AI באותו אופן שהם מתייחסים לקוד שנוצר על ידי אדם. עדסת הסקירה צריכה להיות שונה מפני שדפוסי הכישלון שונים.
ב-PinkLime, אנחנו בונים ישומי ווב לסביבת ייצור עם פיתוח בסיוע AI וסקירת אבטחה מובנית בכל שלב. אם אתם מאמצים כלי AI לכתיבת קוד ורוצים לעשות זאת בצורה מאובטחת, גלו את הגישה שלנו לפיתוח או צרו קשר עם הצוות שלנו.
קריאה נוספת: