طريقة لفحص الكود الثابت. تحليل الكود القديم عند فقد الكود المصدري: أفعل أم لا؟ الجمع بين مهام سير العمل لأنواع مختلفة من التحليل في بيئة التطوير

مقدمة

القدرات القياسية لمنتجات البرمجيات وأنظمة التحكم المختلفة ليست كافية لمعظم العملاء. توفر أنظمة إدارة مواقع الويب (على سبيل المثال ، WordPress أو Joomla أو Bitrix) وبرامج المحاسبة وأنظمة إدارة العملاء (CRM) والمؤسسات والإنتاج (على سبيل المثال ، 1C و SAP) فرصًا كبيرة لتوسيع الوظائف والتكيف مع احتياجات عملاء محددين. يتم تنفيذ هذه الإمكانات باستخدام وحدات مخصصة من جهات خارجية أو تخصيص الوحدات الموجودة. هذه الوحدات عبارة عن كود برنامج مكتوب بإحدى لغات البرمجة المضمنة التي تتفاعل مع النظام وتنفذ الوظائف المطلوبة من قبل العملاء.

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

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

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

تتوفر محللات كود المصدر لمعالجة مسألة تدقيق كود المصدر والحماية من استغلال الثغرات الأمنية في التعليمات البرمجية المضمنة وتطبيقات الويب.

تصنيف محللي كود المصدر

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

• تتضمن المجموعة الأولى أدوات تحليل أكواد تطبيقات الويب وأدوات لمنع استغلال نقاط الضعف في مواقع الويب.
• تتكون المجموعة الثانية من محللات التعليمات البرمجية المضمنة التي يمكنها اكتشاف مناطق المشكلات في التعليمات البرمجية المصدر للوحدات النمطية المصممة لتوسيع وظائف أنظمة الشركة والإنتاج. تتضمن هذه الوحدات برامج لخط إنتاج 1C وإمتدادات لأنظمة CRM وأنظمة إدارة المؤسسات وأنظمة SAP.
• الغرض من المجموعة الأخيرة هو تحليل الكود المصدري في لغات البرمجة المختلفة ، ولا تتعلق بتطبيقات الأعمال وتطبيقات الويب. هذه المحللات مخصصة للعملاء ومطوري البرامج. تُستخدم هذه المجموعة من المحللين أيضًا لاستخدام منهجية التطوير الآمن لمنتجات البرامج. يجد محللو الكود الثابت المشكلات ونقاط الضعف المحتملة في أكواد المصدر ويقدمون توصيات للتخلص منها.

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

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

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

كيف يعمل محلل كود المصدر

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

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

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

الشكل 1. خوارزمية محلل كود المصدر

عند تقييم الكود المصدري ، يستخدم المحللون قواعد بيانات مختلفة تحتوي على أوصاف لنقاط الضعف وأخطاء البرمجة:

• قاعدة خاصة به من نقاط الضعف وأخطاء البرمجة - لكل مطور لمحللي كود المصدر أقسام تحليلات وأبحاث خاصة به ، والتي تعد قواعد متخصصة لتحليل أكواد مصدر البرنامج. جودة قاعدتنا الخاصة هي واحدة من المعايير الرئيسية التي تؤثر على الجودة الشاملة للمنتج. بالإضافة إلى ذلك ، يجب أن تكون قاعدة البيانات الخاصة بها ديناميكية ومحدثة باستمرار - تتطلب العوامل الجديدة للهجمات واستغلال الثغرات الأمنية ، بالإضافة إلى التغييرات في لغات البرمجة وأساليب التطوير ، مطوري المحلل لتحديث قاعدة البيانات باستمرار من أجل الحفاظ على جودة عالية مسح. غالبًا ما تفشل المنتجات ذات القاعدة الثابتة غير القابلة للترقية في الاختبارات المقارنة.
• قواعد الحالة الخاصة بأخطاء البرمجة - هناك عدد من قواعد الحالة الخاصة بنقاط الضعف ، والتي يشارك تجميعها وصيانتها في المنظمين في مختلف البلدان. على سبيل المثال ، في الولايات المتحدة ، يتم استخدام CWE - قاعدة تعداد نقاط الضعف الشائعة ، والتي تحتفظ بها منظمة MITER ، التي تدعمها ، من بين أمور أخرى ، وزارة الدفاع الأمريكية. ليس لدى روسيا قاعدة مماثلة حتى الآن ، لكن FSTEC لروسيا تخطط في المستقبل لتكملة قواعدها من نقاط الضعف والتهديدات بقاعدة لأخطاء البرمجة. يطبق محللو الثغرات دعمًا لقاعدة CWE ، ويدمجونها في قاعدة نقاط الضعف الخاصة بهم أو يستخدمونها كآلية تحقق منفصلة.
• متطلبات المعايير والتوصيات الخاصة بالبرمجة المحمية - هناك عدد من المعايير الحكومية والصناعية التي تصف متطلبات تطوير التطبيقات الآمنة ، بالإضافة إلى عدد من التوصيات و "أفضل الممارسات" من خبراء عالميين في مجال تطوير البرمجيات وحمايتها. لا تصف هذه المستندات أخطاء البرمجة بشكل مباشر ، على عكس CWE ، ولكنها تحتوي على قائمة بالطرق التي يمكن تحويلها للاستخدام في محلل كود المصدر الثابت.

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

سوق عالمي

هناك العديد من المحللين المختلفين في السوق العالمية - سواء من بائعي الأمان المعروفين أو اللاعبين المتخصصين الذين يتعاملون فقط مع هذه الفئة من المنتجات. ظل مركز Gartner التحليلي يصنف ويقيم محللي الكود المصدري لأكثر من خمس سنوات ، بينما حتى عام 2011 ، خصت Gartner المحللات الثابتة التي تمت مناقشتها في هذه المقالة بشكل منفصل ، ثم جمعتها لاحقًا في فئة أعلى - اختبار أمان التطبيق).

في تقرير Gartner Magic Quadrant لعام 2015 ، احتلت HP و Veracode و IBM مكانة رائدة في السوق في مجال تدقيق الأمان. في الوقت نفسه ، تعد Veracode الشركة الرائدة الوحيدة التي ليس لديها محلل كمنتج برمجي ، ويتم توفير الوظيفة فقط كخدمة في سحابة Veracode. تقدم بقية الشركات الرائدة إما منتجات حصرية تقوم بإجراء فحوصات على أجهزة كمبيوتر المستخدمين ، أو القدرة على الاختيار بين منتج وخدمة سحابية. ظلت HP و IBM في طليعة الأسواق العالمية على مدى السنوات الخمس الماضية ، ويرد أدناه نظرة عامة على منتجاتها. الأقرب إلى المناصب القيادية هو منتج Checkmarx ، الذي يتخصص فقط في هذه الفئة من المنتجات ، وبالتالي يتم تضمينه أيضًا في المراجعة.

الشكل 2. الربع السحري المحللجارتنر من قبل التطبيق لاعبي السوق لتحليل أمان التطبيقات في أغسطس 2015

وفقًا لتقرير صادر عن محللين من ReportsnReports ، بلغ سوق محلل كود المصدر الأمريكي 2.5 مليار دولار في عام 2014 ، ومن المتوقع أن يتضاعف إلى 5 مليارات دولار بحلول عام 2019 بنمو سنوي قدره 14.9٪. أكثر من 50٪ من المؤسسات التي شملها الاستطلاع أثناء إعداد خطة التقرير لتخصيص وزيادة الميزانيات لتحليل كود المصدر من أجل التطوير المخصص ، وتحدث 3٪ فقط بشكل سلبي عن استخدام هذه المنتجات.

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

السوق الروسي

يعتبر السوق الروسي لمحللي الكود المصدري حديث العهد - بدأت المنتجات العامة الأولى في الظهور في السوق منذ أقل من خمس سنوات. في الوقت نفسه ، تم تشكيل السوق من اتجاهين - من ناحية ، تقوم الشركات بتطوير منتجات للاختبار لتحديد الفرص غير المعلنة في مختبرات FSTEC و FSB ووزارة الدفاع في الاتحاد الروسي ؛ من ناحية أخرى ، قررت الشركات في مجالات الأمان المختلفة إضافة فئة جديدة من المنتجات إلى محفظتها.

أبرز اللاعبين في السوق الجديدة هم التقنيات الإيجابية و InfoWatch و Solar Security. تخصصت شركة Positive Technologies في البحث عن نقاط الضعف وتحليلها لفترة طويلة ؛ تتضمن محفظتهم منتج MaxPatrol - أحد الشركات الرائدة في السوق المحلية في التحكم الأمني ​​الخارجي ، لذلك ليس من المستغرب أن تقرر الشركة إجراء تحليل داخلي وتطوير محلل كود المصدر الخاص بها. تطورت InfoWatch كمطور لأنظمة DLP ، وأصبحت في النهاية مجموعة من الشركات التي تبحث عن مجالات سوق جديدة. في عام 2012 ، انضم Appercut إلى InfoWatch ، مضيفًا محلل التعليمات البرمجية المصدر إلى محفظة InfoWatch. سمحت استثمارات InfoWatch وخبرتها بتطوير المنتج بسرعة إلى مستوى عالٍ. قدمت شركة Solar Security رسميًا منتجها Solar inCode فقط في نهاية أكتوبر 2015 ، ولكن في وقت صدوره كان هناك أربعة تطبيقات رسمية في روسيا.

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

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

نظرة عامة على المحللين

