Bloom Security تكشف ثغرة في نشر الحزم البرمجية، ووكلاء الذكاء الاصطناعي يضاعفون المخاطر
وصف باحثو Bloom Security ثغرة في البنية التي تُنشر عبرها الحزم البرمجية. وتزداد خطورتها مع أدوات البرمجة المعتمدة على الذكاء الاصطناعي، إذ يثبّت الوكلاء الاعتماديات تلقائياً ودون مراجعة يدوية. وقد تتلقى المؤسسات شيفرة خبيثة دون أن تلاحظ لحظة تثبيتها. نقل الخبر موقع TNW، ولم تُكشف التفاصيل التقنية الكاملة في الجزء المتاح من المادة. • يثبّت الوكلاء الحزم بوتيرة أسرع مما يستطيع البشر فحصه. • نقطة الضعف تقع في سلسلة النشر، لا في النموذج نفسه. • ينبغي على فرق الأمن تقييد صلاحيات الوكلاء في تثبيت الاعتماديات.
معالج بواسطة الذكاء الاصطناعي من TNW؛ بتحرير Hamidun News
في عام 2025 فحص باحثون 576 ألف مقطع شيفرة كتبتها 16 نموذجاً. وتبيّن أن 19,7% من الحزم الموصى بها في المتوسط لم تكن موجودة أصلاً. ويمكن تسجيل هذه الأسماء وحشوها بشيفرة خبيثة، ثم انتظار أن يسحبها مساعد الذكاء الاصطناعي بنفسه إلى المشروع. والآن أضيفت إلى المشكلة طبقة جديدة: فقد وصفت شركة Bloom Security ثغرة في البنية التي يُنشر عبرها البرنامج، يمكن أن توصل الشيفرة الخبيثة إلى البيئة المؤسسية عند اقترانها بالتثبيت التلقائي. ذكر ذلك موقع The Next Web.
ما المعروف عن الثغرة
التفاصيل التقنية في الجزء المتاح من المنشور محدودة، لذا من المهم عدم افتراض ما لم يُذكر. المعروف هو التالي: عثرت Bloom Security على نقطة ضعف في آليات نشر الحزم، وتزداد خطورتها حين لا يكون من يثبّت الاعتماديات إنساناً بل وكيل ذكاء اصطناعي. ويُفهم من عنوان المادة أن الحديث يدور على آلية Trusted Publishing في npm. وهي نظام تُنشر فيه الحزمة من مسار CI موثوق دون رموز وصول (tokens) طويلة الأمد. الفكرة معقولة، فالرموز تُسرق باستمرار، وبعد موجة الهجمات على npm في عام 2025، ومنها الدودة Shai-Hulud التي طالت مئات الحزم، أعاد النظام البيئي النظر جدياً في ممارسات النشر.
والثغرة في آلية الثقة ذاتها تضرب الافتراض الأساسي: إذا نُشرت الحزمة بالطريقة «الصحيحة» فيمكن الوثوق بها. والوكيل يتبنى هذا الافتراض ولن يتحقق منه.
لماذا يغيّر الوكلاء حجم المشكلة
من يثبّت اعتمادية بنفسه ينظر عادةً، ولو نظرة سريعة، إلى الاسم وعدد مرات التنزيل والمستودع. أما الوكيل فيعمل بطريقة مختلفة: هدفه أن تنجح الاختبارات ويكتمل البناء. وإذا كانت الحزمة تحل المهمة، فستصبح في `package.json` خلال ثوانٍ.
ثلاثة عوامل يعزز بعضها بعضاً:
- السرعة. يمكن للوكيل تثبيت عشرات الاعتماديات في جلسة واحدة، وتصبح كل منها نقطة دخول.
- هلوسة الأسماء. نحو 20% من الحزم غير الموجودة في مخرجات النماذج، بحسب بيانات دراسة 2025، تتيح مجالاً للهجوم عبر تسجيل أسماء مشابهة.
- الصلاحيات. كثيراً ما يعمل الوكلاء في بيئات يمكنها الوصول إلى الأسرار وCI والمستودعات الداخلية، بينما تُنفَّذ سكربتات التثبيت في npm فوراً.
وتضيف الثغرة في النشر إلى ذلك متجهاً آخر: فحتى اسم الحزمة الصحيح لم يعد ضماناً للأمان.
من يتأثر بذلك
أكثر المعرّضين للخطر هي الفرق التي أُدمجت فيها البرمجة بالذكاء الاصطناعي في سير العمل دون سياسة مستقلة للاعتماديات: الشركات الناشئة ذات دورات الإصدار السريعة، والمتعاقدون، وفرق المنصات الداخلية. وقد اعتادت أقسام الأمن في الشركات مراقبة البشر وخطوط الأنابيب (pipelines)، أما الوكيل فيقف بينهما ويتجاوز مستويي الرقابة معاً.
لا يزال من غير الواضح إلى أي مدى استُغلّت الثغرة عملياً، وما الإصدارات المتأثرة. وينبغي توجيه هذه الأسئلة إلى مزوّد السجل (registry) وإلى الباحثين أنفسهم.
ما الذي يمكن فعله الآن
يجدر أولاً تحديد الوكلاء في الشركة الذين يستطيعون تنفيذ `npm install`، وفي أي بيئة. فإذا كان الجهاز جهاز مطوّر عليه رموز وصول وإمكانية الوصول إلى مستودعات خاصة، فهذه أولى المناطق التي ينبغي تقييدها.
ثم تأتي إجراءات مجرَّبة:
- تفعيل ملفات lock ومنع الوكلاء من تعديلها دون مراجعة؛
- تعطيل تنفيذ سكربتات التثبيت (`--ignore-scripts`) حيث لا حاجة إليها؛
- إنشاء قائمة سماح (allowlist) بالاعتماديات، أو مرآة داخلية للسجل مع تأخير في ظهور الإصدارات الجديدة؛
- فحص الحزم الجديدة وفق عمرها وعدد القائمين على صيانتها ومصدر بنائها؛
- تشغيل الوكلاء في بيئات معزولة (sandboxes) دون أسرار دائمة.
والخلاصة الرئيسية بسيطة: يجب التحقق من الثقة بالسجل كما يُتحقق من الثقة بالشيفرة، ولا ينبغي أن تتجاوز سرعة الوكيل سرعة الفحص.
أسئلة وأجوبة حول الخبر
ما أبرز التفاصيل حول ما المعروف عن الثغرة؟
التفاصيل التقنية في الجزء المتاح من المنشور محدودة، لذا من المهم عدم افتراض ما لم يُذكر. المعروف هو التالي: عثرت Bloom Security على نقطة ضعف في آليات نشر الحزم، وتزداد خطورتها حين لا يكون من يثبّت الاعتماديات إنساناً بل وكيل ذكاء اصطناعي. ويُفهم من عنوان المادة أن الحديث يدور على آلية Trusted Publishing في npm. وهي نظام تُنشر فيه الحزمة من مسار CI موثوق دون رموز وصول (tokens) طويلة الأمد. الفكرة معقولة، فالرموز تُسرق باستمرار، وبعد موجة الهجمات على npm في عام 2025، ومنها الدودة Shai-Hulud التي طالت مئات الحزم، أعاد النظام البيئي النظر جدياً في ممارسات النشر. والثغرة في آلية
ما أبرز التفاصيل حول لماذا يغيّر الوكلاء حجم المشكلة؟
من يثبّت اعتمادية بنفسه ينظر عادةً، ولو نظرة سريعة، إلى الاسم وعدد مرات التنزيل والمستودع. أما الوكيل فيعمل بطريقة مختلفة: هدفه أن تنجح الاختبارات ويكتمل البناء. وإذا كانت الحزمة تحل المهمة، فستصبح في `package.json` خلال ثوانٍ. ثلاثة عوامل يعزز بعضها بعضاً: السرعة. يمكن للوكيل تثبيت عشرات الاعتماديات في جلسة واحدة، وتصبح كل منها نقطة دخول. هلوسة الأسماء. نحو 20% من الحزم غير الموجودة في مخرجات النماذج، بحسب بيانات دراسة 2025، تتيح مجالاً للهجوم عبر تسجيل أسماء مشابهة. الصلاحيات. كثيراً ما يعمل الوكلاء في بيئات يمكنها الوصول إلى الأسرار وCI والمستودعات الداخلية، بينما تُنفَّ
ما أبرز التفاصيل حول من يتأثر بذلك؟
أكثر المعرّضين للخطر هي الفرق التي أُدمجت فيها البرمجة بالذكاء الاصطناعي في سير العمل دون سياسة مستقلة للاعتماديات: الشركات الناشئة ذات دورات الإصدار السريعة، والمتعاقدون، وفرق المنصات الداخلية. وقد اعتادت أقسام الأمن في الشركات مراقبة البشر وخطوط الأنابيب (pipelines)، أما الوكيل فيقف بينهما ويتجاوز مستويي الرقابة معاً. لا يزال من غير الواضح إلى أي مدى استُغلّت الثغرة عملياً، وما الإصدارات المتأثرة. وينبغي توجيه هذه الأسئلة إلى مزوّد السجل (registry) وإلى الباحثين أنفسهم.
Access Frontier LLMs & Multimodal AI in One Workspace
Discover NomadNet AI (nomadnet.ai) — unified access to frontier language models, research synthesis, and multimodal workflows.
أهم ما في عالم الذكاء الاصطناعي — مرة كل أسبوع
سبع قصص مهمة فعلاً هذا الأسبوع، مختارة بعناية. بلا ضجيج ولا بيانات صحفية.
تم! تحقق من بريدك للتأكيد.