سياسة الإفصاح عن الثغرات الأمنية

توضح سياسة Vulnerability Disclosure Policy ("VDP") الإجراءات والقواعد التي تعتمدها ZynReach لاستقبال بلاغات الثغرات الأمنية المحتملة والتحقق منها ومعالجتها والتواصل بشأنها.

تهدف السياسة إلى:

• تشجيع الإبلاغ المسؤول عن الثغرات.
• حماية العملاء والمستخدمين.
• تقليل المخاطر الأمنية.
• منع الاستغلال غير المصرح به.
• توفير قناة واضحة للباحثين الأمنيين.
• تحسين أمن منصة ZynReach.
• دعم الإفصاح المسؤول عن الثغرات.

تنطبق هذه السياسة على الأصول والخدمات التي تملكها أو تديرها ZynReach والتي يتم إدراجها صراحةً ضمن نطاق هذه السياسة.

ويشمل النطاق، بحسب ما يتم تحديده من وقت لآخر:

ولا يعني ظهور أي نطاق أو عنوان IP أو خدمة مرتبطة بـZynReach أن استخدامها للاختبار مصرح به تلقائيًا.

• موقع ZynReach الرسمي.
• تطبيقات ZynReach الرسمية.
• APIs الرسمية.
• الخدمات والبنية التحتية التي يتم الإعلان عنها باعتبارها ضمن نطاق الاختبار.

تعتبر خارج نطاق هذه السياسة، ما لم يتم النص على خلاف ذلك:

• أنظمة العملاء.
• حسابات العملاء.
• أنظمة الموظفين.
• خدمات الأطراف الثالثة.
• Cloud Infrastructure التي لا تديرها ZynReach مباشرة.
• نطاقات غير مملوكة أو غير مدارة من ZynReach.
• أنظمة الموردين.
• الخدمات الشخصية للمستخدمين.
• أي نظام تم تحديده كتابيًا على أنه خارج النطاق.

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

ولا يجوز استخدام الاختبار لتحقيق منفعة شخصية أو تجارية أو للحصول على بيانات لا تخص الباحث.

يقصد بالثغرة الأمنية أي خلل أو ضعف في التصميم أو التنفيذ أو التكوين يمكن أن يؤدي، بصورة معقولة، إلى:

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

تلتزم ZynReach بتشجيع Responsible Disclosure.

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

يمكن للباحث الأمني الإبلاغ عن الثغرات من خلال قناة الأمان الرسمية التي تحددها ZynReach على موقعها أو Security Contact المعتمد.

يجب استخدام القناة الرسمية بدلًا من نشر تفاصيل الثغرة علنًا.

ينبغي أن يتضمن البلاغ، قدر الإمكان:

• عنوانًا واضحًا.
• وصف الثغرة.
• الأصل المتأثر.
• خطوات إعادة الإنتاج.
• Proof of Concept آمن.
• الأثر الأمني المتوقع.
• مستوى الخطورة المقترح.
• لقطات شاشة عند الحاجة.
• أي معلومات تقنية مفيدة.

يجب تقديم الحد الأدنى من الأدلة اللازمة لإثبات الثغرة.

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

إذا أدى الاختبار بصورة غير مقصودة إلى ظهور:

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

• بيانات شخصية.
• بيانات عملاء.
• بيانات اعتماد.
• مفاتيح API.
• أسرار تقنية.
• معلومات سرية.

يحظر على الباحث محاولة الوصول إلى Customer Data أو Personal Data لا تخصه.

ويعتبر الوصول غير الضروري إلى بيانات العملاء تجاوزًا لنطاق الاختبار.

لا يجوز للباحث:

إلا بالقدر الضروري للغاية لإثبات الثغرة وبما يتفق مع هذه السياسة.

• حذف البيانات.
• تعديلها.
• تشفيرها.
• نقلها.
• إتلافها.
• تغيير صلاحياتها.

يحظر إجراء أي اختبار قد يؤدي بصورة معقولة إلى:

• DDoS.
• DoS.
• Service Disruption.
• Resource Exhaustion.
• System Instability.

لا يجوز تنفيذ:

على Production Systems دون تصريح كتابي مسبق.

