ما هي OWASP؟ مشاريعها ووثائقها ومتى تستخدم كلاً منها

إذا عملت في أي مشروع برمجي لفترة فلا بد أنك سمعت اسم OWASP في أكثر من مكان، فكراسة الشروط Requirements Document من العميل تطلب أن يكون التطبيق «متوافقاً مع OWASP»، وتقرير أداة الفحص الثابت SAST يضع بجانب كل نتيجة وسماً مثل OWASP-A05:2025، ومختبر الاختراق Penetration Tester يكتب في تقريره أنه اتبع «منهجية OWASP»، وزميلك في الفريق يرسل لك رابط ورقة OWASP لتخزين كلمات المرور. وعند هذه النقطة يتساءل المطور بحق: هل OWASP معيار أم شركة أم قائمة؟ وأي وثيقة من وثائقها يقصدها العميل؟ والإجابة أن OWASP مؤسسة غير ربحية تنشر مئات المشاريع المختلفة، منها قوائم توعية، ومنها معايير تحقق، ومنها أدلة اختبار، ومنها أدوات تشغلها على سيرفرك، ولكل نوع منها وظيفة ومرحلة يستخدم فيها، وإذا خلطت بينها طلبت من المورد الشيء الخطأ أو اطمأننت إلى شيء لا يضمن ما تظنه.

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

وسوف نناقش في هذا المقال ما يلي:

• ما هي مؤسسة OWASP، ومن يديرها، ولماذا كل ما تنشره مجاني ومفتوح، وأين فروعها المحلية Chapters في المنطقة العربية.
• مستويات نضج المشاريع Project Maturity من Incubator إلى Flagship، ولماذا يهمك المستوى عندما تختار مشروعاً.
• عائلات الوثائق الخمس: قوائم التوعية Awareness Lists، والمعايير Standards ونماذج النضج، وأدلة الاختبار Testing Guides، وإرشادات المطور Developer Guidance، والأدوات Tools، مع الإصدار الحالي لكل منها.
• خريطة «أي مورد لأي مرحلة» من التعلم إلى التشغيل وميزات الذكاء الاصطناعي، مع مقالاتنا في كل مرحلة.
• أشهر أخطاء الفهم حول OWASP، وكيف تساهم في مشاريعها.

ما هي OWASP؟ مؤسسة غير ربحية Non-profit ومجتمع مفتوح Open Community

الاسم اختصار لـ Open Worldwide Application Security Project، وستجد في الصفحات القديمة لبعض المشاريع الاسم السابق Open Web Application Security Project، وتعرف المؤسسة نفسها في صفحة About بأنها مؤسسة غير ربحية من نوع 501(c)(3) في الولايات المتحدة تعمل على تحسين أمن البرمجيات. وبحسب الصفحة نفسها بدأ المشروع في الأول من ديسمبر 2001، ثم سجل رسمياً باسم OWASP Foundation, Inc. كمؤسسة أمريكية غير ربحية في 21 أبريل 2004، ولذلك تحتفل المؤسسة في 2026 بمرور خمسة وعشرين عاماً على بدايتها.

والفكرة الأساسية التي تميز OWASP عن الشركات الأمنية أنها مجتمع مفتوح، فالصفحة تقول إن كل مشاريعها وأدواتها ووثائقها ومنتدياتها وفروعها مجانية ومفتوحة لكل من يهتم بتحسين أمن التطبيقات، ومن قيمها المعلنة الشفافية الكاملة Open من المالية إلى الكود، والحياد تجاه الموردين Vendor Neutral، وهذا الحياد هو سبب ثقة الناس في قوائمها، لأن القائمة التي تكتبها شركة تبيع أداة فحص سوف تميل بطبيعة الحال إلى ما تجده أداتها. وتذكر الصفحة وقت كتابة المقال أكثر من 250 فرعاً محلياً، وأكثر من 275 مشروعاً نشطاً، وعشرات الآلاف من الأعضاء.

والصورة التالية تبين المؤسسة في المنتصف، والأشياء الأربعة التي تديرها حولها:

من يدير OWASP؟ المجلس Board والموظفون Staff والمتطوعون Volunteers

