كيف تقيّم متصفح فريق: قائمة تحقق عملية

عرّف القرار قبل فتح صفحة الأسعار

يبدأ التقييم المفيد بالعمل، لا بقائمة الموردين. اكتب:

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

أبقِ أنواع الموارد منفصلة. فخطة بها 500 ملف محفوظ و100 ملف متزامن سحابياً وخمسة مقاعد وعشر جلسات متزامنة لا توفر 500 جلسة فريق متزامنة. حوّل كل حد إلى الوحدة التي يستهلكها سير عملك.

ثم حدّد البوابات غير القابلة للتفاوض. ومن أمثلتها:

1. بنى متصفح مدعومة وحديثة؛
2. عدم وجود تلف صامت للملفات أو كاتبين متزامنين؛
3. هويات فردية بوصول قابل للإلغاء وأقل صلاحيات؛
4. عدم وجود أسرار خام في السجلات العادية أو مخرجات الأتمتة؛
5. أدلة تدقيق قابلة للاستخدام؛
6. مسار استعادة وخروج مختبر؛ و
7. استخدام قانوني ومصرح به يتسق مع شروط الخدمة المنطبقة.

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

استخدم مقياس أدلة بسيطاً

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

النتيجة

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

الدليل

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

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

1. حالة المنتج وحدود المطالبة

• □ هل توجد بنية حقيقية قابلة للتثبيت لكل منصة ومعمارية تحتاج إليها؟
• □ هل يستطيع المورد تحديد إصدار التطبيق الحالي وإصدار المتصفح وتاريخ الإصدار؟
• □ هل وُسمت الميزات التجريبية والمعاينة والتجريبية والإتاحة العامة على نحو منفصل؟
• □ هل تتفق الوثائق والتجربة الفعلية بشأن الحدود والسلوك؟
• □ هل حُدد نطاق مطالبات الأمان والإتاحة والتشفير والأداء بمكونات وأدلة محددة؟
• □ هل نُشرت القيود المعروفة وسير العمل غير المدعوم وقواعد نهاية الدعم؟
• □ هل يتجنب المورد ضمانات عدم الظهور أو بقاء الحساب أو الوصول إلى خدمات خارجية؟

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

2. عزل الملفات وسلامتها

عرّف أولاً ما يسميه المنتج ملفاً. قد يقصد دليلاً دائماً لبيانات المتصفح أو سياق متصفح مؤقتاً أو أرشيفاً متزامناً أو جلسة بعيدة أو مجموعة إعدادات. هذه أشياء غير متكافئة.

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

• □ هل يملك كل ملف دائم حد تخزين وعمليات محدداً بوضوح؟
• □ هل يمنع المنتج كاتبين من فتح حالة الملف القابلة للتغيير نفسها؟
• □ هل عُزلت ملفات تعريف الارتباط والتخزين والذاكرة المؤقتة والسجل والإضافات والتنزيلات والأذونات والتفضيلات كما وُثقت؟
• □ هل وُسمت الجلسات المؤقتة والملفات الدائمة بشكل مختلف؟
• □ هل يستخدم التشغيل النظيف بيانات الملف المقصودة فقط؟
• □ هل يحفظ إعادة التشغيل الحالة نفسها التي يعد المنتج بالحفاظ عليها بالضبط؟
• □ هل ضُبطت أذونات الإضافات ومصادر تثبيتها؟
• □ هل تُعامل واردات الملفات كمدخلات غير موثوقة وتُتحقق قبل استخدامها؟
• □ هل يمكن عزل ملف تالف أو غير متوافق دون الكتابة فوق نسخة معروفة بسلامتها؟

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

3. حداثة المتصفح ووضع الحماية والتحديثات

المتصفح مكوّن تعتمد عليه سلامة النظام، ويحتاج إلى صيانة مستمرة. انتقل Chrome إلى إصدار نسخة Stable كل أسبوعين مع Chrome 153 في 8 سبتمبر 2026. لا يحدد جدول الإصدارات هذا مستوى الخدمة الذي يلتزم به كل مزوّد بدقة، لكنه يوضح لماذا لا تكفي عبارة «مبني على Chromium» من دون أدلة على الإصدارات والتحديثات.

