إطار عمل لدمج أمن التطبيقات في هندسة البرمجيات (FIASSE) باستخدام نموذج هندسة البرمجيات القابل للتأمين (SSEM)
# إطار عمل لدمج أمن التطبيقات في هندسة البرمجيات (FIASSE) [](https://creativecommons.org/licenses/by-sa/4.0/) **ملاحظة:** هذا المستودع عمل مستمر. المساهمات مرحّب بها! ## نظرة عامة باختصار: يُرجى قراءة [DOC](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md). استكشف [موقع FIASSE](https://fiasse.org). قم بزيارة [GitHub Discussions](https://github.com/OWASP/FIASSE/discussions) للمساهمة. يحتوي هذا المستودع على موارد ومواد لإطار عمل OWASP لدمج أمن التطبيقات في هندسة البرمجيات (FIASSE). FIASSE (تُنطق /feiz/ مثل 'phase') هو إطار عمل مستقل عن البائعين يعزز **نهجًا مبدئيًا يتمحور حول المطور** لبناء برمجيات **قابلة للتأمين**. وهو يدرك أن الأمن عملية ديناميكية ومستمرة مثل التطوير. ويقدّم نموذج هندسة البرمجيات القابلة للتأمين (SSEM) بوصفه **لغة تصميم مشتركة** تستخدم مصطلحات هندسة البرمجيات الراسخة لدمج الأمن في معمارية البرمجيات وتصميمها وهندستها من خلال تضمين الأمن في المبادئ التي تشكّل الشيفرة نفسها. ويمكّن الإطار فرق التطوير من إضافة قيمة حوسبية بمرونة مع تقليل احتمالية التأثير الجوهري من الأحداث السيبرانية طوال عمر الشيفرة. FIASSE هو إطار إنشائي. فهو يتناول كيفية تنفيذ الأمن في البرمجيات، ويربط قرارات الهندسة مباشرة بالنتائج القابلة للتأمين. وهو ليس إطار ضمان، ولا نموذج نضج، ولا بديلًا عن كتالوجات الضوابط أو مقاييس الثغرات. بل يكمل تلك الأساليب ويخفف الضغط اللاحق على الضمان والامتثال. ## الغرض تقديم إرشادات عملية **تمكّن المطورين** من إنشاء برمجيات قابلة للتأمين دون الحاجة إلى خبرة أمنية عميقة، وإرشاد المتخصصين في الأمن لدمج خبرتهم الأمنية بفعالية في هندسة البرمجيات. ويحقق FIASSE ذلك من خلال **عدسة هندسة البرمجيات**، مما يقلل الحمل المعرفي ويعزز التعاون بين فرق التطوير والأمن. ## كيف يختلف؟ بينما تُبرز المشاريع التي تركز على الضمان مثل OWASP Top 10 ما يجب تجنبه (قائمة حظر)، يقدم OWASP FIASSE مجموعة من السمات والممارسات الإيجابية التي يجب اتباعها (قائمة سماح). ويستفيد هذا النهج من مهارات هندسة البرمجيات الحالية لبناء برمجيات قابلة للتأمين، بدلًا من مطالبة المطورين بتعلم تقنيات الاستغلال أو تبني عقلية تركز على الثغرات. ويتركز التأكيد على تمكين البرمجة الآمنة والعملية من خلال مبادئ هندسية مألوفة. من خلال تحديد الدور العملي للأمن بوضوح داخل عملية التطوير، يضمن هذا الإطار التقاط قيمة الأعمال بفعالية. فإرساء توقعات أمنية صريحة قبل كتابة الشيفرة يقلل من احتمالية اكتشاف عيوب أمنية تحتاج إلى معالجة لاحقًا. وينبغي أن يؤدي التبني الفعال إلى تحسين مقاييس الضمان الحالية، وتقليل تقلب النتائج، وإنتاج إصلاحات أكثر متانة، وتقصير وقت المعالجة. ## القيم الأساسية يسترشد FIASSE بأربع قيم أساسية. كل منها يعبّر عن تفضيل نسبي: لكلا الجانبين قيمة، لكن عندما يجب الاختيار، يفضّل FIASSE الجانب الأيسر. - **السمات القابلة للتأمين على الضوابط الأمنية**: تفضيل الصفات الهندسية التي تتيح بناء النظام والحفاظ على قابلية الدفاع عنه على الضوابط الأمنية المضافة بعد وقوع الأمر لتعويض نقاط الضعف. - **المشاركة على التقييم**: تفضيل التفاعل المنظم بين الأمن والتطوير طوال دورة الحياة على التقييم الذي يُجرى بعد إنجاز العمل. - **المبادئ الأولى للهندسة على المصطلحات الأمنية**: تفضيل التأصيل في المبادئ الأولى الراسخة لهندسة البرمجيات على المصطلحات الخاصة بالأمن أو الاستدلالات العدائية. - **قيمة الأعمال على النشاط الأمني**: تفضيل الأمن الذي يدعم خلق القيمة في المؤسسة على الأمن المسعى إليه كغاية في حد ذاته. ## المبادئ الرئيسية - **النموذج القابل للتأمين (Securable Paradigm)**: لا توجد حالة ثابتة تُسمى "آمن". فالنظام الذي يُعلن أنه آمن اليوم قد يكون عرضة للخطر غدًا. يعيد FIASSE توجيه الهدف الهندسي من "هل هو آمن؟" إلى "هل بُني بحيث يمكن الحفاظ على الأمن؟" من خلال المرونة التكيفية، والأمن التطوري، والتحسين المستمر. - **إضافة قيمة حوسبية بمرونة (Resiliently Add Computing Value)**: التوجيه الأساسي لهندسة البرمجيات في سياق الأعمال. يجب أن تلبي البرمجيات المتطلبات الوظيفية مع الحفاظ على الخصائص القابلة للتأمين التي تمكنها من تحمل التغيير والضغط والهجوم الذي يتبع كل تغيير. - **مهمة الأمن: تقليل الأثر الجوهري (Security Mission: Reducing Material Impact)**: مهمة الأمن هي تقليل احتمالية الأثر الجوهري لحدث سيبراني. إن القضاء التام على الاختراقات ليس هدفًا تجاريًا عمليًا، لذا يجب أن تتوافق استراتيجيات الأمن مع أهداف الأعمال وقدرتها على تحمل المخاطر. - **العلاقة بين الجودة والأمن (The Quality-Security Relationship)**: لا يمكن أن يتجاوز الأمن جودة البرمجيات. فالخصائص التي تجعل البرمجيات سهلة الفهم والتغيير والاختبار والمراقبة هي نفس الخصائص التي تجعل تأمينها ممكنًا. الاستثمار في جودة الهندسة هو استثمار في الأمن. - **الأمن المتمحور حول المطور (Developer-Centric Security)**: تمكين مهندسي البرمجيات من بناء أنظمة قابلة للتأمين باستخدام مبادئ هندسة البرمجيات المألوفة، بدلاً من مطالبتهم بتبني عقلية مختبِر الاختراق. - **SSEM كلغة تصميم مشتركة (SSEM as a Common Design Language)**: استخدام مصطلحات هندسة البرمجيات الراسخة (مثل قابلية التحليل، وقابلية التعديل، وقابلية الاختبار) لتعريف سمات الأمن ومناقشتها. وهذا يجعل الأمن في متناول المطورين ويمنح متخصصي الأمن أساسًا مشتركًا للتقييم. - **مواءمة الأمن مع أهداف التطوير والأعمال (Aligning Security with Development and Business Goals)**: الأمن والتطوير متكاملان وليسا متخاصمين. يشارك AppSec مبكرًا في دورة حياة تطوير البرمجيات (SDLC)، لا سيما أثناء جمع المتطلبات وتخطيط الميزات، بحيث تكون التوقعات واضحة قبل كتابة الكود. - **مبدأ الشفافية (The Transparency Principle)**: تُصمم الأنظمة بحيث يستطيع الأطراف المصرح لهم فهم الحالة الداخلية والسلوك. تُبنى السجلات المنظمة وأدوات القياس ومسارات التدقيق داخل الكود بدلاً من توفيرها بواسطة الأدوات الخارجية وحدها. - **مبدأ أقل مفاجأة (The Principle of Least Astonishment)**: تتصرف الأنظمة بطرق بديهية وقابلة للتنبؤ بالنسبة للمستخدمين والمطورين والمسؤولين. فالقابلية للتنبؤ تساعد في التحليل، وتقلل العبء المعرفي، وتجعل حدود الثقة واضحة. - **المتطلبات كمواطن من الدرجة الأولى في AppSec (Requirements as a First-Class Citizen in AppSec)**: تُسلَّم ميزات الأمن وسيناريوهات التهديد ومعايير قبول الأمن من خلال عملية المتطلبات. غالبًا ما تعود الثغرات إلى توقع لم يُحدَّد قط، لذا فإن تلك الفجوة تنتمي إلى عملية المتطلبات. ## مبادئ الهندسة يقدم القسم 4 من الإطار للمطورين مبادئ تنطبق مباشرة على مستوى الكود: - **مبدأ التحكم في الحدود (The Boundary Control Principle)**: المرونة داخل النظام هي أصل هندسي يجب الحفاظ عليه. أما التحكم عند كل حد ثقة فهو متطلب أمني يجب فرضه. - **التعامل القانوني مع المدخلات (Canonical Input Handling)**: قم بتقنين المدخلات والتحقق منها وتنقيتها عند نقطة الدخول. يقوم **مبدأ التحليل القانوني (Canonical Parsing Principle)** بتحليل المدخلات الخارجية إلى نوع داخلي قانوني عند الحدود ويفشل بشكل مغلق عندما لا ينجح التحليل. - **مبدأ السلامة المعزولة (The Isolated Integrity Principle)**: تُشتق القيم الحرجة للسلامة مثل الأسعار والأدوار وحالة الكائنات من مصادر موثوقة على جانب الخادم. ولا تُقبل أبدًا مباشرة من العميل. - **البرمجة المرنة (Resilient Coding)**: تفرض ممارسات البرمجة الدفاعية تنفيذًا قابلًا للتنبؤ. وتشمل هذه الكتابة القوية، والتحقق من المدخلات عند حدود الثقة، وترميز المخرجات، ومعالجة الأخطاء الشاملة، وإدارة الموارد الآمنة، والفشل الرشيق والآمن، وأقل امتياز على مستوى الكود. - **رعاية التبعيات (Dependency Stewardship)**: طبّق سمات SSEM عند اختيار التبعيات ودمجها ومراقبتها وصيانتها طوال عمر العلاقة. ## نموذج هندسة البرمجيات القابلة للتأمين (SSEM) يحدد SSEM السمات التي تجعل البرمجيات قابلة للتأمين. تضع الفرق أهدافًا لكل سمة، وتقيّم الأنظمة وفقًا لها، وتحسّن بشكل تدريجي. تُنظَّم السمات في ثلاث فئات: | **قابلية الصيانة** | **الموثوقية الأمنية** | **الاعتمادية** | |:--------------------|:-------------------:|----------------:| | قابلية التحليل | السرية | التوافر | | قابلية التعديل | المساءلة | السلامة | | قابلية الاختبار | الأصالة | المرونة | | قابلية المراقبة | | | لا يحتوي SSEM على سمة التفويض بحكم التصميم. التفويض هو ميزة أمنية تُجمَع كمتطلب وتُنفَّذ وفقًا لمعايير القبول. السمات المذكورة أعلاه هي ما يجعل هذه الميزة قابلة للتأمين. يصف الملحق A من الإطار منهجيات قياس كل سمة. ## محتويات المستودع - [docs/securable_framework.md](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md): إطار عمل FIASSE الكامل ومواصفات SSEM في وثيقة واحدة. - [docs/framework/](https://github.com/owasp/fiasse/blob/main/docs/framework): الإطار مقسّم إلى ملف واحد لكل قسم. ملفات الأقسام هذه هي المصدر الموثوق للإطار. يفصل [فهرس الكود](https://github.com/owasp/fiasse/blob/main/docs/framework/code-index.md) الأقسام التي تنطبق مباشرة على الكود عن أقسام العمليات والأدوار والتبنّي. يوفّر [llms.txt](https://github.com/owasp/fiasse/blob/main/docs/framework/llms.txt) فهرسًا لنماذج اللغة. - [skills/](https://github.com/owasp/fiasse/blob/main/skills): FIASSE وSSEM مُحزَّمان كمهارات لوكلاء البرمجة بالذكاء الاصطناعي (انظر أدناه). - TODO: أدلة تنفيذ منهجية FIASSE - نُقلت الأمثلة إلى [Securability-Engineering/securable-framework-supplement](https://github.com/Securability-Engineering/securable-framework-supplement) ## البدء 1. راجع الوثائق في دليل [docs](https://github.com/owasp/fiasse/blob/main/docs). ابدأ بـ[الإطار الكامل](https://github.com/owasp/fiasse/blob/main/docs/securable_framework.md)، أو استخدم [فهرس الكود](https://github.com/owasp/fiasse/blob/main/docs/framework/code-index.md) للعثور على الأقسام التي تنطبق على الكود المعني. 2. ناقش المفاهيم والمبادئ مع فرقك وفي [GitHub Discussions](https://github.com/OWASP/FIASSE/discussions) 3. ابدأ بتطبيق المبادئ في ممارسات هندسة البرمجيات لديك مثل جمع المتطلبات، ومراجعات الدمج، وهندسة الأوامر. 4. اتبع خطوات التبنّي في القسم 8 من الإطار: قيّم الممارسات الحالية، ودمج مصطلحات SSEM، وحدّد المؤثرين الرئيسيين، وثقّف الفرق ودرّبها، وتبنَّ أدوات AppSec الوكيلة كتخفيف للعبء، وعزّز التعاون، وراقب وحسّن باستمرار. - إضافة: ثبّت الإضافة المطابقة لبيئة التطوير المتكاملة (IDE) أو وكيل سطر الأوامر المدعوم بالذكاء الاصطناعي الذي تختاره (مثل GitHub Copilot وClaude Code وOpenCode وغيرها) واستخدم الأوامر النصية الموفرة لتوليد كود قابل للتأمين. ابحث عن "Securability Engineering" أو "FIASSE" في مكتبة الأوامر النصية. - FIASSE مُضمَّن أيضًا كجزء من [OWASP Secure Agent Playbook](https://github.com/OWASP/secure-agent-playbook). ## مهارات لوكلاء البرمجة بالذكاء الاصطناعي يحزم دليل [`skills/`](https://github.com/owasp/fiasse/blob/main/skills) إطار FIASSE/SSEM كمهارات جاهزة للاستخدام لوكلاء البرمجة بالذكاء الاصطناعي التي تدعم تنسيق [Agent Skills](https://code.claude.com/docs/en/skills) (مثل Claude Code). انسخ دليل المهارة الذي تحتاجه إلى مسار المهارات الخاص بوكيلك. - **[`securability`](https://github.com/owasp/fiasse/blob/main/skills/securability/SKILL.md)**: مرجع موجز ومكتفٍ ذاتيًا بالكامل يغطي جميع سمات SSEM العشر والمبادئ الأساسية (No Static State of Secure، وIsolated Integrity، وCanonical Input Handling، وBoundary Control، وLeast Astonishment). مخصص كخيار افتراضي لتوليد الكود ومراجعته اليومية. - **[`securable-code`](https://github.com/owasp/fiasse/blob/main/skills/securable-code/SKILL.md)**: مهارة متعمقة للأعمال المعقدة معماريًا والكثيفة السياق، مثل تصميم حدود الثقة، وأنظمة المصادقة، وتدفقات البيانات متعددة الخدمات، أو هندسة التبعيات. توجّه إلى قسم الإطار المرفق المحدد (في `skills/securable-code/framework/`) ذي الصلة بالكود المعني، مقايضةً بسياق إضافي مقابل التفكير الكامل لإطار المصدر. استخدم `securability` افتراضيًا؛ والجأ إلى `securable-code` عندما تكون قرارات التصميم غير واضحة بما يكفي لتبرير قراءة الإطار نفسه. ## الملخص يُعرّف هذا المستودع البرمجيات القابلة للتأمين بأنها برمجيات مبنية لتبقى قابلة للدفاع: مُهيكلة بحيث يمكن فهمها وتغييرها واختبارها وتحصينها مع تغيّر العالم من حولها. ويؤكد أن الأمن عملية مستمرة، وليس إنجازًا ثابتًا. ويقدّم نموذج هندسة البرمجيات القابلة للتأمين (SSEM)، الذي يؤطّر الأمن كمجموعة متأصلة من الخصائص للبرمجيات جيدة الهندسة. ولتحقيق ذلك، يعرض فئات السمات التالية: قابلية الصيانة، والموثوقية، والاعتمادية (التي تشمل المرونة). ويدعو FIASSE إلى دمج ممارسات الأمن في سير عمل التطوير حيث يكون لها الأثر الأكبر. وهذا ينقلنا من نهج "الأمن كفكرة لاحقة" أو نهج "الإزاحة لليسار" إلى نموذج استباقي تعاوني. يعمل مالكو المنتجات والمطورون ومتخصصو الأمن معًا منذ المراحل الأولى للتصميم، لا سيما من خلال تحديد متطلبات الأمن، والنمذجة التعاونية للتهديدات، ومعايير قبول الأمن. وهذا يضع توقعات واضحة لأنشطة الشيفرة والاختبار. وتعمل مراجعات الدمج كحواجز حماية، لا كبوابات. فكل عملية دمج تُنتج تقرير قابلية تأمين استشاريًا، والبوابة قرار سياسي له مسار تجاوز. وتُعامَل النتائج المستخلصة من التحقق والإنتاج كمعلومات استخبارية تجريبية تشير إلى المرحلة السابقة التي كان يمكنها منعها. ويُقدَّم للمهندسين البرمجيين إرشاد حول الموازنة بين المرونة والتحكم. كما يُقدَّم لهم نموذج حاسم لاتخاذ قرارات الأمن. وفي نهاية المطاف، فإن هذا يمكّن جميع أصحاب المصلحة من المساهمة في بناء أنظمة أكثر متانة واعتمادية وقابلة للتأمين بطبيعتها. يختلف FIASSE عن الأساليب القائمة بأنه لا يطلب من المطورين أن يصبحوا خبراء أمن أو أن يتبنّوا عقلية عدائية. فهو يسمّي أنماطًا مضادة شائعة في أمن التطبيقات (AppSec)، مثل "الجرف لليسار" (Shoveling Left) بإلقاء مخرجات الأدوات الخام على المطورين والتدريب القائم على الاستغلال أولًا، ويستبدلها بمبدأ المعلومات الأمنية القابلة للتنفيذ. ويهدف هذا النهج إلى تقليل العبء المعرفي على المطورين مع ضمان أن يكون ممارسو الأمن واثقين من أن مخاوفهم تُعالَج من خلال سمات محددة في الشيفرة وعمليات هندسة البرمجيات. يقصد FIASSE أن يكون مفتوحًا وسهل المنال وتعاونيًا. ## خارطة الطريق المعالم الأولية لمشروع FIASSE: - **تأسيس المشروع** - إنشاء حوكمة المشروع، وإرشادات المساهمة، وقنوات التواصل. - **المواصفات الأساسية** - النشر الرسمي لإطار FIASSE ومواصفة SSEM، مع تفصيل السمات الأساسية واستراتيجيات الدمج. - **موارد التبني والتعليم** - تمهيد لـ SSEM لتقديم النموذج وتطبيقه. - مجموعة من حالات الاستخدام الأولية وأنماط التبني لتوضيح الفوائد العملية. - تطوير مستمر لأدلة التنفيذ والأمثلة والمواد التعليمية الأخرى. سيتم تطوير مزيد من المعالم مع فريق المشروع. ومساهمات المجتمع مرحّب بها عبر [GitHub Discussions](https://github.com/OWASP/FIASSE/discussions). ## موارد مكمّلة يكمّل هذا المستودع [موقع FIASSE](https://fiasse.org). مشروع [OWASP FIASSE](https://owasp.org/www-project-fiasse/) جزء من [مؤسسة OWASP](https://owasp.org/)، وهي منظمة غير ربحية تركز على مهمة القضاء على البرمجيات غير الآمنة. وتوفّر مؤسسة OWASP ثروة من الموارد والأطر التي تتوافق مع مبادئ FIASSE. يركّز هذا الإطار على هندسة البرمجيات القابلة للتأمين، وتكمّله مشاريع OWASP أخرى: - التحقق من ميزات الأمان ومكتبة جاهزة لمتطلبات الأمان: [معيار التحقق من أمان التطبيقات في OWASP (ASVS)](https://owasp.org/www-project-application-security-verification-standard/) - نضج الضمان: [نموذج نضج ضمان البرمجيات في OWASP (SAMM)](https://owasp.org/www-project-samm/) - الامتثال لأمن المنتج: [إطار قدرات أمن المنتج في OWASP (PSCF)](https://owasp.org/www-project-product-security-capability-framework/) تستضيف OWASP أيضًا العديد من المشاريع التي توثّق متطلبات الأمان وميزاته، مثل [أمن تطبيقات الهاتف المحمول في OWASP](https://mas.owasp.org/). ويُعد [دليل المطور في OWASP](https://owasp.org/www-project-developer-guide/) مصدرًا شاملًا لمختلف موارد OWASP الأخرى. من الموارد الرائعة الأخرى المرجعية لمتطلبات الضمان وممارساته [OpenCRE](https://opencre.org/) الذي يجمع ويُخطّط مختلف أطر الأمان. تدعم كتالوجات الضوابط مثل NIST SP 800-53 والملحق A من ISO/IEC 27001 وPCI DSS إدارة المخاطر والضمان والتقييم الخارجي. ولا يحل FIASSE محلها. بل يتعامل معها كمدخلات لجمع المتطلبات، حيث يُترجم ضابط الكتالوج إلى متطلب أمان مع معايير قبول قبل أن ينفذه التطوير. يُعرّف NIST [إطار تطوير البرمجيات الآمنة (SSDF)](https://csrc.nist.gov/publications/detail/sp/800-218/final) مجموعة أساسية من ممارسات تطوير البرمجيات الآمنة المنظمة في أربع مجموعات. ولا يُعرّف FIASSE مجموعة ممارسات كهذه. بل يتوافق مع SSDF من خلال التأكيد على دمج الأمان في دورة حياة تطوير البرمجيات. يُعرّف [مدونة ممارسات أمن البرمجيات](https://www.ncsc.gov.uk/collection/software-security-code-of-practice-implementation-guidance) الصادرة عن NCSC النتائج المرجوة وبعض الاستراتيجيات الرئيسية. ويركز FIASSE على مبادئ واستراتيجيات المتابعة من المستوى الأول لتحقيق نتائج قابلة للتأمين، موجهة لفِرَق التطوير والضمان لتتوافق مع استراتيجيات الأعمال. ويحدد SSEM السمات المستخدمة لإنتاج النتائج المرجوة، وتوفر منهجية FIASSE إرشادات عملية لتنفيذ هذه السمات في ممارسات هندسة البرمجيات. تُعد معايير الترميز الآمن الصادرة عن [CERT](https://www.cert.org/) في جامعة كارنيجي ميلون مجموعة من القواعد على مستوى اللغة التي تقدم أمثلة "ما لا يجب فعله" تُظهر أنماط شيفرة قابلة للاستغلال وأمثلة "ما يجب فعله". ويكمل FIASSE هذه القواعد من خلال توفير نهج قائم على المبادئ يساعد المبرمجين على فهم "لماذا؟" وراء الشيفرة القابلة للتأمين. إطار أمن مصنع البرمجيات ([SF2](https://sf2framework.com/)) "يزوّد قادة الأمن بنهج استراتيجي لتوسيع قدرات الأمان مع تحسين نتائج الأعمال." وهو إطار على المستوى التنظيمي يكمل تركيز FIASSE على ممارسات هندسة البرمجيات. ## المساهمة نرحب بالمساهمات لتحسين الوثائق والأمثلة. يُرجى الاطلاع على [إرشادات المساهمة](https://github.com/owasp/fiasse/blob/main/CONTRIBUTING.md) للحصول على التفاصيل. ## الترخيص نسب المشتقات على نفس الشروط 4.0 دولي (CC BY-SA 4.0) - راجع ملف [LICENSE](https://github.com/owasp/fiasse/blob/main/licence.txt) للحصول على التفاصيل. ## شكر وتقدير هذا المشروع جهد تعاوني من مجتمع OWASP. نشكر جميع المساهمين على مدخلاتهم القيّمة وتفانيهم في تحسين أمن البرمجيات. توجد [قائمة بالمساهمين](https://github.com/owasp/fiasse/blob/main/CONTRIBUTORS.md) الذين شاركوا في هذا المشروع. ساعد بعض المساهمين الأوائل في تشكيل المفاهيم الأولية واختبار الأفكار من منظور الفريق الأحمر.