• Load Testing.
• Stress Testing.
• Flooding.
• Resource Exhaustion.

يحظر:

أو أي أدوات يكون استخدامها المقصود إحداث ضرر أو استمرار وصول غير مصرح به.

• تثبيت Malware.
• Ransomware.
• Backdoors.
• Persistence Mechanisms.
• Cryptominers.

بعد إثبات وجود الثغرة، يجب على الباحث التوقف عن الاستغلال.

ولا يجوز الاستمرار بهدف:

• زيادة الصلاحيات.
• الوصول إلى أنظمة أخرى.
• استخراج بيانات إضافية.
• إثبات نطاق أكبر من اللازم.

يحظر استخدام ثغرة في ZynReach للوصول إلى:

• أنظمة العملاء.
• أنظمة الموردين.
• خدمات أطراف ثالثة.
• أنظمة مستخدمين آخرين.

إذا أدت الثغرة إلى إمكانية الاستيلاء على حساب:

• يجب استخدام حساب اختبار يملكه الباحث متى أمكن.
• يحظر الاستيلاء على حساب مستخدم آخر.
• يحظر الوصول إلى بيانات الحساب الحقيقية.

يجوز اختبار آليات المصادقة بطريقة محدودة ومسؤولة.

ويجب تجنب:

• Credential Stuffing.
• Password Spraying واسع النطاق.
• Brute Force على حسابات حقيقية.
• محاولة تجاوز المصادقة بطريقة قد تؤثر على المستخدمين.

يجوز اختبار أخطاء الصلاحيات باستخدام حسابات اختبار مناسبة.

ويجب عدم استخدام حسابات مستخدمين حقيقيين دون تصريح.

يجوز استخدام أدوات الفحص الآلي إذا كانت:

• محدودة المعدل.
• غير مدمرة.
• لا تسبب ضغطًا غير مناسب.
• موجهة إلى الأصول المصرح باختبارها.

يجب احترام حدود الاستخدام ومعدلات الطلبات.

ويجوز لـZynReach حظر أو تقييد مصادر الاختبار التي تسبب خطرًا على الخدمة.

لا تشمل هذه السياسة عادةً:

إلا إذا تم الحصول على تصريح كتابي مسبق وصريح.

• Phishing.
• Vishing.
• Smishing.
• Impersonation.
• Social Engineering للموظفين.

لا يسمح باختبار الأمن المادي أو دخول المنشآت أو محاولة تجاوز وسائل الحماية المادية دون تصريح كتابي.

لا يجوز استهداف موظفي ZynReach أو خداعهم للحصول على:

دون موافقة مسبقة وصريحة.

• كلمات مرور.
• رموز MFA.
• بيانات اعتماد.
• معلومات سرية.

إذا تم اكتشاف ثغرة في خدمة طرف ثالث مستخدمة بواسطة ZynReach، يجب الإبلاغ عنها إلى ZynReach إذا كان لها أثر واضح على ZynReach.

ويجوز أيضًا الإبلاغ إلى الطرف الثالث وفق سياسة الإفصاح الخاصة به.

إذا كانت الثغرة ناتجة عن مكون أو مكتبة أو خدمة خارجية، فقد تحتاج ZynReach إلى التنسيق مع المورد أو الجهة المسؤولة قبل الإفصاح العام.

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

ولا يعني ذلك:

• منح تصريح مفتوح لجميع الأنظمة.
• السماح بالوصول إلى بيانات الآخرين.
• السماح بالاختبارات المدمرة.
• منح أي حقوق تتجاوز نطاق الأصول المعلنة.

يجب أن يكون الاختبار:

• حسن النية.
• غير ضار.
• محدودًا.
• متناسبًا مع الغرض من إثبات الثغرة.

يجب على الباحث اتخاذ جميع الإجراءات المعقولة لمنع:

• فقد البيانات.
• تعطيل الخدمات.
• انتهاك الخصوصية.
• كشف المعلومات السرية.
• التأثير على العملاء.

يجب على الباحث إيقاف الاختبار فورًا إذا:

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

بعد الانتهاء من الاختبار يجب إزالة:

بالقدر الذي يمكن للباحث التحكم فيه.

• الملفات التي أنشأها الباحث.
• الحسابات التجريبية التي أنشأها.
• Tokens التجريبية.
• أي أدوات أو بيانات اختبار.

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

ويجب حذفها فورًا بعد الإبلاغ، ما لم يكن الاحتفاظ بها ضروريًا بصورة معقولة لتقديم إثبات للثغرة وبالتنسيق مع ZynReach.

يجب أن يكون PoC:

ولا يجوز أن يتضمن بيانات سرية غير ضرورية.

• Minimal.
• Non-destructive.
• Reproducible.
• Relevant.

يجوز لـZynReach تصنيف الثغرات وفق مستويات مثل:

• Critical — قد تؤدي إلى سيطرة واسعة على الأنظمة أو كشف بيانات حساسة على نطاق كبير.
• High — قد تؤدي إلى وصول أو تأثير جوهري.
• Medium — قد يكون لها تأثير أمني محدود أو يتطلب استغلالها ظروفًا إضافية.
• Low — ثغرات ذات أثر منخفض أو صعوبة استغلال مرتفعة.

يكون تحديد مستوى الخطورة النهائي من اختصاص ZynReach استنادًا إلى:

ولا تلتزم ZynReach بالتصنيف الذي يقترحه الباحث.

• الأثر.
• قابلية الاستغلال.
• نطاق التأثير.
• المتطلبات المسبقة.
• طبيعة البيانات.
• وجود وسائل تخفيف.

بعد استلام البلاغ، يجوز لـZynReach:

• مراجعته.
• إعادة إنتاجه.
• تقييم أثره.
• تصنيفه.
• تحديد أولويته.
• إحالة البلاغ إلى الفريق المختص.

قد تتواصل ZynReach مع الباحث لطلب:

• معلومات إضافية.
• خطوات إعادة إنتاج.
• PoC إضافي.
• توضيح الأثر.
• معلومات عن بيئة الاختبار.

تسعى ZynReach إلى مراجعة البلاغات الأمنية في وقت مناسب وفق:

ولا يشكل أي وقت استجابة تقديري ضمانًا تعاقديًا.

• شدة البلاغ.
• عدد البلاغات.
• الموارد المتاحة.
• تعقيد المشكلة.

قد تقوم ZynReach بتأكيد:

• وجود الثغرة.
• قابلية إعادة الإنتاج.
• الأنظمة المتأثرة.
• نطاق التأثير.

إذا لم تتمكن ZynReach من إعادة إنتاج المشكلة، فقد يتم تصنيف البلاغ على أنه:

مع إمكانية إعادة تقييمه عند تقديم معلومات جديدة.

• Not Reproducible.
• Informational.
• False Positive.

إذا تم الإبلاغ عن الثغرة نفسها سابقًا، يجوز تصنيف البلاغ باعتباره Duplicate، مع الاحتفاظ بحق ZynReach في التواصل مع الباحث وفق تقديرها.

يجوز تقديم ملاحظات أمنية لا تمثل ثغرات مباشرة.

وتقوم ZynReach بتقييمها بحسب فائدتها الأمنية.

قد تقبل ZynReach تقارير تتعلق بتحسينات أمنية حتى إذا لم تمثل ثغرة قابلة للاستغلال.

قد لا تعتبر ZynReach بعض الأنواع ثغرات قابلة للإفصاح، ومنها، بحسب الحالة:

ولا يمثل ذلك قائمة حصرية.

• Missing Security Headers دون أثر أمني فعلي.
• معلومات عامة متاحة للعامة.
• Self-XSS دون مسار تأثير حقيقي.
• Clickjacking على صفحات غير حساسة.
• مشاكل إعدادات غير قابلة للاستغلال.
• إصدارات برمجيات غير مدعومة دون إثبات أثر.
• تقارير تعتمد على سيناريوهات نظرية فقط.

لا تعتبر محاولات Social Engineering ضد موظفي ZynReach ضمن نطاق هذه السياسة إلا إذا تم الاتفاق عليها مسبقًا.

لا يعتبر اختبار الأمن المادي ضمن نطاق VDP ما لم يتم التصريح به كتابةً.