• □ هل تستطيع ربط بنية متصفح المنتج بإصدار upstream دقيق؟
• □ هل يوجد هدف أو سجل منشور لاعتماد تحديثات الأمان upstream؟
• □ من يراقب إصدارات upstream والإصلاحات العاجلة؟
• □ هل تحديثات التطبيق والمتصفح موقعة وموثقة بصورة مستقلة عن اتصال التنزيل؟
• □ هل تستطيع التحقق من بصمات الأثر أو مصدر الإصدار أو سلسلة حيازة مكافئة؟
• □ هل التوزيعات مرحلية ومراقبة وقابلة للإيقاف؟
• □ هل يتجنب الرجوع استعادة إصدار غير آمن في ظل سياسة الأمان الحالية؟
• □ هل اختُبرت عمليات نقل مخطط الملف عبر مسارات الترقية والتخفيض المدعومة؟
• □ هل يبقي المنتج وضع حماية المتصفح مفعلاً في التشغيل العادي؟
• □ هل يستطيع المورد شرح أي عمليات بلا وضع حماية أو ذات صلاحيات وسبب ضرورتها؟

تصف Chromium وضع الحماية بأنه حد يقيد الكود غير الموثوق ويطبق أقل صلاحيات على الكود المحمي ووحدة التحكم فيه. راجع تصميم وضع الحماية في Chromium، ثم اطلب من المورد إظهار إعداد الإنتاج الفعلي. لا يثبت قول إن المنتج «يستخدم Chromium» بقاء كل وسائل التخفيف upstream مفعلة.

ولسلامة التحديث، يعد The Update Framework مرجعاً مفيداً لأنه يعالج صراحةً اختراق المستودعات ومفاتيح التوقيع. وتحدد مواصفة مصدر SLSA معلومات قابلة للتحقق عن مكان وزمان وكيفية إنتاج أثر. لا يلزم أن يستخدم المورد المشروعين نفسيهما، لكن عليه شرح كيف يعالج تصميمه هوية الأثر والمفاتيح المخترقة والرجوع والتجميد ومصدر البناء.

4. الهوية والأجهزة وأقل الصلاحيات

ينظم NIST SP 800-53 الإصدار 5 الضوابط عبر التحكم في الوصول والتدقيق والمصادقة والتخطيط للطوارئ والاستجابة للحوادث ومخاطر سلسلة التوريد. استخدم هذه العائلات كمحاور، لا كدليل على التنفيذ لمجرد توافق الإطار.

• □ هل يحصل كل شخص على هوية فردية بدلاً من تسجيل دخول جماعي؟
• □ هل المصادقة متعددة العوامل متاحة وقابلة للفرض للمسؤولين والأدوار الحساسة الأخرى؟
• □ هل تدعم خيارات مصادقة أقوى ومقاومة للتصيد حيث يتطلب الخطر ذلك؟
• □ هل يمكن ربط الهوية بموفرك عند الحاجة دون تجاوز تفويض المنتج؟
• □ هل الأدوار دقيقة بما يكفي لفصل العرض والتشغيل والتحرير والمشاركة والتصدير والحذف والفوترة والإدارة؟
• □ هل يمكن قصر الوصول على مؤسسة أو مساحة عمل أو مجلد أو مجموعة ملفات صريحة؟
• □ هل يمكن إلغاء جهاز أو جلسة أو مستخدم أو بيانات اعتماد خدمة أو دعوة بسرعة؟
• □ هل تملك حسابات الخدمة هوية وانتهاء ونطاقات وحدود معدل خاصة بها؟
• □ هل تظهر تغييرات الأذونات ومحاولات التفويض الفاشلة في مسار التدقيق؟
• □ هل يزيل إنهاء الخدمة الوصول دون الحاجة إلى تغيير كلمة مرور مشتركة؟

