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

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

עמדתו של פנליג'נט פשוטה: אתה מדבר בשפה טבעית; המערכת מתאמת יותר מ-200 כלים מקצה לקצה; התוצאה היא שרשרת התקפות ניתנת לשחזור עם מיפוי ראיות ובקרות.. ללא כוריאוגרפיה של CLI. ללא ציד צילומי מסך. ללא קבצי PDF תפורים ביד.

מדוע תזמור (ולא "סורק נוסף") הוא הצעד הבא עבור pentestAI

1. ההתפשטות של הכלים היא אמיתית. צוותי האבטחה מחזיקים ב-Nmap, ffuf, nuclei, הרחבות Burp, SQLMap, מנויי OSINT, SAST/DAST, גלאי סודות, מנתחי תצורת ענן, בודקי בסיס קונטיינר/k8s, סורקי חשיפה CI/CD — והרשימה מתארכת מדי רבעון. החסם אינו יכולת הכלים, אלא תיאום.
2. שרשרת תוקפים, רשימת סורקים. כלים בודדים מדווחים על בעיות באופן מבודד. מה שההנהגה רוצה זה סיפור: כניסה → ציר → רדיוס פיצוץ עם הוכחה. מה שההנדסה רוצה זה העתק: בקשות מדויקות, אסימונים, צילומי מסך ורשימת תיקונים. מה שהציות רוצה הוא מיפוי: איזה בקרה נכשלה (ISO 27001 / PCI DSS / NIST).
3. עוזרי LLM ≠ ביצוע אוטומטי. "pentestGPT" מאיץ את תהליך החשיבה והכתיבה, אך עדיין זקוק לבן אדם לבחור כלים, לאכוף את היקף העבודה, לנהל מפגשים ולבנות תוצר אמין.

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

ארכיטקטורת התזמור (איך היא באמת עובדת)

חשבו על Penligent כעל צינור בעל ארבע שכבות ההופך כוונה לנרטיב של מתקפה:

א. מתורגמן כוונות

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

ב. מתכנן

• מפרק את התוכנית ל רצפי כלים: סיור → בדיקת אימות/הפעלה → ניסיונות ניצול (במסגרת המדיניות) → בדיקות רוחביות → איסוף ראיות.
• בוחר מתאמים לכל שלב (לדוגמה, ffuf לגילוי נקודות קצה, nuclei לבדיקות תבניות, SQLMap לאימות הזרקה, נגנים מותאמים אישית לשימוש חוזר באסימונים).
• מקצה תקציבים (זמן, מגבלות תעריף, ריבוי משתמשים) ו אידמפוטנטיות כללים (כך שניסיונות חוזרים לא יגרמו לקריסת האפליקציה או לחריגה ממגבלות הקצב).

ג. מנהל עזבון

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

ד. ראיות ודיווח

• מנורמל את הפלטים ל- סכימה מאוחדת; מתאים ל- שרשרת אחת.
• פולט רשימת תיקונים מוכנים להנדסה ו מיפוי תאימות (NIST/ISO/PCI), בתוספת תקציר מנהלים.

אובייקט תוכנית ברמה גבוהה עשוי להיראות כך:

תוכנית: מטרה: "לפרט משטחי ניהול/איתור באגים ולבדוק קיבוע הפעלה/שימוש חוזר באסימון (בתחום ההיקף)." היקף: תחומים: ["staging-api.example.com"] נתיבי רשימת ההיתרים: ["/admin", "/debug", "/api/*"]
  אילוצים: rate_limit_rps: 3 respect_mfa: true no_destructive_actions: true kpis: - "validated_findings" - "time_to_first_chain"
    - "evidence_completeness" report: control_mapping: ["NIST_800-115", "ISO_27001", "PCI_DSS"] deliverables: ["exec-summary.pdf", "fix-list.md", "controls.json"]

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

ישן מול חדש: השוואה כנה

מהבקשה לדוח: ממצאים קונקרטיים

שפה טבעית ב- → יצירת משימה

משימה penligent create \ --objective "מצא לוחות ניהול חשופים ב-staging-api.example.com; בדוק קיבוע הפעלה/שימוש חוזר באסימון (בתוך ההיקף); תעד עקבות HTTP וצילומי מסך; מיפה ל-NIST/ISO/PCI; הפק סיכום ביצוע ורשימת תיקונים."

סטטוס ומחסומים