أول أداة لتحليل كود المصدر في مراجعتنا هي منتج من Fortify ، مملوك لشركة Hewlett-Packard منذ عام 2010. يتضمن خط HP Fortify العديد من المنتجات لتحليل أكواد البرنامج: هناك أيضًا خدمة Fortify On-Demand SaaS ، والتي تتضمن تحميل كود المصدر إلى HP cloud ، وتطبيق HP Fortify Static Code Analyzer الكامل المثبت على البنية التحتية للعميل.

يدعم HP Fortify Static Code Analyzer مجموعة متنوعة من لغات البرمجة والأنظمة الأساسية ، بما في ذلك تطبيقات الويب المكتوبة بلغة PHP و Python و Java / JSP و ASP.Net و JavaScript ، والتعليمات البرمجية المضمنة في ABAP (SAP) و Action Script و VBScript.

الشكل 3. واجهة محلل الكود الثابت HP Fortify

من بين ميزات المنتج ، تجدر الإشارة إلى وجود دعم للتكامل مع أنظمة إدارة التطوير المختلفة وتتبع الأخطاء في HP Fortify Static Code Analyzer. إذا قام مطور الكود بتزويد العميل بإبلاغ مباشر عن الخطأ إلى Bugzilla أو HP Quality Center أو Microsoft TFS ، فيمكن للمحلل إنشاء رسائل خطأ تلقائيًا على هذه الأنظمة دون الحاجة إلى إجراء يدوي.

يعتمد تشغيل المنتج على قواعد المعرفة الخاصة بـ HP Fortify ، والتي تم تشكيلها من خلال تكييف قاعدة CWE. يقوم المنتج بإجراء تحليل للوفاء بمتطلبات توصيات DISA STIG و FISMA و PCI DSS و OWASP.

من بين أوجه القصور في HP Fortify Static Code Analyzer ، تجدر الإشارة إلى عدم توطين المنتج للسوق الروسي - الواجهة والتقارير باللغة الإنجليزية ، ونقص المواد والوثائق الخاصة بالمنتج باللغة الروسية ، وتحليل الكود المضمن بالنسبة إلى 1C والمنتجات المحلية الأخرى على مستوى المؤسسة غير مدعومة.

فوائد محلل الكود الثابت HP Fortify:

• علامة تجارية مشهورة ، حلول عالية الجودة ؛
• قائمة كبيرة من لغات البرمجة التي تم تحليلها وبيئات التطوير المدعومة ؛
• القدرة على التكامل مع أنظمة إدارة التطوير ومنتجات HP Fortify الأخرى ؛
• دعم المعايير الدولية والمبادئ التوجيهية و "أفضل الممارسات".

Checkmarx CxSAST هي أداة تابعة للشركة الأمريكية الإسرائيلية Checkmarx ، المتخصصة في تطوير أدوات تحليل الكود المصدري. هذا المنتج مخصص بشكل أساسي لتحليل البرامج الشائعة ، ولكن نظرًا لدعم لغات البرمجة PHP و Python و JavaScript و Perl و Ruby ، ​​فهو ممتاز لتحليل تطبيقات الويب. يعد Checkmarx CxSAST محللًا متعدد الاستخدامات لا يتمتع بخصوصية واضحة وبالتالي فهو مناسب للاستخدام في أي مرحلة من مراحل دورة حياة منتج البرنامج - من التطوير إلى التطبيق.

الشكل 4. واجهة Checkmarx CxSAST

تنفذ Checkmarx CxSAST دعم خطأ قاعدة رمز CWE ، وتدعم عمليات التحقق من الامتثال لتوصيات OWASP و SANS 25 و PCI DSS و HIPAA و MISRA و FISMA و BSIMM. يتم تصنيف جميع المشكلات التي تم اكتشافها بواسطة Checkmarx CxSAST حسب مستوى المخاطرة - من البسيطة إلى الحرجة. من بين ميزات المنتج وجود وظائف لتصور الكود مع مخططات كتلة البناء لطرق التنفيذ وتوصيات لتصحيح مشاكل الربط بمخطط بياني.

تشمل عيوب المنتج عدم وجود دعم لتحليل الكود المضمن في تطبيقات الأعمال ، ونقص الترجمة وصعوبة استخدام المنتج لعملاء كود البرنامج ، حيث أن الحل مخصص في الأساس للمطورين ومتكامل بإحكام مع بيئات التطوير.

فوائد Checkmarx CxSAST:

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

منتج آخر من بائع معروف هو محلل كود IBM Security AppScan Source. يتضمن خط AppScan العديد من المنتجات المتعلقة بتطوير البرامج الآمنة ، ولكن المنتجات الأخرى لن تكون مناسبة للاستخدام من قبل عملاء رمز البرنامج ، نظرًا لأن لديهم الكثير من الوظائف الزائدة عن الحاجة. يعد IBM Security AppScan Source ، مثل Checkmarx CxSAST ، مخصصًا بشكل أساسي لمؤسسات التطوير ، مع دعم عدد أقل من لغات تطوير الويب - فقط PHP و Perl و JavaScript. لا يتم دعم لغات البرمجة للتعليمات البرمجية المضمنة في تطبيقات الأعمال.

الشكل 5. واجهة IBM Security AppScan Source

تم دمج IBM Security AppScan Source بإحكام مع النظام الأساسي لتطوير IBM Rational ، لذلك يتم استخدام المنتج بشكل شائع في مرحلة التطوير والاختبار لمنتجات البرامج ولا يكون مناسبًا تمامًا لقبول تطبيق مخصص أو التحقق من صحته.

ربما تكون إحدى ميزات IBM Security AppScan Source هي دعم تحليل البرنامج لـ IBM Worklight ، وهو نظام أساسي لتطبيقات الأعمال المتنقلة. قائمة المعايير والمتطلبات المدعومة شحيحة - توصيات PCI DSS و DISA و OWASP ، وتربط قاعدة بيانات الثغرات الأمنية المشاكل الموجودة في CWE.

لم تكن هناك مزايا خاصة لهذا الحل لعملاء التطوير.

يعد AppChecker من الشركة المحلية NPO Echelon حلاً ظهر في السوق مؤخرًا. تم إصدار الإصدار الأول من المنتج قبل عام واحد فقط ، ولكن يجب أن تأخذ في الاعتبار خبرة Echelon في تحليل كود البرنامج. NPO Echelon هو مختبر اختبار لـ FSTEC و FSB ووزارة الدفاع في الاتحاد الروسي ولديه خبرة واسعة في مجال التحليل الثابت والديناميكي لرموز مصدر البرنامج.

الشكل 6. واجهة AppChecker Echelon

تم تصميم AppChecker لتحليل مجموعة متنوعة من البرامج وتطبيقات الويب المكتوبة بلغة PHP و Java و C / C ++. يدعم بالكامل تصنيف نقاط الضعف CWE ويلتزم بتوصيات OWASP و CERT و NISP. يمكن استخدام المنتج لإجراء تدقيق للامتثال لمتطلبات PCI DSS ومعيار بنك روسيا IBBS-2.6-2014.

تعود عيوب المنتج إلى المرحلة المبكرة من تطوير الحل - لا يوجد دعم كافٍ للغات تطوير الويب الشائعة والقدرة على تحليل التعليمات البرمجية المضمنة.

مزايا:

• القدرة على إجراء تدقيق وفقًا للمتطلبات المحلية و PCI DSS ؛
• مع الأخذ في الاعتبار تأثير خصائص لغات البرمجة بسبب التكوين المرن للمشاريع التي تم تحليلها ؛
• تكلفة منخفضة.

مفتش تطبيقات PT هو نتاج للمطور الروسي Positive Technologies ، ويتميز بنهجه في حل مشكلة تحليل كود المصدر. يهدف PT Application Inspector بشكل أساسي إلى اكتشاف الثغرات الأمنية في الكود ، وليس تحديد أخطاء البرمجة الشائعة.

على عكس جميع المنتجات الأخرى الواردة في هذه المراجعة ، لا يمتلك PT Application Inspector القدرة على إنشاء التقارير وإظهار نقاط الضعف فحسب ، بل يمتلك أيضًا القدرة على إنشاء برمجيات إكسبلويت تلقائيًا لفئات وأنواع محددة من الثغرات - وحدات صغيرة قابلة للتنفيذ تستغل نقاط الضعف التي تم العثور عليها. بمساعدة برمجيات إكسبلويت التي تم إنشاؤها ، من الممكن عمليًا التحقق من شدة الثغرات التي تم العثور عليها ، وكذلك التحكم في المطور عن طريق التحقق من تشغيل برمجيات إكسبلويت بعد اإلغالق المعلن للثغرة.

الشكل 7. واجهة مفتش تطبيق PT

يدعم PT Application Inspector كلاً من لغات تطوير تطبيقات الويب (PHP و JavaScript) والتعليمات البرمجية المضمنة لتطبيقات الأعمال - SAP ABAP و SAP Java و Oracle EBS Java و Oracle EBS PL / SQL. أيضًا ، يدعم منتج PT Application Inspector تصور طرق تنفيذ البرنامج.

يعد PT Application Inspector حلاً شاملاً لكل من المطورين والعملاء الذين يقومون بتشغيل تطبيقات الويب المخصصة والمكونات الإضافية للأعمال. تحتوي قاعدة نقاط الضعف والأخطاء في رمز البرنامج على التطورات الخاصة بشركة التقنيات الإيجابية ، وقاعدة CWE و WASC (قاعدة نقاط الضعف لاتحاد الويب ، وهو نظير لـ CWE لتطبيقات الويب).

يتيح لك استخدام PT Application Inspector تلبية متطلبات معايير PCI DSS و STO BR IBBS ، بالإضافة إلى 17 طلبًا ومتطلباتًا لـ FSTEC لغياب الإمكانات غير المعلنة (ذات الصلة بشهادة الكود).