للمصطلحات الحالية وإرشادات ضمان المصادقة، راجع NIST SP 800-63B-4، الذي اكتمل في 31 يوليو 2025. وأكد ما الذي تغطيه مطالبات المورد بالمصادقة من المنتج: تسجيل الدخول إلى الموقع وفتح سطح المكتب وLocal API وCloud API والاسترداد والوصول إلى الدعم قد تستخدم آليات مختلفة.

5. البيانات الحساسة وحدود الثقة

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

• □ ما محتويات الملفات التي تبقى محلية افتراضياً؟
• □ ما البيانات الوصفية والمحتويات الحساسة التي تُرفع عند تفعيل المزامنة؟
• □ أين يحدث التشفير، وأي أطراف تستطيع الحصول على مفاتيح فك التشفير؟
• □ كيف تُحمى المفاتيح المحلية وتُنسخ وتُدوّر وتُستعاد؟
• □ ما الذي يستطيع مسؤولو المؤسسة ودعم المورد ومشغلو البنية وعملاء الأتمتة قراءته؟
• □ هل تُستبعد ملفات تعريف الارتباط وكلمات المرور وبيانات اعتماد الوكيل وأسرار العاملين الثنائيين ومفاتيح التشفير من الواجهة العادية والسجلات والقياس عن بعد وواجهات API ومخرجات الوكلاء؟
• □ هل تقارير الأعطال والتشخيص قابلة للمعاينة ومنقحة ومبنية على موافقة ومحدودة الاحتفاظ؟
• □ هل يستطيع الدعم العمل دون طلب أرشيفات ملفات خام أو بيانات اعتماد؟
• □ هل تُعامل الإضافات والأرشيفات والتنزيلات وبيانات التحديث المستوردة كمدخلات غير موثوقة؟
• □ هل يُعرّف الحذف عبر النسخ المحلية والكائنات السحابية والنسخ الاحتياطية والسجلات ومواد الدعم؟

لا تقبل كلمة «مشفّر» كإجابة كاملة. سجّل فئة البيانات والموقع وحد التشفير وحامل المفتاح ومسار الاسترداد والحالات التي توجد فيها صيغة نصية صريحة.

6. التعاون وقابلية التدقيق

• □ هل تظل ملكية الملف واضحة أثناء التعيين والتسليم؟
• □ هل يستطيع المنتج منع التعديلات المتزامنة أو حلها بشكل ظاهر؟
• □ هل تُسجل الدعوات وتغييرات الأدوار والتشغيلات والإيقافات والمشاركات والتصديرات والحذف ونداءات الأتمتة وإجراءات الاسترداد؟
• □ هل يحدد كل حدث المنفذ البشري وحمولة العمل المفوضة والمورد والوقت والقرار والنتيجة؟
• □ هل تُسجل القيم قبل التغيير وبعده لتغييرات الإعداد المادية مع تنقيح الأسرار؟
• □ هل الساعات والمناطق الزمنية وترتيب الأحداث ومعرّفات الطلب واضحة؟
• □ هل وُثقت ضوابط الوصول إلى التدقيق وتنسيق التصدير والاحتفاظ والحذف؟
• □ هل يستطيع المسؤول تغيير السجلات نفسها المستخدمة لمراجعة ذلك المسؤول أو حذفها؟
• □ هل يستطيع فريقك تصدير السجلات إلى نظام المراقبة أو التحقيق؟
• □ هل يستمر التسجيل أو يُخزّن بأمان، أم تُمنع العملية عند تعذّر الوصول إلى وجهة التدقيق؟

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

7. الاسترداد والانقطاع والخروج

تبقى مطالبة النسخ الاحتياطي ناقصة إلى أن تُختبر الاستعادة. يتضمن إطار NIST للأمن السيبراني 2.0 نتائج لإنشاء النسخ الاحتياطية وحمايتها وصيانتها واختبارها، والتحقق من أصول الاستعادة والأنظمة المستعادة.