في القمة يوجد المجلس العالمي Global Board، وهو سبعة أعضاء منتخبين لمدة سنتين، ينتخبهم الأعضاء بين أغسطس ونوفمبر، ويضع المجلس الاتجاه الاستراتيجي والسياسات والميزانية، واجتماعاته الشهرية مفتوحة للعامة ومسجلة. وتحت المجلس فريق موظفين صغير يقوده المدير التنفيذي Executive Director، ويهتم بالفعاليات والعلاقات مع الشركات الداعمة والمشاريع والتسويق.

أما العمل الحقيقي فيقوم به المتطوعون، والسبب أن سياسة المشاريع Project Policy تجعل لكل مشروع من قائدين إلى خمسة قادة Project Leaders متطوعين، وتشترط أن يكون القائد عضواً، أما المساهم Contributor فلا يحتاج أن يكون عضواً، وتقول السياسة صراحة إن كل الناس يحق لهم المشاركة في مشاريع OWASP وإن اجتماعات المشاريع مجانية. ويشرف على المشاريع لجنة المشاريع Project Committee مع الموظفين ثم المجلس، ولاحظ أن المشاريع والفروع ليست كيانات قانونية مستقلة، فلا يحق لقائد المشروع أن يوقع عقداً باسم مشروعه أو يفتح له حساباً بنكياً، وكل الأموال تمر عبر المؤسسة.

لماذا كل شيء مجاني؟ التراخيص Licenses التي تستخدمها المشاريع

المجانية هنا ليست كرماً من مشروع واحد، وإنما شرط في السياسة نفسها، فسياسة المشاريع تطلب أن يختار كل مشروع ترخيصاً يعطي الناس وصولاً مجانياً ومفتوحاً، وأن يكون ترخيص الكود Source Code ترخيصاً مفتوح المصدر معتمداً من OSI، وأن يكون ترخيص الوثائق Documentation ترخيص Creative Commons أو ترخيصاً مفتوحاً من جهة معايير دولية، وأي استثناء يحتاج موافقة لجنة المشاريع. ولذلك تجد أغلب الوثائق بترخيص CC BY-SA 4.0، مثل سلسلة أوراق الغش Cheat Sheet Series ودليل اختبار الويب WSTG ونموذج SAMM وقائمة API Security، وتجد الأدوات بتراخيص مختلفة، مثل MIT في Juice Shop، وApache 2.0 في Dependency-Track وThreat Dragon وCRS، وBSD 3-Clause في DefectDojo، وAGPL 3.0 في WrongSecrets.

ولكن لاحظ أن «مجاني ومفتوح» لا يعطيك نفس الحقوق في كل مشروع، فصفحة Kubernetes Top 10 وصفحة MCP Top 10 تذكران ترخيص CC BY-NC-SA 4.0، وحرف NC يعني منع الاستخدام التجاري NonCommercial، لذلك إذا أردت أن تنسخ جزءاً من وثيقة إلى مادة تدريب تبيعها أو منتج تجاري فاقرأ ترخيص تلك الوثيقة بعينها أولاً. وقد شرحنا الفرق بين الرخص المتساهلة Permissive ورخص Copyleft في مقال البرمجيات مفتوحة المصدر وتراخيصها.

الفروع المحلية Chapters والمؤتمرات Conferences والعضوية Membership

الفرع المحلي Chapter مجموعة من المتطوعين في مدينة أو جامعة ينظمون لقاءات مجانية عن أمن التطبيقات، وتجد القائمة الكاملة في صفحة الفروع. وفي المنطقة العربية تذكر قائمة الفروع في موقع OWASP وقت كتابة المقال، في السعودية فرع الرياض Riyadh وفرعاً في تبوك وفرعاً طلابياً في جامعة فهد بن سلطان، وفي الإمارات فرعي دبي Dubai وأبوظبي، ثم الكويت Kuwait City والمنامة والدوحة ومسقط، وعمان Amman في الأردن، والقاهرة Cairo والجيزة في مصر، والجزائر Algiers وتونس Tunisia والمغرب Morocco. ونشاط الفروع يختلف كثيراً، فبعضها صفحته ما زالت القالب الافتراضي الذي يأتي مع إنشاء الفرع، وبعضها نشط، ففرع الرياض مثلاً يذكر في صفحته لقاء في أغسطس 2026 عن أمن الذكاء الاصطناعي، لذلك افتح صفحة الفرع وانظر إلى تاريخ آخر لقاء قبل أن تعتمد عليه.

