حوكمة أمن البرمجة بالإحساس: كيفية اعتماد Codex وClaude Code وCursor وعوامل البرمجة بالذكاء الاصطناعي بأمان

أدوات البرمجة بالذكاء الاصطناعي تغير طريقة عمل فرق البرمجيات.

يستخدم المطورون الآن OpenAI Codex، Claude Code، Cursor، Windsurf، GitHub Copilot، Lovable، Bolt.new، v0، Replit، OpenCode، Gemini CLI، Continue، و Zed AI لتوليد الأكواد، إعادة هيكلة الملفات، بناء واجهات المستخدم، إنشاء الاختبارات، شرح قواعد الأكواد، وأتمتة مهام التطوير.

غالبًا ما يُطلق على هذه الطريقة الجديدة لبناء البرمجيات اسم البرمجة بالإحساس (vibe coding) : وصف النتيجة المرجوة بلغة طبيعية وترك مساعد أو وكيل برمجة بالذكاء الاصطناعي لإنتاج معظم التنفيذ.

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

السؤال الأكبر هو الحوكمة:

كيف يمكن لفرق الهندسة والأمن اعتماد وكلاء الترميز بالذكاء الاصطناعي بأمان دون فقدان الرؤية، جودة المراجعة، التحكم في التبعيات، أو المساءلة؟

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

جديد في أمان البرمجة بالإحساس؟ ابدأ هنا: أمان البرمجة بالإحساس: تأمين الكود المُنشأ بالذكاء الاصطناعي قبل نشره

تريد التعمق في المعالجة؟ اقرأ: المعالجة الأصلية بالذكاء الاصطناعي لأمان البرمجة بالإحساس

---

لماذا تحتاج البرمجة بالإحساس إلى حوكمة، وليس مجرد فحص

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

كان سير العمل الطبيعي يبدو كالتالي:

يكتب المطور الكود → طلب السحب → مراجعة الكود → فحص الأمان → الإصلاح → الدمج

البرمجة بالإحساس تغير سير العمل:

موجه → كود مولّد بالذكاء الاصطناعي → وكيل يعدّل الملفات → تشغيل الاختبارات → طلب سحب → دمج

في بعض الحالات، يمكن لوكيل برمجة بالذكاء الاصطناعي:

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

هذا أمر قوي. كما أنه يغير نموذج المخاطر.

لم تعد فرق الأمان تسأل فقط: “هل هذه الشفرة معرضة للخطر؟” بل تحتاج أيضًا إلى السؤال:

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

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

المخاطر الرئيسية لحوكمة الأمن في الترميز بالأسلوب “Vibe Coding”

لا يُحدث الترميز بالأسلوب “Vibe Coding” فئات جديدة تمامًا من الثغرات الأمنية. بدلاً من ذلك، فإنه يُغير سرعة إدخال الثغرات وقبولها وشحنها.

1. الكود المُنشأ بالذكاء الاصطناعي غير المُتتبع

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

قد يستخدم المطور Claude Code لإعادة هيكلة الواجهة الخلفية، وCursor لتغييرات الواجهة الأمامية، وCodex CLI للتحرير عبر الطرفية، وGitHub Copilot للإكمال التلقائي، وLovable أو v0 لتوليد الواجهات بسرعة.

إذا لم يتم تتبع أي من هذا، فلا تستطيع فرق الأمن التمييز بين:

• كود مكتوب بواسطة الإنسان
• كود بمساعدة الذكاء الاصطناعي
• كود مولّد بواسطة وكيل
• إصلاحات مولّدة بالذكاء الاصطناعي
• تبعيات مولّدة بالذكاء الاصطناعي

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

2. انحراف التبعيات الناتج عن وكلاء الذكاء الاصطناعي

غالبًا ما يقترح وكلاء برمجة الذكاء الاصطناعي حزمًا كجزء من الحل.

يؤدي ذلك إلى مخاطر في سلسلة التوريد:

• حزم ضعيفة
• حزم مهجورة
• حزم ذات أسماء مشابهة للتصيد
• أسماء حزم وهمية
• حزم مشبوهة تم نشرها حديثًا
• تعارضات في التراخيص
• تبعيات غير ضرورية للميزة الفعلية

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

