أمان البرمجيات

تتطلب جميع معايير سلامة البرمجيات تقريبًا توثيقًا شاملًا لعملية التطوير والضمان بأكملها. عادةً ما تتم مراجعة هذا التوثيق واعتماده من قبل جهات خارجية، وبالتالي فهو شرط أساسي للموافقة على البرمجيات المتعلقة بالسلامة. يشمل التوثيق وثائق تخطيط متنوعة، ومواصفات المتطلبات، ووثائق بنية البرمجيات وتصميمها، وحالات اختبار على مستويات تجريد مختلفة، وتقارير تأهيل الأدوات، وأدلة المراجعة، ونتائج التحقق والتدقيق، وما إلى ذلك. يوضح الشكل C.2 في معيار EN 50716 ^{[ 3 ]} 32 وثيقة يجب إنشاؤها خلال دورة حياة التطوير.

تُعرف إمكانية التتبع بأنها ممارسة تهدف إلى إقامة علاقات بين أنواع مختلفة من المتطلبات، وبين المتطلبات ومخرجات التصميم والتنفيذ والاختبار. ووفقًا للمعيار الأوروبي EN 50716 ^{[ 3 ]} ، فإن الهدف هو "ضمان إمكانية إثبات استيفاء جميع المتطلبات على النحو الأمثل، وعدم إدخال أي مواد غير قابلة للتتبع". ومن خلال توثيق إمكانية التتبع والحفاظ عليها، يصبح من الممكن تتبع متطلبات السلامة، على سبيل المثال، في تصميم النظام (للتحقق من مدى مراعاتها بشكل كافٍ)، ثم في شفرة المصدر البرمجية (للتحقق من مدى استيفاء الشفرة للمتطلبات)، وصولًا إلى حالة الاختبار المناسبة وتنفيذ الاختبار (للتحقق من مدى كفاية اختبار متطلبات السلامة).

قد تتضمن معايير السلامة متطلبات تؤثر بشكل مباشر على تنفيذ البرمجيات في شفرة المصدر، مثل اختيار لغة برمجة مناسبة، وحجم الدوال وتعقيدها، واستخدام بنيات برمجية معينة، والحاجة إلى معايير ترميز. يحتوي الجزء 3 من معيار IEC 61508 على المتطلبات والتوصيات التالية:

• يُفضّل استخدام لغة برمجة ذات كتابة قوية. بعض اللغات أنسب من غيرها لأنظمة السلامة. فاللغات التي تدعم الكتابة القوية قادرة على اكتشاف المزيد من الأخطاء أثناء عملية الترجمة، والتي لا تُكتشف عادةً إلا أثناء التشغيل. لذلك، يُنصح عادةً بتجنب استخدام لغة التجميع، بينما يُوصى باستخدام لغات عالية المستوى مُصممة خصيصًا لسوق السلامة (مثل لغة ADA ).
• استخدام معيار ترميز مناسب يحدد مجموعة فرعية من اللغة "الآمنة"، على سبيل المثال MISRA C. MISRA-C هو معيار ترميز للغة البرمجة C يهدف إلى تحسين جودة الكود وسلامته من خلال منع البنى المعرضة للأخطاء، أو الميزات التي تعتمد على المترجم (والتي يكون سلوكها بالتالي غير محدد).
• الحد من استخدام الاستدعاء الذاتي والمؤشرات والمقاطعات (لأنها عرضة للأخطاء).
• منع "تدفق التحكم غير المنظم في البرامج"، أي تجنب القفز بطريقة غير منظمة، على سبيل المثال باستخدام عبارات مثل " goto ".

يجب إثبات التغطية الاختبارية المناسبة، أي أنه بناءً على مستوى الأمان، يجب تطبيق مخططات اختبار أكثر صرامة. ويُذكر أحد المتطلبات المعروفة المتعلقة بالتغطية الاختبارية، والتي تعتمد على مستوى البرنامج، في معيار DO-178C: ^{[ 4 ]}

• المستوى ج: تغطية العبارات مطلوبة - أي "تم استدعاء كل عبارة في البرنامج مرة واحدة على الأقل" أثناء الاختبار.
• المستوى ب: تغطية الفروع مطلوبة - أي "تم استدعاء كل نقطة دخول وخروج في البرنامج مرة واحدة على الأقل، وتم اتخاذ كل قرار في البرنامج بشأن جميع النتائج المحتملة مرة واحدة على الأقل".
• المستوى أ: تغطية الشرط/القرار المعدلة - امتداد لتغطية الفرع، مع اشتراط أن "كل شرط في القرار قد ثبت أنه يؤثر بشكل مستقل على نتيجة ذلك القرار".

