أصدرت xAI الكود المصدري لأداة Grok Build الخاصة بها في 15 يوليو 2026، بعد يومين فقط من إثبات الباحثين أن البرنامج كان يقوم برفع مستودعات git كاملة، ومجلدات المستخدم الرئيسية، وملفات سرية بصمت إلى Google Cloud Storage.
الحادثة التي أدت إلى هذا الإصدار
في 13 يوليو، أظهر باحث أمني أن Grok Build تجاهلت ضوابط الخصوصية المعلن عنها. فعندما قام مستخدم بتفعيل خيار "إيقاف الرفع" (stop uploads)، استمرت الأداة في بث البيانات إلى حاوية سحابية (cloud bucket). وقد استولت عمليات الرفع على كل ملف في دليل العمل، وفي حالة واحدة على الأقل، سحبت مجلد المستخدم الرئيسي بالكامل، مما كشف عن مفاتيح SSH وقواعد بيانات كلمات المرور.
قامت xAI بإخفاء علامة (flag) في جانب الخادم خلف خانة الاختيار الخاصة بالمستخدم. وبعد يومين، أعلنت الشركة أن Grok Build سيتم طرحه كمصدر مفتوح بموجب ترخيص Apache 2.0، وصورت هذه الخطوة كوسيلة لتوسيع نطاق وصول المطورين.
ما الذي لا يزال المستودع يحتويه
تُظهر نظرة سريعة على المستودع الجديد أن روتين تسريب البيانات لا يزال موجوداً. فهو يقع داخل شرط يتحقق من العلامة المخفية — وهي لا تزال موجودة، ولكن تم تعطيلها فقط. كما يحتوي الكود أيضاً على كتل برمجية منسوخة من OpenAI و OpenCode دون نسبتها لمصادرها، ويتضمن تعليمات للوكلاء الفرعيين (sub-agents) لإخفاء وجودهم، وهي تقنية تعيق التحليل الجنائي الرقمي.
لماذا يمثل الكود المتبقي أهمية
يتعين على المطورين الذين يعتمدون Grok Build الآن الوثوق بشركة xAI للحفاظ على حالة العلامة (flag) بشكل صحيح عبر كل تحديث (patch). وهذه الثقة هشة لثلاثة أسباب:
- مسار تحكم مخفي – توجد العلامة في جانب الخادم، وهي غير مرئية للمستخدمين النهائيين. يمكن لأي خطأ في الإعدادات أو موظف داخلي خبيث تغييرها دون ترك أي أثر للتدقيق.
- إعادة استخدام الكود دون ذكر المصدر – قد يؤدي عدم وضوح أصل الترخيص إلى تعريض المستخدمين لمخاطر قانونية إذا كان الكود المستعار يحمل شروطاً غير متوافقة.
- تعليمات التمويه – تجعل آليات الإخفاء المدمجة من الصعب على الأدوات الأمنية اكتشاف الأنشطة الضارة التي قد تطلقها الأداة.
إن وصف "المصدر المفتوح" لا يجلب تلقائياً مراجعة مدفوعة من المجتمع. فمستودع xAI لا يقبل طلبات السحب (pull requests) الخارجية، لذا سيتطور الكود المصدري في حلقة مغلقة رغم كونه قابلاً للقراءة علناً.
كيف تقارن Grok Build بالبدائل
| الأداة | الترخيص | مساهمات المجتمع | الارتباط بالمورد |
|---|---|---|---|
| Grok Build | Apache 2.0 | لا (xAI تمنع طلبات السحب) | منخفض (يدعم نماذج متعددة) |
| Codex CLI | Apache 2.0 | لا (مرتبط بـ OpenAI) | مرتفع (OpenAI فقط) |
| OpenCode | MIT | نعم (يقبل عمل المجتمع) | منخفض (متعدد المزودين) |
| Claude Code | Proprietary | لا | مرتفع (Claude فقط) |
الميزة الواضحة الوحيدة التي تقدمها Grok Build هي قدرتها على الإشارة إلى النماذج المحلية أو الموردين الآخرين، مما يقلل الاعتماد على مزود واحد. أما جميع النقاط الأخرى — مثل انفتاح الترخيص، ونموذج المساهمة، وأصل الكود — فهي إما مساوية للخيارات الحالية أو أسوأ منها.
ما يجب على المطورين فعله الآن
- تدقيق مسار الرفع – افحص الكود الخاص بالشبكة في المستودع وتأكد من عدم وجود أي اتصالات خارجية بنقاط نهاية (endpoints) غير معروفة.
- تغيير المفاتيح السرية – قم بتوليد أي مفاتيح SSH أو رموز API أو مخازن كلمات مرور كانت موجودة بالقرب من Grok Build قبل 13 يوليو.
- التشغيل في بيئة معزولة – قم بنشر الأداة داخل بيئة اختبار (sandbox) أو حاوية (container) تفتقر إلى الوصول إلى الملفات أو بيانات الاعتماد المميزة.
- مراقبة حالة العلامة – إذا كنت تستضيف نسختك الخاصة، فتأكد من أن العلامة المخفية تظل معطلة بعد كل تحديث.
هذه الخطوات لا تقضي على خطر حدوث تغيير مستقبلي من جانب xAI، ولكنها تقلل من احتمال ظهور منطق تسريب البيانات الحالي بصمت مرة أخرى.
الخلاصة
إن طرح Grok Build كمصدر مفتوح بعد فضيحة تسريب البيانات لا يمحو الثغرة الأساسية. لا يزال المستودع يحمل روتين الرفع المخفي، والضمان الوحيد هو علامة تتحكم فيها الشركة. وحتى يتم تجريد الكود من هذا المنطق أو تصبح حالة العلامة قابلة للتدقيق، يجب على المطورين التعامل مع Grok Build كمكون عالي المخاطر وقصر استخدامه على البيئات التي لا تحتوي على بيانات حساسة.