تحليل البرنامج الساكن

جزء من سلسلة مقالات حول
عملية تطوير البرمجيات
نشاطات رئيسة
نماذج العمل
منهجيات التطوير وأُطُره
اختصاصات داعمة
تطبيقات بالممارسة
أدوات
منظَّمات ومعايير
شعار بوابة بوابة برمجيات

تحليل البرامج الساكن (بالإنجليزية: Static program analysis)‏ هو تحليل لبرمجيات الحاسوب يُجرى دون تنفيذ البرامج فعليًا، على عكس التحليل الديناميكي، الذي يُجرى على البرامج أثناء تنفيذها. يُجرى التحليل في معظم الحالات على بعض إصدارات الكود المصدري، أو على بعض أشكال الكود الهدف في حالات أخرى.[1]

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

السبب المنطقي لاستخدامه

[عدل]

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

يمكن وصف المقاييس البرمجية والهندسة العكسية كأشكال من التحليل الساكن. يتزايد نشر المقاييس البرمجية المشتقة والتحليل الساكن معًا، خاصةً في إنشاء أنظمة مضمنة، من خلال تعريف ما يسمى أهداف جودة البرمجيات.[2]

هناك استخدام تجاري متزايد للتحليل الساكن في التحقق من خصائص البرمجيات المستخدمة في الأنظمة الحاسوبية الحساسة للسلامة وتحديد موقع الكود الضعيف المحتمل. مثلًا، حددت الصناعات التالية استخدام تحليل الكود الساكن كوسيلة لتحسين نوعية البرمجيات المعقدة والمتطورة بصورة متزايدة:[3]

  1. البرمجيات الطبية: حددت إدارة الغذاء والدواء الأمريكية (إف دي إيه) استخدام التحليل الساكن للأجهزة الطبية.[4]
  2. البرمجيات النووية: يوصي مكتب التنظيم النووي في المملكة المتحدة باستخدام التحليل الساكن لأنظمة حماية المفاعل.[5]
  3. برمجيات الطيران (إلى جانب التحليل الديناميكي).[6]

أشارت دراسة أجرتها شركة فيّ دي سي ريسيرش عام 2012 إلى أن 28.7% من مهندسي البرمجيات المضمنة المشمولين بالاستقصاء يستخدمون حاليًا أدوات التحليل الساكن ومن المتوقع أن يستخدمه 39.7% في غضون عامين. وجدت دراسة من عام 2010 أن 60% من المطورين الذين جرت مقابلتهم في مشاريع بحثية أوروبية استفادوا على الأقل من برامج التحليل الساكن المدمجة في بيئة التطوير المتكامل الخاصة بهم. واستخدم نحو 10% فقط أداة تحليل أخرى (ربما أكثر تطوراً).[7][8]

يستخدم في مجال صناعة أمن التطبيقات أيضًا ما يسمى اختبار أمن التطبيقات الساكن (إس إيه إس تي). يعتبر اختبار أمن التطبيقات الساكن جزءًا مهمًا من دورة حياة تطوير الأمن (إس دي إل) مثل دورة حياة تطوير الأمن من مايكروسوفت، وهو ممارسة شائعة في شركات البرمجيات.[9][10]

أنواع الأدوات

[عدل]

نشرت مجموعة إدارة الهدف (أو إم جي) دراسة تتعلق بأنواع تحليل البرمجيات المطلوب لقياس جودة البرمجيات وتقييمها. يصف هذا المستند عن «كيفية تسليم أنظمة تكنولوجيا معلومات المرنة والآمنة والفعالة وسهلة التغيير وفقًا لتوصيات اتحاد جودة برمجيات تكنولوجيا المعلومات (سي إس آي كيو)» ثلاثة مستويات من تحليل البرمجيات.[11]

مستوى الوحدة

[عدل]

التحليل الذي يتم داخل برنامج أو روتين فرعي معين، دون الاتصال بسياق ذلك البرنامج.

المستوى التقني

[عدل]

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

مستوى النظام

[عدل]

التحليل الذي يراعي التفاعلات بين برامج الوحدة، لكن دون تقيد بتقنية أو لغة برمجة واحدة محددة.

يمكن تعريف مستوى آخر من تحليل البرمجيات.

مستوى المهمة/العمل

[عدل]

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

الأساليب الشكلية

[عدل]

