قائمة مراجعة أمان سيلزفورس: إيه اللي تصلّحه، وبأي ترتيب

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

تِكوندا عدّت بحزم مُدارة من المراجعة في قطاعات الرعاية الصحية واللوجستيات والتصنيع. اللي جاي ده هو ترتيب الشغل عندنا فعلا، مش شرح نظري للعملية. لرحلة التقديم كاملة، شوف How ISVs Pass the Salesforce AppExchange Security Review.

القائمة في لمحة

1. أكّد إيه اللي بتقدمه: حزمة مُدارة، وكل خدمة خارجية بتلمسها.
2. صلّح التحكم في الصلاحيات: وضع المستخدم، مشاركة صريحة، ومفيش SOQL قابل للحقن.
3. صلّح معالجة المخرجات والأسرار وأمان النقل والمصادقة.
4. شغّل Code Analyzer وفحص الكود في Partner Security Portal وفحص DAST.
5. صلّح اللي يطلبه حد كل فاحص، ووثّق كل إنذار كاذب.
6. جهّز التوثيق وبيانات الدخول وorg اختبار شغّال.
7. قدّم من Partner Console وخطط لإعادة المراجعة السنوية.

إيه اللي اتغير في 2026

تلات حاجات اتغيرت السنة دي، والقوائم القديمة ما تعرفش أي واحدة منهم.

• السوق دلوقتي اسمه AgentExchange. سيلزفورس غيّرت اسم AppExchange إلى AgentExchange في TrailblazerDX 2026 وضمّت Slack Marketplace جواه. مواد Trailhead بقت بتستخدم الاسم الجديد، لكن مراجعة الأمان لسه هي البوابة للإدراج.
• إصدار Apex API رقم 67.0 بيغيّر الإعدادات الافتراضية للأمان. حسب أبرز نقاط Summer '26 للمعماريين، عمليات قاعدة البيانات بقت بتشتغل في وضع المستخدم افتراضيا، والكلاسات من غير إعلان مشاركة بتاخد with sharing افتراضيا، وWITH SECURITY_ENFORCED اتشال، فأي كلاس لسه بيستخدمه على v67.0 مش هيتكمبايل. التريجرات استثناء: دايما بتشتغل في وضع النظام.
• انت اللي بتشغّل الفحص الديناميكي بنفسك. إرشادات التحضير من سيلزفورس بقت توصي بـ OWASP ZAP أو Burp Suite Enterprise Edition للنقاط الخارجية وبتقبل أي فاحص DAST تفضله. شوف تشغيل الفحوص الديناميكية بنفسك بعد Chimera للأدوات والتقرير اللي تقدمه.

الخطوة 1: حدد النطاق

سيلزفورس واضحة إن كل مكونات وخدمات حلك داخلة في النطاق، مهما كان مكانها. يعني الحزمة، وأي خدمة ويب بتناديها، وأي موقع بيخزن بيانات سيلزفورس، وأي عميل جوال أو سطح مكتب. حدد نوع الحزمة قبل ما تبدأ تصلّح الكود، لأنه بيحدد اللي هترفعه؛ مقال Salesforce Packaging Models for ISVs: 1GP vs 2GP vs Unmanaged بيغطي الاختيار ده.

الخطوة 2: صلّح بالترتيب النتائج اللي بتخلي الطلبات تترفض

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

1. صلاحيات مش مفروضة في وضع المستخدم. كل استعلام وكل عملية DML لازم تحترم صلاحيات الكائنات وأمان الحقول وقواعد المشاركة للمستخدم الحالي. ما تعتمدش على الافتراضي في v67.0 لوحده: الحزمة غالبا فيها كلاسات على إصدارات أقدم، والـ trigger handlers ممكن تتنادى من تريجر بيشتغل في وضع النظام. حدد وضع الوصول صراحة بـ WITH USER_MODE مع SOQL وAccessLevel.USER_MODE مع استدعاءات Database، واستبدل أي WITH SECURITY_ENFORCED متبقي قبل ما ترفع إصدار الـ API.
2. المشاركة معلنة على الكلاسات الغلط. تحت v67.0، كلاس من غير كلمة مشاركة بيورث الإعداد من اللي استدعاه، فممكن كلاس مساعد بيتنادى من ميثود @AuraEnabled يشتغل من غير مشاركة وانت مش واخد بالك. اكتب with sharing أو without sharing أو inherited sharing صراحة على كل كلاس، بما فيها الداخلية والمساعدة، عشان المراجع ما يضطرش يعرف أنهي افتراضي بيسري.
3. SOQL ديناميكي متجمّع من مدخلات. استخدم bind variables. ولو لازم الاستعلام يتبني كنص، اعمل escape لكل قيمة داخلة وسيب الـ escape ظاهر في نفس الميثود، لأن هناك المراجع بيقراه.
4. مخرجات من غير escape. أي حاجة توصل للصفحة عن طريق escape="false" أو lwc:dom="manual" أو innerHTML لازم تتنضف قبل ما توصل، مش بعدها.
5. أسرار وبيانات عملاء في المكان الغلط. مفاتيح مكتوبة في Apex، توكنات في custom settings غير محمية، سجل فيه بيانات شخصية بيتمرر لـ System.debug. المراجعين بيتوقعوا Named Credentials وcustom metadata محمية بدل كده.
6. تشفير ضعيف للنقل أو التخزين. قائمة أكثر نتائج المراجعة تكرارا من سيلزفورس بتشترط TLS 1.2 على الاتصالات اللي فيها مواقعك وبوابتك، والفريق بيفحص كل نقطة خارجية عشانه. شفّر كمان أي حاجة بتخزنها خارج المنصة.
7. أنظمة خارجية بتتصادق باسم مستخدم وكلمة سر مخزنين. استخدم OAuth لكل اتصال بتفتحه الحزمة مع خدمة انت أو العميل بتشغلها. بيانات الدخول المخزنة نتيجة لوحدها، وبتصعّب الدفاع عن مستند تدفق البيانات.
8. موقع مركّب اتسلم من غير الأساسيات. لو حلك فيه واجهة ويب خارج الـ org فمحتاجة security headers، وكوكيزها محتاجة Secure وHttpOnly. المراجعين بيفحصوا الموقع اللي بتسلمهولهم، مش اللي بتوصفه.
9. نقاط خارجية محدش فحصها. لو حزمتك بتنادي خدمة انت بتشغلها، الخدمة دي داخلة في النطاق ومحتاجة تقرير فحص ديناميكي خاص بيها.
10. بيئة اختبار المراجع مش قادر يستخدمها. org منتهية، أو تحدي هوية بيقفل عليه، أو كائنات من غير بيانات. سيلزفورس بتقول للشركاء يتعاملوا مع فريق المراجعة كعميل محتمل بيجرب الحل كله من الأول للآخر، ومينفعش يراجع حاجة مش شغالة.