أما المؤتمرات فأكبرها مؤتمرات Global AppSec، وبحسب صفحة الفعاليات كان مؤتمر أوروبا لعام 2026 في فيينا من 22 إلى 26 يونيو، ومؤتمر أمريكا في سان فرانسيسكو من 2 إلى 6 نوفمبر 2026، وبجانبها مؤتمرات محلية باسم AppSec Days ينظمها متطوعو الفروع، ومؤتمر افتراضي في 22 سبتمبر 2026 بمناسبة مرور خمسة وعشرين عاماً على المؤسسة.

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

مستويات نضج المشاريع Project Maturity: من Incubator إلى Flagship

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

• الحاضنة Incubator: كل مشروع جديد يبدأ هنا، وتصفه المؤسسة بأنه تجريبي أو إثبات فكرة Proof of Concept أو عمل قيد التطوير أو أحياناً مجرد فكرة، والشرط الوحيد أن توجد صفحة للمشروع تشرح هدفه.
• المختبر Lab: مشروع أصدر إصداراً رئيسياً واحداً على الأقل، وله تعليمات معقولة للتثبيت أو الاستخدام، وقناة دعم، وإرشادات للمساهمة، وعمره من ثلاثة إلى ستة أشهر على الأقل.
• الإنتاج Production: إصدار رئيسي كل سنة على الأقل مع إصدارات صغيرة منتظمة، وتوثيق كامل، وبلاغات Issues وطلبات دمج Pull Requests تدار فعلاً، ودليل على استخدام حقيقي، وعمر أكثر من سنة، ومعايير المستوى الأول في شارة OpenSSF Best Practices.
• العلم Flagship: ليس درجة رابعة في سلم النضج، وإنما تكريم استراتيجي للمشاريع ذات الأهمية لرسالة OWASP، تقترحه لجنة المشاريع ويقرره المجلس.

والترقية من Incubator إلى Lab ومن Lab إلى Production تكون بطلب من قادة المشروع يراجعه عضو من لجنة المشاريع وقائد مشروع آخر متطوع، والقرار للجنة. وإذا لم يحقق المشروع الحد الأدنى من النشاط، كإصدار واحد في السنة على الأقل، فإنه يعتبر غير نشط Inactive، وتسحب منه قيادته ويحال إلى لجنة المشاريع لتبحث عن قادة جدد أو تحله.

والصورة التالية تبين السلم والمتطلبات الأساسية لكل مستوى، مع أمثلة من المشاريع التي سوف نذكرها في هذا المقال:

وقد يتساءل البعض: لماذا يهمني هذا المستوى وأنا أريد فقط أن أقرأ وثيقة أو أشغل أداة؟ والإجابة أن المستوى يخبرك بما تستطيع أن تبني عليه، فإذا أردت أداة تضعها في خط CI/CD الذي يعتمد عليه فريقك أو وثيقة تكتبها في عقد مع مورد، فابدأ بمشاريع Production وFlagship، والسبب أنها تصدر بانتظام ولها توثيق ومن يجيب عن البلاغات، أما مشروع Incubator فاقرأه كفكرة جيدة قيد النقاش، ولا تقم بوضعه شرطاً في عقد أو أساساً لبرنامج الأمن كله. وتجد المستوى في صندوق Project Information على يمين صفحة كل مشروع في owasp.org.

خمس عائلات من الوثائق والأدوات Document Families

تصنف OWASP مشاريعها رسمياً إلى ثلاثة أنواع: وثائق Documentation وكود Code وأدوات Tool، لكن هذا التقسيم لا يجيب عن سؤال المطور الحقيقي، وهو «ماذا أفعل بهذه الوثيقة؟»، لذلك سوف نقسمها هنا إلى خمس عائلات حسب السؤال الذي تجيب عنه، وهذا التقسيم من عندنا لتسهيل القراءة:

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

قوائم التوعية Awareness Lists: عائلة Top 10

أشهر ما تنشره OWASP قوائم «أخطر عشرة» Top 10، وأولها وأشهرها OWASP Top 10 لتطبيقات الويب، وتصفها صفحتها بأنها وثيقة توعية Awareness Document للمطورين، ونسختها الحالية Top 10:2025 وهي مشروع Flagship، وقد شرحناها فئة فئة بأمثلة كود في مقال OWASP Top 10 للمبتدئين. ومع الوقت ظهرت قوائم مثلها لأنواع أخرى من الأنظمة، والجدول التالي يجمع أهمها:

