ما الذي يختبئ في التعليمات البرمجية الخاصة بك؟

حتى المشاريع البسيطة لديها طريقة للتضخم بسرعة ويتم تضخيم هذا الاتجاه من خلال سهولة دمج الأجزاء الموجودة من التعليمات البرمجية أو مكتبات العقد.

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

حتى قائد الفريق، المسؤول عن الموافقة على جميع طلبات السحب، لا يمكنه معرفة كل سطر من التعليمات البرمجية، وكل وظيفة، وكل متغير.

مسألة ثقة

وهذا أحد أسباب التغيير الطفيف في الكود الذي حدث في تطبيق Orion في أواخر عام 2020، في الحالة المعروفة لاحقًا باسم سولارويندز, لم يتم اكتشافها لفترة طويلة. كان التغيير بأكمله عبارة عن بضع عشرات من الأسطر من التعليمات البرمجية، وكانت جيدة جدًا مخبأة داخل الطبقة الأصلية.

تم توقيع المنتج الذي تم تغييره بشكل صحيح، لذلك لم يكن هناك سبب للشك فيه، ووثقت فرق التطوير بمالك الكود.

لقد علمنا مؤخرًا فقط أن NPM كان لديه "خلل منطقي"التي مكنت الجهات الفاعلة الخبيثة من تمرير المكتبات المارقة على أنها مكتبات شرعية. في الأساس، سمح NPM بإضافة أي شخص كمشرف على الحزمة دون إخطار هؤلاء المستخدمين أو الحصول على موافقتهم. 

وقد مكّن ذلك من إنشاء حزم بها برامج ضارة وتعيينها لمشرفين مشهورين وموثوقين دون علمهم. قد تعني حالة الثقة في غير محلها وجود ثغرة أمنية إشكالية مخبأة في التعليمات البرمجية الخاصة بك.

هناك ممارسة شائعة أخرى يجب مراعاتها وهي قيام المطورين بنسخ ولصق التعليمات البرمجية من المكتبات الموجودة أو StackOverFlow لاستخدامها في التعليمات البرمجية الخاصة بهم أو لإعادة تحميلها إلى مكتبات جديدة. يؤدي القيام بذلك إلى زيادة فرصة نسخ التعليمات البرمجية غير الآمنة والضعيفة التي لا يمكن تتبعها الآن بشكل أساسي. حتى لو حصل الكود الأصلي على CVE وعلاجه في النهاية، فإن الوظيفة الإشكالية التي نسختها تكون غير مرئية ويمكن أن تلوث أي قاعدة تعليمات برمجية قد تستخدمها لسنوات قادمة. 

وفي دراسة حديثة أجريت في جامعة كانساس ("ما الشوكة؟ العثور على نسخ التعليمات البرمجية المخفية في npm")، يوضح الباحثون كيف أن استخدام الحزم التي تم فحصها بالكامل يمكن أن يكون غير آمن.

ماذا يمكنك أن تفعل حيال ذلك؟

لذلك، لا يمكنك الوثوق بالمنتجات الموقعة وتحديثات البائعين. ربما تم بالفعل تعديل التعليمات البرمجية الخاصة بك أو إضافتها، وذلك بسبب كل تلك المكتبات الخارجية والتعليمات البرمجية المدمجة فيها. إذن، ما الذي يمكنك فعله للتأكد من أنك لا تقوم بتثبيت ملفات ضارة في نظامك؟

هناك عدد قليل من الأشياء التي يمكن القيام به:

1. اطلب SBOM كاملاً من كل مالك مكتبة أو بائع برنامج تقوم بدمجه. يمكن أن يساعدك SBOM في التأكد من ماهية جميع "المكونات" الموجودة في المكتبة أو المنتج. بالإضافة إلى ذلك، إذا وجدت شيئًا ما في المكتبة أو المنتج غير مدرج في SBOM، فيجب اعتباره مشبوهًا. يمكنك معرفة المزيد حول ماهية SBOM هنا.
2. اطلب شهادة موثوقة من البائع أو مالك المكتبة بأنه قد تم إجراء فحص السلامة وأنك تحصل على ما تتوقعه. لا يجب أن تثق إلا بضمانات البائع الخاصة.
   
3. عند تثبيت الحزم، استخدم علامة npm CLI --ignore-scripts لتجنب تنفيذ البرامج النصية من حزم الطرف الثالث أثناء مرحلة التثبيت.
4. إستخدم حزمة lock.json ملف لقفل أرقام إصدار الحزمة. عندما تستخدم أ حزمة lock.json فأنت لا تقوم فقط بقفل إصدارات الحزمة التي تستخدمها، بل تقوم أيضًا بقفل تبعياتها أيضًا. ويكمن الخطر في أنك لن تقوم بسحب أي تحديثات تلقائية للحزمة قد تتضمن إصلاحات لأخطاء مختلفة. ولكن، إذا كنت قد بدأت العمل على التحقق من إصدار معين ولا تريد تضمين أي شيء آخر دون التحقق منه أولاً، فإن قفل أرقام الإصدارات الخاصة بك هو الخيار الأفضل.

متابَع اللوائح الجديدة، من المتوقع أن يبدأ معظم الأشخاص في استخدام SBOMs في المستقبل القريب جدًا. كلما زاد عدد الشركات التي تطلب شهادات SBOM والشهادات الأخرى، كلما زاد عدد المنظمات والمشرفين الذين يتعين عليهم الالتزام بها.