لا يتم قبول اختبار DoS أو DDoS كجزء من هذه السياسة دون تصريح مسبق.

لا يجوز استخدام خدمات ZynReach لإرسال ما يلي أثناء الاختبار:

• Spam.
• رسائل جماعية غير مصرح بها.
• محتوى ضار.

يجب على الباحث احترام Privacy Rights لجميع المستخدمين.

ويحظر جمع أو كشف Personal Data غير الضرورية لإثبات الثغرة.

يجب الحفاظ على سرية:

• بيانات العملاء.
• بيانات المستخدمين.
• Security Details.
• Vulnerability Details.
• Credentials.
• Internal Information.

لا يجوز نشر تفاصيل الثغرة أو PoC أو بيانات العملاء قبل التنسيق مع ZynReach.

تفضل ZynReach استخدام Coordinated Vulnerability Disclosure.

ويجوز الاتفاق مع الباحث على:

• تاريخ الإفصاح.
• مستوى التفاصيل.
• CVE عند الاقتضاء.
• الإشارة إلى الباحث.

لا يوجد جدول زمني ثابت للإفصاح العام عن كل ثغرة.

ويتم تحديد التوقيت وفق:

• طبيعة الثغرة.
• مستوى الخطورة.
• مدى انتشارها.
• توفر الإصلاح.
• المخاطر على المستخدمين.

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

يحظر نشر أي:

حتى لو تم الحصول عليها أثناء اختبار أمني.

• Customer Data.
• Personal Data.
• Credentials.
• API Keys.
• Tokens.

يجوز لـZynReach، بموافقة الباحث، الإشارة إلى اسمه أو اسمه المستعار في Hall of Fame أو تقرير أمني.

ما لم يتم الإعلان صراحةً عن Bug Bounty Program منفصل، لا تشكل هذه السياسة وعدًا بدفع:

ويجوز لـZynReach إنشاء برنامج Bug Bounty منفصل بشروط مستقلة.

• مكافآت مالية.
• هدايا.
• تعويضات.

إذا أطلقت ZynReach Bug Bounty Program، فإن شروط ذلك البرنامج ستكون مستقلة عن هذه السياسة وتحدد:

• الأهلية.
• نطاق الأصول.
• المكافآت.
• الاستثناءات.
• شروط الدفع.

المشاركة في برنامج الإفصاح عن الثغرات لا تنشئ:

بين الباحث وZynReach.

• علاقة عمل.
• وكالة.
• شراكة.
• تمثيلًا قانونيًا.

لا تمنح هذه السياسة الباحث أي حق ملكية في:

• ZynReach.
• Source Code.
• Customer Data.
• Intellectual Property.

لا يجوز استخدام اسم ZynReach أو Zyntra Digital أو شعاراتها في أعمال تجارية أو تسويقية دون تصريح، باستثناء الإشارة الواقعية إلى البلاغ الأمني وفق القانون.

يجوز لـZynReach اتخاذ إجراءات مناسبة إذا قام شخص باستخدام VDP:

• للوصول غير المصرح به.
• لابتزاز الشركة.
• للحصول على منفعة غير مشروعة.
• لتعطيل الخدمات.
• لنشر بيانات مسروقة.

لا تعتبر المطالب المالية أو التهديد بالنشر مقابل عدم الإفصاح جزءًا من Responsible Disclosure.

ويجوز لـZynReach التعامل معها وفق القانون والسياسات الأمنية المعمول بها.

التهديد بنشر بيانات العملاء أو الأسرار التجارية لا يمنح الباحث أي حقوق إضافية بموجب هذه السياسة.

يجوز لـZynReach اتخاذ الإجراءات التقنية والقانونية المناسبة لحماية:

• المنصة.
• المستخدمين.
• العملاء.
• البيانات.

عندما يتطلب القانون ذلك، يجوز لـZynReach التعاون مع الجهات المختصة فيما يتعلق بالأنشطة التي تتجاوز هذه السياسة.

عندما يلتزم الباحث بهذه السياسة بحسن نية، تسعى ZynReach إلى التعامل معه باعتباره باحثًا أمنيًا مسؤولًا ضمن حدود القانون وهذه السياسة.