في الجدول أعلاه لاحظ التالي:

• القوائم ليست نسخاً من بعضها، فكل قائمة يكتبها فريق مختلف بطريقة مختلفة، فقائمة الويب تبنى من بيانات اختبار ملايين التطبيقات مع استبيان مجتمعي كما شرحنا في قسم كيف تبنى القائمة، أما صفحة Kubernetes Top 10 فتقول إن الفريق يأمل في المستقبل أن تدعم القائمة ببيانات من المؤسسات، وقائمة NHI ترتب المخاطر بحسب قابلية الاستغلال والانتشار وصعوبة الاكتشاف والأثر.
• قائمة نماذج اللغة كبرت حتى أصبحت مشروعاً مستقلاً باسم OWASP GenAI Security Project، له موقعه وقوائمه وأدلته، ومنها قائمة الوكلاء Agentic، وقد أعلن المشروع عن إصدار 2026 في خبر في سبتمبر 2026، وأغلب ما تجده في المقالات اليوم يشير إلى إصدار 2025، لذلك انتبه للسنة عندما تقرأ رقماً مثل LLM01. وقد ذكرنا أشهر هذه المخاطر في قسم الجودة والأمان في مقال مصطلحات الذكاء الاصطناعي.
• كل خطر في هذه القوائم فئة Category تجمع نقاط ضعف كثيرة، وليس ثغرة واحدة تختبرها بسؤال واحد.

والصورة التالية تجمع العائلة كلها مع إصدار كل قائمة ومستواها:

المعايير Standards ونماذج النضج Maturity Models: ASVS وMASVS وSAMM

هنا تنتقل من «ما الذي يسوء» إلى «ما الذي يجب أن يكون صحيحاً»، وفيما يلي أهم ثلاثة مشاريع في هذه العائلة:

• معيار التحقق من أمن التطبيقات ASVS: OWASP ASVS مشروع Flagship يعطي المطورين قائمة متطلبات للتطوير الآمن، ويعطي الفاحصين أساساً لاختبار الضوابط الأمنية، وآخر إصدار مستقر له 5.0.0 صدر في 30 مايو 2025. ولكل متطلب رقم، وتوصي صفحة المشروع بأن تكتب الإصدار معه مثل v5.0.0-1.2.5، والسبب أن الأرقام قد تتغير بين الإصدارات. وقد شرحنا المعيار ومستوياته الثلاثة وكيف تحوله إلى قصص مستخدم واختبارات في مقال متطلبات الأمان ومراجعة الكود مع OWASP ASVS.
• معيار أمن تطبيقات الجوال MASVS: جزء من مشروع OWASP Mobile Application Security وهو Flagship أيضاً، ويقسم MASVS ضوابطه إلى مجموعات مثل التخزين MASVS-STORAGE والتشفير MASVS-CRYPTO والمصادقة MASVS-AUTH والشبكة MASVS-NETWORK والخصوصية MASVS-PRIVACY، وآخر إصدار له على GitHub هو v2.1.0 من يناير 2024، ومعه قائمة نقاط ضعف الجوال MASWE.
• نموذج نضج ضمان البرمجيات SAMM: OWASP SAMM لا يقيس تطبيقاً، وإنما يقيس فريقك وطريقة عمله، فهو يقسم عمل المؤسسة إلى خمس وظائف Business Functions هي الحوكمة Governance والتصميم Design والتنفيذ Implementation والتحقق Verification والتشغيل Operations، وفيها خمس عشرة ممارسة أمنية Security Practices، لكل منها ثلاثة مستويات نضج، فتقيم أين أنت اليوم وتضع خطة للوصول إلى المستوى الذي يناسب مخاطرك. والنموذج الحالي هو الإصدار الثاني SAMM v2 ويحدث على دفعات صغيرة، ولفرق DevSecOps نموذج آخر هو DevSecOps Maturity Model واختصاراً DSOMM.

وقد يتساءل البعض: إذا كان عندي ASVS فلماذا أحتاج SAMM؟ والإجابة أن ASVS يسأل «هل هذا التطبيق يحقق المتطلب 8.2.2؟»، أما SAMM فيسأل «هل لدى فريقك عادة ثابتة لكتابة المتطلبات الأمنية ونمذجة التهديدات ومراجعة الكود في كل مشروع؟»، فالأول يقيس المنتج والثاني يقيس المصنع، وأنت تحتاج الاثنين عندما يكبر عدد التطبيقات وتريد أن تعرف أين تضع ميزانية الأمن.

