كان هجوم 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 مؤقتة ومعزولة وقابلة للتدقيق تنتج قطعاً موقَّعة بمصدر مسجَّل — من أفضل ممارسة نظرية إلى متطلب تشغيلي في البيئات عالية الأمان. تتحول منظومة أمن سلسلة التوريد إلى بنية تحتية: غير مرئية حين تعمل بشكل صحيح، كارثية حين تغيب.
الأسئلة الشائعة
ما المقصود بـ Securing the Software Supply Chain؟
يتناول هذا المقال الجوانب الأساسية لهذا الموضوع، ويستعرض الاتجاهات الحالية والجهات الفاعلة الرئيسية والتداعيات العملية على المهنيين والمؤسسات في عام 2026.
لماذا يُعد هذا الموضوع مهمًا؟
يكتسب هذا الموضوع أهمية كبيرة لأنه يؤثر بشكل مباشر على كيفية تخطيط المؤسسات لاستراتيجيتها التقنية وتخصيص مواردها وتموضعها في مشهد سريع التطور.
ما أبرز النقاط المستخلصة من هذا المقال؟
يحلل المقال الآليات الرئيسية والأطر المرجعية والأمثلة الواقعية التي تشرح كيفية عمل هذا المجال، مستندًا إلى بيانات حديثة ودراسات حالة عملية.