3. مراجعة ضعيفة لمنطق التفويض

قد تبدو الشيفرة المُنشأة بواسطة الذكاء الاصطناعي صحيحة وظيفيًا بينما تفتقر إلى حدود الأمان.

تشمل الأمثلة الشائعة:

• التحقق من تسجيل دخول المستخدم، ولكن ليس من ملكيته للمورد
• إنشاء إجراءات إدارية دون التحقق من الصلاحيات
• كشف بيانات المستأجرين عبر المؤسسات
• تعطيل أمان مستوى الصف (Row-Level Security) أثناء النمذجة الأولية
• إنشاء نقاط نهاية API تُعيد بيانات أكثر من اللازم

هذه المشكلات خطيرة بشكل خاص لأنها غالبًا ما تجتاز الاختبارات الأساسية.

4. الثقة المفرطة في الإصلاحات المُنشأة بواسطة الذكاء الاصطناعي

لا يُستخدم الترميز الحدسي (Vibe coding) فقط لإنشاء شيفرة جديدة. بل يطلب المطورون أيضًا من أدوات الذكاء الاصطناعي إصلاح الشيفرة المعطلة.

وهذا يُشكل مشكلة حوكمة ثانية: قد يكون الإصلاح نفسه محفوفًا بالمخاطر.

يمكن للإصلاح المُنشأ بواسطة الذكاء الاصطناعي أن:

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

تصحيح الأمان يحتاج إلى تحقق. الإصلاح ليس آمنًا فقط لأنه تم إنشاؤه بسرعة.

5. فقدان قابلية التدقيق

بالنسبة للفرق الخاضعة للتنظيم، لن يكون السؤال المستقبلي فقط “هل تم فحص الكود؟”

قد يصبح:

• من وافق على هذا التغيير الناتج عن الذكاء الاصطناعي؟
• أي نموذج أو وكيل برمجي ساهم فيه؟
• ما هي فحوصات الأمان التي تم إجراؤها؟
• أي نقاط ضعف تم قبولها أو تصحيحها أو تأجيلها؟
• ما الدليل الموجود على قرار التصحيح؟

لهذا السبب يجب أن تتضمن أمان الترميز بالاهتزاز سجلات تدقيق، وليس مجرد تنبيهات.

إطار حوكمة لأمان الترميز بالاهتزاز

لا ينبغي لبرنامج أمان الترميز بالاهتزاز العملي أن يمنع المطورين من استخدام Codex أو Claude Code أو Cursor أو Windsurf أو Copilot أو أدوات الترميز بالذكاء الاصطناعي الأخرى.

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

1. تحديد سير عمل الترميز بالذكاء الاصطناعي المعتمد

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

سير العمل	أمثلة	متطلبات الحوكمة
إكمال الكود بالذكاء الاصطناعي	GitHub Copilot، Cursor autocomplete	مراجعة الكود العادية والفحص
إعادة الهيكلة بمساعدة الذكاء الاصطناعي	Claude Code، Codex، Cursor، Windsurf	مراجعة طلب السحب مطلوبة
تغييرات الكود الوكيلية	Claude Code، Codex CLI، Cursor Agent، Windsurf Cascade	فحص أمني وموافقة بشرية مطلوبة
واجهة المستخدم أو النموذج الأولي المُنشأ	Lovable، Bolt.new، v0، Replit	مراجعة قبل الاستخدام في الإنتاج
تثبيت التبعيات	Codex، Claude Code، OpenCode، وكلاء الطرفية	تحليل تكوين البرامج (SCA) والتحقق من صحة الحزمة مطلوبان
إنشاء إصلاح أمني	مساعد الإصلاح بالذكاء الاصطناعي، أدوات أمن التطبيقات	التحقق مطلوب قبل الدمج

يمنح هذا المطورين الوضوح دون حظر الأدوات المفيدة.

2. تصنيف مناطق الشفرة عالية المخاطر

ليست كل الملفات تحتاج إلى نفس المستوى من المراجعة.

