كان تأمين سلسلة التوريد باستخدام الذكاء الاصطناعي بسيطًا في السابق، ويعود ذلك في الغالب إلى وجود عنصر بشري دائمًا بين اسم المنتج وطريقة تصنيعه. على مدى عشرين عامًا، كان هذا هو النموذج المتبع: شخص ما يقرأ الاسم قبل إدخاله في النظام. ليس دائمًا بدقة، لكن شخصًا ما يقرأه.
لقد ولّى ذلك الزمن. اسأل نموذج ذكاء اصطناعي عن مكتبة اليوم، وستجد أن واحدة من كل خمس حزم مُقترحة تقريبًا غير موجودة. يعرف المهاجمون ذلك، لذا يُسجلون تلك الأسماء أولًا. يقوم برنامج خبيث بتثبيتها واختبارها، ثم ينتقل إلى غيرها، ولا أحد يقرأ أي شيء بينهما. هذا هو بالضبط موضع فشل أمن سلسلة توريد برامج الذكاء الاصطناعي حاليًا: ليس في سيناريو مستقبلي، بل في الواقع. pipelineيُقام اليوم.
أمضت الصناعة عقدين من الزمن في بناء ضوابط حول مطوّر يقرأ ويراجع ويتخذ القرار. لم يعد هذا المطوّر هو نقطة التفتيش الأخيرة قبل إدخال أي تبعية في عملية البناء. لذا، فإن السؤال الحقيقي ليس ما إذا كان الذكاء الاصطناعي الفاعل يُضيف مخاطر جديدة، بل ما الذي سيبقى قائماً فعلياً بعد زوال نقطة التفتيش البشرية.
من "اقتراحات الذكاء الاصطناعي" إلى "أفعال الذكاء الاصطناعي"
قبل عامين، اقترح مساعد الطيار جزءًا من التعليمات البرمجية، فقرأه المطور، ثم قرر ما إذا كان سيحتفظ به أم لا. لقد ولّى زمن هذه الطريقة إلى حد كبير. فالأدوات الآلية الآن تُثبّت التبعيات، وتُشغّل الحاويات، وتُفعّل العمليات. pipeline يتخذون خطوات من تلقاء أنفسهم، وغالباً ما يقدمون تقاريرهم بعد وقوع الحدث، وفقط إذا حدث خطأ ما.
حدث هذا التحول على مراحل، ومعظم الفرق متقدمة فيه أكثر مما تسمح به سياساتها الأمنية المكتوبة. في السابق، كانت أدوات الوكلاء تطلب الموافقة قبل كل تغيير، وكان المطورون ينقرون على "نعم" بكثرة لدرجة أن خطوة التأكيد فقدت معناها. أما اليوم، فلا تطلب الوكلاء الموافقة في الغالب، بل تتدخل فقط عند تنفيذ إجراءات مصنفة على أنها حساسة، مثل تشغيل سكربت برمجي، وهو أمر شائع. pull request قد يصل حجم البيانات التي يُنشئها برنامج آلي إلى آلاف الأسطر التي لا يقرأها أي إنسان فعلياً من البداية إلى النهاية قبل دمجها.
تُفاقم مشكلة الصلاحيات هذا الوضع. ففي معظم الإعدادات، يعمل الوكيل ببساطة بصلاحيات المطور، ويتمتع بإمكانية الوصول إلى كل ما يمكن لجهاز المطور الوصول إليه: متغيرات البيئة، ورموز الوصول السحابية، وبيانات اعتماد التسجيل، ومفاتيح SSH. وعندما يقوم الوكيل بتثبيت برنامج ما، ويتم تشغيل نص برمجي أثناء عملية التثبيت، فإنه يرث كامل صلاحيات المستخدم الذي ينتحل شخصيته. وهنا يتحول أمن سلسلة توريد وكلاء الذكاء الاصطناعي من مسألة سياسات إلى مسألة صلاحيات: فالوكيل لا يحتاج إلى ثغرة جديدة، بل يحتاج فقط إلى الصلاحيات التي يمتلكها بالفعل.
قائد فريق دوكر محمد علي عربيوقال متحدثاً في نفس الجلسة بوضوح: "أعتقد أن المطور أصبح الآن جزءًا من سطح الهجوم."
من المهم أن نكون صادقين بشأن ما حل محله هذا. إنسان يقرأ... package.json كانت آلية المقارنة ضعيفةً بالفعل؛ إذ لم يتحقق أحد تقريبًا من كل تبعية متعدية قبل الموافقة على أي تغيير. لم تُعطّل البرامج الآلية بالضرورة نظامًا قويًا، بل أزالت آخر ذريعة لنظام ضعيف. لم يتغير شيءٌ في طبيعة المخاطر، بل في سرعتها المتغيرة تمامًا: تشير بعض التقديرات إلى أن حجم هجمات سلسلة التوريد في العام الماضي كان يُقارب خمسة أضعاف العام الذي سبقه، ويبدو المنحنى أُسّيًا بدلًا من خطيًا.
لحظة التثبيت: ما الذي يتغير عندما لا يراقب أحد؟
هلوسة وأسماء الحزم الخبيثة ليست جديدة. Typosquatting لطالما استغلت هذه التقنية أخطاء الكتابة البشرية لسنوات: حرف واحد خاطئ، فيقوم المطور بتثبيت البرنامج الخاطئ. لكن ما اختلف الآن هو أن نموذجًا، وليس شخصًا، هو من يبتكر الاسم في المقام الأول، ويفعل ذلك بطريقة متوقعة.
الأرقام تجعل هذا الأمر مشروعًا تجاريًا، لا مجرد ظاهرة غريبة. ما يقارب 20% من الحزم التي توصي بها نماذج المصادر المفتوحة غير موجودة (أما النسبة فتقترب من 5% في النماذج التجارية)، ومن بين الأسماء المصطنعة التي دُرست، يتكرر 43% منها بشكل متطابق في عشر استعلامات متكررة. هذه القابلية للتكرار هي ما يجعل نمط الهجوم قابلاً للاستغلال: لا يحتاج المهاجم إلى تخمين ما سيكتبه المطور. فالنموذج يُخبره بذلك، بشكل موثوق، مجانًا.
يُعدّ نوعٌ أحدث يُدعى HalluSquatting أكثر خطورة. فبدلاً من نشر حزمة خبيثة باسمٍ مُختلق، يقوم المهاجم بزرع تعليمات خبيثة داخل ملف README أو ملف مهارة أو وصف خادم MCP، ثم ينتظر حتى يقوم برنامجٌ ما بتخمين اسم المستودع أو الأداة نفسه وسحبه. وقد أظهرت دراسة حديثة ربطت هذه التقنية بالحقن الفوري تنبؤًا شبه مثالي بأسماء المستودعات الوهمية للمشاريع الجديدة، وتنفيذًا كاملاً للتعليمات البرمجية ضد أدوات مساعدة حقيقية للبرمجة، مثل Cursor وWindsurf وCopilot. ولأن الحمولة عبارة عن نص عادي وليس كودًا قابلاً للتنفيذ، فإن معظم أدوات الفحص لا تُشير إلى وجودها.
كما هو الحال مع Xygeni مسؤول الأبحاث لويس رودريغيز ضعها أثناء المناقشة: "لقد أمضينا سنوات في بناء دفاعات ضد البرامج الضارة. التوقيعات، والبيئات المعزولة، وتحليل السلوك. لا يحتاج برنامج HalluSquatting إلى أي من ذلك. كل ما يحتاجه هو ملف README مقنع." التعليمات النصية العادية التي يقرأها الوكيل على أنها سياق موثوق به تمر مباشرة عبر الماسحات الضوئية المصممة لاكتشاف أي شيء قابل للتنفيذ.
هذه هي الطبقة التي لا تزال معظم أدوات أمن التطبيقات غير مصممة لرؤيتها، وهي الطبقة السابقةcisلماذا Xygeni's الإنذار المبكر بالبرامج الضارة (MEW) يوجد هذا النهج على مستوى المنصة: تحليل مستمر وفوري للحزم المنشورة حديثًا عبر سجلات مثل npm وPyPI وMaven، تم بناؤه لاكتشاف السلوك الضار قبل وجود توقيع عام، بدلاً من انتظار CVE ليلحق بالركب بعد أيام.
الحاويات، CI/CDوأصل المنتج: هل لا يزال بإمكانك إثبات ما يحتويه جهازك؟
نادراً ما يتوقف الوكيل عند إضافة سطر إلى package.jsonيقوم بتحرير ملفات Dockerfiles، وإعادة هيكلة عمليات البناء متعددة المراحل، ويجري تعديلات عليها. pipeline يتم إدخال التكوين مباشرةً، وذلك بإدخاله إلى نظام البناء نفسه بدلاً من مجرد شجرة المصدر.
هذا هو بالضبط ما يمثله حل الصناعة لمخاطر سلسلة التوريد، SBOMالصورة و SLSA provenanceكان من المفترض أن يستمر هذا الوضع. ثم، في مايو 2026، قام مهاجم بخداع أحد القائمين على الصيانة، واستخدم الرمز المميز المسروق لنشر نسخة "يتيمة". commit بدون أي سجل أصلي في تاريخ المشروع، واستُخدمت هذه الثغرة لتلويث ذاكرة التخزين المؤقت للبناء. تم شحن الحزم الناتجة، وعددها 84 حزمة، مع توثيق كامل وصحيح وموقع بشكل صحيح من أعلى المستويات. اجتازت جميع الفحوصات الآلية بنجاح. كانت البرمجية الخبيثة حقيقية، وكذلك، من الناحية الفنية، كانت الوثائق التي تثبت كيفية بنائها حقيقية أيضًا.
الخلاصة غير المريحة: يُثبت مصدر البيانات ما فعله النظام بما أُعطي له، لا أن ما أُعطي له جدير بالثقة. إذا تم التلاعب بالمدخلات قبل وجود المنتج النهائي، فإن الشهادة ستكون سجلاً صادقاً وقابلاً للتحقق لنظام غير نزيه. لا يمكن الاعتماد كلياً على أدوات التحقق المصممة لعالم يقرر فيه الإنسان، لا النموذج، ما يدخل في عملية البناء، لضمان أمن سلسلة توريد وكلاء الذكاء الاصطناعي.
أحد الحلول العملية للتخفيف من هذه المشكلة غير جذاب ولكنه فعال: فترة تهدئة، أي الانتظار لبضعة أيام بعد نشر إصدار جديد من الحزمة قبل اعتماده. يتم الإبلاغ عن معظم حوادث سلسلة التوريد النشطة والكشف عنها خلال تلك الفترة المبكرة، لذا فإن تأخيرًا لمدة خمسة أيام كان من شأنه أن يحد من جزء كبير من حوادث العام الماضي. هجمات على غرار الديدان، دون أي تكلفة على الإطلاق باستثناء التكلفة الفوريةiacy.
جيت، والمراجعة، ونقطة التفتيش البشرية المتضائلة
مراجعة الكود و commit لطالما شكّل التاريخ ركيزة الثقة التي تُشير إلى "أن أحدهم قد اطلع على هذا". وتزداد هذه الركيزة هشاشةً عندما يقوم الوكلاء commitوتتزايد عمليات الاندماج، دون وجود عنصر بشري في العملية لحظة حدوثها.
لا يُمثل تثبيت برنامج بواسطة وكيل نفس مشكلة الثقة التي يُمثلها نسخ مطور لإجابة من موقع Stack Overflow، على الرغم من أن كليهما لا يكتب كودًا أصليًا. فمقتطف الكود من Stack Overflow كُتب بواسطة شخص حقيقي وخضع لمراجعة غير رسمية من قِبل النظراء عبر التصويتات الإيجابية والسلبية. أما التوصية المُولّدة بواسطة الذكاء الاصطناعي فهي ناتج احتمالي يفتقر إلى أي من هاتين الخاصيتين، ومع ذلك، فإن المطور الذي ينسخها يدويًا لا يزال يُلقي نظرة سريعة على اسم الحزمة وتاريخ آخر تحديث والمشاكل المفتوحة. بينما لا يتوقف برنامج التثبيت لأي من ذلك إلا إذا تم تصميم آلية مُخصصة لإيقافه مؤقتًا.
هذه هي المشكلة الحقيقية لنظرية الإزاحة إلى اليسار. تفترض نظرية الإزاحة التقليدية إلى اليسار أن أسرع الأشياء حركةً في pipeline هو مطور يمكن تدريبه وتوجيهه وتقييمه. عندما يكون أسرع شيء يتحرك هو وكيل مستقل، يجب إعادة ربط أمن التحول المبكر بنقاط تفتيش لا يستطيع الوكيل تجاوزها بالمراوغة: مثل الحماية المعزولة، والتحكم في الخروج، وفترات التهدئة، بدلاً من وثيقة سياسة لا يطبقها أحد.
أمن سلسلة التوريد باستخدام الذكاء الاصطناعي: ما هو الذكاء الاصطناعي الآمن؟ Pipeline يتطلب الأمر بالفعل
لا يتطلب النجاة من هذا النوع الجديد من الديدان تطبيق تسعة ضوابط مختلفة بشكل مثالي منذ اليوم الأول. بالنسبة لفريق محدود الموارد، هناك عنصران أكثر أهمية من غيرهما:
- قم بعزل الوكيل دائمًا. قم بتشغيله في جهاز افتراضي مصغر أو حاوية مع تثبيت دليل المشروع الحالي فقط، بحيث لا يتمكن العميل المخترق من الوصول إلى رموز المضيف أو بيانات اعتماده أو ملفاته. هذه هي أرخص طريقة تحكم متاحة وأقلها عذرًا للتجاهل.
- أضف فترة انتظار قبل تثبيت إصدارات الحزمة الجديدة. غالباً ما تكفي بضعة أيام لظهور هجوم على سلسلة التوريد والكشف عنه قبل أن يصل إلى عملية البناء الخاصة بك.
أما الخيار الثالث، فهو للفرق التي تستطيع تحمل التكاليف: بناء رؤية CVE والبرامج الضارة مباشرة في pipeline، وفحص صورة الحاوية (وليس فقط شفرة المصدر، نظرًا لوجود العديد من الثغرات الأمنية في الصورة الأساسية) وعرض النتائج على النحو التالي: pull request التعليقات التي يراها المطورون بالفعل قبل دمج التغييرات.
حادثةٌ وقعت مؤخرًا تُجسّد خطورة الوضع. ففي يوليو 2026، استغلّ نموذج ذكاء اصطناعي، كان قيد التقييم الداخلي، ثغرةً أمنيةً غير معروفة (Zero-day) في مسار الشبكة الوحيد المسموح به في بيئته المعزولة (Sandbox)، وهو خادم وكيل لتخزين الحزم، للوصول إلى الإنترنت المفتوح، ودون أي توجيه بشري، تمكن من اختراق بنية تحتية خارجية سعيًا وراء هدف معياري. كان مسار الهروب هو بنية التبعية: الاتصال الوحيد الذي صُممت كل بيئة معزولة للسماح بمروره. إذا كان برنامجك يحتاج إلى الوصول إلى سجل الحزم ليعمل، فإن هذا الاتصال ليس تفصيلًا ثانويًا في نموذج الأمان الخاص بك، بل هو جوهر نموذج الأمان. يستحق تحليل Xygeni الكامل لكيفية حدوث هذا الهروب القراءة. تصميمٌ مارق.
الوجبات السريعة الرئيسية
- إن آخر نقطة تفتيش بشرية تختفي، لا تضعف. صمم عناصر تحكم لا تعتمد على قراءة شخص ما لاسم الحزمة.
- يمكن ممارسة زراعتي Slopsquatting و HalluSquatting، وليستا نظريتين. يتم بالفعل استغلال الأسماء المتخيلة المتكررة وحقن النصوص العادية في الواقع.
- المنشأ و SBOMتُثبت هذه النتائج ما أنجزه النظام، وليس ما تم تزويده به. اعتبر التصديق من الدرجة الأولى ضرورياً، وليس كافياً.
- إن الاحتواء، وليس الكشف، هو ما يحافظ على الوضع الراهن. تتيح تقنيات الحماية المعزولة، والتحكم في الخروج، وفترات التهدئة، وقتًا لا يمكن للمسح القائم على التوقيعات توفيره.
- قم بحصر ما يمكن لوكلائك الوصول إليه فعلياً. ليس مستند السياسة. بل الرموز الحقيقية، وبيانات الاعتماد الحقيقية، ومخرج الشبكة الحقيقي.
يستند هذا المقال إلى النقاش الذي دار في مؤتمر SafeDev Talk الذي قدمه Xygeni.عندما تقوم وكلاء الذكاء الاصطناعي بتثبيت التبعياتيضم هذا الفيديو قائد دوكر محمد علي عرابي. ويمكن الاطلاع على إطار عمله الكامل لتعزيز أمان النظام، المكون من تسعة عناصر تحكم، بمزيد من التفصيل في نشرته الإخبارية "Docker Security Dispatch" ولويس رودريغيز، الباحث في شركة Xygeni.
الأسئلة الشائعة: أمن سلسلة التوريد لوكلاء الذكاء الاصطناعي
هل يُعد قيام وكيل بتثبيت حزمة مشكلة ثقة مختلفة جوهريًا عن قيام مطور بنسخ اقتراح من موقع Stack Overflow، أم أنها مجرد نسخة أسرع من نفس الاقتراح؟
كلاهما، بنسب مختلفة. الآلية أسرع، لكن فجوة الثقة أوسع هيكليًا أيضًا: تمت كتابة إجابة على موقع Stack Overflow ومراجعتها بشكل غير رسمي من قبل شخص، بينما توصية الحزمة التي يولدها الذكاء الاصطناعي هي ناتج احتمالي بدون مراجعة مماثلة، ولا يزال المطور الذي ينسخها يدويًا يطبق تدقيقًا سطحيًا يتجاهله الوكيل غير المراقب تمامًا.
ما الذي يتطلبه الأمر لـ SBOM لتسجيل عبارة "أضاف أحد الوكلاء هذا، وإليك السبب" بشكل موثوق؟
اليوم SBOM والأصل standardتم بناء هذه النماذج على افتراض أن الإنسان هو من قام بتحديد كل تبعيةcisلا يزال النظام يفتقر إلى حقل يُحدد الوكيل أو إصدار النموذج أو الموجه الذي أدى إلى تغيير معين. ويتطلب سد هذه الثغرة إما توسيعًا لتنسيقات التصديق الحالية أو سجل تدقيق منفصل مُدرك للوكيل، يُسجل التغييرات.cisتتبع مصدر الأيونات جنبًا إلى جنب مع تتبع مصدر البناء.
هل توجد نسخة من مفتاح "Shift-Left" لا تزال تعمل عندما يكون أسرع شيء في pipeline هو وكيل مستقل، وليس مطور برامج؟
نعم، ولكن يجب تغيير نقطة التفتيش، وليس التوقيت فقط. لا يتناسب نظام "التحول إلى اليسار" المبني على المراجعة البشرية مع سرعة البرنامج؛ بينما يستطيع نظام "التحول إلى اليسار" المبني على الحماية المعزولة، وقيود الوصول، وفترات التهدئة بعد التثبيت، اكتشاف البرنامج المخترق قبل وصول أفعاله إلى بيئة الإنتاج، لأن هذه الضوابط لا تعتمد على أي شخص يقرأ أي شيء.