أدلة الاختبار Testing Guides: WSTG وMASTG

إذا كان المعيار يقول «يجب أن يتحقق كذا» فدليل الاختبار يقول «وهكذا تختبره»، وأهم دليلين في OWASP هما:

• دليل اختبار أمن الويب WSTG: Web Security Testing Guide مشروع Flagship، والإصدار المستقر الحالي 4.2، والفريق يعمل على الإصدار 5.0 وتجد مسودته في فرع latest. فإذا قال لك مختبر الاختراق إنه اتبع منهجية OWASP في اختبار تطبيق ويب فاسأله عن أقسام WSTG التي غطاها، وقد استخدمنا قسم اختبار منطق العمل Business Logic Testing منه في مقال الفحص الديناميكي DAST لنبين ما لا يجده الفاحص الآلي.
• دليل اختبار أمن تطبيقات الجوال MASTG: Mobile Application Security Testing Guide دليل للاختبار والهندسة العكسية Reverse Engineering في Android وiOS، يربط كل اختبار بضابط في MASVS ونقطة ضعف في MASWE، وآخر إصدار له على GitHub هو v2.0.0 من يونيو 2026.

إرشادات المطور Developer Guidance: Cheat Sheets وProactive Controls وDeveloper Guide

هذه العائلة هي الأقرب إلى عملك اليومي كمطور، لأنها تجيب عن سؤال «كيف أكتب هذا الجزء بشكل صحيح الآن؟»:

• سلسلة أوراق الغش Cheat Sheet Series: مجموعة أوراق قصيرة كل واحدة عن موضوع محدد، كتبها مختصون في ذلك الموضوع، وهي مشروع Flagship بترخيص CC BY-SA 4.0. وهي أكثر ما نحيل إليه في الموقع، فمعاملات Argon2id في مقال التشفير للمطورين جاءت من ورقة تخزين كلمات المرور، وخطوات مقال نمذجة التهديدات مبنية على ورقة Threat Modeling، والإصلاح في فئة الحقن في مقال OWASP Top 10 يشير إلى ورقة الاستعلامات ذات المعاملات.
• الضوابط الاستباقية Proactive Controls: OWASP Top 10 Proactive Controls هي الوجه الآخر لقائمة Top 10، فبدل عشرة أخطاء تعطيك عشر تقنيات يجب أن يعرفها كل مطور ويطبقها من بداية المشروع، والإصدار الحالي 2024، والمشروع في مستوى Lab، وتقول الوثيقة نفسها إنها نقطة بداية للتدريب، وإن عملية التطوير الآمن الكاملة تحتاج متطلبات من معيار مثل ASVS وأنشطة من نموذج نضج مثل SAMM.
• دليل المطور Developer Guide: OWASP Developer Guide من أقدم وثائق OWASP، فبحسب صفحة المشروع صدر الإصدار 1.0 في 2002 والإصدار 2.0 في 2005، ثم أعيدت كتابته في 2023 و2024 ليناسب الواقع الحالي. وهو لا يتعمق في كل موضوع، وإنما يرتب ممارسات الأمن على وظائف SAMM ويعرفك بمشاريع OWASP التي تفيدك في كل خطوة، فهو مدخل جيد للمطور الجديد.
• دليل DevSecOps وسفراء الأمن: OWASP DevSecOps Guideline يشرح خطاً آمناً لبناء البرمجيات وأي الفحوص تضع فيه، وOWASP Security Champions Guide يشرح كيف تبني برنامج سفراء الأمن في الفرق، والمشروعان ما زالا في مستوى Incubator، وقد ربطنا بهما في مقال DevSecOps للمبتدئين.

الأدوات Tools: من قائمة مكونات البرنامج SBOM إلى التطبيق التدريبي

ليست كل مشاريع OWASP وثائق، فبعضها أدوات تشغلها في خط CI/CD أو على سيرفرك، والجدول التالي يجمع أهمها مع المستوى والترخيص كما في صفحة كل مشروع:

ولاحظ أن أشهر أداة ارتبطت باسم OWASP لسنوات لم تعد في الجدول، وهي ZAP، فبحسب إعلان فريقها في أغسطس 2023 خرج ZAP من OWASP وانضم إلى مشروع Software Security Project الجديد في Linux Foundation، وأصبح اسمه ZAP فقط، والسبب كما يقول قائد المشروع أن OWASP لم تستطع أن تستثمر في المشاريع الكبيرة بما تحتاجه، ثم في سبتمبر 2024 انضم قادته الثلاثة إلى شركة Checkmarx وأصبح اسمه ZAP by Checkmarx، مع بقائه مفتوح المصدر بترخيص Apache v2. وقد شرحنا ZAP واستخدمناه في مقال الفحص الديناميكي DAST مع ZAP، وهذه القصة نفسها درس في حوكمة المشاريع المفتوحة، فالمؤسسة المحايدة تحمي الاسم والحياد، لكنها لا تضمن تمويل المطورين الذين يعملون عليه.

أي مورد من OWASP لأي مرحلة؟ خريطة دورة تطوير البرمجيات SDLC

الآن بعد أن عرفنا العائلات، نرتبها على مراحل بناء التطبيق، لأن السؤال الحقيقي في الفريق ليس «ما هي ASVS؟» وإنما «نحن الآن نكتب المتطلبات، فماذا نفتح؟». والصورة التالية تبين ذلك، والربط من عندنا:

والجدول التالي يفصل الصورة، وفي العمود الأخير المقال الذي يشرح المرحلة في الموقع:

وإذا كان فريقك صغيراً ولا يستخدم أي شيء من هذا اليوم، فلا تقم بفتح الجدول كله في أسبوع واحد، والسبب أن الفريق سوف يغرق في الوثائق ويحكم على الفكرة كلها بأنها بيروقراطية. والحل الأنسب أن تبدأ بثلاثة أشياء: قائمة Top 10 لغة مشتركة في التدريب، وأوراق Cheat Sheets عند كتابة الكود، وأداة SCA في خط CI، ثم تضيف ASVS عندما يطلب منك عميل متطلبات مكتوبة، وSAMM عندما يصبح لديك أكثر من فريق.

أخطاء شائعة في فهم OWASP Common Misconceptions

أغلب سوء الاستخدام الذي نراه في المشاريع لا يأتي من جهل باسم OWASP، وإنما من خلط بين وظائف وثائقها، وفيما يلي أشهرها:

• «التطبيق متوافق مع OWASP Top 10»: القائمة وثيقة توعية وليست معياراً للتحقق ولا قائمة كاملة، فهي تصف فئات المخاطر ولا تعطيك متطلبات قابلة للاختبار، والطريقة الصحيحة أن تطلب من المورد مستوى محدداً من ASVS مع رقم الإصدار، وقد فصلنا ذلك في قسم كيف تستخدم القائمة في فريقك، وكيف لا تستخدمها.
• «التطبيق معتمد من OWASP»: OWASP لا تعتمد منتجات ولا موردين ولا مدققين، ومعيار ASVS نفسه يقول إن أي علامة أو شهادة تدعي التوافق معه ليست معتمدة من OWASP، كما ذكرنا في مقال ASVS. ويجدر الإشارة هنا إلى أن المؤسسة أعلنت في أكتوبر 2025 أنها تعمل على شهادة للمطورين أنفسهم باسم OWASP Certified Secure Developer واختصاراً OCSD، وتصفها صفحتها بأنها شهادة مقترحة Proposed يعمل عليها فريق عمل، فهي شهادة لمعرفة الشخص، وليست ختماً على تطبيق أو منتج.
• «القائمة ثابتة»: القوائم تتجدد كل بضع سنوات، وطريقة بنائها تختلف من قائمة إلى أخرى، فقائمة الويب تعتمد على البيانات مع الاستبيان، وقائمة Kubernetes ما زالت تنتظر البيانات، لذلك اكتب السنة دائماً، فالرقم A03 في 2021 ليس هو A03 في 2025، وLLM01 في 2025 قد لا يكون نفسه في 2026.
• «كل ما يحمل اسم OWASP ناضج»: المؤسسة توافق على فكرة المشروع، ثم يصعد المشروع سلم النضج بعمله، ومشروع Incubator قد يكون فكرة لم تكتمل بعد، فانظر إلى المستوى وتاريخ آخر إصدار قبل أن تعتمد عليه.
• «وسم OWASP في نتيجة الأداة يعني تغطية الفئة»: عندما تكتب أداة SAST بجانب نتيجة OWASP-A05:2025 - Injection كما رأينا في مقال الفحص الثابت، فهذا يعني أن هذه القاعدة تنتمي إلى فئة الحقن، ولا يعني أن الأداة تغطي الفئة كلها، وأغلب الأدوات لا ترى الفئتين A01 وA06 تقريباً.
• «OWASP للويب فقط»: الاسم القديم كان فيه كلمة Web، لكن المشاريع اليوم تغطي واجهات API والجوال وخطوط CI/CD وKubernetes ونماذج اللغة والوكلاء وهويات الآلات.