الخطوة 3: شغّل الفاحصات وحقق حد كل واحد

لازم تقدم تقرير Salesforce Code Analyzer وتقرير فاحص الكود في Partner Security Portal وتقرير DAST. الحد مش صفر نتائج، وبيختلف من فاحص للتاني:

• Salesforce Code Analyzer: صلّح كل النتائج والأخطاء المتعلقة بالأمان ما عدا الإنذارات الكاذبة، وتجاهل اللي مالوش علاقة بالأمان. هو مش بيفحص النقاط الخارجية.
• فاحص الكود في Partner Security Portal (Checkmarx): صلّح النتائج Low وMedium وHigh، وسيب التحذيرات الإعلامية.
• فاحصات DAST زي ZAP وBurp Suite وVeracode Dynamic Analysis وIntruder وAcunetix: صلّح كل حاجة ما عدا البنود الإعلامية والتحذيرات، وارفق لقطة شاشة تثبت إن النقطة الخارجية الصح هي اللي اتفحصت.

ولّد تقرير Code Analyzer v5 بمحدد قواعد AppExchange عشان يطابق اللي المراجع بيتوقعه. في الكود المعقد التشغيل ممكن ياخد ساعات:

sf code-analyzer run --rule-selector AppExchange --rule-selector Recommended:Security --output-file CodeAnalyzerReport.html

الفحوص الإلزامية اتغيرت أكتر من مرة، فراجع متطلبات الفاحصات الحالية قبل ما تولّد أي حاجة.

الخطوة 4: وثّق كل إنذار كاذب

في طلباتنا، أربع فئات بترجع كإنذارات كاذبة حقيقية كفاية عشان تحسب حسابها: نتائج تحكم في الصلاحيات على كود بيفرض وضع المستخدم أصلا، ونتائج مشاركة على كلاسات مبتدخلش ليها غير من سياق المشاركة فيه مطبقة، ونتائج مكتبة قديمة بتتطابق مع رقم إصدار جوه static resource مرفقة، ونتائج cross-site scripting منعكس على باراميترات مبتوصلش للـ DOM أبدا.

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

الخطوة 5: جهّز مواد التقديم

• توثيق استخدام مكتوب بحيث اللي عمره ما شاف التطبيق يقدر يكمل سير عمل كامل.
• توثيق تدفق البيانات بين الـ org وأي موقع مركّب أو تطبيق جوال أو إضافة متصفح.
• كل تقارير الفحص ولقطة شاشة نقطة DAST ومستند الإنذارات الكاذبة.
• org من نوع Developer Edition عليها الحزمة وبيانات اختبار واقعية.
• بيانات دخول لكل نظام خارجي بيلمسه التطبيق، أو نسخة اختبار مستضافة منه.
• روابط التثبيت وبيانات الدخول لأي عميل جوال أو سطح مكتب.

بعد كده تبدأ المراجعة من Publishing Partner Console: افتح تبويب Technologies، اختار Start Review على حلك، وكمّل أقسام جهات الاتصال والتفاصيل التقنية والتوثيق وبيئة الاختبار قبل الدفع.

المراجعة بتاخد قد إيه وبتكلف كام؟

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

لو تفضّل تسيب المراجعة لناس عدّوها قبل كده، تِكوندا بتقدم كشريك سيلزفورس التحضير لمراجعة أمان AppExchange. ولو لسه بتفكر تستعين بمساعدة خارجية، شوف ما الذي يقوم به شريك PDO في سيلزفورس ومتى تحتاج إليه.

الأسئلة الشائعة

هل التطبيقات المجانية محتاجة مراجعة أمان؟

أيوه. أي حل لازم يعدّي المراجعة قبل ما يتدرج في السوق. الرسم 999 دولار اللي سيلزفورس موثقاه بيسري على الحلول المدفوعة.

هل إصدار API رقم 67.0 معناه أتخطى شغل CRUD وFLS والمشاركة؟

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

هل Salesforce Code Analyzer كفاية لوحده؟

لأ. محتاج كمان تقرير فاحص الكود في Partner Security Portal، وأي نقطة خارجية بيناديها تطبيقك محتاجة تقرير DAST خاص بيها.

هل تطبيق Agentforce أو قائم على الوكلاء بيغير القائمة؟

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

هل مراجعة الأمان حدث لمرة واحدة؟

لأ. الحلول المدرجة بتتراجع عادة مرة في السنة، وسيلزفورس تقدر تطلب مراجعة في أي وقت. إصدارات الحزمة الجديدة بتستخدم إقرارا في Partner Console بدل مراجعة جديدة، فخلي القائمة بوابة إصدار دايمة.