מחקר חדש: GPT-4.1 מייצר קוד לא בטוח

LLMs ויצירת קוד לא מאובטח: תרחיש ברירת המחדל

מחקר חדש מבית Backslash Security חושף מגמה מדאיגה: מודלי שפה גדולים (LLMs) כמו GPT-4.1, יחד עם מודלים נפוצים אחרים, נוטים ליצור קוד לא מאובטח כברירת מחדל. המשמעות היא שבלי הוראות או הנחיות ספציפיות המתמקדות באבטחה, הקוד שמיוצר על ידי מערכות AI אלה פגיע לרוב לחולשות ולניצולים נפוצים. עם זאת, המחקר גם מצביע על כך שניתן לשפר משמעותית את אבטחת הקוד שנוצר על ידי מתן הנחיות אבטחה נוספות או יישום ממשל מבוסס כללים.

כדי לחקור עוד נושא זה, Backslash Security הכריזה על השקת שרת פרוטוקול הקשר המודל (MCP), יחד עם כללים והרחבות המיועדים לסביבות פיתוח משולבות (IDEs) Agentic. כלים אלה נועדו להתמודד עם נקודות התורפה האבטחתיות שזוהו בקוד שנוצר על ידי LLM ולספק למפתחים את האמצעים ליצור יישומים מאובטחים יותר.

Backslash Security ערכה סדרה של בדיקות על שבע גרסאות שונות של LLMs פופולריים, כולל מודלי GPT של OpenAI, Claude של Anthropic ו-Gemini של גוגל. המטרה הייתה להעריך כיצד טכניקות הנחיה שונות השפיעו על יכולתם של המודלים ליצור קוד מאובטח. אבטחת פלט הקוד הוערכה על סמך עמידותו בפני עשרה מקרי שימוש של Common Weakness Enumeration (CWE), המייצגים מגוון של נקודות תורפה נפוצות בתוכנה.

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

הנחיות נאיביות: מתכון לפגיעות

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

ההשפעה של הנחיות ממוקדות אבטחה

הנחיות שציינו באופן כללי צורך באבטחה הובילו לתוצאות מאובטחות יותר, מה שמצביע על כך ש-LLMs מסוגלים לייצר קוד מאובטח יותר כאשר הם מונחים לעשות זאת במפורש. יתר על כן, הנחיות שביקשו קוד התואם לשיטות העבודה המומלצות של Open Web Application Security Project (OWASP) הניבו תוצאות טובות עוד יותר. OWASP הוא ארגון ללא מטרות רווח הפועל לשיפור אבטחת התוכנה. עם זאת, אפילו עם הנחיות מתוחכמות יותר אלה, כמה נקודות תורפה בקוד נותרו בעינן בחמישה מתוך שבעת ה-LLMs שנבדקו, מה שמדגיש את האתגרים ביצירת קוד מאובטח באופן עקבי עם LLMs.

הנחיות מבוססות כללים: נתיב לקוד מאובטח

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

שינויי ביצועים בין LLMs

בסך הכל, GPT-4o של OpenAI הדגים את הביצועים הנמוכים ביותר בכל ההנחיות, והשיג תוצאת קוד מאובטח של 1 בלבד מתוך 10 בעת שימוש בהנחיות ‘נאיביות’. אפילו כאשר הונחה ליצור קוד מאובטח, הוא עדיין הפיק פלטים לא מאובטחים הפגיעים לשמונה מתוך עשרה נושאים. GPT-4.1 לא הצליח טוב יותר משמעותית עם הנחיות נאיביות, והשיג ציון של 1.5 מתוך 10.

לעומת זאת, Claude 3.7 Sonnet הופיע כבעל הביצועים הטובים ביותר מבין כלי ה-GenAI שנבדקו. הוא השיג ציון של 6 מתוך 10 באמצעות הנחיות נאיביות ו-10 מתוך 10 מושלם בעת שימוש בהנחיות ממוקדות אבטחה. זה מצביע על כך שחלק מה-LLMs מצוידים טוב יותר להתמודד עם שיקולי אבטחה, אפילו בהיעדר הוראות מפורשות.

הפתרונות של Backslash Security לקידוד Vibe בטוח

כדי לטפל בבעיות שנחשפו על ידי בדיקות הנחיות LLM שלה, Backslash Security מציגה מספר תכונות חדשות שנועדו לאפשר קידוד vibe בטוח. קידוד Vibe מתייחס לתרגול של יצירת קוד באמצעות כלי AI כמו LLMs.

כללי ומדיניות AI של Backslash

כללי ומדיניות AI של Backslash מספקים כללים הניתנים לקריאה על ידי מכונה שניתן להחדיר להנחיות כדי להבטיח כיסוי CWE. ניתן להשתמש בכללים אלה עם כלים כמו Cursor, עורך קוד פופולרי. בנוסף, מדיניות AI שולטת באילו כללי AI פעילים ב-IDEs דרך פלטפורמת Backslash, ומאפשרת לארגונים להתאים אישית את הגדרות האבטחה שלהם.

הרחבת Backslash IDE

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

שרת פרוטוקול הקשר המודל (MCP) של Backslash