• □ هل تستطيع إنشاء نسخة متسقة مع احترام أقفال الملفات؟
• □ هل يمكن تحديد الإصدارات المحلية والمتزامنة وترتيبها؟
• □ هل يستطيع مشغّل استعادة إصدار محدد دون تدمير النسخة الحالية؟
• □ هل يُتحقق من البيانات المستعادة وتوافق المتصفح قبل استئناف الاستخدام العادي؟
• □ ماذا يحدث بعد قتل عملية المتصفح أو فقدان الشبكة أو امتلاء القرص أو انقطاع الرفع أو تعطل التطبيق؟
• □ هل تُحمى آخر نسخة معروفة بسلامتها من إصلاح فاشل؟
• □ هل يمكن إزالة جهاز ملغى أو مفقود دون فقدان مسار الاسترداد الوحيد؟
• □ هل تُحمى مفاتيح أو رموز الاسترداد من الفقد العرضي ومن وصول مسؤول غير مقيد؟
• □ هل يستطيع الفريق تصدير بياناته بصيغة موثقة والتحقق من التصدير قبل إلغاء الخدمة؟
• □ هل توجد عملية مدعومة للحذف وإغلاق الحساب مع بيان واضح للاحتفاظ المتبقي؟

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

8. الأتمتة وضوابط المطورين

• □ هل يعرض المنتج عمليات مجال ذات إصدارات بدلاً من وصول غير مقيد إلى نظام الملفات أو العمليات؟
• □ هل وُثقت قدرات API وCLI وSDK وPlaywright وCDP وWebDriver وwebhook والوكلاء منفصلة؟
• □ هل توجد مصفوفة توافق دقيقة بين المتصفح والعميل؟
• □ هل يمكن تقييد بيانات الاعتماد حسب المستأجر والملف والإجراء والجمهور والانتهاء والمعدل والتكلفة؟
• □ هل تتطلب الإجراءات المدمرة أو الجماعية أو الظاهرة خارجياً أو الحاملة للأسرار أو المسببة للإنفاق سياسة أو موافقة أقوى؟
• □ هل ترتبط المعاينات بالطلب الدقيق الذي سينفذ؟
• □ هل الأوامر المغيرة قابلة للتكرار بأمان أو صريحة بشأن النتائج المجهولة؟
• □ هل يمكن إلغاء العمليات الطويلة واستئنافها بأمان؟
• □ هل يسري الإلغاء أثناء مهمة نشطة؟
• □ هل يمكن إسناد قرارات الأتمتة إلى مسار التدقيق نفسه مثل الإجراءات البشرية؟
• □ هل تبقى مخرجات الأتمتة العادية مفيدة دون إرجاع حالة الجلسة الخام؟
• □ هل رسائل الخطأ محددة بما يكفي للاسترداد دون تسريب الأسرار؟

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

9. تجربة المشغّل والإتاحة

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

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

10. الملاءمة التجارية والتشغيلية

• □ هل تُسعّر المقاعد والملفات المحفوظة والمتزامنة والتخزين وحركة المرور والجلسات المتزامنة ومعدل API وعمال الأتمتة ومستويات الدعم منفصلة وبوضوح؟
• □ أي الحدود توقف صارم أو زيادة تكلفة أو شروط استخدام عادل؟
• □ هل يمكن أن تحدث تغييرات الفوترة أو السعة دون موافقة المسؤول؟
• □ هل وُثقت بروتوكولات الوكيل وطرق المصادقة والإضافات وبيئات الشبكة المدعومة؟
• □ هل تغطي سياسة الدعم حوادث تحديث المتصفح وتلف الملفات وفشل الاستعادة وتقارير الأمان واسترداد الحساب؟
• □ هل حالة الخدمة واتصالات الحوادث ومسارات التصعيد حقيقية ومراقبة؟
• □ هل يحدد العقد إعادة البيانات وحذفها وتغييرات الأسعار والتعليق والإنهاء؟
• □ هل تستطيع المغادرة دون فقدان الأدلة اللازمة لإثبات نقل آمن؟

احسب التكلفة باستخدام عملك المتزامن في الذروة والحالة المتوقعة المتزامنة وحجم الأتمتة ومتطلبات الدعم. سجّل الضرائب والالتزامات السنوية والزيادات وتكلفة الترحيل. وتجنب مقارنة أكبر رقم للملفات في كل صفحة أسعار فقط.