يجب تطبيق ضوابط إضافية عندما تلمس الشفرة المولدة بالذكاء الاصطناعي:

• المصادقة
• التفويض
• تدفقات الدفع
• بيانات المستخدم
• الوصول متعدد المستأجرين
• قواعد أمان قاعدة البيانات
• الأسرار وتكوين البيئة
• خطوط أنابيب CI/CD
• البنية التحتية كشفرة
• نقاط نهاية API العامة
• قوائم التبعيات

تغيير صغير في نص واجهة المستخدم تم إنشاؤه بواسطة v0 ليس مثل تغيير تم إنشاؤه بواسطة الذكاء الاصطناعي في وسيط التحكم في الوصول.

3. وضع فحوصات الأمان قبل الدمج

المسح المتأخر يؤدي إلى معالجة متأخرة.

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

تشمل الفحوصات المفيدة:

• SAST لأنماط الشفرات غير الآمنة
• SCA للتبعيات الضعيفة
• فحص الأسرار للمفاتيح والرموز وبيانات الاعتماد
• فحص IaC للإعدادات الافتراضية غير الآمنة للبنية التحتية
• اختبار API لمشكلات التحكم في الوصول
• DAST لسلوك وقت التشغيل
• إنشاء SBOM لرؤية التبعيات

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

4. طلب المراجعة البشرية للتغييرات الوكيلية

يمكن لوكلاء برمجة الذكاء الاصطناعي إنشاء تغييرات كبيرة بسرعة. وهذا يجعل المراجعة البشرية أكثر أهمية، وليس أقل.

يجب على المراجعين إيلاء اهتمام خاص لـ:

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

سؤال مراجعة مفيد هو:

هل حل الوكيل المهمة بأكثر طريقة آمنة معقولة، أم فقط بأسرع طريقة؟

5. التحقق من الإصلاح المُولّد بواسطة الذكاء الاصطناعي

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

يجب أن يجيب سير عمل الإصلاح الجيد على:

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

هنا يمكن لمنصات أمن التطبيقات (AppSec) وأدوات المعالجة المدعومة بالذكاء الاصطناعي أن تساعد، طالما بقيت جزءًا من سير عمل مراجع. تقليل متوسط وقت المعالجة (MTTR) مهم — لكن السرعة لا ينبغي أن تأتي على حساب التحقق.

مشهد الأدوات لأمن البرمجة بالأسلوب الحيوي (Vibe Coding)

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

الفئة	أمثلة على الأدوات	الدور
وكلاء ومساعدي البرمجة بالذكاء الاصطناعي	Codex، Claude Code، Cursor، Windsurf، GitHub Copilot، OpenCode، Gemini CLI، Continue، Zed AI	إنشاء وتحرير وشرح وإعادة هيكلة الكود
بناة التطبيقات بالذكاء الاصطناعي	Lovable، Bolt.new، v0، Replit	إنشاء سريع للتطبيقات والواجهات الأمامية والنماذج الأولية
منصات أمان الكود وأمن التطبيقات	Checkmarx، Plexicus، Snyk، Semgrep، Veracode، GitHub Advanced Security	فحص الكود والتبعيات والأسرار وانتهاكات السياسات
المعالجة بالذكاء الاصطناعي والتوجيه للمطورين	Plexicus، Checkmarx One Assist، GitHub Copilot Autofix، Snyk، Semgrep Assistant	مساعدة المطورين في فهم النتائج وإصلاحها
أمان سلسلة التوريد	أدوات SCA، أدوات SBOM، فحوصات سمعة الحزم	التحقق من صحة التبعيات التي تم إدخالها عبر سير عمل الذكاء الاصطناعي
التحقق من وقت التشغيل وواجهات API	DAST، اختبار أمان API، أدوات اختبار الاختراق	اكتشاف المشكلات التي قد يفوتها التحليل الثابت
الحوكمة والتدقيق	منصات GRC، فحوصات سياسات SDLC، سجلات التدقيق	تتبع الملكية والاستثناءات والموافقات وأدلة المعالجة

