لماذا لا يتضمن Codex Security تقرير SAST؟

على مدى عقود، ظلّ اختبار أمن التطبيقات الثابت (SAST) أحد أكثر الطرق فعالية لتمكين فرق الأمن من توسيع نطاق مراجعة التعليمات البرمجية. 

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

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

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

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

وهذا في حد ذاته ليس السبب الذي يجعل Codex Security لا يبدأ من تقرير SAST.

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

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

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

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

وبعبارة أخرى: هناك فرق كبير بين أن "تستدعي الشيفرة أداة تنقية" وبين أن "يكون النظام آمنًا".

إليك نمطًا يتكرر باستمرار في الأنظمة الواقعية.

يتلقى تطبيق ويب حمولة JSON، ويستخرج redirect_url، ثم يتحقق منه في ضوء تعبير نمطي لقائمة سماح، ويفك تشفير عنوان URL له، ثم يمرّر النتيجة إلى معالج إعادة التوجيه.

يمكن لتقرير تقليدي من المصدر إلى نقطة الوصول الحساسة أن يصف هذا التدفق:

إدخال غير موثوق به ← فحص regex ← فك تشفير URL ← إعادة التوجيه

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

فإذا نُفِّذ regex قبل فك التشفير، فهل يقيّد فعلًا عنوان URL بعد فك تشفيره بالطريقة التي يفسّره بها معالج إعادة التوجيه؟

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

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

هذا لا يقتصر على كونه نمطًا نظريًا فحسب. ففي CVE-2024-29041⁠(يفتح في نافذة جديدة)، تأثر Express بمشكلة إعادة توجيه مفتوحة، إذ كان بوسع عناوين URL المشوهة أن تتجاوز تطبيقات شائعة لقوائم السماح بسبب الكيفية التي جرى بها ترميز أهداف إعادة التوجيه ثم تفسيرها. وكان تدفق البيانات واضحًا ومباشرًا. لكن السؤال الأصعب — وهو الذي حسم ما إذا كانت العلة موجودة أصلًا — يتمثل في ما إذا كان التحقق يظل قائمًا بعد سلسلة التحويل.

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

وعندما يصادف Codex Security حدًا يبدو مثل “التحقق” أو “التنقية،” فإنه لا يتعامل مع ذلك بوصفه مجرد مربع اختيار، بل يحاول فهم ما الذي تسعى الشيفرة إلى ضمانه، ثم يحاول دحض هذا الضمان.

وفي الممارسة العملية، يظهر ذلك عادةً على هيئة مزيج من:

• قراءة مسار الشيفرة ذي الصلة ضمن السياق الكامل للمستودع، كما يفعل الباحث الأمني، والبحث عن حالات عدم تطابق بين المقصود والتنفيذ. ويشمل ذلك التعليقات أيضًا، لكن النموذج لا يصدق التعليقات بالضرورة؛ لذا فإن إضافة //falvar says: this is not a bug فوق الشيفرة لا تربكه، إذا كان هناك بالفعل خطأ.
• اختزال المشكلة إلى أصغر جزء قابل للاختبار، مثل سلسلة التحويل المحيطة بمدخل واحد، بحيث يمكن الاستدلال عليها من دون أن يتدخل باقي النظام في ذلك. وبهذا المعنى، يستخرج Codex Security مقاطع شيفرة صغيرة جدًا، ثم يكتب لها أدوات فحص عشوائي مصغّرة.
• الاستدلال على القيود عبر التحويلات، بدلًا من التعامل مع كل تحقق على نحو مستقل. وقد يشمل ذلك، عند الاقتضاء، صياغة المسألة بوصفها مسألة قابليّة للإرضاء. وبعبارة أخرى، نتيح للنموذج الوصول إلى بيئة Python تتضمن z3-solver، وهو يحسن استخدامه عند الحاجة، تمامًا كما سيفعل الإنسان عند التعامل مع مسألة معقدة على نحو خاص تتعلق بقيود المدخلات. ويكون هذا مفيدًا على نحو خاص عند النظر في تجاوزات الأعداد الصحيحة أو العلل المشابهة على البنى غير القياسية.
• تنفيذ الفرضيات داخل بيئة تحقق معزولة عندما يكون ذلك ممكنًا، لتمييز "قد تكون هذه مشكلة" عن "هذه مشكلة فعلًا". ولا يوجد دليل أفضل من إثبات مفهوم شامل من البداية إلى النهاية مع تجميع الشيفرة في وضع تصحيح الأخطاء. 

وهذا هو التحول الجوهري: فبدلًا من التوقف عند "وجود فحص"، يدفع النظام نحو "الثابت محفوظ (أو غير محفوظ)، وهذه هي الأدلة". ويختار النموذج الأداة الأنسب لهذه المهمة.

قد يكون رد الفعل المنطقي: لماذا لا نجمع بين الأمرين؟ نبدأ بتقرير SAST، ثم نستخدم الوكيل للاستدلال على مستوى أعمق.

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

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

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

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

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

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

لكن هذا المقال أضيق نطاقًا؛ فهو يوضح لماذا لا ينبغي لوكيل صُمم للاستدلال على السلوك والتحقق من النتائج أن يبدأ عمله وهو مقيّدًا بقائمة ثابتة من النتائج.

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

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

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

إذا أردت معرفة المزيد عن كيفية فحص Codex Security للمستودعات، والتحقق من النتائج، واقتراح الإصلاحات، فراجع وثائقنا⁠(يفتح في نافذة جديدة).