قد يجتاز تطبيق محلي للملاحظات اختبارات الوحدة (unit tests) بنجاح، بينما يحتوي في الوقت نفسه على ثغرتين أمنيتين. فعلى سبيل المثال، يقوم المسار GET /notes/:id بإرجاع الملاحظة رقم 42 كلما طلبها مستخدم مصادق عليه، حتى لو كانت هذه الملاحظة مملوكة لحساب آخر. وبشكل منفصل، يقبل التطبيق مصطلح بحث يصل إلى استعلام قاعدة البيانات دون معالجته بشكل آمن. وتوجد مشكلة ثالثة خارج الكود المخصص للمشروع (المستودع)، حيث يحتوي إصدار إحدى الحزم البرمجية (dependency) على تحذير أمني منشور. ولا يحتاج المهاجم سوى لحساب صالح بصلاحيات محدودة لاستغلال الثغرة الأولى، ونقطة نهاية HTTP متاحة للثغرة الثانية، بينما لا يتطلب الأمر الوصول إلى الكود المصدري لاستغلال مخاطر الحزم البرمجية الخارجية.
تكشف هذه الإخفاقات عن مساحة الهجوم (attack surface) الخاصة بالتطبيق، وهي تشمل كل مسار في الكود، وواجهة في بيئة التشغيل، وحدود للحزم البرمجية الخارجية، حيث يمكن للمدخلات غير الموثوقة أو السلوكيات التي يتحكم فيها المهاجم أن تؤثر على النظام. لا يتمثل سؤال المدافع (المسؤول عن الأمن) في تحديد أداة الفحص الأفضل بشكل عام؛ بل نحتاج إلى تحديد الأدلة التي يجب أن توفرها كل من: اختبار أمن التطبيقات الساكن (SAST)، واختبار أمن التطبيقات الديناميكي (DAST)، وتحليل تكوين البرمجيات (SCA) لنفس تطبيق الملاحظات، ثم استخدام تلك الأدلة لاتخاذ قرار بشأن إمكانية طرح التغييرات (النشر). إذ تكشف مستودعات الكود المصدري، وسلوكيات HTTP أثناء التشغيل، والحزم البرمجية الخارجية جوانب مختلفة من المخاطر.
يُعد طلب المسار /notes/42 أبسط مثال مفيد للمقارنة بين هذه الأساليب. يمكن لتحليل الكود المصدري تحديد شرط التفويض الذي يغفل مقارنة حساب المستخدم الطالب للمعلومة بحساب مالك الملاحظة. أما تحليل بيئة التشغيل فيمكنه إرسال طلب تجريبي مصادق عليه بصفتك مستخدماً معيناً، ومراقبة ما إذا كانت الاستجابة تكشف عن ملاحظة خاصة بمستخدم آخر. بينما يمكن لتحليل الحزم البرمجية فحص ملف تعريف الحزمة (manifest) دون الحاجة لاستدعاء الميزة المعرضة للخطر فعلياً. وتعتمد الأداة القادرة على إثبات كل حالة على موقع وجود الخلل أو الثغرة.
توضح حدود الثقة في تطبيق الملاحظات نقاط البداية والنهاية لكل نوع من أنواع الأدلة.
يوضح هذا الرسم البياني السبب في عدم قدرة أي أداة فحص واحدة على رصد مدخلات المتصفح، ومنطق التطبيق، واستدعاءات قاعدة البيانات، وحدود الحزم الخارجية بنفس المستوى من الدقة والشمولية.
نظراً لأن أدوات الرصد الثلاث تحتاج إلى هدف مشترك، تستخدم الدورة التدريبية مستودعاً واحداً يحتوي على تطبيق للملاحظات مُستضاف محلياً ومُصمَّم عمداً ليتضمن ثغرات أمنية. يقبل التطبيق معاملات HTTP وهياكل بيانات JSON عند حدود واجهة برمجة تطبيقات الويب (Web API)، ويستخدم هوية مُنشأة عبر مسار تسجيل الدخول المحلي، ويُعيد استجابات بتنسيق HTML أو JSON، كما يُجري عمليات قاعدة البيانات من خلال طبقة الوصول إلى البيانات الخاصة به. نحن نقوم بفحص هذا التطبيق المحلي والبيئات التي نتحكم فيها فقط؛ إذ يقع اختبار خدمات الأطراف الثالثة دون إذن كتابي خارج نطاق هذه الدورة، وقد ينتهك قوانين مثل “قانون الاحتيال وإساءة استخدام الحاسوب” (CFAA) في الولايات المتحدة أو “قانون إساءة استخدام الحاسوب لعام 1990” في المملكة المتحدة.
يتضمن المستودع سلوكين مُدرجين عمداً: الأول هو مسار بحث عرضة لهجمات الحقن (Injection)، وهو ما يمثل الثغرة المصنفة تحت الرمز CWE-89 (التحييد غير السليم للعناصر الخاصة المستخدمة في أوامر SQL). أما السلوك الثاني فهو خلل في التفويض على مستوى الكائن (Broken Object-Level Authorization) في المسار GET /notes/:id؛ وهي فئة الفشل التي تُصنفها قائمة OWASP لأهم 10 مخاطر أمنية في واجهات برمجة التطبيقات لعام 2023 تحت الرمز API1. كما يحدد ملف تعريف التبعيات (dependency manifest) حزمة برمجية قديمة عمداً وتحتوي على مشكلة أمنية معروفة. تظل هذه الحالات منفصلة عن بعضها لأن كلاً من الاكتشاف البرمجي (code finding)، والملاحظة المتعلقة ببروتوكول HTTP، والتحذير الأمني الخاص بالحزمة البرمجية، تمثل أدلة مختلفة لا يمكن استبدال أحدها بالآخر.
تُحدد لقطة المستودع (snapshot) مواقع المسارات، وآليات الوصول إلى البيانات، وتعريفات التبعيات، وذلك دون الحاجة إلى تنفيذ أي عملية فحص أو إرسال أي طلبات فعلية.