סטטוס משימה penligent --id  # מציג את השלב הנוכחי, הכלי, ETA ואילוצים בטיחותיים היקף משימה penligent --id  # מדפיס רשימות מותרות, מגבלות קצב, הגדרות MFA, כללי איסור

ראיות ותוצרי דיווח

השגת ראיות penligent --id  --bundle zip

/evidence/http/ זוגות בקשות/תגובות מטוהרים של # (JSONL) /evidence/screenshots/ תמונות מתויגות לפי שלבים של # (png) /evidence/tokens/ מחזור חיים + יומני השמעה חוזרת של # (txt/json)
/report/exec-summary.pdf # סקירה כללית לעסקים /report/fix-list.md # צבר משימות הנדסיות (עדיפות, בעלים, שלבים) /report/controls.json # מיפוי NIST/ISO/PCI (קריא על ידי מחשב)

ממצא מנורמל (דוגמת JSON)

{ "id": "PF-2025-00031", "title": "שימוש חוזר באסימון התקבל ב-/admin/session", "severity": "High", "chain_position": 2,
  "evidence": { "http_trace": "evidence/http/trace-002.jsonl", "screenshot": "evidence/screenshots/admin-session-accept.png", "token_log": "evidence/tokens/replay-02.json" },
  "repro_steps": [ "השג אסימון T1 (משתמש A, חותמת זמן X)", "הפעל מחדש את T1 ב-/admin/session עם כותרות מעוצבות", "התבונן בהנפקת 200 + קובצי Cookie של מנהל המערכת" ], "impact": "ניתן להגיע לפאנל מיוחס באמצעות הפעלה מחדש; גישה פוטנציאלית לנתונים רוחביים.",
  "controls": { "NIST_800_115": ["בדיקת מנגנוני אימות"], "ISO_27001": ["A.9.4 בקרת גישה"], "PCI_DSS": ["8.3 הצפנה ואימות חזקים"] },
  "תיקון": { "בעלים": "platform-auth", "עדיפות": "P1",
    "פעולות": ["קשירת אסימונים להקשר המכשיר/הפעלה", "יישום הגנה מפני השמעה חוזרת של אסימונים חד-פעמיים", "הוספת TTL בצד השרת עם היוריסטיקה IP/UA"], "אימות": "ניסיון השמעה חוזרת חייב להחזיר 401; צרף עקבות מעודכנות." } }

תחומי יכולת (מה שהמערכת באמת מניעה)

היקף האינטרנט וה-API

• אוטומטי: זיהוי admin/debug, בדיקת גבולות אימות, קיבוע הפעלה / שימוש חוזר באסימון בדיקות (בהיקף), פוזינג ממוקד לסיור מוקדם יותר.
• תוצאה: הוכחת בקשה/תגובה, צילומי מסך, תיאור ההשפעה → רשימת תיקונים.

ענן ומכולות

• אוטומטי: גילוי נכסים זמניים/"צללים", זיהוי IAM בהיקף שגוי, רמזים לחשיפת CI/CD runner, איתות על אסימונים/מפתחות לא מעודכנים.
• תוצאה: "כניסה → ציר → השפעה"שרשרת—לא 80 "מדיומים" מבודדים.

אימות, הפעלה וזהות

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

OSINT ומיפוי חשיפה

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

ראיות ודיווח

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

עקרונות מתודולוגיים:
NIST SP 800-115 – מדריך טכני לבדיקת והערכת אבטחת מידע
OWASP WSTG / PTES – מבנה וטרמינולוגיה של בדיקת חדירות מבוססת שלבים

ה"חלק של ה-AI" שבאמת עוזר (מעבר לנתונים המועברים)

• הנחת יסודות מכוונת: מתרגם הוראות מעורפלות ל מוגדר, ניתן לבדיקה צעדים (למשל, "אל תעבור את 3 rps", "ללא פעלים הרסניים", "כבד את MFA").
• רצף אדפטיבי: מחליף כלים על סמך תוצאות ביניים (לדוגמה, אם לא נמצאו כותרות מנהל, עובר לטביעות רגל חלופיות; אם השמעת האסימון נכשלת, בודק את התיקון).
• שלמות הראיות: מבקש מהמבצע ללכוד מחדש את האובייקטים החסרים כדי לעמוד בדרישות. איכות הדוח (צילום מסך + עקבות + יומן אסימונים).
• בקרת יצירת שפה: הופך חפצים גולמיים ל NIST/ISO/PCI טפסים מבלי לאבד את הדיוק הטכני.

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

