AiSOC يوحّد التحقيق في التنبيهات ويحصد 436 نجمة في يوم واحد
يتلقى فريق الأمن مئات التنبيهات المتفرقة ويقضي ساعات في ربطها بهجوم واحد. يجمع AiSOC الإشارات، ويكلّف وكيلاً بالفرز الأولي وفق MITRE ATT&CK، ويسجّل كل خطوة في سجل قابل لإعادة التشغيل. يُنشر المشروع محلياً دون مفاتيح API، ويُوزَّع بترخيص MIT، وقد جمع بالفعل 5 862 نجمة، منها 436 خلال اليوم الأخير.
معالج بواسطة الذكاء الاصطناعي من GitHub Trending AI؛ بتحرير Hamidun News
نادراً ما تعاني فرق الأمن من نقص في الإشارات. غالباً يكون الوضع معاكساً: البريد ينبّه إلى تسجيل دخول مشبوه، وسجل السحابة إلى رمز وصول جديد، وأداة EDR إلى تشغيل عملية غريبة. يعيش كل تنبيه في لوحته الخاصة، ويضطر المهندس إلى معرفة يدوية ما إذا كانت تعود إلى هجوم واحد. يقترح AiSOC جمع هذا التحليل في مكان واحد: توحيد الأحداث، وتكليف وكيل بالفرز الأولي، وحفظ تفسير كل خطوة من خطواته.
دخل مستودع beenuar/AiSOC قائمة الأعلى يومياً في GitHub Trending وحصل على 436 نجمة خلال يوم واحد. ويبلغ إجمالي نجوم المشروع 5 862. هذا ليس دليلاً على النضج بعد، لكنه سبب وجيه لدراسة النهج: مركز عمليات أمنية مفتوح يمكن نشره لديك ودراسة شيفرته وتكييفه دون شراء منصة مغلقة.
كيف يبدو التحقيق
لنتخيل ثلاثة أحداث. في الساعة 10:02 يدخل موظف إلى السحابة من عنوان جديد. في 10:05 يُنشأ رمز وصول لحسابه. في 10:11 تبدأ قراءة جماعية للملفات. كلٌّ على حدة قد يكون الأول سفراً، والثاني عملاً اعتيادياً لمطوّر، والثالث نسخاً احتياطياً. أما معاً فيشبهون تسلسل أفعال مهاجم.
يدمج AiSOC هذه الإشارات في تحقيق واحد. يطابق الوكيل السلوك المرصود مع تقنيات MITRE ATT&CK، ويضع تقييماً أولياً، ويترك سجلاً للقرارات. الجزء الأخير هو الأهم: فالمهندس لا يرى التصنيف النهائي فحسب، بل الأحداث التي أثّرت في الاستنتاج. ويمكن إعادة التحقيق بعد تغيير القواعد أو النموذج ومقارنة النتائج.
يُعلن عن المشروع بوصفه مكتفياً ذاتياً: يمكن نشره محلياً دون مفاتيح API خارجية. ويتيح ترخيص MIT تعديل الشيفرة ودمجها في البنية الخاصة. كما يتيح خادم MCP منفصل ربط وظائف AiSOC بـ Claude وCursor وContinue، مثلاً لفحص حادثة من واجهة وكيل مألوفة.
أين الفائدة الحقيقية
بالنسبة لفريق صغير، هذه طريقة لاختبار سيناريو الوكلاء دون أشهر من تطوير مركز عمليات أمنية خاص. يمكن أخذ أرشيف حوادث مجهولة الهوية، وإعادة تشغيلها، وقياس ثلاثة أمور: كم من التنبيهات المترابطة دمجها النظام فعلاً، وكم من الحوادث الخطرة فاته، وكم من الإنذارات الكاذبة أنتج. وبعد هذا الاختبار فقط يصبح من المنطقي منحه الوصول إلى التدفق التشغيلي.
أما للمطورين فالسجل القابل لإعادة التشغيل مثير للاهتمام. فالنظام القائم على الوكلاء دون تاريخ للقرارات يتحول سريعاً إلى صندوق أسود: تغيّر النموذج، فتغيّرت الإجابة، والسبب مجهول. وتسجيل الأحداث الداخلة والأدوات المستدعاة والاستنتاجات الوسيطة يسهّل التصحيح والتدقيق.
ما يجب التحقق منه قبل الاعتماد
يقيس GitHub Trending الاهتمام لا الموثوقية. قبل التجربة الأولية ينبغي دراسة نموذج التهديدات لـ AiSOC نفسه، ومخطط تخزين السجلات، وفصل الصلاحيات، ومعالجة الأسرار. كما أن خادم MCP يوسّع سطح الهجوم: يجب أن تعمل أدواته بأقل الصلاحيات، ولا يجوز اعتبار البيانات الواردة تعليمات موثوقة.
لا ينبغي السماح للوكيل فوراً بحظر المستخدمين أو إلغاء الرموز أو تغيير قواعد الشبكة. والوضع الأول الآمن هو القراءة والتوصيات فقط مع تأكيد بشري إلزامي. ثم تُقارن النتائج بقرارات المحللين على بيانات تاريخية.
الخلاصة العملية بسيطة: لا يهمّ AiSOC بوعد «استبدال مركز العمليات الأمنية بالذكاء الاصطناعي»، بل بمحاولته جمع التنبيهات المتفرقة وتحليل الوكلاء وسجل قرارات قابل للتحقق في مشروع مفتوح واحد. على المطور دراسة بنية السجل وتكامل MCP. وعلى مدير المنتج إطلاق تجربة محدودة وتحديد مقاييس التنبيهات الفائتة والإنذارات الكاذبة ومدة التحقيق مسبقاً.
- 8 نوفمبر 2026Anthropic تثبت مصدر إجابة الذكاء الاصطناعي دون كشف أوزان النموذج
- 8 نوفمبر 2026نقل Hansard سجل 25 مشروعًا و53 محادثة من Claude Code إلى Codex
- 8 نوفمبر 2026كارباتي يبني HackerTube خلال عطلة نهاية الأسبوع: 6 454 فيديو من 43 مليون تعليق على HN
- 8 نوفمبر 202650 وكيلا للذكاء الاصطناعي في Minecraft أنشأوا بيروقراطية وعانوا الجوع: ما الذي يعنيه ذلك لوكلائكم؟
أسئلة وأجوبة حول الخبر
ما أبرز التفاصيل حول كيف يبدو التحقيق؟
لنتخيل ثلاثة أحداث. في الساعة 10:02 يدخل موظف إلى السحابة من عنوان جديد. في 10:05 يُنشأ رمز وصول لحسابه. في 10:11 تبدأ قراءة جماعية للملفات. كلٌّ على حدة قد يكون الأول سفراً، والثاني عملاً اعتيادياً لمطوّر، والثالث نسخاً احتياطياً. أما معاً فيشبهون تسلسل أفعال مهاجم. يدمج AiSOC هذه الإشارات في تحقيق واحد. يطابق الوكيل السلوك المرصود مع تقنيات MITRE ATT&CK، ويضع تقييماً أولياً، ويترك سجلاً للقرارات. الجزء الأخير هو الأهم: فالمهندس لا يرى التصنيف النهائي فحسب، بل الأحداث التي أثّرت في الاستنتاج.
ما أبرز التفاصيل حول أين الفائدة الحقيقية؟
بالنسبة لفريق صغير، هذه طريقة لاختبار سيناريو الوكلاء دون أشهر من تطوير مركز عمليات أمنية خاص. يمكن أخذ أرشيف حوادث مجهولة الهوية، وإعادة تشغيلها، وقياس ثلاثة أمور: كم من التنبيهات المترابطة دمجها النظام فعلاً، وكم من الحوادث الخطرة فاته، وكم من الإنذارات الكاذبة أنتج. وبعد هذا الاختبار فقط يصبح من المنطقي منحه الوصول إلى التدفق التشغيلي. أما للمطورين فالسجل القابل لإعادة التشغيل مثير للاهتمام. فالنظام القائم على الوكلاء دون تاريخ للقرارات يتحول سريعاً إلى صندوق أسود: تغيّر النموذج، فتغيّرت الإجابة، والسبب مجهول.
ما أبرز التفاصيل حول ما يجب التحقق منه قبل الاعتماد؟
يقيس GitHub Trending الاهتمام لا الموثوقية. قبل التجربة الأولية ينبغي دراسة نموذج التهديدات لـ AiSOC نفسه، ومخطط تخزين السجلات، وفصل الصلاحيات، ومعالجة الأسرار. كما أن خادم MCP يوسّع سطح الهجوم: يجب أن تعمل أدواته بأقل الصلاحيات، ولا يجوز اعتبار البيانات الواردة تعليمات موثوقة. لا ينبغي السماح للوكيل فوراً بحظر المستخدمين أو إلغاء الرموز أو تغيير قواعد الشبكة. والوضع الأول الآمن هو القراءة والتوصيات فقط مع تأكيد بشري إلزامي. ثم تُقارن النتائج بقرارات المحللين على بيانات تاريخية.
Build & Ship Production AI Agents Without Boilerplate Code
Start your free 72-hour trial at Hamidun Academy (academy.hamidun.com) — interactive lessons on Claude Code & Cursor, live Tech Radar, and production agent templates.
أهم ما في عالم الذكاء الاصطناعي — مرة كل أسبوع
سبع قصص مهمة فعلاً هذا الأسبوع، مختارة بعناية. بلا ضجيج ولا بيانات صحفية.
تم! تحقق من بريدك للتأكيد.