למה לאוטמט recon ובדיקות ב-API של NotHoly

הרצת recon מייצרת יותר ממה שאפשר לקרוא: תת-דומיינים, endpoints, headers, גרסאות, קיר של פלט מכלים. החלק האיטי הוא ה-triage, להחליט מה שווה מבט מקרוב. מודל בתוך ה-loop עוזר שם, אבל רק אם הוא לא מסרב להקשר האבטחה ואם נתוני התמיכה לא הופכים כל חיפוש לחיוב. ה-API של NotHoly נותן את שניהם. הטקסט הזה הוא על חיבור זה לפייפליין, לא על שיטת recon; מקרה השימוש של bug bounty מכסה את הזרימה עצמה.

#המודל קורא, הקוד שלכם נוגע

שמרו על הקו ברור. המודל מנתח את הפלט שכבר יש לכם: הוא קורא scan, מדרג את מה שנראה בר-השגה, מנסח את הצעד הבא, כותב את ה-parser שעמדתם לכתוב. השרתים של NotHoly לעולם לא סורקים, בודקים או שולחים payload למטרה. החלק הפעיל, הבקשה למארח שב-scope, רץ בסביבה שלכם, מהכתובת שלכם, בשליטתכם. החלוקה הזאת היא העיקר. אתם מקבלים מודל שידון בממצא בלי להתווכח אם הוא מותר, והתעבורה למטרה נשארת שלכם להריץ ולתעד. תוצאות כלי שאתם מחזירים מטופלות כנתון, לא כהוראה, כך ש-banner עוין ב-scan לא מכוון את ההרצה. כשאתם מריצים את הצעד הפעיל מהטרמינל, notholy engage יכול לרשום את ה-scope ולבדוק כל פקודה מולו לפני שהיא רצה, ושום דבר מה-scope הזה לא עוזב את המכונה שלכם.

#נתונים שלא עולים טוקנים

ה-Research API עונה לחיפושים ש-loop של recon עושה כל הזמן, והוא מוגבל בקצב לפי ארגון ולא נמדד לפי טוקן. GET /v1/cve/{id} ו-GET /v1/cve/search מחזירים את תיאור ה-NVD, CVSS, CWE, ציון EPSS וסטטוס CISA KEV ברשומה אחת, כל מקור עם תאריך. POST /v1/advisories/query מחזיר את מה ש-OSV מפרט לחבילה וגרסה. GET /v1/kb/search קורא בסיס ידע אצור ומורשה עם מקור בכל קטע. POST /v1/web/search ו-POST /v1/web/read מחפשים וקוראים עמודים ציבוריים דרך יציאה שמסרבת לכתובות פרטיות ופנימיות, מקבעת את החיבור ל-IP שנבדק ולעולם לא שולחת תעבורה למטרה. תוצאות מ-NVD, CISA, GitHub, PortSwigger ו-OWASP מופיעות ראשונות, ועמוד יכול לטעות, אז פתחו את המקור לפני שאתם פועלים. העשרת CVE או בדיקת גרסה לא מוציאה טוקנים של המודל.

curl "https://api.notholy.com/v1/cve/search?q=openssh&kev=true&min_epss=0.5" \
  -H "Authorization: Bearer $NOTHOLY_API_KEY"

#חברו לפייפליין

endpoint המודל תואם OpenAI ו-Anthropic, כך שקוד התזמור שלכם, כלי הפונקציה שלכם וה-streaming שלכם נשארים כפי שהם. העבירו למודל את הכלים שלכם, תנו לו לקרוא להם, והריצו אתם בעצמכם: השרת מריץ רק את הפונקציות שאתם שולחים. ה-reasoning וה-max_tokens עוברים, כך ששלב triage יכול לחשוב לפני שהוא מדרג. בקשה בלי streaming עם Idempotency-Key יכולה לחזור ולהתנגן מחדש עד 24 שעות, מה שעוזר לפייפליין שמריץ צעד שוב. POST /v1/messages/count_tokens מודד prompt לפני שאתם מוציאים. Function calling מכיל את צורת הבקשה, וה-ID של המודל בא מהקטלוג. מכיוון שמסלולי המחקר לא עולים טוקנים, אתם מעשירים תור שלם של ממצאים ומשלמים רק על החשיבה שמדרגת אותם.

#איפה זה לא מתאים

לא מתאים אם אתם רוצים שהפלטפורמה תריץ את ה-scan. היא לא. אין הרצה בצד השרת ואין כלי פעיל, ו-read_url פותח רק עמודים ציבוריים, לא מארח פנימי ולא קישור שמצא בעמוד. המודל יכול לדרג false positive ראשון או לפספס אמיתי, אז רשימה מדורגת היא תור לבדיקה, לא פסק דין. מסלולי המחקר חסומים לדקה לפי ארגון, מה שמספיק לפייפליין וחסר ל-crawler המוני. prompts ותשובות למודל לא נשמרים, אם כי המטא-דאטה של כל קריאה כן.

תנו ל-scanners שלכם לסרוק ולמודל לקרוא. שימו מפתח ויתרה קטנה בתמחור, וכוונו את שלב ה-triage של הפייפליין שלכם ל-API.