مرحباً بكم في مدونة WondTech! هل سبق أن سمعت عن ثغرة أمنية في حزمة برمجية وتساؤلت: «هل تأثرنا بها؟». يبدو هذا سؤالاً بسيطاً، أليس كذلك؟ لكن في عالم تطوير البرمجيات، الإجابة عليه أصعب بكثير مما تتخيل، وهذا يؤثر بشكل مباشر على أمان برامجك ومنتجاتك. المشكلة تكمن في أن مجرد النظر إلى قائمة الحزم (dependencies) الحالية لمشروعك لا يكفي أبداً لتحديد ذلك. فقد تكون النسخة الضارة من الحزمة قد ظهرت واختفت بسرعة، وربما تكون أدوات إدارة الحزم قد استبدلتها بالفعل بنسخة أحدث. حتى ملفات «lockfile» التي تسجل النسخ المستخدمة يمكن أن تتغير بعد إطلاق إصدار معين من برنامجك. بالإضافة إلى ذلك، قد تعيد طبقات Docker أو ذاكرة التخزين المؤقت في أنظمة التكامل المستمر (CI) استخدام مكونات لم تعد موجودة في الفرع الرئيسي لمشروعك. باختصار، عملية فحص نظيفة اليوم لا تخبرك الكثير عن الإصدار الذي بنيته بالأمس. هذا يجعل الاستجابة لحوادث أمان سلاسل التوريد البرمجية بمثابة «مشكلة إعادة بناء». فالوحدة المهمة ليست مستودع الكود كما هو الآن؛ بل هي منتج معين تم إنتاجه بواسطة عملية بناء معينة، باستخدام مجموعة محددة من الحزم التي تم حلها في ذلك الوقت. فكروا في ما حدث في الرابع من أغسطس، عندما كشفت شركة Aikido عن اختراق حساب أحد مسؤولي الحزم المرتبطة بـ Keyv. تم استخدام إصدارات ضارة لتثبيت تعليمات برمجية خبيثة تهدف إلى سرقة بيانات الاعتماد. مثل هذه الحوادث سريعة الحركة، وقد تنتهي قبل أن يتمكن فريقك من تحديد ما إذا كان أي منتج تم إطلاقه قد احتوى على النسخة الضارة. ماذا نحتاج إذن؟ نحتاج إلى أداة تستطيع قبول ملف «lockfile» وتاريخ البناء ومعلومات عن المنتج النهائي، ثم تعيد بناء ما تم استخدامه بالضبط في عملية البناء تلك. يجب أن تنتج تقريراً يوضح الصور والخدمات والإصدارات التي وصلت إلى العملاء، مع دليل واضح لكل استنتاج. على سبيل المثال، إدخال في ملف «lockfile» مع تفاصيل الإصدار والتكامل يعد دليلاً مباشراً، بينما نافذة نشر في السجل مع نطاق إصدار قد تكون مجرد استنتاج. التمييز بين هذه الأنواع من الأدلة مهم جداً، لأن النتائج قد تؤدي إلى قرارات مكلفة أو لا رجعة فيها، مثل عزل خدمة أو تغيير بيانات اعتماد. الحفاظ على أمان برامجك يتطلب رؤية واضحة لما تم استخدامه في كل خطوة من خطوات البناء.