Plexicus مبني للفرق التي ترغب في اكتشاف الثغرات وترتيب أولوياتها ومعالجتها عبر الكود والتبعيات وسير عمل التطبيقات مع ازدياد استخدام الكود المولد بالذكاء الاصطناعي في التطوير اليومي.

أهم نقطة هي أن أمان الترميز بالأسلوب التفاعلي (vibe coding) لا يُحل بأداة واحدة. بل يتطلب عملية واضحة، وفحوصات مبكرة، وإرشادات للمعالجة، وأدلة على أن التغييرات عالية المخاطر قد روجعت.

قالب سياسة أمان الترميز بالأسلوب التفاعلي

يمكن للفرق البدء بسياسة داخلية خفيفة.

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

يجب مراجعة الكود المولد بالذكاء الاصطناعي قبل الدمج.

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

التبعيات الجديدة التي يتم تقديمها من خلال سير العمل المدعوم بالذكاء الاصطناعي يجب أن تجتاز التحقق من تحليل تكوين البرامج (SCA) والتحقق من صحة الحزمة.

يجب عدم وضع الأسرار في الاستفسارات (prompts)، الكود المُنشأ، الالتزامات (commits)، أو الأمثلة.

يجب التحقق من الإصلاحات الناتجة عن الذكاء الاصطناعي من خلال الفحص، الاختبار، أو المراجعة اليدوية قبل الدمج.

يجب توثيق الاستثناءات الأمنية مع المالك، السبب، المخاطر، وتاريخ الانتهاء.

هذا النوع من السياسات بسيط، لكنه يمنح الفرق خطًا أساسيًا مشتركًا.

قائمة مراجعة عملية للفرق التي تستخدم Codex، Claude Code، Cursor، والعوامل الذكية (AI Agents)

السؤال	لماذا هو مهم؟
هل نعرف أي أدوات البرمجة بالذكاء الاصطناعي يستخدمها مطورونا؟	الرؤية هي الخطوة الأولى للحوكمة.
هل تتم مراجعة طلبات السحب (Pull Requests) المُنشأة بالذكاء الاصطناعي بواسطة بشر؟	التغييرات الوكيلة (Agentic) يمكن أن تكون واسعة النطاق ودقيقة.
هل يتم فحص التبعيات (Dependencies) المُنشأة قبل الدمج؟	يمكن لأدوات الذكاء الاصطناعي تقديم حزم ضعيفة أو مشبوهة.
هل يتم حظر الأسرار (Secrets) قبل الالتزام (Commit)؟	قد تحتوي الأمثلة المُنشأة على عناصر نائبة غير آمنة أو مفاتيح مكشوفة.
هل تتم مراجعة تغييرات المصادقة (Auth) والتحكم في الوصول (Access Control) بعناية؟	غالبًا ما تمر هذه الأخطاء عبر اختبارات الوظائف.
هل تخضع الملفات عالية المخاطر لمراجعة أكثر صرامة؟	ليس لكل الكود المُنشأ نفس درجة المخاطرة.
هل يتم التحقق من صحة الإصلاحات المُنشأة بالذكاء الاصطناعي؟	يمكن للإصلاح المُنشأ أن يخلق ثغرة أمنية جديدة.
هل نتتبع قرارات المعالجة؟	مسارات التدقيق (Audit trails) مهمة للأمن والامتثال.
هل يتلقى المطورون إرشادات علاجية قابلة للتنفيذ؟	التنبيهات بدون إصلاحات تبطئ الفرق.
هل نقيس الوقت المستغرق للمعالجة؟	سرعة الإصلاح أهم من حجم الاكتشافات.

كيف يبدو الوضع المثالي

لا يحظر برنامج أمان الترميز الناضج أدوات الترميز بالذكاء الاصطناعي. بل يجعل استخدامها أكثر أمانًا.

يبدو الوضع المثالي على النحو التالي:

• يمكن للمطورين استخدام Codex وClaude Code وCursor وWindsurf وGitHub Copilot وLovable وBolt.new وv0 وغيرها من الأدوات.
• تدرك فرق الأمان أين يدخل الكود المُنشأ بالذكاء الاصطناعي في دورة حياة تطوير البرمجيات (SDLC).
• تخضع التغييرات عالية المخاطر لمراجعة إضافية.
• يتم التحقق من صحة التبعيات التي تُدخلها وكلاء الذكاء الاصطناعي.
• يتم حظر الأسرار والتكوينات غير الآمنة في وقت مبكر.
• يتم التحقق من الإصلاحات المُنشأة بالذكاء الاصطناعي قبل الدمج.
• يتم تحديد أولويات نتائج أمان التطبيقات (AppSec) بناءً على المخاطر الفعلية.
• تظهر إرشادات المعالجة بالقرب من سير عمل المطور.
• يتم توثيق قرارات الأمان وتكون قابلة للتدقيق.

هذا هو التوازن الذي تحتاجه الفرق: السرعة دون فقدان السيطرة.

الخاتمة

أصبحت البرمجة بالاهتزاز (Vibe coding) جزءًا من تطوير البرمجيات العادي.

Codex، Claude Code، Cursor، Windsurf، GitHub Copilot، Lovable، Bolt.new، v0، Replit، OpenCode، Gemini CLI، Continue، وZed AI تجعل المطورين أسرع. لكن التطوير الأسرع يتطلب أيضًا رؤية أفضل، وسير عمل مراجعة أقوى، ومعالجة أكثر موثوقية.

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

أمان البرمجة بالاهتزاز يدور حول جعل الكود المُنشأ بواسطة الذكاء الاصطناعي آمنًا بما يكفي للإنتاج: مرئي، مُراجع، ممسوح ضوئيًا، مُعالج، مُتحقق منه، وقابل للتدقيق.

Plexicus يساعد الفرق على اعتماد أدوات البرمجة بالذكاء الاصطناعي دون فقدان السيطرة على الأمان. احجز عرضًا توضيحيًا لترى كيف يعمل في مسار عملك.

---

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

ما هي حوكمة أمان البرمجة بالأسلوب الحيوي (Vibe Coding)؟

حوكمة أمان البرمجة بالأسلوب الحيوي هي مجموعة السياسات والضوابط وسير العمل التي تساعد فرق الهندسة والأمان على استخدام أدوات البرمجة بالذكاء الاصطناعي بأمان — دون فقدان الرؤية، أو جودة المراجعة، أو التحكم في التبعيات، أو المساءلة.

لماذا تحتاج وكلاء البرمجة بالذكاء الاصطناعي إلى حوكمة خاصة؟

يمكن لوكلاء البرمجة بالذكاء الاصطناعي مثل Claude Code وCodex وCursor وWindsurf قراءة المستودعات، وتحرير ملفات متعددة، وإدخال تبعيات، وتعديل منطق المصادقة في جلسة واحدة. تخلق هذه السرعة خطرًا إذا لم يتم مراجعة التغييرات وفحصها والتحقق من صحتها قبل الإنتاج.

ما هي أكبر مخاطر الحوكمة في البرمجة بالأسلوب الحيوي؟

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

ما هي فحوصات الأمان التي يجب إجراؤها على الكود المُنشأ بواسطة الذكاء الاصطناعي؟

يجب على الفرق إجراء فحوصات SAST وSCA وفحص الأسرار وفحص البنية التحتية ككود (IaC) واختبار التحكم في الوصول إلى واجهة برمجة التطبيقات (API) على طلبات السحب المُنشأة بواسطة الذكاء الاصطناعي - ويفضل أن يكون ذلك قبل الدمج، وليس بعد النشر.

كيف يساعد Plexicus في حوكمة أمان برمجة الـ vibe coding؟

Plexicus يساعد الفرق على اكتشاف الثغرات الأمنية في الكود المُنشأ بواسطة الذكاء الاصطناعي عبر دورة حياة تطوير البرمجيات (SDLC) وتحديد أولوياتها ومعالجتها — ويغطي SAST، وSCA، والأسرار، وواجهات برمجة التطبيقات (APIs)، والبنية التحتية ككود (IaC)، وتكوين السحابة — مع تحديد الأولويات بناءً على السياق والمعالجة المُتحقق منها.