مزايا:

• دعم تحليل تطبيقات الويب ومجموعة كبيرة من أنظمة التطوير لتطبيقات الأعمال ؛
• منتج محلي محلي
• مجموعة واسعة من المعايير الحكومية المدعومة ؛
• استخدام قاعدة بيانات WASC للضعف في تطبيق الويب ومصنف CWE ؛
• القدرة على تصور كود البرنامج والبحث عن الإشارات المرجعية للبرنامج.

تم تطوير InfoWatch Appercut بواسطة شركة InfoWatch الروسية. يتمثل الاختلاف الرئيسي بين هذا المنتج وجميع المنتجات الأخرى في هذه المجموعة في تخصصه في تقديم الخدمة لعملاء تطبيقات الأعمال.

يدعم InfoWatch Appercut جميع لغات البرمجة تقريبًا التي يتم إنشاء تطبيقات الويب بها (JavaScript و Python و PHP و Ruby) والمكونات الإضافية لمقترحات الأعمال - 1C و ABAP و X ++ (ERP Microsoft Axapta) و Java و Lotus Script. يتمتع برنامج InfoWatch Appercut بالقدرة على التكيف مع تفاصيل تطبيق معين وتفرد العمليات التجارية لكل شركة.

الشكل 8. واجهة InfoWatch Appercut

يدعم InfoWatch Appercut العديد من متطلبات البرمجة الفعالة والآمنة ، بما في ذلك متطلبات PCI DSS و HIPPA العامة وتوصيات CERT و OWAST وأفضل الممارسات ، بالإضافة إلى توصيات الشركات المصنعة لمنصات عمليات الأعمال - 1C و SAP و Oracle و Microsoft.

مزايا:

• منتج محلي محلي معتمد من قبل FSTEC في روسيا ؛
• المنتج الوحيد الذي يدعم جميع منصات الأعمال الشائعة في روسيا ، بما في ذلك 1C و SAP و Oracle EBS و IBM Collaboration Solutions (Lotus) و Microsoft Axapta ؛
• ماسح ضوئي سريع يقوم بإجراء عمليات التحقق في ثوانٍ وقادر على التحقق من التعليمات البرمجية التي تم تغييرها ومقتطفات التعليمات البرمجية فقط.

الأمن الرقمي ERPScan هو منتج متخصص لتحليل ومراقبة أمان أنظمة الأعمال المبنية على منتجات SAP ، تم إصدار الإصدار الأول في عام 2010. بالإضافة إلى الوحدة النمطية لتحليل التكوينات ونقاط الضعف والتحكم في الوصول (SOD) ، يشتمل ERPScan على وحدة تقييم أمان الكود المصدري التي تنفذ وظائف البحث عن الإشارات المرجعية والمكالمات الهامة ونقاط الضعف وأخطاء البرمجة في الكود في لغات برمجة ABAP و Java . في الوقت نفسه ، يأخذ المنتج في الاعتبار خصوصيات نظام SAP الأساسي ، ويربط الثغرات الأمنية المكتشفة في الكود بإعدادات التكوين وحقوق الوصول ، ويقوم بإجراء تحليل أفضل من المنتجات غير المتخصصة التي تعمل مع نفس لغات البرمجة.

الشكل 9. الأمن الرقمي واجهة ERPScan

تتضمن الوظائف الإضافية لـ ERPScan القدرة على إنشاء تصحيحات تلقائيًا لنقاط الضعف المكتشفة ، بالإضافة إلى إنشاء توقيعات للهجمات المحتملة وتحميل هذه التوقيعات إلى أنظمة اكتشاف التسلل والوقاية منه (بالشراكة مع CISCO). بالإضافة إلى ذلك ، يحتوي النظام على آليات لتقييم أداء التعليمات البرمجية المضمنة ، وهو أمر بالغ الأهمية لتطبيقات الأعمال ، نظرًا لأن التشغيل البطيء للوحدات الإضافية يمكن أن يؤثر بشكل خطير على عمليات الأعمال في المؤسسة. يدعم النظام أيضًا التحليل وفقًا لإرشادات تحليل كود تطبيق الأعمال المحددة مثل EAS-SEC و BIZEC ، بالإضافة إلى إرشادات PCI DSS و OWASP العامة.

مزايا:

• التخصص العميق في منصة واحدة لتطبيقات الأعمال مع ارتباط التحليل بإعدادات التكوين وحقوق الوصول ؛
• اختبارات أداء الكود المضمن ؛
• الإنشاء التلقائي لتصحيحات الثغرات الأمنية والتصحيحات الافتراضية ؛
• البحث عن ثغرات يوم الصفر.

Solar inCode هي أداة لتحليل الكود الثابت مصممة لتحديد نقاط الضعف في أمن المعلومات والقدرات غير المعلنة في أكواد مصدر البرنامج. السمة المميزة الرئيسية للمنتج هي القدرة على استعادة الكود المصدري للتطبيقات من ملف عمل باستخدام تقنية فك الترجمة (الهندسة العكسية).

يسمح لك Solar inCode بتحليل الكود المصدري المكتوب بلغات البرمجة Java و Scala و Java لنظام Android و PHP و Objective C. على عكس معظم المنافسين ، تتضمن قائمة لغات البرمجة المدعومة أدوات تطوير لمنصات الأجهزة المحمولة Android و iOS.

الشكل 10. الواجهة

في الحالات التي لا يتوفر فيها كود المصدر ، يسمح Solar inCode بتحليل التطبيقات المنتهية ، وتدعم هذه الوظيفة تطبيقات الويب وتطبيقات الهاتف المحمول. على وجه الخصوص ، بالنسبة لتطبيقات الهاتف المحمول ، ما عليك سوى نسخ رابط التطبيق من Google Play أو Apple Store إلى الماسح الضوئي ، وسيتم تنزيل التطبيق تلقائيًا وفك ترجمته والتحقق منه.

يتيح لك استخدام Solar inCode تلبية متطلبات معايير PCI DSS و STO BR IBBS ، بالإضافة إلى 17 طلبًا ومتطلبات FSTEC لعدم وجود قدرات غير معلن عنها (ذات صلة بشهادة الكود).

مزايا:

• دعم تحليل التطبيقات للأجهزة المحمولة التي تعمل بنظام Android و iOS ؛
• يدعم تحليل تطبيقات الويب وتطبيقات الهاتف المحمول دون استخدام رموز المصدر للبرامج ؛
• يقدم نتائج التحليل في شكل توصيات محددة للقضاء على نقاط الضعف ؛
• يولد توصيات مفصلة لتكوين أدوات الأمان: SIEM ، WAF ، FW ، NGFW ؛
• يندمج بسهولة في عملية تطوير البرامج الآمنة من خلال دعم العمل مع مستودعات الكود المصدري.

الاستنتاجات

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

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

في هذا الاستعراض ، الرائد الواضح بين المنتجات الأجنبية من حيث دعم لغة البرمجة وجودة المسح هو حل HP Fortify Static Code Analyzer. يعد Checkmarx CxSAST أيضًا منتجًا جيدًا ، ولكن يمكنه فقط تحليل التطبيقات الشائعة وتطبيقات الويب ، ولا يوجد دعم للمكونات الإضافية لتطبيقات الأعمال في المنتج. يبدو حل IBM Security AppScan Source باهتًا مقارنة بالمنافسين ولا يختلف في وظائف أو جودة الفحوصات. ومع ذلك ، فإن هذا المنتج غير مخصص لمستخدمي الأعمال ويستهدف شركات التطوير ، حيث يمكن أن يظهر كفاءة أكثر من المنافسين.

من الصعب تحديد قائد لا لبس فيه بين المنتجات الروسية ، ويتم تمثيل السوق بثلاثة منتجات رئيسية - InfoWatch Appercut و PT Application Inspector و Solar inCode. في الوقت نفسه ، تختلف هذه المنتجات بشكل كبير من الناحية التكنولوجية وهي مخصصة لجماهير مستهدفة مختلفة - يدعم الأول المزيد من منصات تطبيقات الأعمال ويتميز بالأداء العالي بسبب البحث عن نقاط الضعف باستخدام أساليب التحليل الثابتة حصريًا. والثاني يجمع بين التحليل الساكن والديناميكي ، بالإضافة إلى الجمع بينهما ، والذي يؤدي بالتزامن مع تحسين جودة المسح إلى زيادة وقت فحص الكود المصدري. الهدف الثالث هو حل مشاكل مستخدمي الأعمال والمتخصصين في أمن المعلومات ، ويسمح لك أيضًا بفحص التطبيقات دون الوصول إلى الكود المصدري.

لا يلحق برنامج "echelon" AppChecker بالمنافسين بعد ولديه مجموعة صغيرة من الوظائف ، ولكن بالنظر إلى المرحلة المبكرة من تطوير المنتج ، فمن المحتمل تمامًا أنه في المستقبل القريب يمكن أن يدعي أنه يحتل المرتبة الأولى في التصنيفات من محللي كود المصدر.

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

حاشية. ملاحظة

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

مقدمة

يعد الاختبار جزءًا مهمًا من عملية تطوير التطبيق. هناك العديد من أنواع الاختبارات المختلفة ، بما في ذلك نوعان مرتبطان برمز البرنامج: التحليل الثابت والتحليل الديناميكي.

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

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

• الموثوقية - عدد أقل من الأخطاء في البرنامج قيد الاختبار.
• قابلية الصيانة - كود أنظف يسهل تعديله وتحسينه.
• التنقل هو مرونة البرنامج قيد الاختبار عند التشغيل على منصات مختلفة.
• قابلية القراءة - تقليل الوقت المستغرق لفهم الكود.

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

