إطلاق ExploitHunter.app: منصة الأمن بالذكاء الاصطناعي رقم 1

حزمة واسعة للأمن الهجومي، تتضمن مجموعة تقييم عميقة.

جدول المحتويات

• الحلقة المفيدة قصيرة
• لا ينبغي لوكيل الأمن أن يكون لديه نموذج مفضل واحد
• الأدوات التي تستحق الإشادة ليست جميعها تقوم بنفس المهمة
• الأرقام عامة لأن التحذيرات يجب أن تكون كذلك
• المعيار اصطاد المعيار
• الأدلة هي المنتج
• شغّله محليًا. استخدمه بمسؤولية.
• ما التالي

أدوات الأمن تعاني من مشكلة بسيطة في التوثيق.

تجد سطرًا مشبوهًا، تمنحك شارة خطورة، ثم تتركك تثبت ما إذا كان الأمر مهمًا. النتيجة «عالية». لكن الدليل هو ثلاث عمليات grep ترتدي معطفًا واقيًا.

كانت تلك المهام مكلفة بالفعل. والعوامل الذكية تزيدها سوءًا إذا سمحنا لها. نموذج بمتصفح، وشل، وتعليمات غامضة يمكنه توليد كومة مقنعة من النشاط والرموز المحترقة. الرموز المحترقة ≠ حريق.

لذلك بنيت ExploitHunter.app: مساحة عمل مفتوحة المصدر، محلية بالدرجة الأولى، للبحث الأمني المصرح به. تمنح العامل الذكي وظيفة حقيقية: خطط تحقيقًا، ابقَ في نطاق الهدف المسجل، اسأل قبل القيام بعمل خطير، احفظ الأدلة، وأنتج تقريرًا يمكن لشخص آخر مراجعته فعليًا.

ليس ماسحًا ضوئيًا ملصوقًا عليه دردشة آلية. ولا نافذة دردشة تحمل مجموعة أقفال. حلقة بحث بأهداف وحراسات.

الهدف ليس جعل العامل يبدو مشغولاً. الهدف هو جعل كل ادعاء يتحمل تدقيق مهندس آخر.

الحلقة المفيدة قصيرة

مشروع في ExploitHunter يمر بتسلسل ممل عمدًا:

authorize target → plan → request approval → probe → save evidence → prioritize → report

هذا الترتيب مهم.

تفويض الهدف دائم. لا يعيش فقط في رسالة دردشة حيث يمكن أن تكتسب عبارة «حسنًا، تفضل» معاني جديدة بعد ثلاث جولات. الفحوصات النشطة، اختبارات بيانات الاعتماد، أوامر الشل، وكتابة الملفات تتطلب بوابة موافقة. موافقات الأوامر عالية التأثير مربوطة بالقصد، ومقتصرة على المشروع والهدف، وقابلة للاستخدام مرة واحدة افتراضيًا.

ثم يأتي الجزء الذي تحب أدوات الأمن التغاضي عنه: الإثبات. يخزن ExploitHunter الفحص، والاستجابة، ونص الأمر، ولقطة الشاشة، والأثر الداعم مع النتيجة. يمكن للتقرير أن يستشهد بعمله بدلاً من إعادة صياغة الانطباعات من الإجابة النهائية للنموذج.

هذا لا يجعل البحث آمنًا بالسحر. إنه يقلل من انحراف النطاق، ويجعل المراجعات أقل اعتمادًا على الذاكرة، ويمنح الفرق شيئًا أفضل من «الذكاء الاصطناعي قال ذلك.»

لا ينبغي لوكيل الأمن أن يكون لديه نموذج مفضل واحد

أحدث إعلانات الأمن القائمة على العوامل الذكية هي إشارة مفيدة: المزيد من الفرق تدرك أن تحليل المصدر يحتاج إلى تفكير من منظور المهاجم، والتكذيب، والإصلاح—ليس كرنفالًا آخر من المصارف المنعزلة. إعلان VulnHunter من Capital One يوضح هذه الحجة بوضوح لسير عمل تحليل الشيفرة المُحسّن لـ Claude/Claude Code.

ExploitHunter يراهن على نهج مختلف.

البحث الأمني ليس مهمة نموذج واحد. الاستطلاع الواسع على الويب، مختبر محلي مقيد، تجميع الأدلة، تدفق متصفح، وتمريرة الإصلاح النهائية—كلها تكافئ نماذج مختلفة، ميزانيات أدوات، ومواقف خصوصية. النموذج الصحيح هو قرار توجيه، وليس شعارًا على شاشة الإعدادات.

