> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # SAST: كيف يجد تحليل الكود الثابت الثغرات قبل التشغيل - URL: https://arabroot.io/articles/تحليل-الكود-الثابت-sast-مع-semgrep-و-sonarqube/ - Published: 2026-10-05T22:45:00.000Z - Updated: 2026-10-09T09:43:05.000Z - Description: كيف تقرأ أداة SAST الكود بحثاً عن الثغرات، وما الذي لا تراه أبداً، وكيف تمنع الإنذارات الخاطئة من أن تفقد الفريق ثقته بها. - Author: فريق عرب رووت - Tags: الأدلة التقنية, DevOps والتشغيل, DevOps وCI/CD, الاستضافة الذاتية في دليل [DevSecOps للمبتدئين](https://arabroot.io/articles/devsecops-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-sast-%D9%88-dast-%D9%88-sca/) رأيت أن الفحص الثابت للكود SAST وجد حقن SQL وXSS في تطبيقنا التجريبي خلال ثوان، ورأيت معه أول إنذار خاطئ False Positive، وأن الأداة لم تر مفتاح API مكتوباً في الكود نفسه. وفي هذا المقال سوف ننزل طبقة أعمق، فالسؤال هنا ليس «هل نشغل أداة SAST؟» وإنما كيف تقرأ هذه الأداة الكود أصلاً، ولماذا تجد ثغرة في سطر وتفوتها في السطر الذي يليه، ولماذا يتوقف الفريق عن قراءة نتائجها بعد شهر إذا لم يضبطها أحد، وما الأداة المناسبة لمشروعك إذا كان بلغة Python أو Java أو C#. وسوف نناقش في هذا المقال ما يلي: - لماذا لا تكفي مراجعة الكود Code Review والبحث النصي grep لاكتشاف الثغرات، وما الذي يضيفه الفحص الثابت. - كيف تعمل أداة SAST من الداخل: تحويل الكود إلى شجرة AST، ومطابقة الأنماط Pattern Matching، وتتبع البيانات الملوثة Taint Analysis من المصدر Source مروراً بالمنظف Sanitizer إلى المكان الخطر Sink، وحدود التحليل بين الدوال Inter-procedural. - ما الذي لا تراه أداة SAST أبداً، والدقة Precision والشمول Recall، ولماذا تقتل الإنذارات الخاطئة الأداة في الفريق. - Semgrep CE وSonarQube Community Build وCodeQL بتراخيصها وشروطها الحقيقية، وجدول أدوات لكل لغة، مع اهتمام خاص بأدوات Java وC#. - تجربة عملية على التطبيق التجريبي: نتائج حقيقية، وإنذار خاطئ نتجاهله بالطريقة الصحيحة، وقاعدة Semgrep نكتبها لنمط خاص بتطبيقنا، ومقارنة مع Bandit، وإصلاح ثغرة ورؤية النتيجة تختفي، والخط الأساسي Baseline، ومخرج SARIF، وSonarQube مع بوابة الجودة Quality Gate، ثم SpotBugs مع FindSecBugs على Java، ومحللات Roslyn على C#. - تشغيل الفحص في خط CI: الفحص التزايدي على طلب الدمج مقابل الفحص الكامل، والكود القديم، وكيف تعرض منصات الكود نتائج SARIF. ## لماذا نحتاج أداة تقرأ الكود بحثاً عن الثغرات Vulnerabilities؟ ### مراجعة الكود Code Review وحدها الطريقة الأولى التي تعتمد عليها أغلب الفرق هي مراجعة الكود في طلب الدمج Pull Request، فيقرأ زميل التغيير ويعلق عليه قبل الدمج. وهذه المراجعة مهمة جداً لكنها تفشل في اكتشاف الثغرات لأسباب واضحة، فالمراجع يقرأ الفرق Diff وليس الملف كاملاً، فإذا كانت القيمة تأتي من المستخدم في دالة لم تتغير وتصل إلى استعلام SQL في الدالة التي تغيرت فلن يرى إلا نصف القصة، وهو يركز عادة على المنطق والتسمية والتصميم، ومع طلب دمج فيه ستمائة سطر في نهاية يوم طويل فإن سطراً واحداً يبني استعلاماً بـ f-string يمر بسهولة. ### البحث النصي grep عن الدوال الخطرة والحل الثاني الذي يخطر على البال هو أن تبحث في الكود عن الكلمات الخطرة، مثل `execute(` و`shell=True` و`eval(`، وهذا أفضل لأنه آلي ويمر على كل الملفات، لكنه يفشل من الجهتين، فهو يجد كل استدعاء ل `execute` بما فيها الاستعلامات الآمنة التي تستخدم المعاملات Parameters، فتغرق في النتائج، ولا يعرف شيئاً عن الكود نفسه، فإذا كتب أحدهم `run = db().execute` ثم `run(sql)` لم يجده، ولا يعرف إن كانت القيمة داخل الاستعلام ثابتة أم قادمة من المستخدم. ### الفحص الثابت SAST: أداة تفهم بنية الكود Code Structure الحل الأنسب هو أداة تقرأ الكود كما يقرأه المترجم Compiler، أي أنها تفهم أن هذا استدعاء دالة وأن هذه القيمة جاءت من `request.args` ثم مرت في هذا المتغير ثم وصلت إلى ذلك الاستعلام، وهذا هو الفحص الثابت لأمان التطبيقات Static Application Security Testing واختصاراً SAST. والكلمة المهمة هنا «الثابت Static»، أي أن الأداة لا تشغل التطبيق أبداً، فلا تحتاج سيرفراً ولا قاعدة بيانات ولا متصفحاً، وإنما تقرأ الملفات فقط، لذلك تعمل في ثوان على جهاز المطور وفي كل طلب دمج، وتشير إلى الملف والسطر قبل أن يصل الكود إلى أي بيئة. وعكسها الفحص أثناء التشغيل DAST الذي شرحناه في [فحص التطبيق أثناء التشغيل DAST مع ZAP](https://arabroot.io/articles/%D9%81%D8%AD%D8%B5-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82-%D8%A7%D8%AB%D9%86%D8%A7%D8%A1-%D8%A7%D9%84%D8%AA%D8%B4%D8%BA%D9%8A%D9%84-dast-%D9%85%D8%B9-zap/)، والذي يهاجم التطبيق وهو يعمل من الخارج دون أن يرى الكود. ## كيف تعمل أداة SAST من الداخل؟ الصورة التالية تبين الطريق الذي يقطعه ملف واحد داخل أداة SAST، من النص المكتوب إلى نتيجة برقم السطر: ![مخطط من خمس خطوات: ملف app.py فيه request.args وexecute، ثم Parser، ثم شجرة AST فيها Call execute وتحتها Attribute وf-string والمتغير q باللون الأحمر، ثم محركان: Pattern matching يطابق الشكل وData flow يتتبع المصدر إلى المكان الخطر، ثم Findings برقم السطر وصيغ text وJSON وSARIF](https://arabroot.io/content/images/2026/10/sast-01-how-sast-works.webp) الأداة لا تشغل الكود، وإنما تحوله إلى شجرة ثم تبحث فيها بالقواعد ### تحويل الكود إلى شجرة AST بالتحليل النحوي Parsing الخطوة الأولى هي التحليل النحوي Parsing، فالأداة تملك محللاً Parser لكل لغة تدعمها، يحول النص إلى شجرة البنية المجردة Abstract Syntax Tree واختصاراً AST، وهي الشجرة نفسها التي يبنيها المترجم قبل أن يحول الكود إلى برنامج. ففي الشجرة لا يوجد شيء اسمه «سطر فيه كلمة execute»، وإنما يوجد عقدة استدعاء Call، دالتها `db().execute`، ومعاملها الأول نص منسق f-string فيه جزء ثابت هو `SELECT ...` وجزء متغير هو `q`. وهذا ما يجعل الأداة لا تهتم بالمسافات والتعليقات وأسماء المتغيرات، فالكود `db().execute(f"...{q}")` والكود نفسه مقسماً على خمسة أسطر لهما الشجرة نفسها. ويجدر الانتباه هنا إلى أن بعض الأدوات تحتاج أكثر من الشجرة، فأدوات Java وC# الكبيرة تحتاج أن يبنى المشروع Build حتى تعرف نوع كل متغير والمكتبة التي جاء منها كل كلاس، فـ SpotBugs مثلاً يقرأ ملفات ال bytecode بعد الترجمة وليس ملفات `.java`، ومحللات Roslyn تعمل داخل المترجم نفسه أثناء `dotnet build`، بينما Semgrep يكتفي بالملفات كما هي ولا يحتاج إلى بناء المشروع، وهذا يجعله أسرع وأسهل في الإعداد، وأقل معرفة بالأنواع Types في الوقت نفسه. ### مطابقة الأنماط Pattern Matching أبسط نوع من القواعد هو مطابقة الأنماط، أي أن القاعدة تصف شكل الكود الخطر، مثل «أي استدعاء ل `$DB.execute(...)` معامله الأول نص منسق»، والأداة تبحث في الشجرة عن كل عقدة بهذا الشكل. وهذه القواعد سريعة وسهلة الكتابة، وتجد الثغرة حتى لو كانت القيمة قادمة من دالة أخرى، لكنها لا تعرف من أين جاءت القيمة داخل النص، فتبلغ عن الاستعلام الذي يبنى من قائمة ثابتة كما تبلغ عن الاستعلام الذي يبنى من مدخلات المستخدم، وهنا يبدأ الإنذار الخاطئ كما سوف ترى في التجربة. ### تتبع البيانات الملوثة Taint Analysis النوع الأذكى هو تحليل تدفق البيانات Data Flow Analysis، وأشهر صوره تتبع البيانات الملوثة Taint Analysis. والفكرة أن القاعدة تعرف ثلاثة أشياء: - **المصدر Source:** المكان الذي تدخل منه بيانات لا تثق بها، مثل `request.args` و`request.form` في Flask، أو معامل دالة Controller في ASP.NET Core، أو `HttpServletRequest.getParameter` في Java. - **المكان الخطر Sink:** الدالة التي يصبح فيها هذا المدخل خطراً، مثل `execute` لقاعدة البيانات، و`subprocess.run` مع `shell=True`، و`redirect`، ودالة تكتب HTML. - **المنظف Sanitizer:** الدالة التي تجعل القيمة آمنة لهذا المكان بالتحديد، مثل `markupsafe.escape` قبل HTML، أو المعامل `?` بدل دمج النص في SQL. ثم تعلم الأداة كل قيمة تخرج من المصدر بأنها «ملوثة Tainted»، وتتبعها عبر الإسناد إلى متغير آخر وبناء النصوص واستدعاء الدوال، فإذا وصلت إلى المكان الخطر دون أن تمر بمنظف أبلغت عنها. والصورة التالية تبين المسارين: ![مسارين: في الأول يخرج request.args من مستخدم أحمر ويمر عبر q وf-string ويصل إلى db().execute دون شيء في الطريق فتظهر علامة finding حمراء، وفي الثاني يمر عبر درع أخضر مكتوب تحته escape(q) أو ? param فيصل إلى db().execute وتظهر علامة quiet خضراء، وتحتهما أمثلة لأماكن خطرة أخرى: PAGE.format للـ XSS وredirect وsubprocess.run](https://arabroot.io/content/images/2026/10/sast-02-taint.webp) المصدر Source والمنظف Sanitizer والمكان الخطر Sink، والأداة تعرفها من القواعد فقط لاحظ الجملة الأخيرة في الصورة، فالأداة لا تعرف أن الدالة `clean_input()` التي كتبها زميلك قبل سنتين منظف، ولا تعرف أن `PAGE` في تطبيقنا قالب HTML خام، إلا إذا أخبرتها القاعدة بذلك، وهذا هو سبب أهمية القواعد المخصصة Custom Rules التي سوف نكتب واحدة منها في التجربة. ### حدود التحليل بين الدوال Inter-procedural وقد يتساءل البعض: إذا كانت الأداة تتبع القيمة، فلماذا لا تتبعها دائماً حتى النهاية؟ والإجابة أن تتبع القيمة داخل دالة واحدة Intra-procedural رخيص، أما تتبعها عبر كل استدعاء لكل دالة في كل ملف Inter-procedural فيكلف وقتاً وذاكرة تزيد بسرعة مع حجم المشروع، لذلك تتوقف كل أداة في مكان ما. ويذكر جدول [مقارنة Semgrep CE مع Semgrep Code](https://docs.semgrep.dev/semgrep-pro-vs-oss?ref=arabroot.io) أن النسخة المجتمعية تقوم بتحليل التلوث داخل الدالة الواحدة Single function taint analysis، أما التحليل عبر الدوال والملفات فهو في النسخة التجارية، وصفحة القاعدة [CA3001 من Microsoft](https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca3001?ref=arabroot.io) تقول إن القاعدة لا تتتبع البيانات بين ال Assemblies، وإن لعمق التتبع بين الدوال حداً يمكن ضبطه. ولنأخذ مثالاً صغيراً نقسم فيه ثغرة SQL على دالتين، فالمصدر في دالة المسار والمكان الخطر في دالة مساعدة: ```python import sqlite3 from flask import Flask, request app = Flask(__name__) def find_products(term): conn = sqlite3.connect("/tmp/shop.db") return conn.execute(f"SELECT name FROM products WHERE name LIKE '%{term}%'").fetchall() @app.route("/search2") def search2(): return {"rows": find_products(request.args.get("q", ""))} ``` الآن نفحص الملف بقواعد Flask فقط، وهي قواعد تتبع التلوث: ```bash docker run --rm -v "$PWD:/src" semgrep/semgrep:1.178.0 \ semgrep scan --config p/flask --metrics=off . ``` والمخرج سوف يكون كما يلي: ```text ✅ Scan completed successfully. • Findings: 0 (0 blocking) • Rules run: 18 • Targets scanned: 1 • Parsed lines: ~100.0% • No ignore information available Ran 18 rules on 1 file: 0 findings. ``` صفر نتائج، والثغرة موجودة. ثم نفحص الملف نفسه بالمجموعة الافتراضية `p/default` التي تضم قواعد أنماط أيضاً: ```text ┌─────────────────┐ │ 2 Code Findings │ └─────────────────┘ helper.py ❯❱ python.lang.security.audit.formatted-sql-query.formatted-sql-query ❰❰ Blocking ❱❱ Detected possible formatted SQL query. Use parameterized queries instead. Details: https://sg.run/EkWw 10┆ return conn.execute(f"SELECT name FROM products WHERE name LIKE '%{term}%'").fetchall() ❯❯❱ python.sqlalchemy.security.sqlalchemy-execute-raw-query.sqlalchemy-execute-raw-query ❰❰ Blocking ❱❱ Avoiding SQL string concatenation: untrusted input concatenated with raw SQL query can result in SQL Injection. In order to execute raw query safely, prepared statement should be used. SQLAlchemy provides TextualSQL to easily used prepared statement with named parameters. For complex SQL composition, use SQL Expression Language or Schema Definition Language. In most cases, SQLAlchemy ORM will be a better option. Details: https://sg.run/2b1L 10┆ return conn.execute(f"SELECT name FROM products WHERE name LIKE '%{term}%'").fetchall() ``` في المخرج أعلاه لاحظ التالي: - قاعدة Flask التي تتبع التلوث `tainted-sql-string` لم تجد شيئاً، لأن المصدر في `search2` والمكان الخطر في `find_products`، والتحليل في النسخة المجتمعية يتوقف عند حدود الدالة، وهذا إنذار مفقود False Negative. - القاعدتان اللتان وجدتا الثغرة قاعدتا أنماط، فهما تريان «نص منسق داخل execute» ولا تعرفان أن `term` قادم من المستخدم، وهما نفسهما سوف تبلغان عن استعلام آمن في التجربة بعد قليل. - Bandit أيضاً وجد هذا السطر بالقاعدة `B608`، وهي قاعدة أنماط كذلك، كما سوف ترى في المقارنة. والصورة التالية تلخص ما حدث، ومن يستطيع تتبع القيمة عبر الاستدعاء: ![كود من دالتين: search2 فيها request.args.get ومكتوب تحتها Source here، وfind_products فيها conn.execute مع f-string ومكتوب تحتها Sink here، وسهم call بينهما، وعلى اليمين ثلاث نتائج: Taint inside one function بعلامة حمراء لأن Semgrep CE وجد صفر نتائج، وPattern on the sink line بعلامة صفراء لأن formatted-sql-query وBandit B608 وجدا السطر، وTaint across functions بعلامة خضراء لـ CodeQL وRoslyn CA3001 والمحركات التجارية](https://arabroot.io/content/images/2026/10/sast-03-functions.webp) التحليل داخل الدالة يفقد القيمة عند الاستدعاء، وقاعدة النمط تراها دون أن تعرف مصدرها والدرس هنا عملي، فلا تحكم على أداة من عدد النتائج في مثال صغير، وإنما اسأل: هل تتبع القيمة بين الدوال؟ وبين الملفات؟ وإلى أي عمق؟ فالمشروع الحقيقي يقرأ المدخل في Controller ويمرره إلى Service ثم إلى Repository، أي ثلاث دوال في ثلاثة ملفات، وهذا هو المكان الذي تختلف فيه الأدوات فعلاً. ## ما الذي لا تراه أداة SAST أبداً؟ هناك أشياء لا تراها أي أداة SAST مهما كانت قوية، والسبب أنها ليست في الكود أصلاً، أو أنها في الكود لكن الخطأ فيها يعتمد على معنى لا تعرفه الأداة. والصورة التالية تبين ما تراه الأداة وما يقع خارج نظرها، والفحص الذي يغطي كل جزء: ![على اليسار لوحة خضراء Inside the repository فيها ملفات وعدسة وقائمة بما تراه الأداة: SQL وأوامر من نصوص، ومدخلات تصل إلى HTML وredirect، ومفاتيح مكتوبة في الكود، وتشفير ضعيف، وshell=True، والملف والسطر، وعلى اليمين خمس بطاقات خارج نظرها: Runtime configuration مع DAST، وAuthorization logic مع الاختبارات والمراجعة، وBusiness logic مع نمذجة التهديدات، وLibraries مع SCA، وDocker Image والسيرفر مع فحص الحاويات](https://arabroot.io/content/images/2026/10/sast-04-blind-spots.webp) أداة SAST ترى المستودع فقط، ولكل منطقة خارجه فحص آخر - **الإعداد وقت التشغيل Runtime Configuration:** متغير البيئة `DEBUG=1` على سيرفر الإنتاج Production، وترويسات الأمان التي يضيفها ال Reverse Proxy، وإعداد TLS، فكلها خارج المستودع أو تتغير بعد النشر، لذلك يكشفها الفحص أثناء التشغيل وفحص الإعدادات، وقد ناقشنا الترويسات في [ترويسات الأمان HSTS وCSP](https://arabroot.io/articles/%D8%AA%D8%B1%D9%88%D9%8A%D8%B3%D8%A7%D8%AA-%D8%A7%D9%84%D8%A3%D9%85%D8%A7%D9%86-hsts-%D9%88-csp/). - **منطق الصلاحيات Authorization Logic:** إذا فتح المستخدم B الرابط `/orders/17` الخاص بالمستخدم A وظهر له الطلب، فهذه ثغرة خطيرة، لكن الكود «صحيح» من وجهة نظر الأداة، فهو يقرأ رقماً ويجلب سطراً من قاعدة البيانات بمعامل آمن، والأداة لا تعرف من يملك الطلب رقم 17، لذلك يكشف هذا النوع اختبار يكتبه الفريق «مستخدم لا يرى بيانات غيره» ومراجعة تصميم الصلاحيات، وقد شرحنا نماذجها في [الصلاحيات المركزية Authorization](https://arabroot.io/articles/%D8%A7%D9%84%D8%B5%D9%84%D8%A7%D8%AD%D9%8A%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%B1%D9%83%D8%B2%D9%8A%D8%A9-authorization-rbac-%D9%88-rebac/). - **منطق العمل Business Logic:** كوبون خصم يستخدم مرتين، أو كمية سالبة تجعل السعر سالباً، أو خطوة دفع يمكن تخطيها، وكلها أخطاء في المعنى وليس في الشكل، ومكانها [نمذجة التهديدات Threat Modeling](https://arabroot.io/articles/%D9%86%D9%85%D8%B0%D8%AC%D8%A9-%D8%A7%D9%84%D8%AA%D9%87%D8%AF%D9%8A%D8%AF%D8%A7%D8%AA-threat-modeling-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/) قبل الكتابة والاختبارات بعدها. - **المكتبات التي لم تكتبها:** Flask 2.2.2 في تطبيقنا فيه ثغرات منشورة، لكن الكود الضعيف في مجلد المكتبات وليس في مستودعك، ومكانه فحص الاعتماديات SCA في [فحص الاعتماديات مع OSV-Scanner وDependency-Track](https://arabroot.io/articles/%D9%81%D8%AD%D8%B5-%D8%A7%D9%84%D8%A7%D8%B9%D8%AA%D9%85%D8%A7%D8%AF%D9%8A%D8%A7%D8%AA-sca-%D9%85%D8%B9-osv-scanner-%D9%88-dependency-track/). - **ال Docker Image والسيرفر:** حزم نظام التشغيل القديمة والمنافذ المفتوحة، ومكانها [فحص الحاويات والبنية ككود مع Trivy](https://arabroot.io/articles/%D9%81%D8%AD%D8%B5-%D8%A7%D9%84%D8%AD%D8%A7%D9%88%D9%8A%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D8%A8%D9%86%D9%8A%D8%A9-%D9%83%D9%83%D9%88%D8%AF-%D9%85%D8%B9-trivy/). لذلك لا تقم بقراءة تقرير SAST نظيف على أنه «التطبيق آمن»، والسبب أن التقرير يقول شيئاً واحداً فقط، وهو أن الأنماط التي تعرفها القواعد لم تظهر في الكود الذي قرأته الأداة. ## الدقة Precision والشمول Recall، ولماذا تقتل الإنذارات الخاطئة الأداة كل أداة فحص تقع بين هدفين متعارضين. الأول هو الشمول Recall، أي نسبة الثغرات الحقيقية التي وجدتها الأداة من كل الثغرات الموجودة، والثاني هو الدقة Precision، أي نسبة التنبيهات الصحيحة من كل التنبيهات التي أطلقتها. والصورة التالية مثال توضيحي لأداتين على الكود نفسه، وفيه عشر ثغرات حقيقية بين ستين موضعاً: ![لوحتان من النقاط: في Tool A الصاخبة 40 حلقة تنبيه تحيط بكل الثغرات العشر الحمراء و30 نقطة رمادية آمنة، فالدقة 25% والشمول 100%، وفي Tool B الهادئة 7 حلقات تحيط بست ثغرات ونقطة آمنة واحدة، فالدقة 86% والشمول 60%](https://arabroot.io/content/images/2026/10/sast-05-precision-recall.webp) مثال توضيحي: الأداة الصاخبة تجد كل شيء ولا يقرؤها أحد، والهادئة يقرأ الفريق كل تنبيه منها والمعادلتان بسيطتان، فالدقة هي عدد التنبيهات الصحيحة True Positives مقسوماً على كل التنبيهات، والشمول هو عدد التنبيهات الصحيحة مقسوماً على كل الثغرات الحقيقية، أي الصحيحة مع المفقودة False Negatives. وقد تبدو الأداة A أفضل لأنها لم تفوت شيئاً، لكن في الواقع فهي غير كذلك، فالمطور الذي يفتح طلب دمج ويجد أربعين تنبيهاً، ويكتشف أن أول عشرة منها خاطئة، سوف يتوقف عن القراءة ويضغط «تجاهل الكل»، وبهذا تصبح الثغرات العشر الحقيقية مدفونة بين التنبيهات، وتصبح الدقة الفعلية للأداة صفراً لأن أحداً لا يقرؤها. أما الأداة B فقد فوتت أربع ثغرات، لكن كل تنبيه منها يقرأ ويصلح، والثغرات الأربع يمكن أن تكشفها طبقة أخرى من الفحص أو قاعدة إضافية في المستقبل. لذلك فالقاعدة العملية هي: ابدأ بقواعد عالية الدقة تمنع الدمج، واجعل القواعد الصاخبة في وضع التنبيه فقط أو في الفحص الليلي، ولا تقم بتفعيل كل القواعد المتاحة في اليوم الأول، والسبب أن ثقة الفريق في الأداة تبنى ببطء وتضيع بسرعة. وقد ذكرنا في [قسم الإنذارات الخاطئة في دليل DevSecOps](https://arabroot.io/articles/devsecops-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-sast-%D9%88-dast-%D9%88-sca/#false-positives) كيف يتعامل الفريق مع النتيجة الخاطئة، وفي التجربة سوف نطبق ذلك على نتيجة حقيقية. ## الأدوات Tools بين المحركات العامة وأدوات كل لغة تنقسم أدوات SAST مفتوحة المصدر إلى محركات عامة تدعم لغات كثيرة بقواعد قابلة للكتابة، وأدوات خاصة بلغة واحدة تعرفها بعمق. وقبل الجدول نتوقف عند الثلاثة الكبار، لأن تراخيصها وشروطها فيها تفاصيل يجب أن تعرفها قبل أن تبني عليها خط CI. ### Semgrep CE: المحرك Engine مفتوح والقواعد Rules لها ترخيص آخر [Semgrep](https://github.com/semgrep/semgrep?ref=arabroot.io) محرك يكتب قواعده بلغة قريبة من الكود نفسه، فالقاعدة `$DB.execute(f"...")` تشبه الكود الذي تبحث عنه، وهذا ما يجعل كتابة القواعد المخصصة سهلة لأي مطور. وتنص [صفحة التراخيص الرسمية](https://docs.semgrep.dev/licensing?ref=arabroot.io) على أن المحرك المجتمعي Semgrep CE مفتوح المصدر بترخيص LGPL-2.1، أما القواعد التي تكتبها الشركة وتنشرها في السجل Registry فلها ترخيص منفصل اسمه Semgrep Rules License v1.0، يسمح للأفراد والشركات باستخدامها داخلياً، ويمنع استخدامها في منتج أو خدمة SaaS منافسة. وفي النسخة المجتمعية التحليل داخل الملف الواحد والدالة الواحدة كما رأيت، والتحليل عبر الملفات في المنتج التجاري Semgrep Code. ويجدر الانتباه إلى أمرين عمليين. الأول أن Semgrep يرسل افتراضياً إحصاءات استخدام Metrics عند تحميل القواعد من السجل، وتؤكد [صفحة الإحصاءات](https://docs.semgrep.dev/metrics?ref=arabroot.io) أن الكود المصدري لا يرسل أبداً، لكن مع مشروع خاص في خط CI فالأنسب أن تضيف `--metrics=off`، وهنا تظهر المشكلة الثانية، فالخيار `--config auto` الذي يختار القواعد حسب لغات مشروعك لا يعمل مع إيقاف الإحصاءات، وهذا ما رأيناه في التجربة: ```text [00.30][ERROR]: Cannot create auto config when metrics are off. Please allow metrics or run with a specific config. ``` لذلك استخدم `--config auto` للاستكشاف الأول على جهازك، وفي خط CI اختر مجموعة قواعد محددة مثل `p/default` أو `p/python` مع `--metrics=off`، وهذا أفضل أيضاً لأن النتائج تصبح قابلة للتكرار. وهناك أيضاً [Opengrep](https://github.com/opengrep/opengrep?ref=arabroot.io)، وهو نسخة منفصلة Fork من Semgrep بترخيص LGPL-2.1، أنشأها تحالف من شركات أمن بعد أن نقلت Semgrep بعض الميزات إلى الترخيص التجاري، ويقول ملف README الخاص به إنه متوافق مع قواعد Semgrep ويضيف تتبعاً للتلوث بين الدوال داخل الملف الواحد بالخيار `--taint-intrafile`، ولم نختبره في هذا المقال. ### SonarQube Community Build: الجودة Quality والأمان Security في لوحة واحدة [SonarQube](https://github.com/SonarSource/sonarqube?ref=arabroot.io) سيرفر يجمع نتائج تحليل الكود في لوحة واحدة، الأخطاء Bugs ورائحة الكود Code Smells والتكرار والتغطية والأمان، ونسخته المجانية اسمها اليوم Community Build، وكانت تسمى سابقاً Community Edition، وترخيصها LGPL-3.0 كما في ملف LICENSE في المستودع. وأهم فكرة فيه هي بوابة الجودة Quality Gate، وهي شروط يجب أن ينجح فيها التحليل، والبوابة الافتراضية اسمها Sonar way، وتذكر [صفحة بوابات الجودة](https://docs.sonarsource.com/sonarqube-community-build/quality-standards-administration/managing-quality-gates/introduction-to-quality-gates?ref=arabroot.io) أنها تطبق شروطها على الكود الجديد New Code فقط: لا توجد مشاكل جديدة، وكل نقاط الأمان الحساسة الجديدة تمت مراجعتها، وتغطية الاختبارات للكود الجديد 80% على الأقل، والتكرار فيه 3% على الأكثر. وهذه الفكرة، أي أن تحكم على الكود الجديد فقط، هي نفسها فكرة الخط الأساسي Baseline التي سوف نعود إليها. وهناك ثلاثة أمور يجب أن تعرفها عن النسخة المجانية قبل أن تعتمد عليها في الأمان: - تذكر [مقارنة النسخ في مدونة Sonar](https://www.sonarsource.com/blog/sonarqube-compare-editions/?ref=arabroot.io) أن Community Build لا تحتوي على تحليل الفروع Branches وطلبات الدمج Pull Requests، أي أنها تحلل فرعاً رئيسياً واحداً، ولا تحتوي على تحليل التلوث Taint Analysis، وهو المسؤول عن قواعد الحقن مثل SQL Injection وCommand Injection في النسخ التجارية، وتعالج تحليلاً واحداً في الوقت نفسه. - نقاط الأمان الحساسة Security Hotspots كانت نوعاً خاصاً من النتائج في SonarQube، وهي كود حساس يحتاج مراجعة إنسان ليقرر إن كان آمناً، بحالات «للمراجعة To review» و«تم الإقرار Acknowledged» و«تم الإصلاح Fixed» و«آمن Safe»، بينما الثغرة Vulnerability مشكلة يجب إصلاحها. لكن Sonar أعلنت في [مارس 2026](https://community.sonarsource.com/t/moving-security-hotspots-to-security-issues/180583?ref=arabroot.io) أنها تعيد كتابة كل قواعد ال Hotspots كمشاكل أمان عادية Security Issues، وأن واجهاتها البرمجية سوف تحذف لاحقاً، وفي النسخة التي شغلناها 26.9 لم نجد أي قاعدة من نوع Hotspot، وظهرت قاعدة مثل «SECRET\_KEY مكتوب في الكود» كثغرة Vulnerability، وبعضها يحمل الوسم `former-hotspot`، وصفحة Security Hotspots في الواجهة عليها كلمة Deprecated كما سوف ترى في الصورة. - قاعدة البيانات المدمجة في ال Docker Image للتجربة فقط، والواجهة نفسها تحذر من ذلك، وللاستخدام الحقيقي تحتاج PostgreSQL. ### CodeQL: الكود كقاعدة بيانات Database، وشروط استخدام Terms of Use يجب قراءتها CodeQL من GitHub يعامل الكود كبيانات، فيبني من المشروع قاعدة بيانات CodeQL Database فيها الشجرة وتدفق البيانات والأنواع، ثم تشغل عليها استعلامات بلغة QL تشبه SQL، كما تشرح [صفحة Code Scanning](https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning?ref=arabroot.io). وهو من أقوى الأدوات في التحليل بين الدوال والملفات، ويدعم C وC++ وC# وGo وJava وKotlin وJavaScript وTypeScript وPython وRuby وRust وSwift. لكن هنا تفصيل في الترخيص يقع فيه كثيرون: - الاستعلامات والمكتبات في مستودع [github/codeql](https://github.com/github/codeql?ref=arabroot.io) بترخيص MIT، أي أنها مفتوحة المصدر. - أما أداة CodeQL CLI نفسها، أي البرنامج الذي يبني قاعدة البيانات ويشغل الاستعلامات، فلها [شروط GitHub CodeQL](https://github.com/github/codeql-cli-binaries/blob/main/LICENSE.md?ref=arabroot.io)، وهي تسمح باستخدامها للبحث الأكاديمي وللعرض التوضيحي، وعلى الكود المنشور بترخيص مفتوح المصدر معتمد من OSI فقط، وتسمح ببناء قواعد البيانات في خط CI آلي فقط للمشاريع مفتوحة المصدر المستضافة على GitHub.com، وتمنع صراحة استخدامها مع كود ليس مفتوح المصدر. - ولاستخدامها على مستودع خاص في GitHub تحتاج ترخيص GitHub Code Security، كما تذكر صفحة Code Scanning نفسها. لذلك إذا كان كود شركتك خاصاً ومستضافاً على Gitea أو GitLab على سيرفرك، فلا تقم بتشغيل CodeQL CLI عليه في خط CI، والسبب أن الشروط تمنع ذلك صراحة حتى لو كانت الأداة متاحة للتحميل، والخيار المفتوح لهذه الحالة هو Semgrep CE أو Opengrep مع SonarQube Community Build وأدوات اللغة. ### جدول الأدوات لكل لغة Per-language Tools بالإضافة إلى المحركات العامة، لكل لغة أدوات تعرفها بعمق، وهي غالباً أسهل في الإضافة لأنها تعمل كإضافة لأداة البناء نفسها. والجدول التالي يجمع أشهرها مع الترخيص من ملف LICENSE في المستودع وآخر إصدار وقت كتابة المقال: | الأداة | اللغة | الترخيص | آخر إصدار | نقاط القوة | نقاط الضعف | | ------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- | | [Semgrep CE](https://github.com/semgrep/semgrep?ref=arabroot.io) | أكثر من 30 لغة | المحرك LGPL-2.1، والقواعد Semgrep Rules License | 1.179.0 (أكتوبر 2026) | قواعد قريبة من الكود وسهلة الكتابة، ولا يحتاج بناء المشروع، وسريع | التلوث داخل الدالة الواحدة، وتكرار النتائج من قواعد كثيرة على السطر نفسه | | [SonarQube Community Build](https://github.com/SonarSource/sonarqube?ref=arabroot.io) | Java وC# وPython وJavaScript وTypeScript وأكثر من 15 لغة أخرى | LGPL-3.0 | 26.9.0 | لوحة وتاريخ وبوابة جودة على الكود الجديد، والجودة مع الأمان | لا يوجد تحليل تلوث ولا تحليل للفروع وطلبات الدمج في النسخة المجانية، ويحتاج سيرفراً وقاعدة بيانات | | [CodeQL](https://github.com/github/codeql?ref=arabroot.io) | C/C++ وC# وGo وJava وKotlin وJavaScript وPython وRuby وRust وSwift | الاستعلامات MIT، والأداة بشروط GitHub | مع GitHub | أعمق تحليل بين الدوال والملفات، واستعلامات قابلة للكتابة | الأداة نفسها للكود مفتوح المصدر فقط إلا بترخيص تجاري، وبناء قاعدة البيانات بطيء | | [Bandit](https://github.com/PyCQA/bandit?ref=arabroot.io) | Python | Apache-2.0 | 1.9.4 (فبراير 2026) | بسيط وسريع، ويجد الأسرار المكتوبة في الكود ودوال خطرة كثيرة | قواعد أنماط فقط، فلا يرى XSS ولا Open Redirect في تجربتنا | | [gosec](https://github.com/securego/gosec?ref=arabroot.io) | Go | Apache-2.0 | 2.29.0 (أغسطس 2026) | يفهم أنواع Go ويخرج SARIF، ونشط التطوير | خاص بلغة Go فقط، فتحتاج معه أداة أخرى للقواعد المخصصة أو للغات الأخرى في المشروع | | [Brakeman](https://github.com/presidentbeef/brakeman?ref=arabroot.io) | Ruby on Rails | [Brakeman Public Use License](https://github.com/presidentbeef/brakeman/blob/main/LICENSE.md?ref=arabroot.io) (ليس مفتوح المصدر بتعريف OSI) | 8.1.0 (أكتوبر 2026) | يفهم بنية Rails من النماذج إلى ال Views | الترخيص يسمح بفحص برامجك، ويمنع الاستخدام التجاري مثل خدمة SaaS أو منتج دون ترخيص مدفوع | | [SpotBugs](https://github.com/spotbugs/spotbugs?ref=arabroot.io) مع [FindSecBugs](https://github.com/find-sec-bugs/find-sec-bugs?ref=arabroot.io) | Java وKotlin وScala | SpotBugs بترخيص LGPL-2.1، وFindSecBugs بترخيص LGPL-3.0 | SpotBugs 4.10.4 (أغسطس 2026)، وFindSecBugs 1.14.0 (أبريل 2025) | يعمل في Maven وGradle، ويقرأ ال bytecode فيعرف الأنواع، و[144 نوعاً من الثغرات](https://find-sec-bugs.github.io/?ref=arabroot.io) في FindSecBugs | يحتاج بناء المشروع، وإصدارات FindSecBugs متباعدة | | [Roslyn .NET Analyzers](https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/security-warnings?ref=arabroot.io) | C# وVisual Basic | MIT | تأتي مع .NET SDK | داخل المترجم نفسه، ولا تحتاج أي تثبيت، وقواعد CA3001 إلى CA3012 تتتبع التلوث بين الدوال | قواعد التلوث معطلة افتراضياً، ولا تتتبع البيانات بين ال Assemblies | | [Security Code Scan](https://github.com/security-code-scan/security-code-scan?ref=arabroot.io) | C# وVisual Basic | LGPL-3.0 | 5.6.7 (سبتمبر 2022) | كان أشهر محلل أمان مفتوح ل .NET | لا يوجد إصدار منذ سبتمبر 2022، فلا تبدأ به مشروعاً جديداً | | [eslint-plugin-security](https://github.com/eslint-community/eslint-plugin-security?ref=arabroot.io) | JavaScript وNode.js | Apache-2.0 | 4.2.0 (أكتوبر 2026) | يعمل داخل ESLint الموجود في المشروع غالباً | يقول ملف README نفسه إنه يجد الكثير من الإنذارات الخاطئة التي تحتاج فرزاً، مثل قاعدة detect-object-injection التي تنبه على كل variable\[key\] | ### مطورو Java وC#: ماذا تستخدم بالتحديد؟ إذا كنت تكتب Java فالبداية الأسهل هي [إضافة SpotBugs ل Maven](https://spotbugs.github.io/spotbugs-maven-plugin/?ref=arabroot.io) مع FindSecBugs كإضافة داخلها، فهي تعمل بعد الترجمة على ال bytecode، لذلك تعرف أن `Statement.executeQuery` هي دالة JDBC بالتحديد، وأن المعامل نص غير ثابت، وقائمة [أنواع الثغرات في FindSecBugs](https://find-sec-bugs.github.io/bugs.htm?ref=arabroot.io) تغطي Spring وJAX-RS وServlets وJPA وأخطاء التشفير، ثم أضف SonarQube Community Build للوحة والتاريخ وبوابة الجودة، وSemgrep للقواعد المخصصة لأن كتابة قاعدة فيه أسهل بكثير من كتابة كاشف Detector في SpotBugs. وإذا كنت تكتب C# فلديك محلل أمان داخل الأداة التي تستخدمها كل يوم، فمحللات [Roslyn .NET Analyzers](https://github.com/dotnet/roslyn-analyzers?ref=arabroot.io) انتقلت إلى مستودع dotnet/sdk وتأتي مع كل .NET SDK، وفيها مجموعة قواعد الأمان التي تبدأ ب CA2xxx وCA3xxx وCA5xxx. وأهمها قواعد التلوث من CA3001 لحقن SQL إلى CA3012، والتي تتتبع القيمة من مدخلات طلب HTTP إلى المكان الخطر عبر الدوال، لكنها كما في صفحة CA3001 معطلة افتراضياً في .NET 10، فإذا لم تقم بتفعيلها فأنت لا تفحص شيئاً من هذا النوع وأنت تظن العكس. أما Security Code Scan الذي تجده في مقالات كثيرة فلا يوجد له إصدار منذ سبتمبر 2022 كما في [صفحته على NuGet](https://www.nuget.org/packages/SecurityCodeScan.VS2019/?ref=arabroot.io)، لذلك الأنسب لمشروع جديد هو قواعد Roslyn المدمجة مع SonarQube Community Build، وكلاهما سوف تراه يعمل في التجربة. ## تجربة عملية Lab: التطبيق نفسه تحت أربع أدوات سوف نستخدم [التطبيق التجريبي في دليل DevSecOps](https://arabroot.io/articles/devsecops-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-sast-%D9%88-dast-%D9%88-sca/#lab-app)، وهو متجر صغير ب Flask فيه ثغرات مقصودة مرقمة من VULN-01 إلى VULN-07، ونأخذ منه نسخة إلى مجلد التجربة ونضيف إليها ما نحتاجه هنا، وكل ثغرة نضيفها نرقمها من VULN-10\. ولا تقم بتشغيل هذا التطبيق على سيرفر متصل بالإنترنت، والسبب أنه مكتوب ليخترق. وكل ال Containers في التجربة تبدأ أسماؤها ب `lab-dso-sast-`، والمنفذ الوحيد المفتوح هو SonarQube على `127.0.0.1:19890`. ### تجهيز نسخة التطبيق ومستودع Git Repository نضيف إلى النسخة مساراً جديداً `/products` يرتب المنتجات بعمود يختاره المستخدم، وال SQL لا يسمح بتمرير اسم عمود كمعامل `?`، لذلك نختار اسم العمود من قائمة سماح Allowlist ثابتة، وهذا كود آمن، لكننا نتوقع أن تعترض عليه الأدوات: ```python @app.route("/products") def products(): # Sort column: SQL cannot take a column name as a ? parameter, so it is chosen from a fixed allowlist. sort = request.args.get("sort", "name") column = {"name": "name", "price": "price"}.get(sort, "name") rows = db().execute(f"SELECT name, price FROM products ORDER BY {column}").fetchall() return {"products": [dict(r) for r in rows]} ``` ثم نجعل المجلد مستودع Git، لأن Semgrep يقرأ الملفات التي يتتبعها Git، ولأننا سوف نحتاج تاريخ ال Commits في الخط الأساسي بعد قليل: ```bash cp -r content/labs/devsecops-app lab-sast/app cd lab-sast/app git init -q -b main git add . && git commit -qm "demo app as shipped" # after adding /products: git commit -qam "lab: /products sorted by an allowlisted column" ``` ### الفحص الأول First Scan مع Semgrep نبدأ بالأمر الذي يكتبه أي شخص يجرب Semgrep لأول مرة، أي اختيار القواعد آلياً حسب لغات المشروع: ```bash docker run --rm -v "$PWD:/src" semgrep/semgrep:1.178.0 semgrep scan --config auto ``` والمخرج طويل، حوالي مئتي سطر، وهذا أوله وآخره كما ظهر: ```text ┌─────────────┐ │ Scan Status │ └─────────────┘ Scanning 3 files tracked by git with 1074 Code rules: Language Rules Files Origin Rules ───────────────────────────── ─────────────────── 47 3 Community 1074 python 243 1 dockerfile 6 1 ┌──────────────────┐ │ 18 Code Findings │ └──────────────────┘ Dockerfile ❯❯❱ dockerfile.security.missing-user.missing-user ❰❰ Blocking ❱❱ By not specifying a USER, a program in the container may run as 'root'. This is a security hazard. If an attacker can control a process running as root, they may have control over the container. Ensure that the last USER in a Dockerfile is a USER other than 'root'. Details: https://sg.run/Gbvn ▶▶┆ Autofix ▶ USER non-root CMD ["python", "app.py"] 12┆ CMD ["python", "app.py"] app.py ❯❯❱ python.flask.security.audit.hardcoded-config.avoid_hardcoded_config_SECRET_KEY ❰❰ Blocking ❱❱ Hardcoded variable `SECRET_KEY` detected. Use environment variables or config files instead Details: https://sg.run/Ekde 16┆ app.config["SECRET_KEY"] = "flask-dev-secret-2024" ... ❯❱ python.flask.security.audit.app-run-param-config.avoid_app_run_with_bad_host ❰❰ Blocking ❱❱ Running flask app with host 0.0.0.0 could expose the server publicly. Details: https://sg.run/eLby 133┆ app.run(host="0.0.0.0", port=8000) ┌──────────────┐ │ Scan Summary │ └──────────────┘ ✅ Scan completed successfully. • Findings: 18 (18 blocking) • Rules run: 296 • Targets scanned: 3 • Parsed lines: ~100.0% • Scan was limited to files tracked by git • For a detailed list of skipped files and lines, run semgrep with the --verbose flag Ran 296 rules on 3 files: 18 findings. ``` ولأن هذا الشكل يصعب قراءته في تقرير، نشغل المجموعة `p/default` مع إيقاف الإحصاءات، وبصيغة `--emacs` التي تضع كل نتيجة في سطر واحد، وقد أعطت النتائج الثماني عشرة نفسها في هذا المشروع: ```bash docker run --rm -v "$PWD:/src" semgrep/semgrep:1.178.0 \ semgrep scan --config p/default --metrics=off --emacs --quiet ``` والمخرج سوف يكون كما يلي، بعد قطع الأسطر الطويلة عند نهاية الكود لأن الرسالة نفسها ظهرت كاملة أعلاه: ```text Dockerfile:12:1:error(missing-user):CMD ["python", "app.py"]:By not specifying a USER, a p app.py:16:1:error(avoid_hardcoded_config_SECRET_KEY):app.config["SECRET_KEY"] = "flask-dev-secret-2024" app.py:86:5:warning(sql-injection-db-cursor-execute): q = request.args.get("q", "") app.py:90:12:warning(formatted-sql-query): rows = db().execute(f"SELECT name, price FROM products WHERE name LIKE '%{q}%'").fetchall() app.py:90:12:error(sqlalchemy-execute-raw-query): rows = db().execute(f"SELECT name, price FROM products WHERE name LIKE '%{q}%'").fetchall() app.py:90:25:error(tainted-sql-string): rows = db().execute(f"SELECT name, price FROM products WHERE name LIKE '%{q}%'").fetchall() app.py:90:25:error(tainted-sql-string): rows = db().execute(f"SELECT name, price FROM products WHERE name LIKE '%{q}%'").fetchall() app.py:91:21:warning(raw-html-format): items = "".join(f"
  • {r[0]}: {r[1]}
    • " for r in rows) app.py:91:21:warning(raw-html-format): items = "".join(f"
  • {r[0]}: {r[1]}
    • " for r in rows) app.py:94:5:warning(directly-returned-format-string): return PAGE.format(f"

    Results for {q}

    ") app.py:94:12:warning(raw-html-format): return PAGE.format(f"

    Results for {q}

    ") app.py:94:12:warning(raw-html-format): return PAGE.format(f"

    Results for {q}

    ") app.py:101:12:error(open-redirect): return redirect(request.args.get("next", "/")) app.py:109:12:warning(formatted-sql-query): rows = db().execute(f"SELECT name, price FROM products ORDER BY {column}").fetchall() app.py:109:12:error(sqlalchemy-execute-raw-query): rows = db().execute(f"SELECT name, price FROM products ORDER BY {column}").fetchall() app.py:109:25:error(tainted-sql-string): rows = db().execute(f"SELECT name, price FROM products ORDER BY {column}").fetchall() app.py:109:25:error(tainted-sql-string): rows = db().execute(f"SELECT name, price FROM products ORDER BY {column}").fetchall() app.py:133:5:warning(avoid_app_run_with_bad_host): app.run(host="0.0.0.0", port=8000) ``` ### من النتائج Findings إلى الثغرات Vulnerabilities، ماذا وجدت الأداة وماذا فاتها؟ ثماني عشرة نتيجة لا تعني ثماني عشرة ثغرة، فأول عمل بعد أي فحص هو أن تجمع النتائج حسب المشكلة الحقيقية. والجدول التالي يربط النتائج بثغرات التطبيق: | الثغرة | السطر | عدد النتائج | الحكم | | ------------------------------------------------- | ------------- | ----------- | ------------------------------------------------------------------ | | VULN-01 مفتاح الجلسة SECRET\_KEY في الكود | 16 | 1 | صحيحة True Positive | | VULN-01 التوكن ADMIN\_API\_TOKEN في الكود | 17 | 0 | مفقودة False Negative | | VULN-02 حقن SQL في البحث | 86 و90 | 5 | صحيحة، لكن من خمس قواعد | | VULN-03 XSS في صفحة النتائج | 91 و94 | 5 | صحيحة، والسطر 91 فيه بيانات من قاعدة البيانات وليس من الطلب مباشرة | | VULN-05 إعادة التوجيه المفتوحة Open Redirect | 101 | 1 | صحيحة | | VULN-07 ال Container يعمل ك root | Dockerfile 12 | 1 | صحيحة | | الترتيب بعمود من قائمة سماح في /products | 109 | 4 | خاطئة False Positive | | الاستماع على 0.0.0.0 داخل ال Container | 133 | 1 | خاطئة في سياقنا | | VULN-04 ترويسات الأمان، وVULN-06 المكتبات القديمة | | 0 | خارج نظر SAST كما ذكرنا | في الجدول أعلاه لاحظ التالي: - ثماني نتائج من الثماني عشرة جاءت من قواعد Django وSQLAlchemy على تطبيق Flask لا يستخدم أياً منهما، لأن مجموعة القواعد العامة تضم قواعد لأطر عمل كثيرة تتشابه أنماطها، وهذا مثال حقيقي على الضجيج Noise، فالثغرة الواحدة ظهرت خمس مرات. - التوكن `ADMIN_API_TOKEN` لم يظهر، لأن القاعدة الموجودة تعرف المفتاح `SECRET_KEY` في إعداد Flask بالتحديد، ولا تعرف أن هذا النص الطويل سر، وهذا عمل أداة أخرى تفحص النصوص نفسها، وقد شرحناها في [اكتشاف الأسرار المسربة مع Gitleaks وTruffleHog](https://arabroot.io/articles/%D8%A7%D9%83%D8%AA%D8%B4%D8%A7%D9%81-%D8%A7%D9%84%D8%A7%D8%B3%D8%B1%D8%A7%D8%B1-%D8%A7%D9%84%D9%85%D8%B3%D8%B1%D8%A8%D8%A9-%D9%85%D8%B9-gitleaks-%D9%88-trufflehog/). - الإنذاران الخاطئان سوف نتعامل معهما الآن بالطريقة الصحيحة. ### الإنذار الخاطئ False Positive وتجاهله بالطريقة الصحيحة السطر 109 آمن لأن `column` لا يمكن أن يكون إلا `name` أو `price`، لكن قواعد التلوث رأت أن قيمة من `request.args` دخلت إلى `dict.get` ثم خرجت إلى الاستعلام، وهي لا تعرف أن نتيجة البحث في القاموس قيمة من القاموس نفسه وليست قيمة المستخدم. والطريقة الخاطئة هنا هي حذف القاعدة `tainted-sql-string` من الإعداد، والسبب أن القاعدة نفسها هي التي وجدت VULN-02 الحقيقية قبل سطرين، والطريقة الخاطئة الثانية هي استثناء الملف كله. والطريقة الصحيحة هي أن نتجاهل هذه النتيجة في هذا السطر فقط، وبأسماء القواعد بالتحديد، ومع السبب. وتشرح [صفحة التجاهل في Semgrep](https://docs.semgrep.dev/ignoring-files-folders-code?ref=arabroot.io) أن التعليق `# nosemgrep: rule-id` يوضع على السطر نفسه أو على السطر الذي قبله، وأن اسم القاعدة يكتب كاملاً بمساره، ولا توجد في الصيغة خانة رسمية للسبب، لذلك نكتب السبب في تعليق مستقل قبله: ```python # Reviewed 2026-10: column is one of two fixed strings from the allowlist above, never the raw request value. # nosemgrep: python.flask.security.injection.tainted-sql-string.tainted-sql-string, python.django.security.injection.tainted-sql-string.tainted-sql-string, python.lang.security.audit.formatted-sql-query.formatted-sql-query, python.sqlalchemy.security.sqlalchemy-execute-raw-query.sqlalchemy-execute-raw-query rows = db().execute(f"SELECT name, price FROM products ORDER BY {column}").fetchall() # nosec B608 ``` وبالطريقة نفسها نتجاهل نتيجة `0.0.0.0`، فالتطبيق داخل Container يجب أن يستمع على كل الواجهات حتى يصل إليه Docker، والحماية الحقيقية هي نشر المنفذ على `127.0.0.1` فقط في السيرفر: ```python # Inside the Container the app must listen on all interfaces; the host publishes it on 127.0.0.1 only. # nosemgrep: python.flask.security.audit.app-run-param-config.avoid_app_run_with_bad_host app.run(host="0.0.0.0", port=8000) # nosec B104 ``` ثم نعيد الفحص بالأمر نفسه، وهذا ملخصه: ```text ✅ Scan completed successfully. • Findings: 13 (13 blocking) • Rules run: 296 • Targets scanned: 3 • Parsed lines: ~100.0% • No ignore information available Ran 296 rules on 3 files: 13 findings. ``` في الإعداد أعلاه لاحظ التالي: - اختفت النتائج الخمس، أربع على السطر 109 وواحدة على السطر 133، وبقيت النتائج الحقيقية كلها، لأننا ذكرنا القواعد بأسمائها ولم نكتب `# nosemgrep` وحدها، فالتعليق دون أسماء يخفي أي قاعدة جديدة تظهر على هذا السطر في المستقبل. - أضفنا `# nosec B608` و`# nosec B104` ل Bandit، لأن لكل أداة صيغة تجاهل خاصة بها، فالتعليق الذي يفهمه Semgrep لا يفهمه Bandit، وSonarQube يستخدم حالة «مقبول Accepted» أو «إنذار خاطئ False Positive» في الواجهة. - السطر الأول بتاريخ وسبب، حتى يعرف من يقرأ الكود بعد سنة لماذا تم التجاهل، ومتى يجب أن يراجعه، فإذا تغير الكود وأصبح `column` يأتي من مكان آخر فالتعليق يقول بوضوح إن الافتراض انكسر. - التجاهل يمر بمراجعة الكود في طلب الدمج مثل أي سطر آخر، وهذا أهم من الصيغة نفسها، فمطور يتجاهل نتيجة دون أن يراه أحد هو ثغرة في العملية وليس في الكود. 📌 كتبنا أيضاً السبب في السطر نفسه بعد أسماء القواعد في ملف اختبار منفصل، مثل `# nosemgrep: rule-id (allowlisted column)`، ونجح التجاهل في Semgrep 1.178.0، لكن الصيغة غير موثقة، لذلك فضلنا التعليق المستقل للسبب حتى لا يتغير سلوكها في إصدار قادم. ### كتابة قاعدة مخصصة Custom Rule لنمط خاص بتطبيقنا تطبيقنا يبني صفحاته بقالب HTML خام اسمه `PAGE` مع `PAGE.format(...)`، وهذا نمط خاص بنا لا تعرفه القواعد العامة، فهي وجدت XSS بقواعد عامة عن «نص HTML منسق»، وبخمس نتائج على سطرين. والقاعدة المخصصة تقول ما نعرفه نحن عن الكود بالضبط: المصدر مدخلات الطلب، والمكان الخطر `PAGE.format`، والمنظف `escape`. وننشئ ملف القاعدة `rules/page-format-xss.yaml` بوضع التلوث `mode: taint` الذي تشرحه [صفحة Taint Mode](https://docs.semgrep.dev/writing-rules/data-flow/taint-mode?ref=arabroot.io): ```yaml rules: - id: page-format-xss mode: taint languages: [python] severity: ERROR message: >- Request data reaches PAGE.format() without escaping. PAGE is our raw HTML template, so this is reflected XSS. Escape the value with markupsafe.escape() first, or render a Jinja2 template. metadata: cwe: "CWE-79: Improper Neutralization of Input During Web Page Generation" owner: shop-team pattern-sources: - pattern: flask.request.args.get(...) - pattern: flask.request.form.get(...) - pattern: flask.request.args[...] - pattern: flask.request.form[...] pattern-sanitizers: - pattern: markupsafe.escape(...) - pattern: html.escape(...) pattern-sinks: - pattern: PAGE.format(...) ``` والقاعدة كود، والكود يحتاج اختباراً، لذلك نكتب بجانبها ملفاً بالاسم نفسه `rules/page-format-xss.py` فيه حالة يجب أن تجدها، وحالتان يجب ألا تجدهما، بالتعليقين `# ruleid:` و`# ok:` كما في [صفحة اختبار القواعد](https://docs.semgrep.dev/writing-rules/testing-rules?ref=arabroot.io): ```python from flask import request from markupsafe import escape PAGE = "{}" def search(): q = request.args.get("q", "") # ruleid: page-format-xss return PAGE.format(f"

    Results for {q}

    ") def search_escaped(): q = request.args.get("q", "") # ok: page-format-xss return PAGE.format(f"

    Results for {escape(q)}

    ") def welcome(): name = "guest" # ok: page-format-xss return PAGE.format(f"

    Hello {name}

    ") ``` الآن نشغل الاختبار من مجلد التجربة الذي يحتوي المجلدين `app` و`rules`: ```bash docker run --rm -v "$PWD:/src" -w /src semgrep/semgrep:1.178.0 \ semgrep scan --test --metrics=off rules/ ``` والمخرج سوف يكون كما يلي: ```text ┌─────────────┐ │ Scan Status │ └─────────────┘ Scanning 1 file with 1 Code rule: Scanning 1 file. 1/1: ✓ All tests passed No tests for fixes found. ``` ثم نشغل القاعدة وحدها على التطبيق: ```bash docker run --rm -v "$PWD:/src" -w /src semgrep/semgrep:1.178.0 \ semgrep scan --config rules/page-format-xss.yaml --metrics=off app/ ``` والمخرج سوف يكون كما يلي: ```text │ 1 Code Finding │ └────────────────┘ app/app.py ❯❯❱ rules.page-format-xss ❰❰ Blocking ❱❱ Request data reaches PAGE.format() without escaping. PAGE is our raw HTML template, so this is reflected XSS. Escape the value with markupsafe.escape() first, or render a Jinja2 template. 94┆ return PAGE.format(f"

    Results for {q}

    ") ┌──────────────┐ │ Scan Summary │ └──────────────┘ ✅ Scan completed successfully. • Findings: 1 (1 blocking) • Rules run: 1 • Targets scanned: 1 • Parsed lines: ~100.0% • Scan was limited to files tracked by git • For a detailed list of skipped files and lines, run semgrep with the --verbose flag Ran 1 rule on 1 file: 1 finding. ``` في الإعداد أعلاه لاحظ التالي: - نتيجة واحدة على السطر الصحيح، برسالة تذكر قالبنا باسمه وطريقة الإصلاح المناسبة لتطبيقنا، بدل خمس نتائج عامة تقترح `django.shortcuts.render` على تطبيق Flask. - الصفحة الرئيسية `index()` تمرر `session.get("user")` إلى `PAGE.format` ولم تظهر، لأن الجلسة ليست مصدراً في قاعدتنا، وهذا قرار يجب أن تتخذه بوعي، فإذا كان اسم المستخدم يمكن أن يحتوي HTML عند التسجيل فأضف الجلسة إلى المصادر. - اسم القاعدة في المخرج `rules.page-format-xss`، أي أن Semgrep يضيف اسم المجلد قبل اسم القاعدة، وهذا هو الاسم الذي تكتبه في `# nosemgrep:` إذا احتجت إليه. - ملف الاختبار يجعل القاعدة آمنة للتعديل، فإذا أضاف أحد مصدراً جديداً أو منظفاً جديداً فأمر `--test` في خط CI يخبره فوراً إن كسر حالة قديمة. ### المقارنة Comparison مع Bandit Bandit أداة Python بقواعد أنماط مكتوبة ككود Python، ونشغله على النسخة نفسها قبل التجاهل: ```bash docker run --rm -v "$PWD:/src" -w /src python:3.13-slim sh -c ' pip install -q --root-user-action=ignore bandit==1.9.4 bandit -q -r app/ -f custom --msg-template "{relpath}:{line} {test_id} {severity}/{confidence} {msg}"' ``` والمخرج سوف يكون كما يلي: ```text app/app.py:16 B105 LOW/MEDIUM Possible hardcoded password: 'flask-dev-secret-2024' app/app.py:17 B105 LOW/MEDIUM Possible hardcoded password: 'dso_live_7Hq2Lx9Vt4Rz8Wn3Bk6Mh1Sd5Gj0CyPa' app/app.py:19 B108 MEDIUM/MEDIUM Probable insecure usage of temp file/directory. app/app.py:90 B608 MEDIUM/MEDIUM Possible SQL injection vector through string-based query construction. app/app.py:109 B608 MEDIUM/MEDIUM Possible SQL injection vector through string-based query construction. app/app.py:133 B104 MEDIUM/MEDIUM Possible binding to all interfaces. ``` والجدول التالي يضع الأداتين جنباً إلى جنب على الثغرات نفسها: | الثغرة | Semgrep p/default | Bandit 1.9.4 | | ----------------------------- | ---------------------- | ------------------------------------------ | | VULN-01 SECRET\_KEY | وجدها | وجدها B105 | | VULN-01 ADMIN\_API\_TOKEN | فاتته | وجدها B105 لأن اسم المتغير فيه TOKEN | | VULN-02 حقن SQL | وجدها بالتلوث والأنماط | وجدها B608 بالنمط | | VULN-03 XSS | وجدها | فاتته | | VULN-05 Open Redirect | وجدها | فاتته | | VULN-07 root في Dockerfile | وجدها | لا يقرأ Dockerfile | | العمود من قائمة السماح | إنذار خاطئ من 4 قواعد | إنذار خاطئ B608 | | المسار /tmp/shop.db الافتراضي | لا شيء | B108، وهي ملاحظة صحيحة لأن /tmp مكان مشترك | والخلاصة من المقارنة أن الأداتين تكمل إحداهما الأخرى، فـ Bandit يعرف Python بقواعد قليلة ودقيقة على الأسرار والدوال الخطرة، ولا يعرف شيئاً عن Flask، وSemgrep يعرف أطر العمل ويتتبع البيانات، لكنه فوت التوكن. وتشغيل الاثنين في خط CI يأخذ ثواني معدودة، لذلك لا يوجد سبب للاختيار بينهما في مشروع Python. ### إصلاح الثغرة Fix ورؤية النتيجة Finding تختفي نصلح VULN-02 بالطريقة الموجودة في التطبيق نفسه في دالة `login()`، أي معامل `?` بدل دمج النص: ```diff - rows = db().execute(f"SELECT name, price FROM products WHERE name LIKE '%{q}%'").fetchall() + rows = db().execute("SELECT name, price FROM products WHERE name LIKE ?", (f"%{q}%",)).fetchall() ``` ثم نعيد الفحص بصيغة السطر الواحد: ```text Dockerfile:12:1:error(missing-user):CMD ["python", "app.py"]:By not specifying a USER, a program in the contai app.py:16:1:error(avoid_hardcoded_config_SECRET_KEY):app.config["SECRET_KEY"] = "flask-dev-secret-2024":Hardco app.py:91:21:warning(raw-html-format): items = "".join(f"
  • {r[0]}: {r[1]}
    • " for r in rows):Detected u app.py:91:21:warning(raw-html-format): items = "".join(f"
  • {r[0]}: {r[1]}
    • " for r in rows):Detected u app.py:94:5:warning(directly-returned-format-string): return PAGE.format(f"

    Results for {q}