وكلاء البرمجة بالذكاء الاصطناعي ألغوا آخر مراجع بشري للكود. هذه الآن مشكلة سلسلة التوريد لديكم
توليد الكود بالوكلاء الذكية نقل بصمت مهمة فحص الاعتماديات من المهندسين إلى آلات لا تفحص شيئاً على الإطلاق. الحل ليس الهروب من لغة برمجة أو سجل حزم بعينه، بل تقييد ما تشغّله وكلاؤكم فعلياً.
اسأل مهندساً عن الحزم البرمجية التي دخلت ميزة الأسبوع الماضي، وكنت تحصل سابقاً على إجابة واضحة. اسأله الآن، حين يكون وكيل ذكاء اصطناعي هو من كتب الكود، وغالباً ما تحصل على هزّة كتفين لا أكثر. الوكيل أضاف الاعتمادية. مدير الحزم سحب شجرة اعتمادياتها الفرعية. لم يقرأ أحد أياً من ذلك، لأن القراءة لم تكن يوماً جزءاً من سير العمل الذي بيعت به هذه الأدوات. هذا هو جوهر معضلة أمن سلسلة توريد وكلاء البرمجة بالذكاء الاصطناعي.
من المفيد هنا الدقة في تفكيك عبارة «الوكيل فعل ذلك»، لأنها تخفي وراءها ثلاث آليات منفصلة تماماً. الأداة المدفوعة بنموذج لغوي تقرّر أن مكتبة برمجية معينة مطلوبة فتكتب سطر الاستيراد. بعدها يوسّع مدير الحزم لديكم ذلك الاسم الواحد إلى شجرة كاملة من الاعتماديات الفرعية لم تختاروها أبداً. ثم تُشغّل الإضافة البرمجية في محرر الأكواد عملية التثبيت، وأحياناً حزمة الاختبارات كذلك، داخل بيئة التطوير لديكم كأثر جانبي لمجرد «تجربة الأمر». المهندس البشري حين يختار مكتبة يلقي نظرة على الأقل على المستودع وعدد التنزيلات وتاريخ آخر تحديث. أما محلّل الاعتماديات فلا يلقي أي نظرة على الإطلاق، والإضافة تُشغّل كل ما ينتجه ذلك المحلّل دون سؤال. الحزم الواقعة على عمق ثلاث طبقات تحصل بالضبط على القدر نفسه من التدقيق الذي توفّره هذه السلسلة، أي لا شيء.
ليست كل الوكلاء تتصرف على هذا النحو، وهذا التحفّظ مهم. لا تزال أدوات كثيرة تتوقف وتطلب إذناً قبل كل أمر تشغيل، وموردوها يوثّقون ضوابط الموافقة هذه بوضوح: وكيل Cursor يملك إعداد تشغيل تلقائي ينفّذ الأوامر المدرجة في قائمة موثوقة دون تأكيد، وأداة Claude Code من Anthropic تأتي بوضع قبول تلقائي وقوائم صلاحيات موثوقة إلى جانب أوضاعها الافتراضية القائمة على السؤال. الحقيقة الموثّقة هي أن هذه الأوضاع عديمة الأذونات موجودة فعلاً، وهي بالذات ما يُروَّج له باعتباره السرعة. أما مدى انتشار ترك الفرق لهذه الأوضاع مفعّلة فلا ينشره أي مورد، لذا يجب التعامل مع فكرة أن المراجعة البشرية تهبط إلى الصفر باعتبارها استنتاجاً منطقياً لا رقماً مقيساً: هو استنتاج ينبع من طريقة عمل هذه الأوضاع، لا من استطلاع فعلي.
ماذا يحدث حين تكون الحزمة التي لم يراجعها أحد خبيثة؟
تحصلون على نمط فشل حدث بالفعل، وعدده في تصاعد مستمر. رصد تقرير حالة سلسلة توريد البرمجيات المفتوحة المصدر 2024 من Sonatype أكثر من 512,000 حزمة خبيثة مفتوحة المصدر خلال سنة واحدة فقط، بارتفاع نسبته 156% عن العام السابق. هذا عدد وليس احتمالاً مقيساً، لكن الاتجاه لا يحتمل الشك: كلما زاد عدد الحزم المعادية داخل السجلات، زاد احتمال أن يلامسها أي عملية تحليل اعتماديات، حتى لو تعذّر على أحد وضع رقم دقيق لتلك النسبة. أين قد تختبئ حزمة كهذه؟ وجد بحث Endor Labs حول إدارة الاعتماديات أن نحو 95% من الاعتماديات الثغرية هي اعتماديات فرعية غير مباشرة، من النوع الذي لا يختاره أي مطوّر يدوياً. هذه أرقام عن حزم ثغرية وليست خبيثة، فهي تقيس أين تتجمّع العيوب لا أين تقع الهجمات. لكن الاثنين يتشاركان المخبأ نفسه: إذا كانت العيوب العرضية تتجمّع أصلاً في الطبقات التي يحلّلها الوكيل بصمت، فذلك بالضبط حيث سيستقر كود مزروع دون أن يُقرأ أيضاً.
الحادثة الموثّقة تجعل الأمر ملموساً. وصف باحثون أمنيون في Snyk حالة مطوّر كان يختبر تكاملاً مع محرر Cursor فجلب نسخة مسمومة من حزمة بايثون شائعة كاعتمادية فرعية. الكود الخبيث كتب ملف تشغيل مخفياً عمل عند كل استيراد. والمفارقة أن ما كشف الأمر كان شبه كوميدي: الحمولة الخبيثة أطلقت عمليات بايثون فرعية بشكل متكرر حتى نفدت ذاكرة الجهاز وتوقف عن العمل. الاكتشاف جاء صدفة بسبب استنفاد الموارد، لا نتيجة ضابط أمني تنبّه للأمر.
تتبّعوا الآلية وستجدون الدرس مزعجاً. لم يكن أحد مهملاً. سلوك سلسلة الأدوات الاعتيادي وحده كان كافياً: طلب الوكيل حزمة، أضاف محلّل الاعتماديات شيئاً تعتمد عليه تلك الحزمة، وشغّلت الإضافة البرمجية كل ذلك. لم يختر أي إنسان الكود الخبيث. ثلاث خطوات آلية أنجزت العملية من البداية للنهاية، ولا واحدة منها تراجع شيئاً. ولهذا التعرّض بُعد امتثالي إضافي في منطقتنا: أي تسريب بيانات ناتج عن سلسلة كهذه يقع مباشرة تحت مظلة تشريعات حماية البيانات الإقليمية، مثل نظام حماية البيانات الشخصية السعودي (PDPL) أو تشريعات الإمارات المماثلة، وهو ما يرفع كلفة الحادثة إلى ما هو أبعد من الاختراق التقني وحده، خصوصاً مع الاستثمارات السيادية المتنامية في الذكاء الاصطناعي بدول الخليج.
لماذا الهروب من سجل الحزم هو رد الفعل الخاطئ
الغريزة الأولى بعد حادثة كهذه هي فقدان الثقة بالنظام البيئي بأكمله: توجيه اللوم إلى المستودع، أو الهروب إلى لغة برمجة ذات سمعة «أكثر أماناً». هذا يسيء قراءة موضع التعرّض. المشكلة لم تكن يوماً في سمعة سجل الحزم. هي كامنة في كود غير مراجَع على عمق عدة اعتماديات، وكل نظام حزم عام يحمل هذه السمة. أعداد Sonatype للحزم الخبيثة تمتد عبر npm وPyPI وغيرها، فتغيير السجل يغيّر فقط العلامة التجارية التي لا تثقون بها، بينما يبقى الكود غير المقروء على خادم البناء لديكم.
كيف تُقيّدون وكيل برمجة فعلياً؟
ثلاثة ضوابط تؤدي معظم العمل، ولا واحد منها استثنائي أو نظري. كل واحد منها يستهدف الغاية نفسها: التوقف عن محاولة الحكم على مدى ثقتكم بحزمة معينة، والاكتفاء بتقييد ما يمكن لحزمة غير موثوقة فعله.
أولاً، سياسة رفض افتراضي لحركة الاتصال الصادرة من عملية البناء. وكيل البناء يحتاج إلى فهرس حزم وربما مضيف مستودع Git. لا يحتاج إلى نقطة نهاية بيانات وصفية للسحابة لديكم، ولا إلى شبكتكم الداخلية، ولا إلى خادم عشوائي في أي مكان آخر. على GitHub Actions هذا ضابط مطبَّق فعلياً اليوم عبر Harden-Runner من StepSecurity، الذي يحجب حركة الاتصال الصادرة افتراضياً ويقبل قائمة موثوقة:
# .github/workflows: حجب الاتصال الصادر، والسماح فقط بما يحتاجه البناء
- uses: step-security/harden-runner@v2
with:
egress-policy: block
allowed-endpoints: >
pypi.org:443
files.pythonhosted.org:443
github.com:443
حمولة تحاول تسريب مفتاح SSH لن تجد الآن أي وجهة ترسل إليها، ويسجّل Harden-Runner المكالمة المحجوبة فتظهر المحاولة في سجل التشغيل. بذلك تكونون قد قيّدتم ما يمكن للحزمة فعله دون الحاجة إلى الحكم أصلاً على مدى أمانها.
ثانياً، التثبيت من ملف قفل موثّق بالمستودع مع بصمات تجزئة (hash)، ورفض أي شيء لا يطابقها. تثبيت رقم إصدار الحزمة الرئيسية وحده لا يكفي، لأن الخطر يكمن في الشجرة الفرعية. ملف القفل يسجّل كل حزمة تم تحليلها وبصمتها، فلا يمكن لنسخة مستبدلة أو مسمومة أن تصل بصمت. الأوامر جاهزة فعلاً: npm ci يثبّت حصرياً من ملف package-lock.json الموثّق بالمستودع، وpip install --require-hashes -r requirements.txt يرفض أي تنزيل تكون بصمته مفقودة أو خاطئة، وإضافة --ignore-scripts في npm تمنع تنفيذ الكود وقت التثبيت الذي تعتمد عليه هجمات كثيرة. مع تثبيت البصمات، لا تعود النسخة السيئة تنزيلاً صامتاً بل تصبح فرقاً (diff) يراجعه إنسان، أو ماسح آلي، قبل أن يُشغَّل أي شيء:
# package-lock.json، يظهر داخل طلب السحب (pull request)
"node_modules/log-helper": {
- "version": "2.4.0",
- "integrity": "sha512-6b1e2c..."
+ "version": "2.4.1",
+ "integrity": "sha512-00d4af..."
بدون ملف القفل، يكتفي محلّل الاعتماديات بجلب النسخة الجديدة ويبقى التغيير غير مرئي تماماً. مع وجوده، يتحول التبديل إلى خط أحمر ينتظر المراجعة بدلاً من تثبيت صامت.
ثالثاً، فحص كل تغيير في الاعتماديات آلياً، وإسقاط عملية البناء حين يعثر الفحص على شيء لا يمكن تبريره. هنا لحقت الأدوات بالركب فعلياً. OSV-Scanner من Google يفحص ملفات القفل مقارنة بقاعدة بيانات ثغرات عامة، وخدمات مثل Socket تفحص كل حزمة مضافة بحثاً عن أوامر تنفيذ وقت التثبيت، وكود مموّه، ونشاط شبكي غير متوقع، مباشرة داخل طلب السحب نفسه. اربطوا أحدها بالبيئة المعزولة ذاتها وشغّلوه عند كل تغيير في ملف القفل:
# .github/workflows: إسقاط طلب السحب عند اعتمادية معروفة الخطورة أو مضافة حديثاً
- uses: google/osv-scanner-action@v2
with:
scan-args: "--lockfile=package-lock.json"
إضافة نموذج ذكاء اصطناعي فوق هذه الطبقات هي، برأيي، النقطة التي تميل فيها المعادلة الاقتصادية أخيراً لصالح المدافع، رغم أن هذا الجزء استنتاج لا نتيجة قياس فعلي: النماذج نفسها التي تُثبّت دون قراءة قادرة أيضاً على قراءة فرق الاعتماديات أسرع من أي إنسان، ورصد خطاف تشغيل مشبوه، وتتبّع مسار تسريب محتمل. حين تُستخدم بهذه الطريقة، يكون المهاجم قد أتمت هجومه بينما أتممتم أنتم مراجعتكم. الماسحات المذكورة أعلاه هي النواة القابلة للتطبيق فوراً، أما النموذج فهو مسرّع فوقها، لا بديل عن البيئة المعزولة وملف القفل.
نطبّق الانضباط ذاته في كل مشروع استشاري نتولاه، وهو نهج يمتد إلى التحليلات الأوسع التي ننشرها: أبقوا الإنسان داخل الحلقة حيث يهم الحكم والتقدير، وقيّدوا الآلة حيث لا يهم.
الوكلاء لن يعودوا إلى الصندوق، ولا ينبغي أن يعودوا. لكن الفريق الذي يثبّت ما لا يقرأه يكون قد ألغى بنفسه خط دفاعه الأخير. الحل ليس منح الحزم ثقة أكبر. الحل أن تمنحوا عملية البناء مكاناً آمناً للتشغيل، وملف قفل يجعل أي عبث مرئياً، وماسحاً يقرأ كل تغيير حتى لا تصل أي اعتمادية غير مقروءة إلى الإنتاج.
أسئلة شائعة
هل وكلاء البرمجة بالذكاء الاصطناعي أخطر من مطوّر بشري يثبّت الحزم بنفسه؟
الخطر من الفئة نفسها لهجمات سلسلة التوريد، لكن التعرّض أوسع في أوضاع الموافقة التلقائية والتثبيت الخلفي التي تفعّلها الفرق طلباً للسرعة، حيث يحلّل الوكيل اعتماديات فرعية متسلسلة ويشغّلها دون أن يلقي عليها أحد نظرة تقريباً، فيمكن للاختراق أن ينتشر قبل أن يلاحظه أحد.
هل يجب تغيير لغة البرمجة بعد حادثة اختراق في الاعتماديات؟
لا. كل نظام حزم عام يحمل كوداً فرعياً غير مراجَع، وبحث Endor Labs يضع نحو 95% من الاعتماديات الثغرية في تلك الطبقة الفرعية، فتغيير اللغة ينقل فقط العلامة التجارية التي لا تثقون بها دون أن يحل شيئاً. ثبّتوا الإصدارات عبر ملف قفل مزوّد ببصمات تجزئة، وتحققوا من مصدر الحزم، واعزلوا بيئة التنفيذ بدلاً من ذلك.
هل يمكن لوكيل ذكاء اصطناعي أن يساعد في الدفاع ضد الحزم الخبيثة بدلاً من أن يكون مصدر الخطر فقط؟
نعم، والنواة القابلة للتطبيق فوراً ليست استثنائية: شغّلوا عمليات البناء داخل بيئة معزولة برفض افتراضي مثل Harden-Runner، وضعوا ماسحاً آلياً مثل OSV-Scanner أو Socket على كل فرق في الاعتماديات لرصد أوامر التثبيت والكود المموّه والاتصالات الشبكية غير المتوقعة. يمكن لنموذج ذكاء اصطناعي فرز الفروقات المرصودة أسرع من أي إنسان، لكن يجب التعامل مع ذلك كمسرّع فوق الماسح والبيئة المعزولة، لا كبديل عنهما.
مواضيع ذات صلة
- في أوبونتو 26.04 LTS، حزمة coreutils التي تعتمد عليها بنيتكم التقنية لم تعد GNU
- علاوة السيادة: لماذا تكسب حلول الذكاء الاصطناعي السيادي للمؤسسات الرهان على حرية الوصول لا على السرعة
- قضايا الأسرار التجارية تُحسم قبل سنوات من استقالة أي موظف. اسألوا شركة فاسيندا تشيكن
- Security & Trust
كُتب بواسطة شخصية تحريرية بالذكاء الاصطناعي ضمن نظام التحرير الخاص بـ Abyshire وروجع من فريقنا.