هذا هو السبب في أن ExploitHunter يدعم المزودين المستضافين بالإضافة إلى Ollama وLM Studio. قم بتشغيله كخدمة Node محلية أو تطبيق سطح مكتب Electron. اترك مفاتيح API المستضافة فارغة ويمكنه استخدام نموذج محلي متوافق دون إرسال عمل مرشح إلى مزود مدفوع. استخدم مسارًا مستضافًا عندما تبرر السرعة أو مشكلة صعبة ذلك. أبقِ العمل الحساس محليًا عندما تكون تلك الحدود أكثر أهمية من توفير بضع ثوانٍ من وقت التشغيل.

محلي أولاً لا يعني أن كل نموذج تم تنزيله يصبح وكيل أمني موثوق. حاول الفحص الأولي لآلة التطوير الأخيرة 24 حزمة من LM Studio؛ ثلاثة فقط اجتازت بوابات التحميل، وأول رمز مميز، والإنتاجية. أربع محاولات لاحقة لمسار المتصفح لم تنتج أي صف مؤهل لجودة النموذج: واحد تجاوز السياق المتاح، والثلاثة الأخرى أنهيت دون الرمز المميز، والمخرجات، وأدلة الاستمرارية المطلوبة من قبل المسار. وصلت محاولة مسار الإنتاج الأخيرة إلى مراجعة الإكمال، لكن قاضي الجودة سجل الجلسة المحظورة بصفر بشكل صحيح. هذه نتائج تكامل، وليست درجات جودة نموذج—وهذا بالضبط سبب اختبار ExploitHunter للمسار الكامل بدلاً من إعلان النصر عندما يجيب نموذج على استفسار واحد.

لا يوجد نصر أخلاقي في جعل كل مهمة أمنية تستخدم أغلى نموذج متاح. هناك فقط فاتورة.

الأدوات التي تستحق الإشادة ليست جميعها تؤدي نفس المهمة

أصبح هذا المجال مثيرًا للاهتمام بسرعة. هذا جيد. تحتاج فرق الأمن إلى أكثر من شكل واحد من الأدوات، والتظاهر بغير ذلك هو كيف يصبح كل فئة قائمة ميزات في معطف واقٍ من المطر.

قد تكون المجموعة المفيدة أكثر من واحدة من هذه الأدوات: ماسح شيفرة مصدرية لرفع المرشحين، ومسار مهام لفرز الأنماط المتكررة، ومساحة عمل بحث للتحقق من الحالات الخطيرة، وعامل إصلاح لتحويل العمل المُتحقق منه إلى تصحيح قابل للمراجعة. لا أحد يحتاج إلى تميمة أمنية تفوز بالجميع.

الأرقام منشورة لأن التحذيرات يجب أن تكون كذلك

لقد قمنا بتشغيل تقييمات على شكل منتج ضد أهداف محلية ضعيفة عمدًا، ومختبرات شبكة Docker، وسيناريوهات سلوك أدوات اصطناعية، وقطع أثرية غير متصلة. هذه ليست ادعاءات بتفوق معياري شامل. إنها ملاحظات مؤرخة من مسار محدد، مع الحفاظ على القطع الأثرية للتشغيل وأنماط الفشل إلى جانب الصفوف الجيدة.

ابدأ بأوضح مقارنة مباشرة. سبعة مسارات حالية أكملت كل منها نفس السيناريوهات الأربعة عشر لسلوك الأداة الأمنية تحت تكوين ثابت. هذه هي متوسط نتائج المجموعة الكاملة، مع فصل تكلفة النموذج عن إنفاق القاضي:

هذه مقارنة نماذج، وليست تشابهًا عائليًا مبهمًا. يتفوق Sol على المتوسط بـ 3 نقاط على Gemini و 4 نقاط على DeepSeek Flash. يقترب Flash ضمن 0.94 نقطة مئوية من Sol بينما يكلف حوالي 98× أقل. Gemini هو المسجل الأعلى الأكثر ثباتًا، بنتائج بين 409 و414. يتفوق Kimi على GLM بمتوسط 1.7 نقطة وهو أكثر ثباتًا بكثير؛ GLM يكلف حوالي 8× أقل. كل مرشح أنتج، وحاول، ونفذ صفر أوامر خطيرة.

