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

הבעיה שמגן פותר

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

איך זה עובד: ארבע שכבות

• 1. סריקה

  מחברים ריפו מ-GitHub (ואופציונלית פרויקט Supabase). בכל סריקה, במכולה זמנית שנמחקת בסיומה, רצים: חיפוש סודות בקוד ובכל היסטוריית git (Gitleaks), תלויות פגיעות (OSV-Scanner), כללי קוד משלנו (Opengrep), ובניית האפליקציה בפועל כדי לחפש מפתחות סודיים בקבצי ה-JavaScript שנשלחים לגולשים. לפרויקטי Supabase נוסף קריאת ה-Security Advisor ובדיקה של טבלאות ללא RLS במיגרציות. כל ממצא מוצג בסכמה אחת: חומרה, מיקום, הסבר בעברית ובאנגלית, והנחיית תיקון.

• 2. תיקון באישור אדם

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

• 3. מודיעין איומים

  כל יום מגן מצליב את המאגרים הציבוריים (GitHub Advisories, OSV, CISA KEV ו-NVD) עם גרסאות התלויות שבהן האפליקציה שלך משתמשת בפועל, ושולח התראה רק כשיש פגיעה אמיתית. הדחיפות נקבעת לפי כללים (האם מנצלים את החולשה בפועל, ומה החומרה), לא לפי מודל. סוכן נפרד מנסח כללי זיהוי חדשים; כל כלל עובר בדיקות אוטומטיות, 48 שעות ב"מצב צל" שלא מוצג ללקוחות, ואישור ידני לפני שהוא פעיל.

• 4. פיקוח רציף

  מגן קולט אירועים מ-GitHub, מלוגים של Vercel ושל Supabase, ומזהה בכללים קבועים: ניסיונות כניסה בכוח גס (כולל כניסה שהצליחה אחרי רצף כשלונות), קריאת נתונים חריגה בהיקפה, מנהל חדש, שינוי בקובצי workflow, deploy key חדש, ווירוסים בקבצים שהועלו ל-buckets ציבוריים (ClamAV). התראות מגיעות לאימייל, Slack או Telegram לפי חומרה, בלי כפילויות, ועם התראת "שתיקה" אם מקור הלוגים הפסיק לשדר.

עקרונות אבטחה

• לא כותבים אצל הלקוח

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

• קוד הריפו הוא נתונים לא אמינים

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

• הרשאות מינימליות וקצרות

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

• כל פעולה נרשמת

  יומן ביקורת לכל פעולה, ו-Row Level Security בכל טבלה: ארגון רואה רק את הנתונים שלו.

• בני אדם בנקודות המכריעות

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

מצב הפרויקט

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

• סריקת ריפו אמיתי של GitHub (גם פרטי)

  הותקן GitHub App, נסרק ריפו אמיתי והופקו ממצאים.

  נבדק מול שירות אמיתי

• התראות בטלגרם, ומנגנון הדה-דופליקציה

  נשלחו התראות אמיתיות, בעברית, בלי כפילויות.

  נבדק מול שירות אמיתי

• מודיעין איומים מהמאגרים החיים

  נבדק מול GitHub Advisories, OSV, CISA KEV ו-NVD.

  נבדק מול שירות אמיתי

• סוכני ה-AI (מתקן, בודק עצמאי, מנסח כללים, תקצירי התראות)

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

  נבדק בסימולציה

• Slack, Vercel Log Drains, לוגי Supabase, ClamAV

  נבדקו במערכות מדומות ובקבצי בדיקה מוכרים (EICAR); עדיין לא מול חשבונות אמיתיים.

  נבדק בסימולציה

• הרצה מתארחת של הסריקות לכמה לקוחות

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

  בתכנון

• סריקת קבצים ב-buckets פרטיים

  לא נתמכת במכוון: ל-Supabase אין מפתח קריאה בלבד.

  בתכנון