كيف توثّق النتائج الإيجابية الخاطئة للمراجعة الأمنية في Salesforce

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

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

إيه اللي بيتحسب نتيجة إيجابية خاطئة؟

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

الفئات اللي بترجع بتكرار كفاية علشان تخطّط ليها هي:

• ملاحظات التحكم في الوصول على كود شغال أصلًا في user mode باستخدام WITH USER_MODE أو AccessLevel.USER_MODE.
• ملاحظات المشاركة على فئات ما بيتم الدخول إليها إلا من سياق طبّق المشاركة بالفعل.
• ملاحظات الحقن على استعلامات بتستخدم متغيرات ربط ما تتبّعهاش الفاحص.
• ملاحظات البرمجة عبر المواقع (XSS) على معاملات ما بتوصلش للـ DOM أبدًا أو بتتشفّر قبل ما توصل.
• ملاحظات المكتبات المعرّضة للخطر المطابَقة على نص إصدار جوّه static resource مضمّنة الحزمة ما بتشغّلهاش أبدًا.

العتبة مختلفة لكل فاحص

قبل ما تكتب أي تبرير، اعرف أي ملاحظات لازم تتعامل معاها أصلًا. العتبة مش صفر ملاحظات، وهي بتختلف حسب الأداة:

• Salesforce Code Analyzer: صلّح كل خطأ متعلق بالأمان، وتجاهل الملاحظات اللي مش متعلقة بالأمان. اقرأ توثيق الأداة على Salesforce Code Analyzer.
• ماسح المصدر: عالج ملاحظات Low وMedium وHigh، وسيب التحذيرات المعلوماتية البحتة على حالها.
• الفاحصات الديناميكية (DAST): عالج كل حاجة ما عدا العناصر المعلوماتية والتحذيرات، واحتفظ بلقطة شاشة تثبت إن الـ endpoint الصح هو اللي اتفحص.

أي حاجة فوق حد الضوضاء يا بتتصلح يا بتتوثّق. مفيش خيار تالت إنك تتجاهلها بصمت.

إيه اللي بتطلبه Salesforce في مستند النتائج الإيجابية الخاطئة

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

الشكل اللي عليه المدخَل الجيد

اِدّي كل عنصر مُعلَّم مدخَلًا خاصًا بيه بدل فقرة عامة واحدة. المدخَل القوي بيجاوب، بالترتيب:

1. أي ملاحظة. اسم الفاحص، ومعرّف القاعدة أو الفئة، والخطورة اللي حدّدها.
2. فين. الملف والسطر بالضبط، علشان المراجع يفتحه من غير ما يدوّر.
3. مسار البيانات. جملة عن إزاي البيانات بتوصل للسطر ده، وليه النمط المُعلَّم مش بينطبق عليه.
4. الضابط. الآلية المحددة اللي بتحميه، مُسمّاة بشكل ملموس: متغير الربط، فرض user mode، نداء الترميز، سياق المشاركة.
5. الدليل. فين الضابط ده جوّه الحزمة، وللملاحظات الديناميكية، لقطة الشاشة اللي بتبيّن الـ endpoint اللي اتفحص فعلًا.

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

ليه مستندات النتائج الإيجابية الخاطئة بتترفض

الرفض اللي بنشوفه بيتجمّع في حفنة أخطاء ممكن تتفاداها:

• تبريرات في سطر واحد. "مش قابل للاستغلال" أو "متعالَج في مكان تاني" مش بيدّي المراجع حاجة يتحقق منها، فبترجع كسؤال، والأسئلة بتكلّف دورة مراجعة.
• من غير ملف وسطر. التبرير اللي المراجع مش قادر يلاقيه في الكود مش ممكن يتأكد منه.
• توثيق مشكلة حقيقية. إنك تعتبر ملاحظة حقيقية نتيجة إيجابية خاطئة بيهزّ الثقة في المستند كله، والمراجع بيبدأ يراجع تاني اللي كان تمام.
• غياب دليل الفحص الديناميكي. ملاحظة DAST بتتشال من غير لقطة للـ endpoint المفحوص بتتقري كإنها ما اتفحصتش، مش كإنها آمنة.
• مراجع قديمة. أرقام أسطر ما بقتش مطابقة للحزمة المُقدَّمة لأن الكود اتحرّك بعد الفحص.

إزاي انضباط الميتاداتا بيخلّي ده قابل للتكرار

Salesforce بتعيد تدقيق الحزم المدرجة دوريًا، ومعنى كده إنك هتكتب تبريرات للنتائج الإيجابية الخاطئة أكتر من مرة. لما ميتاداتا حزمتك تعيش في نظام التحكم بالمصدر، بتبقى كل permission set وsharing rule وnamed credential مُؤرّخة، فتقدر تشاور على الضابط بالضبط اللي بيسند التبرير وتبيّن إنه ما اتغيّرش. الفرق اللي بتتعامل مع الميتاداتا ككود بتعيد استخدام مستند السنة اللي فاتت بدل ما تبني السبب من الأول.

ولو بتفضّل شريك عدّى المراجعة قبل كده يكتب التبريرات دي معاك، فـ Tekunda بتبني وتحزّم منتجات AppExchange كـ Salesforce PDO.

FAQ

أقدر أكتم الملاحظة بدل ما أوثّقها؟

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

كل مدخَل محتاج يبقى مفصّل قد إيه؟

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

النتائج الإيجابية الخاطئة الديناميكية محتاجة دليل إضافي؟

أيوة. أرفق لقطة شاشة تثبت إن الـ endpoint الصح هو اللي اتفحص، وإلا الملاحظة بتتقري كإنها ما اتفحصتش بدل ما تبقى آمنة.