أعمدة الفشل مفيدة بنفس القدر. سعر Flash ممتاز، لكن متوسط إخفاقاته في الحراسة 9.67. متوسط Sol هو الأفضل، لكن نطاق درجته الملاحظ يمتد 23 نقطة. Gemini ثابت بشكل ملحوظ، لكنه يكلف أكثر من Sol بينما يسجل أقل. “الأفضل” لا تزال جملة تحتاج إلى مفعول به.

أكمل Qwen 3.6 Flash أيضًا تشغيل الهدف الحالي المحدث—375/425، 8/14، $0.047781، و28 إخفاق حراسة—لكنه لم يكن جزءًا من خط الأساس المتكرر أعلاه. تظل نتائج GPT OSS السابقة، وClaude، وGrok، وGemma المحلية ملاحظات مؤرخة صالحة؛ لم يتم تهريبها إلى هذا المتوسط كما لو أن العينة متطابقة. كما تم استبعاد آثار LM Studio المرشحة الأربعة الأحدث: يسجل Langfuse المحاولات، لكن لم يكتمل أي منها بالرمز المميز والمخرجات وأدلة الاستمرارية المطلوبة لدرجة النموذج.

ثم يتغير الترتيب عندما نترك سلوك الأداة الاصطناعي ونضع الوكلاء في مختبرات أهداف حقيقية.

Kimi مقابل GLM مفيد بشكل خاص. في استعادة الأرشيف، استخدم Kimi 11 استدعاء أداة مقابل 24 لـ GLM، وسجل 10/10 مقابل 9/10، وكانت التكلفة أقل. على مجموعة السيناريوهات الأربعة عشر الأوسع، متوسط Kimi 399.0/425 مقابل 397.3 لـ GLM، كلاهما متوسط 10.33 نجاح سيناريو، وKimi أكثر ثباتًا بشكل كبير—لكن GLM يكلف $0.287614 مقابل $2.303873 لـ Kimi. نفس عائلتي النموذج. اقتصاديات مهمة مختلفة. قرار توجيه مختلف.

تضيف عمليات المسح الرخيصة والمحلية مسارًا مفيدًا آخر. في عمليات مسح واسعة لمرة واحدة لـ Juice Shop المقوى، وجد Qwen 3.6 Flash 7 فئات ثغرات مع أدلة لجميعها في 21.4 ثانية مقابل $0.007271؛ أنتجت Gemma 4 E4B المحلية أيضًا 7/7 فئات مدعومة بأدلة مقابل $0. هذه ملاحظات هدف واحد، وليست مقارنة السيناريوهات الأربعة عشر المشتركة أعلاه، لكنها بالضبط نوع اقتصاديات المرور الأولى التي يمكن للموجه استغلالها.

نعم، إذن قارن النماذج. لكن قارنها داخل المسار الذي شغّلته فيه فعليًّا. النتائج الحالية تسمّي عدة فائزين: Sol في متوسط الدرجات وعدد النجاحات؛ Gemini في الاتساق عالي المستوى ودرجة الحكم؛ Flash في أداء التكلفة؛ Terra كمسار متوازن؛ GLM في اقتصاديات مشابهة لـ Kimi؛ وKimi في شريحة استرداد الأرشيف المُتحقَّق منها. خريطة التوجيه مصنوعة من لوحات المتصدرين؛ إنها ليست عذرًا لتجنبها.

إذا أردت النسخة الطويلة، بما في ذلك المنهجية، ميزانيات الأدوات، الضوابط السلبية، والطرق التي تحرج بها النماذج نفسها عندما يحتوي سجل الأوامر على الإجابة بالفعل، اقرأ وكلاء الأمان يحتاجون إلى موجهات النماذج، وليس تصنيفات النماذج.

المعيار القياسي أمسك بالمعيار القياسي

أهم نتيجة لم تكن فوز نموذج. بل كانت خسارة المُسجِّل.

أول تقرير لاسترداد الأرشيف أعطى Kimi 5/10 وGLM 9/10. المهمة نفسها كانت ناجحة: كلا الوكيلين استردا harbor-lantern-47، وفحص مستقل من جهة المضيف عبر unzip -t -P أثبت أن كلمة المرور تعمل بينما البدائل لم تنجح.