מדדי ביצוע מרכזיים (KPI) שחשובים

תרחישים מציאותיים

1. סטיה בלוח הניהול הציבורי על בימוי: הוכח את החזרה/התיקון, צרף עקבות, מפה לבקרות, ושלח משימה P1 עם קריטריונים ברורים ל"סיום".
2. חשיפה ל-CI/CD: גילוי רצים עם טווחים מתירניים; שרשרת לגישה לסודות; ייעוץ לגבי טווחים ובדיקות TTL.
3. נכס "צל" בענן: שירות ניפוי באגים נשכח; הצג ערך → ציר IAM; כמת את רדיוס הפיצוץ.
4. משטח עוזר AI: לאמת פעולות גניבה או כפייה המונעות על ידי הזרקת פקודות בתוך ההיקף המותר; לתעד תוצרים ולשלוט בהשפעות.

דפוסי אינטגרציה (ללא חיווט ידני של כל הרכיבים)

Penligent מתייחס לכלים כאל מתאמים עם קלט/פלט סטנדרטי:

מתאמים: - id: "nmap.tcp" קלט: { host: "staging-api.example.com", ports: "1-1024" } פלט: { services: ["http/443", "ssh/22", "..."] }

  - id: "ffuf.enum" input: { base_url: "https://staging-api.example.com", wordlist: "common-admin.txt" } output: { paths: ["/admin", "/console", "/debug"] }

  - id: "nuclei.http" input: { targets: ["https://staging-api.example.com/admin"], templates: ["misconfig/*","auth/*"] } output: { findings: [...] }

  - id: "sqlmap.verify" input: { url: "https://staging-api.example.com/api/search?q=*", technique: "time-based" } output: { verified: true, trace: "evidence/http/sqlmap-01.jsonl" }

  - id: "token.replay" input: { token: "T1", endpoint: "/admin/session" } output: { status: 200, issued_admin_cookie: true, screenshot: "..." }

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

מגבלות ושימוש אחראי (מציאות כנה)

• לא תחליף אנושי לצוות האדום. שרשראות חברתיות, פיזיות וחדשניות במיוחד עדיין נהנות מיצירתיות של מומחים.
• ההיקף חייב להיות מפורש. המערכת תאכוף רשימות אישור ואילוצים; על הצוותים להגדיר אותם כהלכה.
• הראיות הן המלכות. אם אינטגרציה אינה יכולה לייצר תוצרים באיכות גבוהה, המתכנן צריך לעבור למתאם אחר או לסמן את השלב כ"לא מאושר".
• מיפוי תקנים ≠ ייעוץ משפטי. מיפוי NIST/ISO/PCI מסייע בשיחות ביקורת; בעלי התוכניות שומרים על האחריות לפרשנות ולאישור.
• התפוקה משתנה בהתאם למשטח. תהליכי אימות כבדים/רב-דיירים דורשים זמן ריצה ארוך יותר; הגבלת קצב וציות ל-MFA הם פשרות מכוונות למען הבטיחות והחוקיות.

רשימת בדיקה מעשית למפעיל

1. ציין את המטרה בשפה פשוטה. כלול יעדי היקף, בטיחות ותאימות.
2. העדיפו "איכות שרשרת" על פני ספירה גולמית. שרשרת אחת, המבוססת על ראיות מוצקות, עולה על 30 "מדיומים" תיאורטיים.
3. שמרו על מתאמים רזים. העדיפו כלים מעטים, מובנים היטב ובעלי תוצאות חזקות על פני כלים רבים ורועשים.
4. הגדר את המושג "מוכן". עבור כל P1, הצהיר מראש על עקבות האימות הצפויות לאחר תיקון.
5. תוכניות חוזרות. השווה את ההבדלים; העבר את הנתונים של לפני ואחרי להנהלה — כך תוכל להראות שהסיכון פוחת.

הפניות ולקריאה נוספת

• NIST SP 800-115 – מדריך טכני לבדיקת אבטחת מידע והערכתה
  https://csrc.nist.gov/publications/detail/sp/800-115/final
• מדריך OWASP לבדיקות אבטחת אינטרנט (WSTG)
  https://owasp.org/www-project-web-security-testing-guide/

סיכום

אם המציאות שלך היא "עשרה כלים מצוינים ואפס לחץ מתואם", pentestAI צריך להיות תזמור:

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

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