تتطلب معايير سلامة البرمجيات عادةً تنفيذ بعض الأنشطة باستقلالية، أي من قِبل شخص مختلف، أو شخص يتبع لتسلسل إداري مختلف، أو حتى من قِبل منظمة مستقلة. يضمن هذا تجنب تضارب المصالح ويزيد من فرص اكتشاف الأخطاء (مثل تلك الموجودة في تصميم البرمجيات). على سبيل المثال، يشترط معيار EN 50716 ^{[ 3 ]،} الشكل 2، أن يشغل أدوار "المنفذ" و"المختبِر" و"المُدقِّق" أشخاص مختلفون، وأن يشغل دور "المُدقِّق" شخص يتبع لتسلسل إداري مختلف، وأن يشغل دور "المُقيِّم" شخص من وحدة تنظيمية مختلفة. كما يشترط معيارا DO-178C ^{[ 4 ]} وDO-278A ^{[ 5 ]} تنفيذ العديد من الأنشطة (مثل التحقق من تغطية الاختبار، وأنشطة ضمان الجودة) "باستقلالية"، حيث تُعرَّف الاستقلالية بأنها "فصل المسؤوليات بما يضمن تحقيق تقييم موضوعي".

في هندسة سلامة الأنظمة، من الشائع تحديد حدود عليا لمعدلات فشل الأنظمة الفرعية أو المكونات. ويجب بعد ذلك إثبات أن هذه الأنظمة الفرعية أو المكونات لا تتجاوز معدلات الفشل المحددة لها، وإلا يجب استخدام آليات التكرار أو غيرها من آليات تحمل الأعطال. هذا النهج غير عملي بالنسبة للبرمجيات، إذ لا يمكن التنبؤ بمعدلات فشل البرمجيات بدقة. على الرغم من إجراء بحوثٍ هامة في مجال موثوقية البرمجيات (انظر على سبيل المثال Lyu (1996)، ^{[ 12 ])،} فإن معايير سلامة البرمجيات الحالية لا تشترط استخدام أيٍّ من هذه الأساليب، بل إنها تثني عن استخدامها، كما في DO178C ^{[ 4 ]} (ص 73) الذي ينص على ما يلي: "نُشرت العديد من الأساليب للتنبؤ بموثوقية البرمجيات بناءً على مقاييس التطوير، مثل بنية البرمجيات، ومعدل اكتشاف العيوب، وما إلى ذلك. لا تُقدّم هذه الوثيقة إرشاداتٍ بشأن هذه الأنواع من الأساليب، لأنه في وقت كتابة هذه الوثيقة، لم تُقدّم الأساليب المتاحة حاليًا نتائج يُمكن الوثوق بها." وينصّ البند 4.1.2 من ARP 4761 ^{[ 13 ]} على أن أخطاء تصميم البرمجيات "ليست هي نفسها أعطال الأجهزة. فعلى عكس أعطال الأجهزة، لا يُمكن تحديد احتمالات حدوث هذه الأخطاء كميًا."

قد تتعارض مصالح سلامة البرمجيات وأمنها في بعض الحالات. فمن جهة، قد تشكل البرمجيات غير الآمنة والمتعلقة بالسلامة خطراً أمنياً، ومن جهة أخرى، تتعارض بعض ممارسات الأمان (مثل التحديثات المتكررة وفي الوقت المناسب) مع ممارسات الأمان المعتمدة (الاختبار والتحقق الدقيقين قبل إجراء أي تغيير في النظام التشغيلي).

تتبع البرامج التي تستخدم تقنيات الذكاء الاصطناعي ، مثل التعلم الآلي، دورة حياة مختلفة جذريًا. إضافةً إلى ذلك، يصعب التنبؤ بسلوكها مقارنةً بالأنظمة المطورة بالطرق التقليدية. لذا، فإن مسألة إمكانية استخدام هذه التقنيات وكيفية استخدامها قيد البحث حاليًا. في الوقت الراهن، لا تُوصي المعايير عمومًا باستخدامها. على سبيل المثال، ينص معيار EN 50716 (الجدول أ.3) على عدم التوصية باستخدام الذكاء الاصطناعي والتعلم الآلي لأي مستوى من مستويات سلامة الأنظمة.

لا يزال يُنظر إلى تطوير البرمجيات الرشيقة ، الذي يتميز عادةً بالعديد من التكرارات، على أنه فوضوي للغاية بالنسبة لتطوير البرمجيات المتعلقة بالسلامة. وقد يعود ذلك جزئيًا إلى عبارات مثل "البرمجيات العاملة أهم من التوثيق الشامل"، الواردة في بيان تطوير البرمجيات الرشيقة. ^{[ 14 ]} على الرغم من أن معظم معايير سلامة البرمجيات تُقدم دورة حياة البرمجيات بتسلسل تقليدي يشبه نموذج الشلال ، إلا أن بعضها يتضمن عبارات تسمح بدورات حياة أكثر مرونة. ينص معيار DO-178C على أن "عمليات دورة حياة البرمجيات قد تكون تكرارية، أي يتم الدخول إليها وإعادة الدخول إليها". ويتضمن معيار EN 50716 الملحق (ج) الذي يُبين كيفية استخدام دورات حياة التطوير التكرارية بما يتماشى مع متطلبات المعيار.