ولا تمنح هذه السياسة حصانة من المسؤولية عن الأفعال التي تقع خارج نطاقها.

لا تنطبق الحماية المذكورة في هذه السياسة على:

• الاختبارات المدمرة.
• الوصول إلى بيانات الآخرين عمدًا.
• الابتزاز.
• سرقة البيانات.
• تعطيل الخدمة.
• نشر معلومات سرية.
• استغلال الثغرة لتحقيق منفعة غير مشروعة.

يجوز لـZynReach إضافة أو إزالة أصول من نطاق السياسة.

ويتم تطبيق النسخة المنشورة حاليًا من السياسة على الاختبارات الجديدة.

يجوز لـZynReach اتخاذ إجراءات أمنية فورية، مثل:

إذا رأت أن الاختبار يشكل خطرًا على الخدمة أو المستخدمين.

• حظر IP.
• تعطيل Token.
• إغلاق Endpoint.
• تعليق حساب اختبار.

يجوز لـZynReach مطالبة الباحث بإيقاف الاختبار فورًا عندما:

ويجب احترام طلب الإيقاف.

• يكون الأصل خارج النطاق.
• يكون الاختبار مؤثرًا على Production.
• تكون هناك مخاطر على العملاء.
• تظهر بيانات حساسة.
• يتجاوز الباحث حدود هذه السياسة.

قد تتغير بنية ZynReach أو خدماتها بمرور الوقت.

وقد يؤدي ذلك إلى:

• إزالة ثغرة.
• تغيير طريقة إعادة الإنتاج.
• تغيير نطاق الأصول.
• تغيير التأثير.

يتحمل الباحث مسؤولية:

• الالتزام بهذه السياسة.
• استخدام أدوات آمنة.
• حماية بيانات الاعتماد.
• عدم تجاوز النطاق.
• عدم الإضرار بالأنظمة.

تلتزم ZynReach، ضمن مواردها وإجراءاتها، بـ:

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

لا تضمن ZynReach إصلاح كل تقرير أو إصلاحه خلال مدة محددة.

ويتم تحديد الأولوية وفق مستوى المخاطر والأثر.

قد تعالج ZynReach الثغرة من خلال:

بحسب طبيعة المشكلة.

• Code Fix.
• Configuration Change.
• Access Control.
• Monitoring.
• Compensating Control.
• Architecture Change.

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

بعد معالجة الثغرة، قد يتم إجراء اختبار للتحقق من:

• فعالية الإصلاح.
• عدم عودة المشكلة.
• عدم ظهور تأثيرات جانبية جوهرية.

يجوز لـZynReach نشر Security Advisory عندما ترى أن ذلك مفيد.

وقد يتضمن:

• وصفًا عامًا.
• مستوى الخطورة.
• الأنظمة المتأثرة.
• الإصلاح.
• إجراءات التخفيف.

إذا كان ذلك مناسبًا، يجوز لـZynReach أو جهة مختصة التنسيق للحصول على CVE أو معرف أمني مناسب.

يجوز لـZynReach تحديث هذه السياسة عند الحاجة بسبب:

• تغييرات تقنية.
• تغييرات قانونية.
• تغييرات أمنية.
• تغير نطاق الخدمة.

تعتبر النسخة المنشورة على القنوات الرسمية لـZynReach هي المرجع المعتمد لسياسة الإفصاح الحالية، ما لم يوجد اتفاق مكتوب مختلف.

تخضع هذه السياسة للقانون الواجب التطبيق على ZynReach والاتفاقيات ذات الصلة.

ولا تمنح هذه السياسة أي حقوق تتعارض مع القانون الإلزامي.

عدم قيام ZynReach بإنفاذ أي حكم من أحكام هذه السياسة في حالة معينة لا يشكل تنازلًا عن حقها في إنفاذه مستقبلًا.

إذا أصبح أي حكم من أحكام هذه السياسة غير صالح أو غير قابل للتنفيذ، تبقى باقي الأحكام نافذة بالقدر الذي يسمح به القانون.

تعمل هذه السياسة بالتكامل مع:

• Security & Trust Policy.
• Incident Response & Security Breach Notification Policy.
• Enterprise Security Addendum.
• Privacy Policy.
• Data Processing Agreement.
• Acceptable Use Policy.
• Terms of Service.

لا تعد هذه السياسة تعديلًا أو تنازلًا عن:

إلا إذا تم النص على ذلك صراحةً.

• Terms of Service.
• MSA.
• DPA.
• SLA.
• Enterprise Agreement.

يجب توجيه البلاغات الأمنية إلى قناة Security Contact الرسمية المنشورة بواسطة ZynReach.

Security Contact: يتم تحديد عنوان البريد الإلكتروني الرسمي وقناة الإبلاغ في صفحة Security / Vulnerability Disclosure على zynreach.com.

في حالة وجود ثغرة يمكن أن تؤدي إلى:

ينبغي الإشارة إلى أن البلاغ URGENT / CRITICAL SECURITY في عنوان الرسالة.

• اختراق واسع.
• كشف بيانات عملاء.
• تجاوز شامل للمصادقة.
• تعطيل واسع للخدمة.

يوصى بأن يكون البلاغ بالصيغة التالية:

• Title — [Severity] — [Short Vulnerability Description].
• Affected Asset — [Domain / Application / API].
• Description — [Description].
• Steps to Reproduce — [Steps].
• Proof of Concept — [Safe PoC].
• Impact — [Security Impact].
• Suggested Remediation — [Optional].
• Researcher Contact — [Contact Information].

يجب على الباحث عدم إرسال معلومات شخصية غير ضرورية.

وتستخدم ZynReach بيانات الاتصال التي يقدمها الباحث لأغراض التعامل مع البلاغ، وفق Privacy Policy والقانون المعمول به.

تتعامل ZynReach مع تفاصيل الثغرات غير المنشورة باعتبارها معلومات أمنية حساسة.

لا ينبغي تطوير أو نشر Exploit كامل ضد Production Environment عندما يكون إثبات المفهوم الآمن كافيًا لإثبات الثغرة.

يجب افتراض أن Production Environment يحتوي على بيانات وأنظمة حقيقية.

وعليه يجب اعتماد أقصى درجات الحذر أثناء الاختبار.

يفضل استخدام:

بدلًا من حسابات العملاء أو المستخدمين الحقيقيين.

• Test Accounts.
• Test Data.
• Researcher-Owned Accounts.

يجب دائمًا اختيار الطريقة الأقل تأثيرًا لإثبات الثغرة.

عند التعارض بين استكمال الاختبار وحماية المستخدمين أو البيانات أو الخدمة، يجب إعطاء الأولوية للحماية.

تحتفظ ZynReach بالحق في:

وذلك دون الإخلال بالحقوق القانونية للباحث أو أي طرف آخر.

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

يوضح الجدول التالي بيانات سجل هذه الوثيقة:

• اسم الوثيقة — Vulnerability Disclosure Policy.
• الاختصار — VDP.
• الشركة — Zyntra Digital.
• المنصة — ZynReach.
• الموقع — zynreach.com.
• الإصدار — 1.0.
• تاريخ السريان — 31 أغسطس 2026.
• التصنيف — Public / Security.
• المالك — Security / Engineering.
• المراجعة — دورية أو عند حدوث تغيير جوهري.
• الوثائق المرتبطة — Security & Trust Policy / Incident Response Policy / Enterprise Security Addendum / Privacy Policy / AUP / Terms of Service.

Zyntra Digital / ZynReach

• اسم المسؤول
• المسمى الوظيفي
• التوقيع
• التاريخ

هذه السياسة تهدف إلى تنظيم الإفصاح المسؤول عن الثغرات الأمنية في ZynReach، ولا تمنح أي شخص تصريحًا عامًا لاختبار جميع أنظمة ZynReach أو أنظمة العملاء أو أنظمة الأطراف الثالثة.

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

لا تمنح هذه السياسة حصانة مطلقة من المسؤولية القانونية، ولا تلغي أي حقوق أو التزامات يقررها القانون أو العقود السارية.

© 2026 Zyntra Digital. All Rights Reserved.