كان هجوم SolarWinds عام 2020 نقطة تحوّل حقيقية. لم يخترق المهاجمون المنظمات المستهدفة مباشرة. بل اخترقوا خط أنابيب بناء البرمجيات لدى مورّد موثوق، وأدرجوا كوداً خبيثاً في تحديث برمجي شرعي، ووزّعوه على آلاف العملاء الذين كان لديهم كل أسباب الثقة فيما يثبّتونه. كشفت الثغرة عن وزارة الخزانة الأمريكية ووزارة الأمن الداخلي ومئات المنظمات في القطاع الخاص. لم تكن الأضرار نتيجة كلمات مرور ضعيفة أو خوادم غير مُحدَّثة — بل كانت نتيجة عدم موثوقية سلسلة توريد البرمجيات بشكل جوهري.

أذكى هذا الإدراك أحد أهم حركات أمن البنية التحتية في عقد العشرينيات. في 2026، نضجت منظومة أمن سلسلة توريد البرمجيات — Sigstore لتوقيع القطع البرمجية، وSLSA للإثبات الرقمي لنزاهة البناء، وSBOMs لشفافية التبعيات، والسجلات المحصّنة للحاويات — من مشاريع بحثية إلى متطلبات إنتاج في المنظمات الهندسية الجادة.

المشكلة التي جعلها SolarWinds لا يمكن إنكارها

البرمجيات الحديثة لا تُكتب من الصفر. إنها تُجمَّع. يسحب تطبيق مؤسسي نموذجي مئات التبعيات مفتوحة المصدر، التي تسحب هي بدورها مئات أخرى. يحتوي التطبيق المتوسط على سطور أكثر من كود الأطراف الثالثة من الكود الداخلي. كل واحدة من هذه التبعيات تمثل ناقلاً محتملاً للهجوم.

أثبتت ثغرة Log4Shell أواخر 2021 ذلك بوضوح مرعب. عيب حرج في Log4j، مكتبة تسجيل Java منتشرة في كل مكان تُستخدم في كل شيء من خوادم المؤسسات إلى الأنظمة المدمجة، كشف عن مئات الملايين من التطبيقات عالمياً. المشكلة لم تكن أن Log4j مجهولة — بل كانت في كل مكان تحديداً لأنها كانت موثوقة ومعتمدة على نطاق واسع. كان انتشارها الواسع هو سطح الثغرة بعينه.

تكاثر نموذج الهجوم عبر التبعيات منذ ذلك الحين. أصبحت الحزم الخبيثة المرفوعة على npm وPyPI وRubyGems — المسمّاة عمداً لتشبه الحزم الشرعية الشهيرة (typosquatting) — ناقلاً روتينياً للتهديد. نمت هجمات سلسلة التوريد بأكثر من 730% بين 2019 و2022 وفق تقرير Sonatype السنوي حول حالة سلسلة توريد البرمجيات، وتواصل الاتجاه في الارتفاع.

Sigstore: توقيع كل شيء، عدم الثقة في أي شيء غير موقَّع

Sigstore مشروع تابع للـ Linux Foundation يوفر بنية تحتية مفتوحة ومجانية لتوقيع القطع البرمجية — صور الحاويات، الثنائيات، إثباتات البناء — والتحقق من هذه التوقيعات بشفافية. الفكرة الجوهرية هي أن مصدر البرمجيات (من أين جاءت ومن بناها) يجب أن يكون قابلاً للتحقق تماماً كشهادات HTTPS على مواقع الويب.

اقتضى النهج التقليدي لتوقيع الكود إدارة مفاتيح خاصة، وهو أمر صعب فعلاً بشكل آمن على نطاق واسع. تتسرب المفاتيح وتضيع وتُجدَّد بشكل غير متسق. حل Sigstore هو استخدام شهادات قصيرة الأجل مرتبطة بهوية OIDC (هوية GitHub أو Google للمطوِّر) بدلاً من مفاتيح خاصة طويلة الأجل. يُسجَّل حدث التوقيع في سجل شفافية عام يعمل بالإضافة فقط يسمى Rekor، مما يتيح لأي شخص التحقق من أن قطعة برمجية محددة وقّعتها هوية محددة في وقت محدد.