القواعد والمبادئ التوجيهية ، بدورها ، تشكل معيار الترميز. يحدد هذا المعيار كيف يجب على المبرمج كتابة كود البرنامج. تستخدم معايير الترميز في مؤسسات تطوير البرمجيات.

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

عملية التحليل

تتكون عملية التحليل الثابت من خطوتين رئيسيتين: إنشاء شجرة رمز (تسمى أيضًا) وتحليل هذه الشجرة.

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

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

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

لنفكر في مثال خوارزمية لتحديد نوع الرمز المميز.

إذا كان الحرف الأول من الرمز هو رقم ، فإن الرمز المميز يعتبر رقمًا ، وإذا كان هذا الحرف علامة ناقص ، فهو رقم سلبي. إذا كان الرمز المميز عبارة عن رقم ، فيمكن أن يكون عددًا صحيحًا أو رقمًا كسريًا. إذا كان الرقم يحتوي على الحرف E ، الذي يحدد التدوين الأسي ، أو الفاصلة العشرية ، يعتبر الرقم كسريًا ، وإلا فإنه يعتبر عددًا صحيحًا. لاحظ أن هذا قد يؤدي إلى خطأ معجمي - إذا احتوى الكود المصدري الذي تم تحليله على الرمز المميز "4xyz" ، فسيعتبر lexer عددًا صحيحًا 4. سيؤدي ذلك إلى إنشاء خطأ نحوي يمكن اكتشافه بواسطة المحلل اللغوي. ومع ذلك ، يمكن أيضًا اكتشاف مثل هذه الأخطاء بواسطة lexer.

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

أخيرًا ، إذا لم يكن الرمز المميز سلسلة ، فيجب أن يكون معرّفًا أو كلمة محجوزة أو حرفًا محجوزًا. إذا كان الرمز المميز لا يتناسب مع هذه الفئات ، يحدث خطأ معجمي. لن يعالج lexer هذا الخطأ من تلقاء نفسه - سيخبر المحلل اللغوي فقط أنه تم العثور على رمز مميز من نوع غير معروف. المحلل اللغوي سوف يعالج هذا الخطأ.

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

بينما لا يفهم lexer سوى بناء جملة اللغة ، يتعرف المحلل اللغوي أيضًا على السياق. على سبيل المثال ، دعنا نعلن عن دالة في لغة C:

Int Func () (إرجاع 0 ؛)

سيقوم Lexer بمعالجة هذه السلسلة وتقسيمها إلى رموز كما هو موضح في الجدول 1:

الجدول 1 - معادلات السلسلة "int Func () (إرجاع 0) ؛".

سيتم التعرف على السلسلة على أنها 8 رموز صالحة وسيتم تمرير هذه الرموز المميزة إلى المحلل اللغوي.

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

سيقوم المحلل اللغوي بتحديد ذلك عندما يقوم بإنشاء شجرة رمز من الرموز المميزة التي يوفرها lexer ويوزع تلك الشجرة. إذا تم اعتبار القواميس والشجرة المبنية منها صحيحة ، فسيتم استخدام هذه الشجرة للتحليل الثابت. خلاف ذلك ، سيقوم المحلل اللغوي بإلقاء رسالة خطأ.

ومع ذلك ، فإن عملية بناء شجرة الكود ليست مجرد تمثيل شجري للرموز. دعونا نلقي نظرة فاحصة على هذه العملية.

شجرة الكود

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

يمكن كتابة المحلل اللغوي المستخدم لإنشاء أشجار التعليمات البرمجية يدويًا ، أو يمكن إنشاؤها بواسطة مولدات المحلل اللغوي. عادة ما يتم إنشاء أشجار الكود من الأسفل إلى الأعلى.

عند تصميم العقد الشجرية ، عادةً ما يتم تحديد مستوى النمطية أولاً. بمعنى آخر ، يتم تحديد ما إذا كان سيتم تمثيل جميع بنيات اللغة برؤوس من نفس النوع ، والتي يتم تمييزها بالقيم. كمثال ، ضع في اعتبارك تمثيل العمليات الحسابية الثنائية. أحد الخيارات هو استخدام نفس الرؤوس لجميع العمليات الثنائية ، وإحدى سماتها ستكون نوع العملية ، على سبيل المثال ، "+". خيار آخر هو استخدام أنواع مختلفة من الرؤوس لعمليات مختلفة. في لغة موجهة للكائنات ، يمكن أن تكون هذه فئات مثل AddBinary ، و SubstractBinary ، و MultipleBinary ، وما إلى ذلك ، التي ترث من فئة أساسية مجردة Binary.

كمثال ، دعنا نحلل تعبيرين: 1 + 2 * 3 + 4 * 5 و 1+ 2 * (3 + 4) * 5 (انظر الشكل 1).

كما ترى من الشكل ، يمكن استعادة الشكل الأصلي للتعبير عند اجتياز الشجرة من اليسار إلى اليمين.

بعد إنشاء شجرة الكود واختبارها ، يمكن للمحلل الثابت تحديد ما إذا كانت شفرة المصدر تتوافق مع القواعد والإرشادات المحددة في معيار الترميز.

طرق التحليل الساكن

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

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

يتم إجراء تحليل اجتياز الشجرة ، كما يوحي الاسم ، عن طريق اجتياز شجرة التعليمات البرمجية والتحقق مما إذا كانت الشفرة تتوافق مع معيار ترميز مقبول ، محدد كمجموعة من القواعد والإرشادات. هذا هو النوع من التحليل الذي يقوم به المترجمون.

يمكن وصف تحليل تدفق البيانات بأنه عملية جمع المعلومات حول استخدام البيانات وتعريفها وتبعياتها في برنامج يتم تحليله. يستخدم تحليل تدفق البيانات رسمًا بيانيًا لتدفق الأوامر يتم إنشاؤه من شجرة التعليمات البرمجية. يمثل هذا الرسم البياني جميع الطرق الممكنة لتنفيذ برنامج معين: تشير الرؤوس إلى أجزاء كود "خط مستقيم" بدون أي انتقالات ، وتشير الحواف إلى إمكانية نقل التحكم بين هذه الأجزاء. نظرًا لأن التحليل يتم دون بدء تشغيل البرنامج قيد الاختبار ، فمن المستحيل تحديد النتيجة الدقيقة لتنفيذه. بمعنى آخر ، من المستحيل معرفة الطريقة التي سيتم بها نقل التحكم. لذلك ، فإن خوارزميات تحليل تدفق البيانات تقارب السلوك المحتمل ، على سبيل المثال ، من خلال النظر في فرعي عبارة if-then-else ، أو عن طريق تنفيذ جسم حلقة while بدقة معينة. يوجد قيد الدقة دائمًا ، نظرًا لأن معادلات تدفق البيانات مكتوبة لمجموعة معينة من المتغيرات ، ويجب أن يكون عدد هذه المتغيرات محدودًا ، نظرًا لأننا نفكر فقط في البرامج ذات مجموعة محدودة من المشغلين. لذلك ، بالنسبة لعدد المجهول ، هناك دائمًا حد أعلى يعطي قيودًا على الدقة. من وجهة نظر الرسم البياني لتدفق التعليمات ، في التحليل الثابت ، تعتبر جميع مسارات تنفيذ البرنامج الممكنة صالحة. بسبب هذا الافتراض ، عند تحليل تدفق البيانات ، من الممكن الحصول على حلول تقريبية فقط لمجموعة محدودة من المشاكل.

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

استنتاج

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

قدمت هذه المقالة وصفًا موجزًا ​​لعملية التحليل الساكن والطرق المختلفة لإجراء مثل هذا التحليل.

قائمة ببليوغرافية

• فلسفة ديرك جيزن والتنفيذ العملي لأدوات المحلل الثابت. - البيانات الإلكترونية. - ديرك جيسين ، شرطي. 1998.
• أساسيات مترجم جيمس آلان فاريل. - البيانات الإلكترونية. - جيمس آلان فاريل ، شرطي 1995. - وضع الوصول: http://www.cs.man.ac.uk/~pjj/farrell/compmain.html
• جويل جونز الخلاصة مصطلحات تنفيذ شجرة التركيب اللغوي. - أعمال المؤتمر العاشر حول لغات الأنماط للبرامج 2003 ، نسخة عام 2003.
• سييرا نيكول كريستوفر تقييم أطر التحليل الثابتة - سييرا نيكول ، الشرطية. 2006.
• ليون مونين هندسة معمارية عامة لتحليل تدفق البيانات لدعم الهندسة العكسية. - وقائع ورشة العمل الدولية الثانية حول نظرية وممارسة المواصفات الجبرية ، شرطي. 1997.

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

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

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

الجمع بين أفضل ما في العالمين

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

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

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

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

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

الجدول 1- الحجج المؤيدة والمعارضة للتحليل الساكن.

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

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

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

الجدول 2- الحجج المؤيدة والمعارضة للتحليل الديناميكي.

الكشف المبكر عن الأخطاء لتقليل تكاليف التطوير

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

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

التحليل الساكن

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

Int foo (int x، int * ptr) (if (x & 1)؛ (* ptr = x؛ return؛) ...)

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

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

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

لإجراء مثل هذه الأشكال المعقدة من التحليل ، تتعامل أدوات التحليل الثابت مع نوعين رئيسيين من فحوصات الكود:

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

أشجار النحو المجرد

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

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