الأساليب الشكلية هي المصطلح المطبق على تحليل البرمجيات (والعتاد الحاسوبي) الذي تُستخدم أساليب رياضية دقيقة حصرًا للحصول على نتائجه. تشمل التقنيات الرياضية المستخدمة دلالات ترميزية، ودلالات بديهية، ودلالات تشغيلية والتفسير المجرد.

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

تتضمن بعض تقنيات تنفيذ التحليل الساكن الشكلي ما يلي:[13]

  • التفسير المجرد، لنمذجة تأثير كل تعليمة على حالة الآلة المجردة (أي «يُنفذ» البرمجيات بناءً على الخصائص الرياضية لكل تعليمة وتصريح). تقارب هذه الآلة المجردة سلوكيات النظام بشكل مفرط: وبالتالي يصبح نظام المجرد أسهل في التحليل، على حساب عدم الاكتمال (ليس كل خاصية حقيقية في النظام الأصلي حقيقة في النظام المجرد). ولكن إذا أُجري التفسير المجرد على النحو الصحيح يكون سليمًا (يمكن تعيين كل خاصية حقيقية للنظام التجريدي إلى خاصية حقيقية للنظام الأصلي). يعتمد ملحق تحليل قيمة إطار التحليل المعياري لبرامج سي (فريما سي). وأداة التحليل بوليسبيس بشدة على التفسير المجرد.[14]
  • تحليل تدفق البيانات، تقنية تعتمد على الشبكية لجمع المعلومات عن مجموعة القيم المحتملة؛
  • منطق هور، نظام شكلي مع مجموعة من القواعد المنطقية للتفكير بدقة حول صحة برامج الحاسوب. يوجد أداة دعم لبعض الغات البرمجة (مثل لغة البرمجة سبارك (مجموعة فرعية من لغة البرمجة أيدا) ولغة جافا للنمذجة -جاي إم إل- باستخدام المدقق الساكن الموسع للجافا  (إي إس سي/ جافا) والمدقق الساكن الموسع لجافا 2 ومحلق إطارالتحليل المعياري لبرامج سي ذات الشرط المسبق الأضعف (دبليو بّي) للغة سي الموسعة بلغة المحاكاة المستمرة المتقدمة إيه سي إس إل (لغة مواصفات سي حسب المعهد الوطني الأمريكي للمعايير/آيزو).
  • التحقق من النموذج، يراعي الأنظمة ذات الحالات المنتهية أو يمكن اختزالها إلى حالة منتهية عن طريق التجريد؛
  • التنفيذ الرمزي، مستخدم أيضًا لاشتقاق العبارات الرياضية التي تمثل قيمة المتغيرات المتحولة عند نقاط معينة في الكود.

تحليل ساكن مُساق بالبيانات

[عدل]

يستخدم التحليل الساكن المساق بالبيانات كميات كبيرة من التعليمات البرمجية لاستنتاج قواعد الترميز. مثلًا، يمكن استخدام جميع حزم جافا مفتوحة المصدر في موقع غيت هاب لتعلم إستراتيجية تحليل جيدة. يمكن لقاعدة الاستدلال أن تستخدم تقنيات التعلم الآلي. فمثلُا، تبين أنه عندما ينحرف كثيرًا عن طريقة استخدام واجهة برمجة التطبيقات كائنية التوجه، فمن المحتمل أن يكون هذا خطأ برمجي. من الممكن أيضًا التعلم من الإصلاحات والتحذيرات السابقة الكثيرة.[15][16][17]

انظر أيضًا

[عدل]

مراجع

[عدل]
  1. ^ Wichmann، B. A.؛ Canning، A. A.؛ Clutterbuck، D. L.؛ Winsbarrow، L. A.؛ Ward، N. J.؛ Marsh، D. W. R. (مارس 1995). "Industrial Perspective on Static Analysis" (PDF). Software Engineering Journal: 69–75. مؤرشف من الأصل (PDF) في 2011-09-27.
  2. ^ "Software Quality Objectives for Source Code" نسخة محفوظة 2015-06-04 على موقع واي باك مشين. (PDF). Proceedings: Embedded Real Time Software and Systems 2010 Conference, ERTS2010.org, Toulouse, France: Patrick Briand, Martin Brochet, Thierry Cambois, Emmanuel Coutenceau, Olivier Guetta, Daniel Mainberte, Frederic Mondot, Patrick Munier, Loic Noury, Philippe Spozio, Frederic Retailleau.
  3. ^ Improving Software Security with Precise Static and Runtime Analysis نسخة محفوظة 2011-06-05 على موقع واي باك مشين. (PDF), Benjamin Livshits, section 7.3 "Static Techniques for Security". Stanford doctoral thesis, 2006.
  4. ^ FDA (8 سبتمبر 2010). "Infusion Pump Software Safety Research at FDA". Food and Drug Administration. مؤرشف من الأصل في 2010-09-01. اطلع عليه بتاريخ 2010-09-09.
  5. ^ Computer based safety systems - technical guidance for assessing software aspects of digital computer based protection systems, "Computer based safety systems" (PDF). مؤرشف من الأصل (PDF) في 2013-01-04. اطلع عليه بتاريخ 2013-05-15.
  6. ^ Position Paper CAST-9. Considerations for Evaluating Safety Engineering Approaches to Software Assurance نسخة محفوظة 2013-10-06 على موقع واي باك مشين. // FAA, Certification Authorities Software Team (CAST), January, 2002: "Verification. A combination of both static and dynamic analyses should be specified by the applicant/developer and applied to the software."
  7. ^ VDC Research (1 فبراير 2012). "Automated Defect Prevention for Embedded Software Quality". VDC Research. مؤرشف من الأصل في 2012-04-11. اطلع عليه بتاريخ 2012-04-10.
  8. ^ Prause, Christian R., René Reiners, and Silviya Dencheva. "Empirical study of tool support in highly distributed research projects." Global Software Engineering (ICGSE), 2010 5th IEEE International Conference on. IEEE, 2010 http://ieeexplore.ieee.org/ielx5/5581168/5581493/05581551.pdf نسخة محفوظة 2020-10-07 على موقع واي باك مشين.
  9. ^ M. Howard and S. Lipner. The Security Development Lifecycle: SDL: A Process for Developing Demonstrably More Secure Software. Microsoft Press, 2006. (ردمك 978-0735622142)
  10. ^ Achim D. Brucker and Uwe Sodan. Deploying Static Application Security Testing on a Large Scale نسخة محفوظة 2014-10-21 على موقع واي باك مشين.. In GI Sicherheit 2014. Lecture Notes in Informatics, 228, pages 91-101, GI, 2014. "Archived copy" (PDF). مؤرشف (PDF) من الأصل في 2014-10-21. اطلع عليه بتاريخ 2015-05-20.{{استشهاد ويب}}: صيانة الاستشهاد: الأرشيف كعنوان (link)
  11. ^ "Archived copy". مؤرشف (PDF) من الأصل في 2013-12-28. اطلع عليه بتاريخ 2013-10-18.{{استشهاد ويب}}: صيانة الاستشهاد: الأرشيف كعنوان (link)
  12. ^ Bartel، Alexandre؛ Klein، Jacques؛ Monperrus، Martin؛ Le Traon، Yves (1 يونيو 2014). "Static Analysis for Extracting Permission Checks of a Large Scale Framework: The Challenges and Solutions for Analyzing Android". IEEE Transactions on Software Engineering. ج. 40 ع. 6: 617–632. arXiv:1408.3976. DOI:10.1109/tse.2014.2322867. مؤرشف من الأصل في 2020-05-17.
  13. ^ Vijay D’Silva؛ وآخرون (2008). "A Survey of Automated Techniques for Formal Software Verification" (PDF). Transactions On CAD. مؤرشف من الأصل (PDF) في 2016-03-04. اطلع عليه بتاريخ 2015-05-11.
  14. ^ Jones، Paul (9 فبراير 2010). "A Formal Methods-based verification approach to medical device software analysis". Embedded Systems Design. مؤرشف من الأصل في 2011-07-10. اطلع عليه بتاريخ 2010-09-09. {{استشهاد ويب}}: |archive-date= / |archive-url= timestamp mismatch (مساعدة)
  15. ^ "Learning from other's mistakes: Data-driven code analysis". www.slideshare.net (بالإنجليزية). Archived from the original on 2017-01-15.
  16. ^ Oh، Hakjoo؛ Yang، Hongseok؛ Yi، Kwangkeun (2015). "Learning a strategy for adapting a program analysis via bayesian optimisation". Proceedings of the 2015 ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications - OOPSLA 2015. ص. 572–588. DOI:10.1145/2814270.2814309. ISBN:9781450336895.
  17. ^ Monperrus، Martin؛ Mezini، Mira (2013). "Detecting missing method calls as violations of the majority rule". ACM Transactions on Software Engineering and Methodology. ج. 22 ع. 1: 1–25. arXiv:1306.0762. DOI:10.1145/2430536.2430541. مؤرشف من الأصل في 2019-04-26.