بحلول 2025، معالجة Sigstore مليارات التوقيعات. بدأ Python Package Index (PyPI) طرح إثباتات المصدر المبنية على Sigstore. دمج GitHub مع Sigstore في workflows الـ Actions، مما يتيح لأي مستودع توليد إثباتات البناء الموقَّعة تلقائياً. تبع ذلك سجل npm الخاص بـ GitHub. لأي منظمة تسحب الحزم من هذه السجلات، البنية التحتية اللازمة للتحقق من أن حزمة بُنيت فعلاً من الكود المصدري المُعلن — ولم تُعبَّث بها في العبور — باتت موجودة وتُشكّل المعيار المتوقع بصورة متزايدة.

SLSA: مستويات نزاهة البناء

يُخبرك Sigstore من وقّع القطعة البرمجية. SLSA (Supply-chain Levels for Software Artifacts، تُنطق “salsa”) يُخبرك بمدى موثوقية عملية البناء التي أنتجتها. SLSA إطار عمل طُوِّر في Google وتتولى الآن رعايته منظمة OpenSSF يُعرِّف أربعة مستويات تدريجية لأمن سلسلة التوريد.

في المستوى 1 من SLSA، توثّق عمليات البناء. في المستوى 2، تخضع لإدارة الإصدارات وتستخدم خدمة بناء. في المستوى 3، تُحصَّن خدمة البناء ضد التلاعب — تُسجَّل المصادر وخطوات البناء في مصدر قابل للتحقق. المستوى 4 (الأكثر صرامة، غير المعتمد على نطاق واسع بعد) يتطلب مراجعة ثنائية لجميع التغييرات وعملية بناء محكمة وقابلة للإعادة.

الأثر العملي هو أن SLSA يمنح فرق الشراء ومدققي الأمن ومهندسي المنصات مفردات للسؤال “كم مقدار الثقة في هذه القطعة البرمجية؟” بدلاً من مجرد “هل وُقِّعت؟” صورة حاوية بُنيت من بيئة بناء مؤقتة معزولة بمصدر مسجَّل على مستوى 3 من SLSA هي أكثر موثوقية من تلك المبنية محلياً على حاسوب مطوِّر ومدفوعة مباشرة إلى سجل، بصرف النظر عن توقيع كليهما.

تحرّكت كبرى مزودي الخدمات السحابية لدعم إثباتات SLSA بشكل أصيل. Google Cloud Build يولّد مصدر SLSA المستوى 3. GitHub Actions تدعم توليد إثباتات SLSA. المرسوم التنفيذي للحكومة الفيدرالية الأمريكية بشأن تحسين الأمن السيبراني الوطني أوجب إرشادات NIST تتوافق مع مبادئ SLSA للبرمجيات المشتراة من قِبل الوكالات الفيدرالية.

إعلان

متطلبات SBOM: معرفة ما يوجد في برمجياتك

Software Bill of Materials (SBOM) هو قائمة جرد قابلة للقراءة آلياً بجميع مكونات قطعة برمجية — تبعياتها المباشرة، وتبعياتها المتعدية، وإصداراتها، والتزامات الترخيص المعروفة. المفهوم مستعار من التصنيع، حيث قائمة المواد وثيقة قياسية.

جعل المرسوم التنفيذي الأمريكي لمايو 2021 الـ SBOMs إلزامية للبرمجيات المباعة للحكومة الفيدرالية. قانون الاتحاد الأوروبي للمرونة السيبرانية، الذي دخل حيز التنفيذ في 2024، يوسّع متطلبات مماثلة على نطاق واسع لمنتجات البرمجيات المباعة في السوق الأوروبية. في 2026، أصبح إنتاج واستهلاك الـ SBOMs بسرعة ممارسة هندسية قياسية في المنظمات التي تأخذ مخاطر سلسلة التوريد بجدية، لا مجرد خانة امتثال تُعلَّم عليها.

