سيكون نظام Linux والبرامج مفتوحة المصدر أكثر سخونة من أي وقت مضى ، لكن التغييرات الحقيقية ستكون في كيفية تأمينها.
لينكس في كل مكان. هذا ما تشغله كل السحابات ، حتى Microsoft Azure . هذا هو ما يجعل كل 500 من أفضل 500 كمبيوتر عملاق تعمل . هيك ، حتى Linux على سطح المكتب ينمو إذا كان بإمكانك تصديق موقع Pornhub ، الذي يزعم أن مستخدمي Linux نما بنسبة 28٪ ، بينما انخفض مستخدمو Windows بنسبة 3٪.
البرامج مفتوحة المصدر تنمو أيضًا بسرعة فائقة. وفقًا لـ Gartner's 2021 Hype Cycle for Open-Source Software (OSS) : "بحلول عام 2025 ، ستزيد أكثر من 70٪ من المؤسسات إنفاقها على تكنولوجيا المعلومات على OSS ، مقارنةً بإنفاقها الحالي على تكنولوجيا المعلومات. بالإضافة إلى ذلك ، بحلول عام 2025 ، البرمجيات كخدمة ( ستصبح SaaS) نموذج الاستهلاك المفضل لـ OSS نظرًا لقدرتها على توفير بساطة تشغيلية أفضل وأمان وقابلية التوسع. "
بالتفكير في قواعد البيانات ، ولحم البقر والبطاطس في برامج المؤسسة ، تتوقع Gartner أنه سيتم تطوير أكثر من 70٪ من التطبيقات الداخلية الجديدة على قاعدة بيانات مفتوحة المصدر. في الوقت نفسه ، سيتم تحويل 50٪ من مثيلات قواعد البيانات العلائقية الحالية الخاصة بالملكية أو سيتم تحويلها إلى أنظمة DBMS مفتوحة المصدر.
سأشتري هذه الأرقام. لقد كنت أتابع Linux والبرامج مفتوحة المصدر منذ اليوم الأول. في كل مكان أذهب إليه ويعترف كل من أتحدث إليه بأن الزوجين يديران عالم البرمجيات.
ولكن مع القوة الكبيرة تأتي أيضًا مسؤولية كبيرة كما يعرف الرجل العنكبوت. وكما اكتشف العديد من المطورين مؤخرًا عندما تم اكتشاف ثغرات أمنية متعددة مع log4j2 مكتبة مفتوحة المصدر لتسجيل Apache Java ، فإنها تأتي أيضًا بصداع كبير.
مشاكل log4j2 سيئة بقدر ما يمكن أن يحصل عليها السوء. وفقًا لمقياس قاعدة بيانات الثغرات الأمنية الوطنية (NVD) ، تم تصنيفه على أنه 10.0 CVSSv3 وهو أمر مروع تمامًا.
إن مشكلته الحقيقية لا تتعلق بالمصدر المفتوح نفسه. لا يوجد شيء سحري حول منهجية وأمن المصادر المفتوحة . لا يزال بإمكان الأخطاء الأمنية إدخال الرمز. قانون لينوس هو أنه بالنظر إلى ما يكفي من مقل العيون ، فإن كل الحشرات ضحلة. ولكن إذا لم يبحث المطورون بشكل كافٍ ، فستظل الثغرات الأمنية تمر مرور الكرام. كما أسميه الآن قانون شناير ، " الأمن عملية ، وليس منتج " ، يشير إلى أن اليقظة المستمرة ضرورية لتأمين جميع البرامج.
ومع ذلك ، فإن الألم الحقيقي مع log4j هو كيفية إخفاء Java للمكتبات التي يستخدمها كود المصدر والثنائيات في العديد من إصدارات Java Archive (JAR) . النتائج؟ ربما تستخدم إصدارًا ضعيفًا من log4j ولا تعرف حتى يتم استغلاله.
كما أوضح Josh Bressers ، نائب رئيس Anchore للأمان مؤخرًا ، "يتمثل أحد التحديات التي تطرحها ثغرة log4j في العثور عليها بالفعل. عادةً ما تكون تطبيقات Java والتبعيات في نوع من تنسيق الحزم الذي يجعل التوزيع والتشغيل أمرًا سهلاً حقًا ، ولكن يمكن أن يجعل اكتشاف ما بداخل حزم البرامج هذه أمرًا صعبًا ".
لحسن الحظ ، هناك ماسحات ضوئية log4j يمكنها مساعدتك في اكتشاف مكتبات log4j المعيبة قيد الاستخدام. لكنهم ليسوا مثاليين.
توجد مشكلة أخرى خلف فوضى log4j ، وهي "كيف تعرف مكونات المصدر المفتوح التي يستخدمها برنامجك؟" على سبيل المثال ، تم استخدام log4j2 منذ عام 2014. لا يمكنك أن تتوقع من أي شخص أن يتذكر ما إذا كان قد استخدم هذا الإصدار الأول في بعض البرامج التي ما زلت تستخدمها اليوم.
الإجابة هي أن مجتمع المصادر المفتوحة بدأ يأخذ على محمل الجد في السنوات الأخيرة: إنشاء فواتير المواد البرمجية (SBOM) . يوضح SBOM بالضبط مكتبات البرامج والإجراءات والشفرات البرمجية الأخرى التي تم استخدامها في أي برنامج. مسلحًا بهذا ، يمكنك فحص إصدارات المكونات المستخدمة في برنامجك.
كما أوضح David A. Wheeler ، مدير أمن سلسلة التوريد مفتوح المصدر في مؤسسة Linux ، باستخدام SBOMs والبنيات القابلة للتكرار التي تم التحقق منها ، يمكنك التأكد من أنك تعرف ما هو موجود في برامجك. بهذه الطريقة ، إذا تم العثور على ثغرة أمنية في أحد المكونات ، فيمكنك ببساطة تصحيحها بدلاً من البحث مثل مجنون عن أي رمز مشكلة محتمل قبل التمكن من إصلاحه.
بالمناسبة ، يوضح ويلر أن "البناء القابل للتكرار" هو "الذي ينتج دائمًا نفس المخرجات مع إعطاء نفس المدخلات بحيث يمكن التحقق من نتائج البناء. البناء القابل للتكرار الذي تم التحقق منه هو عملية تنتج فيها المؤسسات المستقلة بناءًا من التعليمات البرمجية المصدر وتحقق من أن النتائج المبنية تأتي من شفرة المصدر المطالب بها ".
للقيام بذلك ، تحتاج أنت والمطورون لديك إلى تتبع برامجك في SBOM باستخدام تنسيق تبادل بيانات حزمة البرامج (SPDX) الخاص بمؤسسة Linux Foundation . ثم، لمزيد من حماية هذا الرمز الخاص بك هو حقا ما يدعى أنه تحتاج إلى صدق وتحقق SBOM مع خدمات مثل Codenotary خدمة المجتمع شهادة و Tidelift كتالوجات .
كل هذا يسهل قوله. القيام بذلك بجد. في عام 2022 ، سيقضي جميع مطوري البرامج مفتوحة المصدر إلى حد كبير وقتًا طويلاً في التحقق من التعليمات البرمجية الخاصة بهم بحثًا عن المشكلات ، ثم بناء وحدات SBOMs تعتمد على SPDX. سيطالب المستخدمون ، القلقون بشأن كوارث من نوع Solarwind ومشكلات أمان log4j ، بهذا.
في الوقت نفسه ، يعمل مطورو Linux على زيادة تأمين نظام التشغيل من خلال جعل لغة Rust Linux الثانية . لماذا ا؟ لأنه ، على عكس C ، لغة Linux الأساسية ، فإن Rust أكثر أمانًا. على وجه التحديد ، يعتبر Rust أكثر أمانًا من C في معالجة أخطاء الذاكرة.
كما أوضح رايان ليفيك ، مطور سحابي رئيسي من Microsoft ، " Rust آمن تمامًا للذاكرة ." هذه صفقة ضخمة ، لأنه ، كما أشار مطورو نواة Linux Alex Gaynor و Geoffrey Thomas في قمة Linux Security لعام 2019 ، فإن ما يقرب من ثلثي ثغرات أمان Linux kernel تأتي من مشكلات تتعلق بأمان الذاكرة. ومن أين يأتون؟ مشاكل متأصلة في C و C ++.
الآن ستتم إعادة كتابة Linux في Rust. على الأقل ليس هذا العقد ، تحقق معي مرة أخرى في 2030 ، ولكن سيتم كتابة الكثير من برامج تشغيل Linux والرموز الأخرى في Rust.
كما أخبرني Linus Torvalds بينما "لا يدفع" بأي حال من الأحوال من أجل Rust ، "إنه" منفتح على ذلك بالنظر إلى المزايا الموعودة وتجنب بعض المخاطر المتعلقة بالسلامة. ومع ذلك ، فقد اختتم ، "أعلم أيضًا أنه في بعض الأحيان لا تنجح الوعود . "
سنرى كيف يعمل كل شيء. بغض النظر عن كيفية سير التفاصيل ، هناك شيء واحد أعرفه على وجه اليقين. سنرى أن تأمين الكود قد أصبح أهم مشكلة بالنسبة إلى Linux ومطوّري البرامج مفتوحة المصدر في عام 2022. لقد أصبح كلاهما مهمًا للغاية بالنسبة لهما في أي طريقة أخرى.