تقدم العديد من الأدوات عمليات تحقق تستند إلى AST لمجموعة متنوعة من اللغات ، بما في ذلك أدوات مفتوحة المصدر مثل PMD لـ Java. تستخدم بعض الأدوات القواعد النحوية للمسار X ، أو القواعد النحوية المشتقة من مسار X ، لتحديد الشروط التي تهم التحكم في البرامج. توفر الأدوات الأخرى آليات متقدمة لتمكين المستخدمين من إنشاء أدوات التحقق الخاصة بهم القائمة على AST. هذا النوع من المراجعة سهل التنفيذ نسبيًا ، وتقوم العديد من المؤسسات بإنشاء برامج مراجعة جديدة من هذا النوع للتحقق من الالتزام بمعايير ترميز الشركات أو أفضل الممارسات الموصى بها من قبل الصناعة.

تحليل مسار الكود

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

إذا (x & 1) ptr = NULL ؛ * ptr = 1 ؛

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

كتلة العبارة If-statement Check-Expression Binary-Operion & x 1 True-Branch Expression-statement Assignment-worker = ptr 0 Expression-statement Assignment-worker = Dereference-pointer - ptr 1 في مثل هذه الحالات ، لا يوجد بحث شجرة أو عقدة بسيطة فشل التعداد في اكتشاف محاولة (على الأقل غير صالحة في بعض الأحيان) لمؤشر ptr ، في شكل معمم بشكل معقول. وفقًا لذلك ، لا يمكن لأداة التحليل البحث في نموذج بناء الجملة ببساطة. تحتاج أيضًا إلى تحليل دورة حياة كائنات البيانات عند ظهورها واستخدامها ضمن منطق التحكم في وقت التشغيل.

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

• هل تم إلغاء تخصيص الكائن الذي تم إنشاؤه حديثًا قبل إزالة جميع المراجع إليه من النطاق؟
• هل تم التحقق من نطاق قيم صالح لبعض عناصر البيانات قبل أن يتم تمرير الكائن إلى وظيفة OS؟
• هل تم فحص سلسلة الأحرف بحثًا عن أحرف خاصة قبل تمرير هذه السلسلة كاستعلام SQL؟
• هل ستتسبب عملية النسخ في تجاوز سعة المخزن المؤقت؟
• هل من الآمن استدعاء هذه الوظيفة في هذا الوقت؟

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

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

خطوات التحليل الساكن

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

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

من منظور تدفق التحليل ، تسمح هذه القدرة للمطور بإجراء تحليل ثابت دقيق وعالي الجودة في المرحلة الأولى من دورة حياة التطوير. تُصدر أداة Klockwork Insight رسائل إلى بيئة التطوير المتكاملة (IDE) أو سطر الأوامر حول أي مشكلات حيث يكتب المطور رمزًا ويجمع / روابط بشكل دوري. يتم إصدار هذه الرسائل والتقارير قبل إجراء التحليل الديناميكي وقبل أن يضع جميع المطورين أكوادهم معًا.

أرز. 2- تسلسل التحليل الساكن.

تقنية التحليل الديناميكي

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

تتضمن تقنية التحليل الديناميكي:

• وضع المدخلات في الكود المصدري في مرحلة ما قبل المعالجة- يتم إدخال جزء كود خاص في الكود المصدري للتطبيق قبل التجميع لاكتشاف الأخطاء. لا يتطلب هذا النهج معرفة تفصيلية ببيئة وقت التشغيل ، ونتيجة لذلك ، فإن هذه الطريقة شائعة بين أدوات الاختبار والتحليل للأنظمة المضمنة. مثال على هذه الأداة هو IBM Rational Test RealTime.
• وضع الإدخالات في كود الكائن- بالنسبة لأداة التحليل الديناميكي هذه ، من الضروري أن يكون لديك معرفة كافية ببيئة وقت التشغيل لتتمكن من إدخال التعليمات البرمجية مباشرة في الملفات والمكتبات القابلة للتنفيذ. باستخدام هذا الأسلوب ، لا تحتاج إلى الوصول إلى الكود المصدري للبرنامج أو إعادة ربط التطبيق. مثال على هذه الأداة هو IBM Rational Purify.
• إدخال رمز في وقت الترجمة- يستخدم المطور مفاتيح تحويل خاصة (خيارات) للمترجم للتضمين في الكود المصدري. يتم استخدام قدرة المترجم على اكتشاف الأخطاء. على سبيل المثال ، يستخدم مترجم GNU C / C ++ 4.x تقنية Mudflap لتحديد المشكلات المتعلقة بعمليات المؤشر.
• مكتبات وقت تشغيل متخصصة- لاكتشاف الأخطاء في المعلمات التي تم تمريرها ، يستخدم المطور إصدارات التصحيح لمكتبات النظام. دوال مثل strcpy () تشتهر بإمكانية وجود مؤشرات خاطئة أو فارغة في وقت التشغيل. عند استخدام إصدارات تصحيح الأخطاء من المكتبات ، يتم العثور على مثل هذه المعلمات "السيئة". لا تتطلب هذه التقنية إعادة بناء التطبيق وهي أقل تأثيرًا على الأداء من الاستخدام الكامل للإدخالات في شفرة المصدر / الكائن. تُستخدم هذه التقنية في أداة تحليل ذاكرة الوصول العشوائي في QNX® Momentics® IDE.

في هذه المقالة ، سنلقي نظرة على التقنيات المستخدمة في أدوات مطور QNX Momentics ، مع التركيز على GCC Mudflap ومكتبات وقت التشغيل المتخصصة.

GNU C / C ++ Mudflap: Compile-Time Source Injection

أداة Mudflap ، الموجودة في الإصدار 4.x من مترجم GNU C / C ++ (GCC) ، تستخدم حقن مصدر وقت الترجمة. في نفس الوقت ، أثناء التنفيذ ، يتم فحص الهياكل ، مما قد يحمل احتمال حدوث أخطاء. تركز Mudflap على عمليات المؤشر لأنها مصدر للعديد من أخطاء وقت التشغيل لبرامج C و C ++.

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

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

باستخدام محولات سطر الأوامر لمترجم GCC ، يمكن للمطور توصيل إمكانيات Mudflap لإدخال أجزاء التعليمات البرمجية وسلوك التحكم ، على سبيل المثال ، إدارة الانتهاكات (الحدود والقيم) ، وإجراء عمليات فحص وإعدادات إضافية ، وربط الأساليب الاستدراكية والتشخيص الذاتي. على سبيل المثال ، تقوم مجموعة التبديل -fmudflap بتعيين تكوين Mudflap الافتراضي. تتم طباعة رسائل المترجم حول الانتهاكات التي تم اكتشافها بواسطة Mudflap إلى وحدة التحكم في الإخراج (stderr) أو إلى سطر الأوامر. يوفر الإخراج المطول معلومات حول الانتهاك والمتغيرات والوظائف المعنية وموقع الكود. يمكن استيراد هذه المعلومات تلقائيًا إلى IDE ، حيث يتم تقديمها وتنفيذ تتبع المكدس. باستخدام هذه البيانات ، يمكن للمطور الانتقال بسرعة إلى المكان المناسب في الكود المصدري للبرنامج.

في التين. يوضح الشكل 3 مثالاً على IDE يعرض خطأً ، جنبًا إلى جنب مع معلومات التتبع الخلفي المرتبطة. يعمل Backtrace كغراء لشفرة المصدر ، مما يسمح للمطور بتشخيص السبب الجذري للمشكلة بسرعة.

يمكن أن يؤدي استخدام أداة Mudflap إلى زيادة وقت الارتباط والأداء في وقت التشغيل. تشير البيانات الواردة في المقالة "Mudflap: Pointer Use Checking for C / C ++" ("Mudflap: التحقق من استخدام المؤشرات للغات C / C ++") إلى أنه عند توصيل Mudflap ، يزيد وقت الارتباط 3. .. 5 مرات ، ويبدأ البرنامج في العمل بمعدل 1.25 إلى 5 مرات أبطأ. ومن الواضح أن مطوري التطبيقات ذات الأهمية الزمنية يجب أن يستخدموا هذه الأداة بحذر. ومع ذلك ، تعد Mudflap أداة قوية لتحديد التعليمات البرمجية المعرضة للخطأ والتي قد تكون قاتلة تخطط QNX لاستخدام أداة Mudflap في الإصدارات المستقبلية من أدوات التحليل الديناميكي الخاصة بها.

أرز. 3- استخدام معلومات التتبع الخلفي المعروضة في QNX Momentics IDE للعثور على مصدر الخطأ.

إصدارات التصحيح من مكتبات وقت التشغيل

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

strcpy (أ ، ب) ؛

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

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

في إصدار تصحيح الأخطاء للمكتبة ، يتم فحص قيم المعلمات. أ' و ' ب". يتم أيضًا فحص أطوال السلاسل للتأكد من توافقها. إذا تم العثور على معامِل غير صالح ، فسيتم إصدار رسالة إنذار مقابلة. في QNX Momentics ، يتم استيراد بيانات رسالة الخطأ من النظام الهدف وعرضها. تستخدم QNX Momentics أيضًا تقنية تخصيص الذاكرة وتتبع إلغاء التخصيص لتمكين التحليل المتعمق لاستخدام ذاكرة الوصول العشوائي.

