الرئيسيةعريقبحث

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

☰ جدول المحتويات

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

عملية تطوير البرمجيات
نشاطات وخطوات
المتطلبات · مواصفة وظيفية
البنيان · تصميم البرمجيات
التنفيذ · الفحص
نشر البرمجيات · صيانة البرمجيات
منهجيات
أجيل · هندسة برمجيات الغرفة النظيفة · Iterative
RAD · RUP · Spiral
Waterfall · XP · Lean
سكرم · V-Model · TDD
اختصاصات داعمة
إدارة تكوين البرمجيات
توثيق البرمجيات
ضمان الجودة
Project management
تصميم تجربة المستخدم
أدوات
المصرف · المصحح · Profiler
GUI designer · ب ت م

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

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

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

يمكن وصف المقاييس البرمجية والهندسة العكسية كأشكال من التحليل الساكن. يتزايد نشر المقاييس البرمجية المشتقة والتحليل الساكن معًا، خاصةً في إنشاء أنظمة مضمنة، من خلال تعريف ما يسمى أهداف جودة البرمجيات.[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. (Mar 1995). "Industrial Perspective on Static Analysis" ( كتاب إلكتروني PDF ). Software Engineering Journal: 69–75. مؤرشف من الأصل ( كتاب إلكتروني PDF ) في 27 سبتمبر 2011.
  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 (2010-09-08). "Infusion Pump Software Safety Research at FDA". Food and Drug Administration. مؤرشف من الأصل في 01 سبتمبر 201009 سبتمبر 2010.
  5. Computer based safety systems - technical guidance for assessing software aspects of digital computer based protection systems, "Computer based safety systems" ( كتاب إلكتروني PDF ). مؤرشف من الأصل ( كتاب إلكتروني PDF ) في January 4, 201315 مايو 2013.
  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 (2012-02-01). "Automated Defect Prevention for Embedded Software Quality". VDC Research. مؤرشف من الأصل في 11 أبريل 201210 أبريل 2012.
  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
  9. M. Howard and S. Lipner. The Security Development Lifecycle: SDL: A Process for Developing Demonstrably More Secure Software. Microsoft Press, 2006. (ردمك )
  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 ) من الأصل في 21 أكتوبر 201420 مايو 2015.
  11. "Archived copy" ( كتاب إلكتروني PDF ). مؤرشف ( كتاب إلكتروني PDF ) من الأصل في 28 ديسمبر 201318 أكتوبر 2013.
  12. Bartel, Alexandre; Klein, Jacques; Monperrus, Martin; Le Traon, Yves (1 June 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:. doi:10.1109/tse.2014.2322867. مؤرشف من الأصل في 17 مايو 2020.
  13. Vijay D’Silva; et al. (2008). "A Survey of Automated Techniques for Formal Software Verification" ( كتاب إلكتروني PDF ). Transactions On CAD. مؤرشف ( كتاب إلكتروني PDF ) من الأصل في 04 مارس 201611 مايو 2015.
  14. Jones, Paul (2010-02-09). "A Formal Methods-based verification approach to medical device software analysis". Embedded Systems Design. مؤرشف من الأصل في 10 يوليو 201109 سبتمبر 2010.
  15. "Learning from other's mistakes: Data-driven code analysis". www.slideshare.net (باللغة الإنجليزية). مؤرشف من الأصل في 15 يناير 2017.
  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.  .
  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:. doi:10.1145/2430536.2430541. مؤرشف من الأصل في 26 أبريل 2019.

موسوعات ذات صلة :