الصيغتان السائدتان لـ SBOM هما SPDX (تحافظ عليها Linux Foundation) وCycloneDX (تحافظ عليها OWASP). معظم أدوات البناء الكبرى ومنصات CI/CD تتضمن الآن إضافات أو دعماً أصيلاً لتوليد الـ SBOMs تلقائياً كجزء من عملية البناء. العمل الصعب ليس توليد الـ SBOM — بل تشغيله: دمج بيانات SBOM في سير عمل إدارة الثغرات لكي تتلقى فرق الهندسة، حين يظهر CVE جديد في تبعية متعدية، تنبيهات قابلة للتنفيذ بدلاً من ضجيج المسح العام.

ثقة الحاويات ونموذج أمن السجلات

أصبحت الحاويات وحدة التعبئة والنشر البرمجي السائدة. بيد أن صور الحاويات هي بحد ذاتها قطع سلسلة توريد: يشير Dockerfile إلى صورة أساسية من سجل، بُنيت من كود مصدري يسحب تبعياته الخاصة. كل طبقة سطح هجوم محتمل.

جاء الرد بتحصين سجلات الحاويات والسير الوظيفية المحيطة بها. Cosign، جزء من مشروع Sigstore، يتيح توقيع صور الحاويات وتخزين توقيعاتها في سجل متوافق مع OCI. أدوات إنفاذ السياسات كـ Kyverno وOPA/Gatekeeper تتيح لعناقيد Kubernetes رفض صور الحاويات غير الموقَّعة أو غير المعتمدة عند القبول — مانعةً تشغيل الصور غير المتحقق منها في الإنتاج بصرف النظر عما يحاول المطوّرون أو الأنظمة الآلية نشره.

انتقل مفهوم “المنشئ الموثوق” — بيئة CI/CD مؤقتة ومعزولة وقابلة للتدقيق تنتج قطعاً موقَّعة بمصدر مسجَّل — من أفضل ممارسة نظرية إلى متطلب تشغيلي في البيئات عالية الأمان. تتحول منظومة أمن سلسلة التوريد إلى بنية تحتية: غير مرئية حين تعمل بشكل صحيح، كارثية حين تغيب.

مقالات ذات صلة

إعلان

رادار القرار (منظور الجزائر)

البُعد التقييم
الصلة بالجزائر عالية — تواجه فرق تطوير البرمجيات الجزائرية، ولا سيما تلك التي تبني للحكومة والقطاع المصرفي والبنية التحتية الحيوية، المخاطر ذاتها لسلسلة التوريد التي يواجهها نظراؤهم العالميون؛ تبنّي هذه الممارسات شرط مسبق لعقود التسليم البرمجي الدولية
البنية التحتية جاهزة؟ جزئياً — بنية CI/CD (GitHub Actions، GitLab CI) مستخدمة على نطاق واسع من المطوّرين الجزائريين؛ دمج أدوات Sigstore وSLSA يتطلب تعديل الأنابيب دون استثمار بنية تحتية جديدة
المهارات متاحة؟ جزئياً — مهارات DevSecOps نادرة في المنطقة؛ توليد الـ SBOMs وإثبات سلسلة التوريد ليست بعد جزءاً من التدريب القياسي للمطوّرين في الجزائر، مما يخلق حاجة ملحّة للتطوير المهني
الجدول الزمني للعمل 6-12 شهراً — ينبغي للمنظمات ذات العملاء الحكوميين الأوروبيين أو الأمريكيين البدء فوراً في تبني ممارسات SBOM والتوقيع؛ التبني الأوسع للنظام البيئي هو انتقال من 12 إلى 24 شهراً
أصحاب المصلحة الرئيسيون شركات تطوير البرمجيات، فرق تكنولوجيا المعلومات في شركات التقنية المالية والبنوك، وحدات التحول الرقمي الحكومية، المتخصصون في الأمن السيبراني، مؤسسات التعليم الهندسي
نوع القرار استراتيجي

خلاصة سريعة: طموحات الجزائر المتنامية في تصدير البرمجيات — التي تستهدف عملاء المؤسسات في أوروبا والشرق الأوسط — ستصطدم بصورة متزايدة بمتطلبات SBOM وإثبات سلسلة التوريد كشرط للمشتريات. فرق التطوير الجزائرية التي تبني هذه القدرات الآن ستتميز بموقفها الأمني؛ أما تلك التي تنتظر فستجد نفسها مستبعدة من العقود عالية القيمة بسبب متطلبات امتثال لم تكن تتابعها.

المصادر والقراءات الإضافية