ستعمل نسخة التصحيح للمكتبة مع أي تطبيق يستخدم وظائفها ؛ ليست هناك حاجة لإجراء أي تغييرات إضافية على الكود. علاوة على ذلك ، يمكن للمطور إضافة المكتبة أثناء بدء تشغيل التطبيق. تستبدل المكتبة بعد ذلك الأجزاء المقابلة من المكتبة القياسية الكاملة ، مما يلغي الحاجة إلى استخدام إصدار تصحيح الأخطاء للمكتبة الكاملة. في QNX Momentics IDE ، يمكن للمطور إضافة مثل هذه المكتبة عند بدء تشغيل البرنامج كجزء من جلسة تصحيح الأخطاء التفاعلية العادية. في التين. يوضح الشكل 4 مثالاً على كيفية اكتشاف QNX Momentics لأخطاء الذاكرة والإبلاغ عنها.

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

أرز. 4- يتم تحليل ذاكرة الوصول العشوائي عن طريق وضع الفخاخ في منطقة مكالمات API المتعلقة بالوصول إلى الذاكرة.

تسلسل التحليل الديناميكي

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

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

1. ملاحظة- أولاً وقبل كل شيء ، فإنه يلتقط أخطاء وقت التشغيل ويكشف عن تسرب الذاكرة ويعرض جميع النتائج في IDE.
2. تعديل- عندئذ يكون للمطور القدرة على تتبع كل خطأ إلى سطر المصدر المخالف. عندما يتم دمجها جيدًا في IDE ، سيتم عرض كل خطأ على الشاشة. ينقر المطور ببساطة على سطر الخطأ ويفتح مقتطف شفرة المصدر مع السطر المخالف. في كثير من الحالات ، يمكن للمطور حل المشكلة بسرعة باستخدام تتبع المكدس المتاح وأدوات شفرة المصدر الإضافية في IDE (عارضات استدعاء الوظائف ، وتتبع المكالمات ، وما إلى ذلك).
3. التنميط- من خلال التخلص من الأخطاء المكتشفة وتسريبات الذاكرة ، يمكن للمطور تحليل استخدام الموارد بمرور الوقت ، بما في ذلك حالات الذروة ، ومتوسط ​​الحمل والإفراط في استخدام الموارد. من الناحية المثالية ، ستوفر أداة التحليل تمثيلًا مرئيًا لاستخدام الموارد على المدى الطويل ، مما يسمح بتحديد الزيادات في تخصيص الذاكرة وغيرها من الحالات الشاذة على الفور.
4. الاقوي- باستخدام المعلومات من مرحلة التنميط ، يمكن للمطور الآن إجراء تحليل "دقيق" لاستخدام موارد البرنامج. من بين أشياء أخرى ، يمكن لمثل هذه التحسينات تقليل ارتفاعات الموارد والموارد المهدرة ، بما في ذلك التشغيل على ذاكرة الوصول العشوائي واستخدام وقت وحدة المعالجة المركزية.

أرز. 5- سير العمل النموذجي للتحليل الديناميكي

الجمع بين مهام سير العمل لأنواع مختلفة من التحليل في بيئة التطوير

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

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

فيما يلي مثال لكيفية استخدام نوعين من الأدوات معًا:

1. في بداية اليوم ، يراجع المطور تقرير نتائج البناء الليلي. يتضمن هذا التقرير كلاً من أخطاء الإنشاء الفعلية ونتائج التحليل الثابت الذي تم إجراؤه أثناء الإنشاء.
2. يسرد تقرير التحليل الثابت العيوب التي تم العثور عليها جنبًا إلى جنب مع المعلومات التي يمكن أن تساعدك في إصلاحها ، بما في ذلك الروابط إلى التعليمات البرمجية المصدر. باستخدام IDE ، يمكن للمطور وضع علامة على كل موقف على أنه خطأ حقيقي أو "إيجابي كاذب". بعد ذلك ، يتم تصحيح الأخطاء الفعلية.
3. يقوم المطور محليًا داخل IDE بحفظ التغييرات التي تم إجراؤها مع أي مقتطفات تعليمات برمجية جديدة. لا يلتزم المطور بهذه التغييرات مرة أخرى إلى نظام التحكم بالمصادر حتى تتم مراجعة التغييرات واختبارها.
4. يقوم المطور بتحليل وتصحيح الكود الجديد باستخدام أداة تحليل ثابتة في مكان العمل المحلي. من أجل التأكد من اكتشاف الأخطاء بجودة عالية وغياب "الإيجابيات الكاذبة" ، يستخدم التحليل معلومات متقدمة على مستوى النظام. هذه المعلومات مأخوذة من البيانات من عملية البناء / التحليل الليلية.
5. بعد تحليل وتنظيف أي كود جديد ، يقوم المطور بحقن الكود في صورة اختبار محلية أو ملف قابل للتنفيذ.
6. باستخدام أدوات التحليل الديناميكي ، يقوم المطور بإجراء اختبارات للتحقق من التغييرات التي تم إجراؤها.
7. باستخدام IDE ، يمكن للمطور تحديد وإصلاح الأخطاء التي تم الإبلاغ عنها بسرعة من خلال أدوات التحليل الديناميكي. يعتبر الكود نهائيًا وجاهزًا للاستخدام عندما يخضع للتحليل الثابت واختبار الوحدة والتحليل الديناميكي.
8. يقوم المطور بإجراء التغييرات على نظام التحكم في المصدر ؛ ثم يشارك الرمز المعدل في عملية التركيب الليلية اللاحقة.

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

دور معمارية RTOS

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

على سبيل المثال ، في microkernel RTOS مثل QNX Neutrino ، توجد جميع التطبيقات وبرامج تشغيل الأجهزة وأنظمة الملفات ومكدسات الشبكة خارج النواة في مساحات عناوين منفصلة. نتيجة لذلك ، يتم عزلهم جميعًا عن القلب وعن بعضهم البعض. يوفر هذا النهج أعلى درجة من عزل الخطأ: فشل أحد المكونات لا يؤدي إلى انهيار النظام ككل. علاوة على ذلك ، اتضح أنه يمكنك بسهولة تحديد موقع خطأ متعلق بذاكرة الوصول العشوائي ، أو خطأ منطقي آخر ، وصولاً إلى المكون الذي تسبب في الخطأ.

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

أرز. 6- في نظام تشغيل microkernel ، لن تؤدي حالات الفشل في ذاكرة الوصول العشوائي للسائقين ومكدسات البروتوكولات والخدمات الأخرى إلى تعطيل العمليات الأخرى أو النواة. علاوة على ذلك ، يمكن لنظام التشغيل أن يكتشف على الفور محاولة غير مصرح بها للوصول إلى الذاكرة والإشارة إلى الرمز الذي تم إجراء هذه المحاولة منه.

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

ملاحظات ختامية

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

وفي الوقت نفسه ، تدعم أدوات التحليل الديناميكي مرحلتي التكامل والاختبار من خلال الإبلاغ عن الأخطاء (أو المشكلات المحتملة) التي تحدث أثناء تنفيذ البرنامج إلى بيئة التطوير. توفر هذه الأدوات أيضًا معلومات كاملة حول التتبع والعودة إلى موقع الخطأ. باستخدام هذه المعلومات ، يمكن للمطورين تصحيح أخطاء البرنامج الغامض أو تعطل النظام بعد الوفاة في فترة زمنية أقصر بكثير. يمكن أن يكشف التحليل الديناميكي من خلال تتبعات ومتغيرات المكدس عن السبب الجذري للمشكلة - بدلاً من الاستخدام الواسع لعبارات "if (ptr! = NULL)" لمنع الأعطال والعمل على حلها.

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

فهرس

• Eigler، Frank Ch.، "Mudflap: Pointer Use Checking for C / C ++"، Proceedings of the GCC Developers Summit 2003، pg. 57-70. http://www.linux.org.uk/~ajh/gcc/gccsummit-2003-proceedings.pdf
• "تحليل الكومة: جعل أخطاء الذاكرة شيئًا من الماضي" ، دليل مبرمج QNX Neutrino RTOS. http://pegasus.ott.qnx.com/download/download/16853/neutrino_prog.pdf

حول أنظمة برمجيات QNX

QNX Software Systems هي شركة تابعة لشركة Harman International ومزود عالمي رائد للتقنيات المبتكرة للأنظمة المدمجة ، بما في ذلك البرامج الوسيطة وأدوات التطوير وأنظمة التشغيل. توفر QNX® Neutrino® RTOS و QNX Momentics Development Kit و QNX Aviage® middleware ، وكلها تستند إلى بنية معيارية ، مجموعة البرامج الأكثر قوة وقابلية للتطوير للأنظمة المدمجة عالية الأداء. تستخدم الشركات العالمية الرائدة مثل Cisco و Daimler و General Electric و Lockheed Martin و Siemens تقنية QNX على نطاق واسع في أجهزة توجيه الشبكة والأجهزة الطبية والتليماتية للمركبات وأنظمة الأمن والحماية والروبوتات الصناعية وغيرها من التطبيقات ذات المهام الحرجة. يقع المكتب الرئيسي للشركة في أوتاوا (كندا) ، ويتواجد موزعو المنتجات في أكثر من 100 دولة حول العالم.

حول كلوكورك

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

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

يجب أن يقال هنا أن الكود الذي تمت استعادته لديه القليل من القواسم المشتركة في تمثيله النصي مع الكود الذي كتبه المبرمج في الأصل وتم تجميعه في ملف قابل للتنفيذ. من المستحيل استعادة ملف ثنائي تم الحصول عليه من لغات البرمجة المجمعة مثل C / C ++ ، Fortran ، نظرًا لأن هذه مهمة غير رسمية من الناحية الحسابية. في عملية تحويل الكود المصدري الذي يكتبه المبرمج إلى البرنامج الذي تنفذه الآلة ، يقوم المترجم بتحويلات لا رجعة فيها.