كيف تساهم في OWASP؟

بما أن كل شيء مفتوح فالمساهمة لا تحتاج دعوة، وكل مشاريع OWASP تقريباً موجودة في حساب OWASP على GitHub أو في حسابات المشاريع نفسها، والطرق العملية كما يلي:

1. ابدأ من المشروع الذي تستخدمه فعلاً، واقرأ ملف CONTRIBUTING فيه، ثم ابحث عن بلاغ صغير أو خطأ في الوثائق أو مثال ناقص بلغتك البرمجية، وقد شرحنا خطوات أول مساهمة في قسم أول مساهمة لك خطوة بخطوة.
2. لاحظ أن سياسة المشاريع تطلب اتفاقية المساهم DCO، أي أن تقر في كل Commit بأن الكود من عملك أو أن لك حق المساهمة به، وتجد الفرق بين DCO وCLA في قسم DCO أم CLA.
3. انضم إلى Slack الخاص بالمجتمع، فلأغلب المشاريع قناة باسمها مثل #project-threat-dragon، وهي أسرع طريق للتواصل مع القادة.
4. الترجمة مساهمة حقيقية، فقائمة LLM Top 10 مثلاً مترجمة إلى الإسبانية والبرتغالية والصينية وغيرها، ودليل المطور مترجم إلى الإسبانية والبرتغالية والفارسية، ولم نجد ترجمة عربية في صفحات الترجمات التي راجعناها لهذين المشروعين، فإذا ترجمت ورقة Cheat Sheet أو فصلاً من دليل فقد نفعت كل من يقرأ بالعربية.
5. احضر لقاءات الفرع القريب منك، أو قدم فيه محاضرة، أو اقترح على جامعتك فرعاً طلابياً، وطلاب الجامعات يستطيعون أيضاً العمل على مشاريع OWASP عبر برنامج Google Summer of Code.

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

مسار القراءة Reading Path بعد هذا المقال

هذا المقال يعطيك الخريطة، والمقالات التالية تتعمق في أهم مشاريع OWASP واحداً واحداً، بدءاً من القوائم ثم المعيار ثم التصميم والفحوص:

دليلOWASP Top 10 للمبتدئين: أخطر عشر مشكلات في تطبيقات الويبأخطر عشر مشكلات أمنية في تطبيقات الويب، كل واحدة بمثال ضعيف ثم مصلح، وكيف تمنعها في الكود وأين تكتشفها.دليلأمن ال API بالأمثلة مع OWASP API Security Top 10أشهر عشرة مخاطر في واجهات API كما ترتبها OWASP، ولكل خطر مثال لكود ضعيف وكيف تصلحه وتختبره.دليلOWASP Top 10 لتطبيقات LLM: المخاطر وكيف تحمي تطبيقكأخطر عشر مشكلات في التطبيقات المبنية على نماذج اللغة، من حقن التعليمات Prompt Injection إلى تسرب البيانات، وكيف تمنع كلاً منها.دليلOWASP ASVS ومراجعة الكود الأمنية لكل Pull Requestكيف تكتب متطلبات أمان يمكن اختبارها مع OWASP ASVS، وتراجع كل طلب دمج أمنياً في عشرين دقيقة بقائمة جاهزة.دليلنمذجة التهديدات Threat Modeling للمبتدئينكيف تسأل ما الذي قد يسوء في تصميم تطبيقك قبل أن تكتب الكود، وتقرر لكل تهديد هل تصلحه أو تقبله، مع قالب جاهز للنسخ.دليلDevSecOps للمبتدئين: الأمن داخل خط CI/CD ومتى يعمل كل فحصما الذي يجده كل فحص أمني في خط CI/CD وما الذي يفوته، وكيف ترتب نتائجه حتى تصل إلى قرار بدل قائمة طويلة.