שרת פרוטוקול הקשר המודל (MCP) של Backslash הוא API מודע הקשר התואם לתקן MCP. הוא מחבר את Backslash לכלי AI, ומאפשר קידוד, סריקה ותיקונים מאובטחים. תקן MCP מספק מסגרת משותפת לכלי AI לתקשר ולשתף מידע, מה שמקל על הפיתוח של יישומים מאובטחים המופעלים על ידי AI.

התמודדות עם האתגרים של קוד שנוצר על ידי AI

יוסי פיק, מייסד שותף וסמנכ’ל טכנולוגיות ב-Backslash Security, מדגיש את האתגרים שקוד שנוצר על ידי AI מציב בפני צוותי אבטחה. הוא מציין ש’קוד שנוצר על ידי AI – או קידוד vibe – יכול להרגיש כמו סיוט עבור צוותי אבטחה. הוא יוצר שטף של קוד חדש ומביא סיכוני LLM כמו הזיות ורגישות הנחיה.’ הזיות מתייחסות למקרים שבהם LLMs מייצרים מידע שגוי או חסר היגיון, בעוד שרגישות הנחיה מתייחסת לנטייה של LLMs לייצר פלטים שונים בהתבסס על וריאציות עדינות בהנחיית הקלט.

עם זאת, פיק גם מאמין ש-AI יכול להיות כלי רב ערך עבור צוותי AppSec כאשר משתמשים בו עם הפקדים הנכונים. הוא טוען ש’עם הפקדים הנכונים – כמו כללים מוגדרים על ידי ארגון ושרת MCP מודע הקשר המחובר לפלטפורמת אבטחה בנויה למטרה – AI יכול למעשה לתת לצוותי AppSec שליטה רבה יותר מההתחלה.’ Backslash Security שואפת לספק פקדים אלה באמצעות הכללים הדינמיים מבוססי המדיניות שלה, שרת ה-MCP הרגיש להקשר והרחבת IDE, שכולם מיועדים לעידן הקידוד החדש.

ההשלכות של קוד לא מאובטח שנוצר על ידי AI

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

פגיעות מוגברת להתקפות סייבר

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

קושי בזיהוי ותיקון נקודות תורפה

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

היעדר מודעות אבטחתית בקרב מפתחים

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

אתגרי תאימות רגולטורית

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

שיטות עבודה מומלצות ליצירת קוד מאובטח המופעל על ידי AI

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

ספק הדרכת אבטחה למפתחים

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

יישם מדיניות ונהלי אבטחה

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

השתמש בכלי אבטחה לסריקת קוד שנוצר על ידי AI

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

יישם מחזור חיי פיתוח מאובטח (SDLC)

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

הקם תוכנית לתגמול באגים

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

התעדכן באיומי האבטחה העדכניים ביותר

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

שתף פעולה עם מומחי אבטחה

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

העתיד של יצירת קוד מאובטח המופעל על ידי AI

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

התקדמות באבטחת AI

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

שילוב אבטחה בפיתוח AI

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

שיתוף פעולה בין מומחי AI ואבטחה

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

מודעות מוגברת לסיכוני אבטחת AI

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

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

פתרונות אבטחה של Backslash לקוד שנוצר על ידי AI

Backslash Security מספקת פתרונות ייעודיים לטיפול בסיכוני האבטחה הנובעים מקוד שנוצר על ידי AI. פתרונות אלה כוללים:

  • ניתוח סטטי של קוד: זיהוי חולשות אבטחה בקוד שנוצר על ידי AI לפני הפריסה.

  • בדיקות חדירה: הדמיית התקפות סייבר כדי לזהות נקודות תורפה בקוד שנוצר על ידי AI.

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

  • הדרכה וייעוץ: סיוע לארגונים להבין את הסיכונים הכרוכים בקוד שנוצר על ידי AI ולפתח אסטרטגיות להפחתת סיכונים.

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

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

  • הזרקת קוד: תוקפים יכולים להחדיר קוד זדוני לקוד שנוצר על ידי AI ולגרום לו לבצע פעולות לא רצויות.

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

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

  • תצורות שגויות: קוד שנוצר על ידי AI עשוי להיות מוגדר בצורה שגויה, מה שיוצר נקודות תורפה שניתן לנצל.

ניהול סיכוני אבטחה בקוד שנוצר על ידי AI

כדי לנהל את סיכוני האבטחה הכרוכים בקוד שנוצר על ידי AI, ארגונים צריכים:

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

  • ליישם בקרות אבטחה: יישום בקרות אבטחה להפחתת סיכוני האבטחה.

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

  • להגיב לתקריות אבטחה: פיתוח תוכנית תגובה לתקריות אבטחה כדי להגיב במהירות ויעילות להתקפות.

שימוש ב-AI כדי לשפר את האבטחה

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

  • לזהות חולשות אבטחה: AI יכול לנתח קוד כדי לזהות חולשות אבטחה שאחרת היו עשויות להתפספס.

  • למנוע התקפות: AI יכול לנטר מערכות כדי לזהות ולמנוע התקפות בזמן אמת.

  • להגיב לתקריות: AI יכול לסייע בתגובה לתקריות אבטחה על ידי אוטומציה של משימות כגון בידוד מערכות פגומות.

סיכום

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