إزاي تجتاز شركات ISV مراجعة AppExchange الأمنية من Salesforce

معظم حالات الرفض في مراجعة AppExchange الأمنية ليست بسبب أخطاء غريبة. إنها تعود إلى قائمة قصيرة متوقعة: CRUD/FLS غير مطبَّق، ومخالفات sharing، وإعدادات جلسات ضعيفة، وأسرار داخل الـ metadata. شركات ISV التي تتعامل مع المراجعة كتدقيق كود قبل التقديم بأسبوعين تخسر بسببها عادةً دورة كاملة.

لماذا تفشل التطبيقات في مراجعة Salesforce الأمنية؟

يجري فريق المراجعة في Salesforce تحليلًا ثابتًا (Checkmarx و PMD عبر Salesforce Code Analyzer). ومنذ توقف ماسح Chimera المستضاف في 2025-06-16، أصبح الفحص الديناميكي لأي endpoints خارجية تستدعيها حزمتك مسؤوليتك أنت تشغيلًا وتقديمًا، كما يوضح مقال تشغيل الفحوص الديناميكية بنفسك بعد Chimera. وتنقسم الأعطال التي نراها أكثر في مشاريع ISV إلى أربع فئات:

• ثغرات CRUD/FLS. كود Apex يقرأ الكائنات أو يكتب فيها دون التحقق من صلاحيات المستخدم الحالي على الكائن والحقل، خصوصًا في Visualforce controllers و REST endpoints.
• غياب تعريفات sharing. كلاسات بدون with sharing تنفذ DML، أو كلاس "with sharing" يستدعي helper من نوع "without sharing" فيرث سياقه الأقل تقييدًا.
• إعدادات جلسات وهوية خاطئة. test orgs تمنع فيها identity challenge أو MFA أدوات المراجع، بدلًا من الأسلوب الموصى به باستخدام IP allowlist.
• أسرار في المكان الخطأ. مفاتيح API مخزنة في custom metadata types يستطيع أي admin لدى المشترك الاستعلام عنها، وبيانات شخصية تُسجَّل عبر System.debug.

إزاي تجهّز تطبيقًا لمراجعة AppExchange الأمنية؟

التحضير انضباط في الأساس، وليس أدوات جديدة. قبل أن تطلب المراجعة:

• شغّل Salesforce Code Analyzer على الحزمة كاملة، وليس على الكلاسات المعدلة مؤخرًا فقط، وصنّف كل نتيجة.
• تأكد أن كل عملية DML موجودة داخل كلاس معرَّف بـ with sharing، أو وثّق الحالة المحددة لتجاوز CRUD/FLS (تجميعات roll-up وكائنات السجلات الداخلية هما الحالتان اللتان تقبلهما Salesforce عادةً).
• افحص كل نطاق غير تابع لـ Salesforce تستدعيه حزمتك باستخدام ماسح تطبيقات ويب معتمد، وعالج النتائج عالية الخطورة قبل التقديم.
• انقل الأسرار من الـ metadata إلى Named Credentials أو مخزن أسرار خارجي يُستدعى وقت التشغيل.

ماذا تعني النتيجة الإيجابية الخاطئة من Checkmarx أو PMD فعلًا؟

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

إزاي يقلل شريك التنفيذ مخاطر المراجعة الأمنية؟

الشريك الذي مرّر حزمًا عبر المراجعة من قبل يعرف أي النتائج تستحق النقاش وأيها يكفي إصلاحه، وهذا التقدير هو مصدر توفير الوقت. قادت Tekunda مراجعات AppExchange الأمنية من البداية إلى النهاية لعملاء ISV، من التدقيق الأول لكود Apex والتكاملات حتى إعادة التقديم بعد ملاحظات المراجعين، لذلك نادرًا ما تحدث في مشاريعنا الجولتان أو الثلاث التي تفاجئ من يقدّم لأول مرة.

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

ماذا يحدث إذا عادت المراجعة بنتائج؟

الرفض ليس بداية من الصفر. إذا كانت النتائج تخص كودًا يعمل على منصة Salesforce فقط، فارفع إصدارًا جديدًا من الحزمة المُدارة وابدأ المراجعة مجددًا من تبويب Packages. وإذا كان الإصلاح بالكامل في تطبيقك الخارجي، فيمكنك عادةً تعديل التقديم الحالي. وفي الحالتين، افتح case تحت "Partner Community & AppExchange" باسم الحزمة ومعرّفها وإصدارها، حتى يربط فريق المراجعة إعادة تقديمك بالقائمة الصحيحة.

FAQ

كم تستغرق مراجعة Salesforce الأمنية؟

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

هل يمكن لشركة ISV تخطي المراجعة لحزمة موجهة لجمهور محدود؟

لا. أي حزمة مُدارة أو حل Platform API أو حل Marketing Cloud API يُوزَّع عبر AppExchange يجب أن يجتاز المراجعة قبل إدراجه، بغض النظر عن حجم الجمهور المقصود.

هل تنطبق المراجعة على الحزم unmanaged؟

تنطبق عملية المراجعة الأمنية الرسمية تحديدًا على حزم 2GP و1GP المُدارة والحلول القائمة على API المقدمة للإدراج في AppExchange.

ما أكثر أخطاء CRUD/FLS شيوعًا؟

بناء controller أو REST endpoint يقرأ كائنًا أو يكتب فيه مباشرة عبر SOQL/DML دون التحقق أولًا من صلاحيات المستخدم الحالي، فيتجاوز قيود الـ profile وpermission set بصمت.

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