هناك رمز مفتوح المصدر داخل كل مشروع تطوير برمجيات تقريبًا يمكنك التفكير فيه. المطورين يحبون ذلك. لكنك تحتاج إلى فهم المخاطر الخفية وكيفية تقليلها ، أو يمكنك ترك تطبيقك مفتوحًا أمام ثغرات أمنية غير معروفة.
الترميز قبل المصدر المفتوح
ذات مرة كتب مطورو البرمجيات كل شيء من البداية. ثم بدأت تظهر مكتبات الأكواد ومجموعات الأدوات والوظائف الإضافية الأخرى. يمكنك الحصول على دعم باستخدام مجموعة أدوات لتوفير بعض الوظائف ، مثل وحدة إعداد التقارير أو عنصر واجهة مستخدم.يمكنك إدخالها في مشروعك كمكونات جاهزة ومشكلة بالكامل واستخدامها على الفور. كان البديل هو إضاعة الوقت والمال وجهود التطوير لإعادة اختراع العجلة.
بالطبع ، بمرور الوقت ، ستنشئ مكتبتك الخاصة من الإجراءات والوحدات النمطية التي تمت كتابتها داخليًا. لذلك عندما كنت تقوم بتطوير روتين تعليمي جديد أو عنصر واجهة ، كان لديك ثلاثة خيارات. اكتبه بنفسك ، أو أعد استخدام بعض الأكواد المكتوبة مسبقًا في المنزل ، أو اشترِ في مكتبة أو مجموعة أدوات.
صعود المصدر المفتوح
أدى ظهور كود مفتوح المصدر إلى تغيير كل ذلك. تجعل البرامج مفتوحة المصدر الكود المصدري لمشروع ما متاحًا مجانًا للاستخدام من قبل الآخرين ، في حدود ترخيص حميد عادةً. لقد كان نمو واستيعاب المصادر المفتوحة مذهلين. لا يبدو أن كلمة الانتشار تغطيها. كانت هناك زيادة هائلة في البرامج مفتوحة المصدر ، ليس فقط من حيث العدد المذهل للمشاريع والمنتجات مفتوحة المصدر الموجودة ، ولكن أيضًا في استخدام المصادر المفتوحة داخل المنتجات التجارية.
وصلت البرمجيات مفتوحة المصدر إلى كتلة حرجة منذ بضع سنوات ، وانتقلت من موقعها المتميز على الهامش إلى مورد إنمائي سائد محتضن بالكامل. نظرًا لأنه كان مدفوعًا وطورًا من قبل مجتمع وليس مؤسسة تجارية تقليدية ، فقد تم اعتباره أيضًا نوعًا من الهواة.
الآن يبدو أن المصدر المفتوح قد نشأ ونضج. ولها. لكن التغيير الأكبر كان التقدير الأوسع للمصادر المفتوحة ، وفهم الفوائد التي يجلبها ، والاعتراف بأن تضمين المصدر المفتوح في منتجك ليس شيئًا يدعو للخجل.
تشير التقديرات إلى أن مشاريع البرامج غير التافهة تكتب حوالي 20 بالمائة من الكود الأصلي على الأكثر. الـ 80 بالمائة الأخرى مفتوحة المصدر. وصل موقع استضافة المستودعات الرئيسية مفتوحة المصدر ، GitHub ، إلى أكثر من 100 مليون مستودع في عام 2018. وهناك العديد من منصات Git المستضافة الأخرى ، مثل GitLab و BitBucket.
المصدر المفتوح هو ظاهرة تطوير برمجيات. ولكن ليس كل الورود في حديقة التطوير. هناك قضايا يجب أن تكون على دراية بها وتديرها.
مشاكل الأمان
استخدام مكونات مفتوحة المصدر في مشاريع البرمجيات الكبيرة يقلل من تكاليف التطوير ، ويقصر وقت التطوير الشامل ، وقد قيل إنه يعزز الابتكار. نظرًا لأنه يحرر موظفي التطوير لديك من الأمور العادية ، فإنه يسمح لهم بالتركيز على الجوانب الفريدة والجذابة للسوق لمنتجك.
هناك بعض المنتجات مفتوحة المصدر التي وراءها كيان تجاري. تصدر المنظمة منتجاتها بموجب نظام ترخيص مزدوج. سيكون للنسخة التجارية قناة دعم رسمية ومهنية وقد تحتوي على مزايا أخرى مثل إضافات الملكية المضمنة مع المنتج. يقومون أيضًا بإصدار نسخة مدعومة من المجتمع ستستفيد من جهود الترميز التي يبذلها الفريق التجاري وكذلك من المساهمات من مجتمعه الخاص. ستعود مساهمات المجتمع الكبيرة أيضًا إلى النسخة التجارية.
ومع ذلك ، فإن غالبية المشاريع مفتوحة المصدر يقودها المجتمع بالكامل. قد يكون لديهم دعم من الكيانات التجارية ، لكن هذا الدعم هو تبرعات ورعاية ، وليس مساهمات برمجية.
بغض النظر عن مصدرها ، تميل المكونات مفتوحة المصدر التي تم اختيارها لتضمينها في مشاريع التطوير الجديدة إلى أن تكون مشاريع راسخة وذات سمعة طيبة في حد ذاتها. لقد حصلوا على درجة عالية من الثقة. لكن هذا ليس هو الحال دائمًا. في بعض الأحيان تكون الوظيفة التي تحتاجها متاحة ، ولكنها موجودة في مشروع جديد وغير مثبت إلى حد ما. لكن لديك شفرة المصدر ، أليس كذلك؟ يمكنك القيام بمراجعة التعليمات البرمجية له.
من وجهة نظر أمنية ، المصدر المفتوح ليس أكثر أو أقل أمانًا من الكود المحلي. إنها كلها تعليمات برمجية كتبها الإنسان بعد كل شيء. يشير المدافعون عن المصادر المفتوحة إلى قانون إريك س. ريموند الذي سماه تكريماً لـ Linus Torvalds ، والذي ينص على أنه "إذا أعطيت ما يكفي من مقل العيون ، فإن كل الأخطاء تكون ضحلة."مع قيام عدد كافٍ من الأشخاص بمراجعة الكود واختباره التجريبي ، يجب تحديد المشكلات وتمييزها وإصلاحها بسرعة.
هذا صحيح بقدر ما يذهب. لكن القضايا الأمنية ليست بالضرورة أخطاء. يمكن أن تكون الثغرة عبارة عن ظرف ينشأ كأثر جانبي لمنطق معقد في مشروع يضم العديد من وحدات الكود المصدري التي تصل إلى ملايين أسطر التعليمات البرمجية. المنتج يفعل ما يفترض به ، ولذا يُنظر إليه على أنه يعمل على النحو المنشود. وهكذا فإنه يجتاز مراجعة الكود ، والتحقق من المنتج ، والاختبار الميداني ، ويحصل على فاتورة صحية نظيفة.
بعيدًا عن الحظ الأعمى والمصادفة ، لن تكشف حلقة المراجعة والاختبار والمحاكمة والإفراج عن الثغرات الأمنية.
لماذا المصدر المفتوح جذاب للقراصنة
علاوة على ذلك ، هناك جوانب مفتوحة المصدر جذابة بشكل إيجابي للقراصنة والجهات الفاعلة في التهديد. يمكنهم رؤية شفرة المصدر أيضًا. يمكنهم البحث عن نقاط الضعف بعقلية مختلفة عن المساهمين المجتمعيين العاديين الذين ، على الرغم من أنهم قد يكونون مطورًا كفؤًا ، من غير المحتمل أن يكون لديهم أي خلفية أمنية حقيقية.
بالطبع ، يأتي المساهمون في المصادر المفتوحة بجميع النكهات بخلفيات متنوعة. سيكون لدى بعضهم بلا شك خبرة أمنية في العالم الحقيقي - لكنهم سيكونون أقلية. الفاعلون المهددون هم وحش آخر تمامًا. وهم لا يقتصرون على البحث عن الثغرات الأمنية ، يمكنهم حقنها أيضًا.
كانت هناك العديد من الحالات التي قام فيها أحد الفاعلين بالتهديد بإدخال ثغرة أمنية عبر التصحيح الذي قاموا بإنشائه وإرساله إلى المشروع. لقد شق طريقه من خلال مراجعة الكود ، إلى قاعدة الكود ، وفي الإصدار التالي من المنتج.
ربما كان المثال النهائي لهذا مكون JavaScript يسمى حدث تيار. تمت صيانة هذا المشروع مفتوح المصدر من قبل مطور واحد. كان عبء الإشراف على المشروع أكبر منه. تم إقناعه بتسليمها إلى مشرف جديد.
كان المشرف الجديد يمثل تهديدًا. لقد تولوا إدارة المشروع وتشغيله كالمعتاد لفترة قصيرة ، ثم أضافوا إليه تعليمات برمجية ضارة.كانت كل نسخة من كل برنامج آخر يستخدم هذا البرنامج تختطف بهدوء أنواعًا معينة من محفظة Bitcoin لممثل التهديد.
ما يمكنك فعله لتقليل المخاطر
كما هو الحال مع العديد من جوانب الأمان ، يمكنك إدارة هذه المخاطر من خلال تطبيق الضوابط. وهذا يتطلب حوكمة - بعبارة أخرى ، سياسات وإجراءات. لحسن الحظ ، هناك برنامج يمكنه المساعدة.
إنشاء سجل مفتوح المصدر
تحتاج إلى تحديد المصدر المفتوح الذي تستخدمه. قم بإنشاء سجل يسرد المكونات مفتوحة المصدر التي تستخدمها في مشاريعك. أدرج كل مكون مفتوح المصدر ، والإصدار أو الإصدارات التي استخدمتها ، والمشاريع التي استخدمتها فيها ، وما هو أحدث إصدار ، ومكان تنزيله. في وثائق التصميم لكل مشروع من مشاريعك ، يجب أن تسرد المكونات مفتوحة المصدر قيد الاستخدام.
الشيطان في التفاصيل. لا تنس التبعيات والطبيعة الهرمية للكثير من المصادر المفتوحة. غالبًا ما تستخدم المشاريع مفتوحة المصدر مشاريع أخرى داخل نفسها ، متداخلة مثل الدمى الروسية ، أو تتطلب مكونات أخرى مفتوحة المصدر ليتم تثبيتها على الجهاز المستهدف حتى يتمكنوا من الاستفادة منها.
تعمق في هذه التبعيات ، وقم بإدراجها في سجل المصدر المفتوح الخاص بك.
تشغيل عمليات التدقيق التلقائية
نقاط الضعف في الحزم مفتوحة المصدر هي مشكلة رئيسية لـ NPM ، مدير الحزم لـ JavaScript. لمعالجة هذا الأمر ، قاموا بإنشاء أداة تدقيق تلقائي ستقوم بالبحث عن الحزم القديمة مع تحديثات الأمان.
هذا ، بالطبع ، له حدوده ، ومن المهم أن تكون واعيًا ولا تعتمد بالكامل على الأدوات التلقائية. سوف يلتقط فقط الحزم ذات الثغرات الأمنية والتحديثات المعروفة. إذا كانت الحزمة بها ثغرة أمنية ، ولكن لم يتم تحديثها لإصلاحها ، فلن يخبرك تدقيق NPM بأي شيء.
إنشاء خريطة نقاط الضعف
يمنحك سجل المصدر المفتوح صورة واضحة للمصدر المفتوح الذي تستخدمه. الخطوة التالية هي تحديد نقاط الضعف المعروفة على هذا السجل. في بعض الأحيان ، يمكن اكتشافها من خلال زيارة الصفحة الرئيسية للمشروع والنظر في قائمة المشكلات المعروفة.
ستمنحك قاعدة البيانات الوطنية للثغرات الأمنية (NVD) صورة أكثر دقة. يمكنك استخدام صفحة البحث الخاصة بهم للبحث عن المنتجات بالاسم لمعرفة نقاط الضعف والتعرض الشائعة التي تؤثر على مكون البرنامج هذا. يعد NVD مصدرًا رائعًا ، حتى لو كان تنسيقه يستغرق بعض الشيء حتى تعتاد عليه.
تحديث السجل الخاص بك وخريطة الضعف
بالطبع ، هذا شيء تحتاج إلى الاحتفاظ به في المقدمة. يتم اكتشاف ثغرات جديدة طوال الوقت ، لذلك من المرجح أن تتآكل ببطء حالة أمان منتجك عند الإطلاق مع مرور الوقت.
إدراكًا لهذه الحاجة الجديدة ، هناك تطبيقات تجارية (Black Duck و WhiteSource) ستساعد في ذلك. يمكنهم فحص مشاريعك وتحديد التعليمات البرمجية مفتوحة المصدر والبحث عن الثغرات الأمنية تلقائيًا. تقدم بعض هذه (FOSSA) فئة مجانية.
يجب أن يكون التحليل الثابت لقاعدة التعليمات البرمجية الخاصة بك - بما في ذلك المكونات مفتوحة المصدر - جزءًا قياسيًا من دقة التطوير الخاصة بك ، على أي حال. يمكن لأدوات مثل Coverity Scan العثور على عيوب في التعليمات البرمجية الخاصة بك مثل فيضان المخزن المؤقت الذي يمكن أن يؤدي إلى نقاط الضعف. حتى أنه سيقدم المشورة بشأن كيفية تصحيحها.
تحقق من تراخيص المصدر المفتوح والتزم بها
تأكد من فهمك للتراخيص السارية على المصدر المفتوح الذي تستخدمه. هناك العديد من التراخيص المختلفة ، لذا تحقق من التزامك بجميع المتطلبات. قم بإشراك مسؤول الترخيص أو الامتثال ، إذا كان لديك واحد.
عدم الامتثال لترخيص مفتوح المصدر يمكن أن يؤدي إلى التقاضي. المشاريع مفتوحة المصدر سريعة في الاستجابة لخروقات الترخيص مثل بيوت البرمجيات التجارية.
تحديث مكوناتك مفتوحة المصدر
نظرًا لأن مجتمعات المصدر المفتوح الذي تستخدمه يتم إصلاح الثغرات الأمنية ، تأكد من ترقية إصداراتك حتى تستفيد من تلك الإصلاحات.المصدر المفتوح يستخدم نموذج "سحب". لقد أعلنوا عن إصلاح جديد ثم يتعين عليك الانتقال وتنزيل هذا الإصدار الجديد. هذا هو عكس الكثير من البرامج التجارية التي لديها نموذج "دفع" حيث يتم إرسال التحديثات إلى المستخدمين المسجلين.
راقب صفحات المشروع لإعلانات الإصدار الجديد ، وقم بتنزيل واختبار البنيات الجديدة.
تكلفة المصدر المفتوح
البرمجيات مفتوحة المصدر مجانية الحصول عليها ، لكنها تأتي مصحوبة بنفقات إدارية وحوكمة. يجب فهم الآثار المترتبة على ذلك والتحكم فيها من أجل استخدامها بأمان وبأقل قدر من المخاطر.
