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

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

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

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

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

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

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

מה הסיכון לעסק?

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

שש שאלות לפני שכלי כזה עולה

לא צריך להבין קוד כדי לשאול אותן. צריך לקבל עליהן תשובה ברורה, רצוי בכתב.

1. מי נכנס, ומה כל אחד רואה?

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

2. איפה הסודות, ומי מחזיק אותם?

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

3. מה קורה עם מה שמשתמשים מקלידים?

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

4. איפה זה רץ, ומה חשוף לעולם?

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

5. על מה הכלי נשען, ומי מעדכן?

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

6. מה נרשם, ומי מקבל דוח?

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

מי שרוצה את הרשימה המלאה ברמה הטכנית יכול להתחיל מ-OWASP Top 10, הרשימה המקובלת של סיכוני אבטחה באפליקציות רשת.

מספיק לבקש מכלי ה-AI לבדוק את עצמו?

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

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

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

איפה המנהל נשאר בתמונה?

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

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

איך מתחילים?

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

שאלות נפוצות

האם לאסור על עובדים לבנות כלים עם AI?

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

מספיק לבקש מכלי ה-AI לבדוק את האבטחה בעצמו?

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

מה ההבדל בין כלי אישי לכלי שצריך בדיקה?

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

מי צריך להיות אחראי על כלי כזה?

אדם אחד עם שם, שיודע מה הכלי עושה, איפה הוא רץ ומה עושים כשהוא נשבר. אם העובד שבנה אותו עוזב ואף אחד לא יודע לענות על זה, יש לכם בעיה.

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

מקור: הנושא עלה מריל של BreakingBreach באינסטגרם עם פרומפט של 27 בדיקות אבטחה. השאלות והניתוח לחברות הם שלנו. רקע: OWASP Top 10.