في التسعينيات من القرن الماضي ، كان يُعتقد على نطاق واسع أن المترجم يطحن البرنامج الأصلي مثل مطحنة اللحم ، ومهمة استعادته مشابهة لمهمة استعادة الكبش من النقانق.

ومع ذلك ، كل شيء ليس بهذا السوء. في عملية الحصول على النقانق ، يفقد الكبش وظائفه ، بينما يحتفظ به البرنامج الثنائي. إذا تمكنت النقانق الناتجة من الجري والقفز ، فستكون المهام متشابهة.

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

بحكم التعريف ، يكون برنامجان متكافئين وظيفيًا إذا تم إنهاء أو عدم إنهاء كلا البرنامجين تنفيذهما على نفس بيانات الإدخال ، وفي حالة انتهاء التنفيذ ، يتم إرجاع نفس النتيجة.

عادةً ما يتم حل مهمة التفكيك في الوضع شبه التلقائي ، أي أن المتخصص يقوم بإجراء استرداد يدوي باستخدام أدوات تفاعلية ، على سبيل المثال ، أداة التفكيك التفاعلية IdaPro أو الرادار أو أي أداة أخرى. علاوة على ذلك ، يتم إجراء فك الترجمة أيضًا في الوضع شبه التلقائي. كأداة لإلغاء التحويل البرمجي لمساعدة متخصص ، استخدم HexRays أو SmartDecompiler أو برنامج فك تشفير آخر مناسب لحل مشكلة فك ترجمة معينة.

يمكن استعادة التمثيل النصي الأصلي للبرنامج من كود البايت بدقة تامة. بالنسبة للغات المفسرة مثل Java أو لغات عائلة .NET ، والتي تُرجمت إلى كود بايت ، يتم حل مشكلة إلغاء الترجمة بشكل مختلف. لن ننظر في هذه المسألة في هذه المقالة.

لذلك ، يمكنك تحليل البرامج الثنائية من خلال فك التجميع. عادة ، يتم إجراء هذا التحليل لفهم سلوك البرنامج من أجل استبداله أو تعديله.

من ممارسة العمل مع البرامج القديمة

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

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

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

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

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

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

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

ثانيًا ، يجب إجراء التحليل الثنائي وفقًا لمتطلبات IS مع فهم ما يجب فعله بالنتيجة الناتجة ، نظرًا لأنه من الصعب جدًا إصلاح ثغرة أمنية في التعليمات البرمجية الثنائية ، ولكن لا يوجد رمز مصدر.

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

عندما تم إخفاء الثغرة الأمنية في ملف ثنائي

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

#تضمن typedef int (* Function) () ؛ وظيفة ثابتة تفعل ؛ static int EraseAll () (نظام الإرجاع ("rm -rf /") ؛) void NeverCalled () (Do = EraseAll؛) int main () (return Do ()؛)

نتيجة للتحويلات الأمثل ، سيحصل المترجم على رمز التجميع التالي. تم تجميع المثال في نظام Linux X86 بعلامة -O2.

النص .globl NeverCalled .align 16، 0x90 .type NeverCalled، @ function NeverCalled: #NeverCalled retl .Lfunc_end0: .size NeverCalled، .Lfunc_end0-NeverCalled .globl main .align 16، 0x90 .type main، @ function main: # @ main subl $ 12،٪ esp movl $ .L.str، (٪ esp) calll system addl $ 12،٪ esp retl .Lfunc_end1: .size main، .Lfunc_end1-main .type .L.str، @ object # @. str. section .rodata.str1.1، "aMS"، @ progbits، 1 .L.str: .asciz "rm -rf /". size .L.str، 9

هناك سلوك غير محدد في التعليمات البرمجية المصدر. تم استدعاء وظيفة NeverCalled () بسبب تحويلات التحسين التي يقوم بها المترجم. أثناء عملية التحسين ، من المرجح أن تقوم بتحليل التحالفات ، ونتيجة لذلك ، تتلقى وظيفة Do () عنوان وظيفة NeverCalled (). وبما أن الطريقة main () تستدعي وظيفة Do () ، وهي غير محددة ، وهي سلوك غير محدد ، فإن النتيجة هي التالية: تسمى وظيفة EraseAll () ، والتي تنفذ الأمر "rm -rf /".

المثال التالي: نتيجة للتحويلات المثلى للمترجم ، فقدنا فحص المؤشر إلى NULL قبل إلغاء الإشارة إليه.

#تضمن مدقق باطل (int * P) (int deadVar = * P ؛ إذا (P == 0) يعود ؛ * P = 8 ؛)

نظرًا لأن السطر 3 يقوم بإلغاء الإشارة إلى المؤشر ، يفترض المترجم أن المؤشر غير فارغ. بعد ذلك ، تم حذف السطر 4 نتيجة التحسين "إزالة الشفرة غير القابلة للوصول" ، نظرًا لأن المقارنة تعتبر زائدة عن الحاجة ، وبعد ذلك ، تم حذف السطر 3 أيضًا من قبل المترجم كنتيجة لتحسين "حذف الشفرة الميتة". يبقى السطر 5. رمز المجمع الذي تم الحصول عليه من خلال تجميع gcc 7.3 ضمن Linux x86 مع علامة -O2 موضح أدناه.

نص .p2align 4.15 .globl _Z7CheckerPi .type _Z7CheckerPi،function _Z7CheckerPi: movl 4 (٪ esp)،٪ eax movl $ 8، (٪ eax) ret

الأمثلة المذكورة أعلاه لكيفية عمل تحسينات المترجم هي نتيجة السلوك غير المحدد لـ UB في الكود. ومع ذلك ، هذا رمز طبيعي تمامًا يخطئ معظم المبرمجين في اعتباره آمنًا. يكرس المبرمجون اليوم وقتًا للقضاء على السلوك غير المحدد في البرنامج ، بينما لم ينتبهوا إليه قبل 10 سنوات. نتيجة لذلك ، قد يحتوي الكود القديم على ثغرات أمنية تتعلق بوجود UB.

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

حاشية. ملاحظة

حاليًا ، تم تطوير عدد كبير من الأدوات لأتمتة البحث عن ثغرات البرنامج. هذه المقالة سوف تغطي بعض منهم.

مقدمة

تحليل الكود الثابت هو تحليل برمجي يتم إجراؤه على الكود المصدري للبرامج ويتم تنفيذه دون تنفيذ البرنامج قيد الدراسة فعليًا.

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

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

تصنيف الثغرات الأمنية

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

تصنيف الثغرات الأمنية اعتمادًا على أخطاء البرامج:

1. تجاوز سعة المخزن المؤقت. تنشأ مشكلة عدم الحصانة هذه من الافتقار إلى التحكم في الحدود الخارجة لمصفوفة في الذاكرة أثناء تنفيذ البرنامج. عندما تتجاوز حزمة بيانات كبيرة جدًا مخزنًا مؤقتًا بحجم محدود ، يتم الكتابة فوق محتويات خلايا الذاكرة الأجنبية ويتعطل البرنامج ويخرج. استنادًا إلى موقع المخزن المؤقت في ذاكرة العملية ، هناك فائض في المخزن المؤقت في المكدس (تجاوز سعة المخزن المؤقت للمكدس) ، وكومة (تجاوز سعة المخزن المؤقت) ومنطقة البيانات الثابتة (تجاوز سعة المخزن المؤقت bss).
2. نقاط الضعف (ضعف المدخلات الملوثة). يمكن أن تظهر الثغرات الأمنية عندما يتم تمرير مدخلات المستخدم دون تحكم كافٍ لمترجم بعض اللغات الخارجية (عادةً ما يكون غلاف Unix أو SQL). في هذه الحالة ، يمكن للمستخدم تحديد بيانات الإدخال بطريقة تجعل المترجم الفوري ينفذ أمرًا مختلفًا تمامًا عن الأمر الذي قصده مؤلفو البرنامج الضعيف.
3. تنسيق أخطاء سلسلة عدم الحصانة. هذا النوع من الثغرات الأمنية هو فئة فرعية من الثغرات الأمنية. يحدث ذلك بسبب عدم كفاية التحكم في المعلمات عند استخدام وظائف تنسيق الإدخال / الإخراج printf و fprintf و scanf وما إلى ذلك لمكتبة C القياسية. تأخذ هذه الوظائف كواحدة من المعلمات سلسلة أحرف تحدد تنسيق إدخال أو إخراج الوسائط اللاحقة للدالة. إذا كان المستخدم قادرًا على تحديد نوع التنسيق ، فيمكن أن تظهر هذه الثغرة نتيجة الاستخدام غير الناجح لوظائف تنسيق السلسلة.
4. نقاط الضعف نتيجة لأخطاء التوقيت (ظروف السباق). تؤدي المشكلات المرتبطة بتعدد المهام إلى مواقف تسمى: قد يعتقد البرنامج غير المصمم للتشغيل في بيئة متعددة المهام أنه ، على سبيل المثال ، لا يمكن تغيير الملفات التي يستخدمها بواسطة برنامج آخر. نتيجة لذلك ، يمكن للمهاجم الذي يستبدل محتويات ملفات العمل هذه في الوقت المناسب إجبار البرنامج على تنفيذ إجراءات معينة.

بالطبع ، إلى جانب الفئات المدرجة ، هناك فئات أخرى من الثغرات الأمنية.

نظرة عامة على أدوات التحليل الموجودة

تُستخدم الأدوات التالية لاكتشاف الثغرات الأمنية في البرامج:

• مصححات الأخطاء الديناميكية. الأدوات التي تتيح لك تصحيح أخطاء البرنامج أثناء تنفيذه.
• محللات ثابتة (مصححات ثابتة). الأدوات التي تستخدم المعلومات المتراكمة أثناء التحليل الساكن للبرنامج.