خطة تجربة مضبوطة

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

1. سجّل البيئة. دوّن إصدارات التطبيق والمتصفح ونظام التشغيل والعتاد والشبكة ونوع الوكيل ومجموعة الإضافات وخطة الحساب وتاريخ الاختبار.
2. أنشئ دورين وعدة ملفات. أدرج مسؤولاً ومشغّلاً مقيداً ومجلدات منفصلة وملفاً واحداً على الأقل لا يجوز للمشغّل الوصول إليه.
3. شغّل سير العمل العادي. شغّل الملفات واستخدمها وأوقفها وسلّمها وأعد تشغيلها. سجّل الحالة المتوقعة والفعلية.
4. اختبر الرفض. حاول بالهوية المقيدة الوصول إلى ملف خارج النطاق وتصديره وتغيير دور وتشغيل أمر أتمتة.
5. اختبر الانقطاع. ببيانات قابلة للتخلص، اقطع إيقاف المتصفح أو خطوة المزامنة باستخدام طريقة يدعمها المورد أو طريقة آمنة أخرى. تحقق من مسار الاسترداد.
6. استعد وقارن. استعد لقطة معروفة إلى نسخة جديدة، وتحقق من سلامتها، وأبقِ النسخة الحالية حتى القبول.
7. ألغِ الوصول. أزل مستخدماً وجهازاً وجلسة وبيانات اعتماد خدمة؛ وأكد الرفض في الواجهة وAPI وافحص أحداث التدقيق.
8. افحص قابلية النقل. صدّر البيانات المسموح بها، وافحص صيغتها الموثقة، وأعد استيرادها إلى وجهة قابلة للتخلص إن كان ذلك مدعوماً، وحدد ما استُبعد.
9. راجع الإتاحة. أكمل المهام الأساسية بلوحة المفاتيح والتقنية المساعدة ذات الصلة على كل منصة مطلوبة.
10. طابق التكاليف والمطالبات. قارن استخدام الموارد الملحوظ واستجابات الدعم بالمقترح والعقد.

نموذج سجل القرار

المتطلب	الأولوية	النتيجة	الدليل والتاريخ	القيد أو الخطر	المالك والإجراء التالي
مثال: لا يستطيع المشغّل تصدير حالة الجلسة	بوابة	ناجح	تجربة مضبوطة، الإصدار X، YYYY-MM-DD	سطح API فقط؛ لم يُختبر CLI	على مسؤول الأمان اختبار CLI

اختم التقييم بأربع قوائم صريحة:

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

إشارات الخطر الشائعة

أوقف القرار عندما:

• يتعذر تحديد إصدار المتصفح؛
• يجب تعطيل وضع الحماية للاستخدام العادي؛
• يشترك المسؤولون والأتمتة في بيانات اعتماد دائمة؛
• يعتمد المنتج على مشاركة ملفات تعريف الارتباط أو كلمات المرور الخام لتسليم الفريق؛
• يستطيع API تصدير أسرار تدعي الواجهة حمايتها؛
• تحذف أحداث التدقيق المنفذ أو يتعذر تصديرها؛
• تعني كلمة «نسخ احتياطي» وجود نسخة سحابية فقط دون استعادة معروضة؛
• يتعذر على المورد شرح الكتابات المنقطعة أو الوصول المتزامن إلى الملفات؛
• لا يملك سير عمل حرج غير ميسر بديلاً؛
• يتطلب تقرير أمان إرسال أسرار عبر بريد إلكتروني عادي؛ أو
• تعد الادعاءات المتعلقة بالمنتج بعدم القابلية للكشف أو وصول الحساب المضمون أو التحايل على إنفاذ المنصة.

نتيجة «لم يتحقق» ليست اتهاماً. إنها عبارة دقيقة عن دليل مفقود. أبقها ظاهرة حتى يقدم المورد دليلاً أو يختبر فريقك السلوك أو يقبل مالك القرار الخطر.