المشكلة كانت في حمولة الحكم. طبقت تدقيق أدوات محظورة من نوع Cybench الخام على مهمة ExploitHunter أصلية حيث كانت كتابات الأدلة متوقعة. نفس مخرجات النموذج. نفس الأثر المخزن. معيار خاطئ.

أزل التدقيق غير ذي الصلة، وتنتقل Kimi من 5/10 إلى 10/10. يبقى GLM عند 9/10. تمت كتابة الدرجات المصححة إلى آثار Langfuse الأصلية كـ browser-e2e-llm-judge-corrected؛ تحقق API للقراءة فقط في 17 يوليو أكد كلا القيمتين على معرفات الأثر المحفوظة.

تلك القفزة الخمس نقاط هي السبب وراء تخزين ExploitHunter للآثار، الأدلة، إصدارات المسجِّل، التكلفة، الرموز، ميزانيات الأدوات، وإخفاقات الحزام بدلاً من تسوية تقييم في رقم بطولي واحد. معيار قياسي لا يمكن تدقيقه هو مجرد نموذج آخر يدّعي بثقة.

الدليل هو المنتج

الجديد هنا ليس أن LLM يمكنه تعداد المسارات، إرسال طلب HTTP، أو اقتراح تصحيح. نحن نعلم أنه يستطيع فعل ذلك. الجزء الصعب هو ضمان بقاء التحقيق قابلاً للفحص عندما يغادر نافذة سياق النموذج.

يحتفظ ExploitHunter بذاكرة مشروع دائمة وتاريخ الخيط، لكن السجل الدائم هو خط أنابيب الأدلة: ما تمت محاولته، تحت أي موافقة، ضد أي هدف مصرح به، وما عاد. يمكن للنتائج بعد ذلك تغذية تتبع التصحيح، تحليل المتغيرات، رسم مسار الهجوم، وتقرير مع استشهادات بدلاً من كتلة نثرية واثقة.

لهذا التصميم فائدة أنانية: يجعل النظام أسهل في التصحيح. عندما يفوت الوكيل شيئًا، يفرط في استخدام الأدوات، يختلق استنتاجًا، أو يفشل في حفظ أثر، تكون المشكلة مرئية. يمكننا إصلاح المنتج بدلاً من الجدال مع لقطة شاشة لفقاعة دردشة.

شغّله محليًّا. استخدمه بمسؤولية.

ExploitHunter مرخّص بـ MIT، مفتوح المصدر، ومصمم للعمل الذي أنت مصرح به. المستودع يتضمن هدف Juice Shop مقوّى محليًا ومختبرات شبكة متعددة الخدمات لاختبار سير العمل دون توجيه وكيل إلى شيء لا تملكه.

git clone https://github.com/justsml/ExploitHunter.app.git
cd ExploitHunter.app
pnpm install
cp .env.example .env
pnpm dev

ثم افتح http://localhost:3210.

ابدأ بهدف تملكه أو لديك إذن صريح لاختباره. سجّل النطاق. دع الوكيل يضع خطة. وافق على الإجراء الذي تنوي فعله بالفعل. احتفظ بالإيصالات.

هذه هي النسخة المملة من الأمان الوكيلي.

وهي أيضًا النسخة التي أريدها إلى جانبي عندما يبدأ الجزء المثير.

ما هو التالي

المهمة التالية ليست ادعاءً ضخمًا حول الاختراق الذاتي. بل هي جعل الحلقة البحثية أكثر جدارة بالثقة: تقارير أفضل عن تكرار التشغيل، تدقيق أدلة أكثر صرامة، تغطية أوسع للنماذج المحلية، وضوح أكبر في الموافقات، ومسارات أسرع من اكتشاف مُثبَّت إلى تصحيح يرغب إنسان في دمجه.

وكلاء الأمان لا يحتاجون إلى إذن أكثر للارتجال.

إنهم يحتاجون إلى قيود أفضل، وإيصالات أفضل، وطريقة ليكونوا مفيدين قبل وصول الفاتورة.

لقطة تقييم تم التحقق منها في 17 يوليو 2026. المقاييس أعلاه مأخوذة من تشغيلات المستودع الموثقة لـ Hard Juice Shop، وDocker-network، وسلوك الأداة المحلية، وتشغيلات LM Studio قبل الإقلاع، مع فحص تتبعات Langfuse المقابلة للقراءة فقط. تصف ظروف التقييم تلك، وليس ضمانًا للأداء على كل هدف.