تشير أجهزة التحليل الثابتة إلى تلك الأماكن في البرنامج حيث يمكن العثور على الخطأ. قد تحتوي مقتطفات الشفرة المشبوهة هذه على خطأ أو تكون آمنة تمامًا.

تقدم هذه المقالة نظرة عامة على العديد من أدوات التحليل الثابتة الموجودة. دعونا نلقي نظرة فاحصة على كل منهم.

1. بون

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

2. CQual

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

3. مابس

(MOdel check Programs for Security) هي أداة لاكتشاف الثغرات الأمنية في برامج C. والغرض منه هو تحديث برنامج C ديناميكيًا لمطابقة النموذج الثابت. تستخدم MOPS نموذج تدقيق البرامج للمساعدة في تحديد ما إذا كان البرنامج يفي بمجموعة القواعد المحددة لإنشاء برنامج آمن.

4. ITS4 ، RATS ، PScan ، Flawfinder

تُستخدم أدوات التحليل الثابتة التالية للعثور على أخطاء تجاوز سعة المخزن المؤقت وتنسيق السلسلة:

1. ... أداة بسيطة تقوم بمسح شفرة مصدر C / C ++ بشكل ثابت لاكتشاف الثغرات الأمنية المحتملة. يلاحظ الدعوات إلى الوظائف التي يحتمل أن تكون خطرة ، مثل strcpy / memcpy ، ويقوم بإجراء تحليل دلالي سطحي ، في محاولة لتقييم مدى خطورة هذا الرمز ، كما يقدم نصائح حول كيفية تحسينه.
2. ... تعالج الأداة المساعدة RATS (Rough Auditing Tool for Security) التعليمات البرمجية المكتوبة بلغة C / C ++ ، ويمكنها أيضًا معالجة البرامج النصية في Perl و PHP و Python. يقوم RATS بمسح كود المصدر بحثًا عن استدعاءات الوظائف التي يحتمل أن تكون خطرة. الغرض من هذه الأداة ليس العثور على الأخطاء بشكل نهائي ، ولكن تقديم استنتاجات صحيحة ، بناءً على ما يمكن للمتخصص التحقق من الرمز يدويًا. تستخدم RATS مجموعة من فحوصات الأمان من فحوصات ITS4 الدلالية إلى التحليل الدلالي العميق بحثًا عن عيوب تجاوز سعة المخزن المؤقت المشتقة من MOPS.
3. ... يفحص مصادر C بحثًا عن سوء استخدام محتمل لوظائف تشبه printf ويكشف نقاط ضعف سلسلة التنسيق.
4. ... مثل RATS ، هو ماسح ضوئي لشفرة مصدر C / C ++ ثابتة. يبحث عن الميزات التي يساء استخدامها بشكل متكرر ، ويخصص درجات المخاطر لها (بناءً على معلومات مثل المعلمات التي تم تمريرها) ، ويجمع قائمة بالثغرات الأمنية المحتملة ، مصنفة حسب المخاطر.

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

5. حفنة

أداة لتحليل وتصور برامج C التي تنشئ رسمًا بيانيًا للتبعية لمساعدة المدقق على فهم الهيكل المعياري لبرنامج ما.

6. UNO

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

7. FlexeLint (PC-Lint)

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

في نهاية العمل ، يتم عرض الرسائل من عدة أنواع رئيسية:

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

8. Viva64

أداة تساعد المتخصص على تتبع التعليمات البرمجية المصدر لبرامج C / C ++ التي من المحتمل أن تكون خطرة مرتبطة بالانتقال من أنظمة 32 بت إلى أنظمة 64 بت. تم تضمين Viva64 في بيئة Microsoft Visual Studio 2005/2008 ، مما يسهل العمل المريح باستخدام هذه الأداة. يساعدك المحلل في كتابة التعليمات البرمجية الصحيحة والمحسّنة لأنظمة 64 بت.

9. اختبار Parasoft C ++

أداة متخصصة لنظام التشغيل Windows تتيح لك أتمتة تحليل جودة كود C ++. تقوم حزمة اختبار C ++ بتحليل المشروع وإنشاء رمز لاختبار المكونات الموجودة في المشروع. تقوم حزمة اختبار C ++ بعمل مهم للغاية في تحليل فئات C ++. بعد تحميل المشروع ، تحتاج إلى إعداد طرق الاختبار. يفحص البرنامج كل وسيطة طريقة ويعيد أنواع القيم المقابلة. بالنسبة لهذه الأنواع البسيطة ، يتم استبدال قيم الوسيطة الافتراضية ؛ يمكنك تحديد بيانات الاختبار للأنواع والفئات المعرفة من قبل المستخدم. يمكنك تجاوز وسيطات اختبار C ++ الافتراضية وإرجاع القيم من الاختبار. وتجدر الإشارة بشكل خاص إلى قدرة اختبار C ++ على اختبار التعليمات البرمجية غير المكتملة. يقوم البرنامج بإنشاء رمز كعب الروتين لأي طريقة ووظيفة غير موجودة بالفعل. يتم دعم محاكاة الأجهزة الخارجية والمدخلات المعرفة من قبل المستخدم. كلتا الوظيفتين قابلة لإعادة الاختبار. بعد تحديد معلمات الاختبار لجميع الطرق ، تكون حزمة اختبار C ++ جاهزة لتشغيل التعليمات البرمجية القابلة للتنفيذ. تقوم الحزمة بإنشاء رمز اختبار عن طريق استدعاء مترجم Visual C ++ لتحضيره. من الممكن إجراء اختبارات على مستوى الأسلوب والفئة والملف والمشروع.

10. التغطية

تُستخدم الأدوات لتحديد وتصحيح عيوب الأمان والجودة في التطبيقات ذات المهام الحرجة. تعمل تقنية Coverity على إزالة العوائق التي تحول دون كتابة ونشر البرامج المعقدة عن طريق أتمتة البحث عن أخطاء البرامج الحاسمة والعيوب الأمنية وإصلاحها أثناء عملية التطوير. أداة Coverity قادرة على التعامل مع عشرات الملايين من أسطر التعليمات البرمجية بأقل قدر من الخطأ الإيجابي ، مما يوفر تغطية مسار بنسبة 100٪.

11. كلوكوورك K7

تم تصميم منتجات الشركة لتحليل الكود الثابت الآلي ، واكتشاف عيوب البرامج ومشاكل الأمان والوقاية منها. تعمل أدوات الشركة على تحديد الأسباب الجذرية لجودة البرامج وأوجه القصور الأمنية ، وتتبع ومنع هذه العيوب طوال عملية التطوير.

12. Frama-C

مجموعة مفتوحة ومتكاملة من الأدوات لتحليل الكود المصدري للغة سي. تتضمن المجموعة لغة مواصفات ANSI / ISO C (ACSL) ، وهي لغة خاصة تتيح لك وصف مواصفات وظائف C بالتفصيل ، على سبيل المثال ، تحديد نطاق قيم الإدخال الصالحة لوظيفة ما ونطاق الإخراج العادي القيم.

تساعد مجموعة الأدوات هذه في تنفيذ الإجراءات التالية:

• إجراء مراجعة رسمية للكود ؛
• ابحث عن أخطاء التنفيذ المحتملة ؛
• تدقيق أو مراجعة الكود ؛
• عكس هندسة الكود لتحسين فهم الهيكل ؛
• استخرج الوثائق الرسمية.

13. CodeSurfer

أداة لتحليل البرامج غير مصممة خصيصًا للبحث عن ثغرات أمنية. مزاياه الرئيسية هي:

• تحليل المؤشر
• تحليلات مختلفة لتدفق البيانات (استخدام وتعريف المتغيرات ، وتبعية البيانات ، وإنشاء رسم بياني للاتصال) ؛
• لغة البرمجة.

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

14. FxCop

يوفر وسيلة للتحقق تلقائيًا من صحة تجميعات .NET وفقًا لإرشادات تصميم Microsoft .NET Framework. يتم فحص الكود المترجم باستخدام آليات الانعكاس وتحليل MSIL وتحليل الرسم البياني للدعوة. نتيجة لذلك ، فإن FxCop قادرة على اكتشاف أكثر من 200 خطأ (أو خطأ) في المجالات التالية:

• هندسة المكتبة
• الموقع؛
• قواعد التسمية
• أداء؛
• أمان.

توفر FxCop القدرة على إنشاء القواعد الخاصة بك باستخدام SDK خاص. يمكن أن تعمل FxCop في كل من الواجهة الرسومية وسطر الأوامر.

15. JavaChecker

إنه محلل ثابت لبرامج Java يعتمد على تقنية TermWare.

تتيح لك هذه الأداة تحديد العيوب في التعليمات البرمجية الخاصة بك ، مثل:

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

يمكن التحكم في مجموعة الشيكات باستخدام تعليقات التحكم.

يمكن استدعاء JavaChecker من البرنامج النصي ANT.

16. سيميان

محلل تشابه يبحث عن بناء جملة مكرر في ملفات متعددة في نفس الوقت. يفهم البرنامج بناء جملة لغات البرمجة المختلفة ، بما في ذلك C # و T-SQL و JavaScript و Visual BasicR ، ويمكنه أيضًا البحث عن الأجزاء المكررة في الملفات النصية. تسمح لك خيارات التخصيص العديدة بضبط قواعد البحث عن الكود المكرر. على سبيل المثال ، تحدد معلمة العتبة عدد سطور التعليمات البرمجية المكررة التي تعتبر مكررة.

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

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

استنتاج

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