أخطاء شائعة Common Mistakes

• نسخ قائمة Top 10 في كراسة الشروط: المورد سوف يرد «متوافق» دون أن يختبر شيئاً، فاطلب مستوى ASVS بإصداره، مثل L2 من ASVS 5.0.0، واطلب معه تقرير اختبار يذكر أرقام المتطلبات.
• ذكر رقم متطلب أو فئة دون إصدار: «المتطلب 1.2.5» أو «الفئة A03» بلا سنة يفقد معناه بعد الإصدار التالي، فاكتب v5.0.0-1.2.5 وA03:2025.
• اعتماد وثيقة Incubator أساساً لبرنامج الأمن: ابن البرنامج على مشاريع Flagship وProduction، واستخدم مشاريع Incubator مصادر أفكار.
• الاعتماد على مقال قديم عن ZAP أو LLM Top 10: ZAP لم يعد مشروعاً من مشاريع OWASP منذ 2023، وقائمة LLM لها إصدار 2026، فارجع إلى الصفحة الرسمية لكل مشروع قبل أن تبني عليه.
• نسخ وثيقة بترخيص NC إلى منتج تجاري: اقرأ ترخيص الوثيقة نفسها، فليست كل وثائق OWASP بترخيص CC BY-SA.
• تشغيل Juice Shop أو Amass على أنظمة لا تملكها: Juice Shop مكانه جهازك أو مختبرك المعزول، وAmass يجمع معلومات عن الأصول، فاستخدمه على نطاقاتك أو بإذن مكتوب فقط.
• الاكتفاء بالقراءة: الوثائق لا تحمي التطبيق وحدها، فكل وثيقة تقرؤها يجب أن تنتهي بمتطلب في التذكرة أو اختبار في الكود أو فحص في الخط.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• OWASP مؤسسة أمريكية غير ربحية بدأت مشروعاً في 2001 وسجلت مؤسسة في 2004، يديرها مجلس منتخب من سبعة أعضاء وفريق موظفين صغير، ويعمل في مشاريعها وفروعها آلاف المتطوعين، وكل ما تنشره مجاني ومفتوح بتراخيص مفتوحة تختلف من مشروع إلى آخر.
• لكل مشروع مستوى نضج: Incubator ثم Lab ثم Production، أما Flagship فتكريم استراتيجي يقرره المجلس، فاختر مشاريع Production وFlagship لما يعتمد عليه فريقك.
• قوائم Top 10 للتوعية، ومنها الويب 2025 وAPI 2023 وLLM 2026 والوكلاء 2026 والجوال 2024 وCI/CD وKubernetes 2025 وهويات الآلات 2025 وMCP التجريبية، ولكل منها طريقة بناء مختلفة.
• ASVS 5.0.0 وMASVS معايير للمتطلبات والتحقق، وSAMM يقيس نضج الفريق وليس التطبيق، وWSTG وMASTG أدلة اختبار، وCheat Sheets وProactive Controls وDeveloper Guide إرشادات للمطور.
• من الأدوات CycloneDX وهو معيار ECMA-424، وDependency-Track وDependency-Check وDefectDojo وThreat Dragon وpytm وCRS وCoraza وJuice Shop، أما ZAP فقد خرج من OWASP في 2023.
• OWASP لا تعتمد تطبيقات ولا موردين، فعبارة «متوافق مع OWASP» تحتاج دائماً سؤالاً بعدها: أي وثيقة، وأي إصدار، وأي مستوى؟

وفي المقالات القادمة بإذن الله سوف نكمل عائلة Top 10 بقائمة أمن واجهات API وقائمة تطبيقات نماذج اللغة، كل منها بأمثلة كود وتجربة عملية.

سجل التحديثات

• أكتوبر 2026: كتابة المقال من صفحات OWASP الرسمية، والتحقق من تاريخ المؤسسة وطريقة إدارتها من صفحات About والمجلس وسياسة المشاريع، ومن مستويات النضج من لجنة المشاريع، ومن قائمة الفروع وجدول الفعاليات من بيانات موقع owasp.org، ومن إصدار كل قائمة ومعيار وأداة ومستواها وترخيصها من صفحة كل مشروع وإصداراته على GitHub.