TL؛ DR
تُكتب معظم متطلبات أمان تطوير البرمجيات على شكل نوايا، مما يعني أنه لا يمكن لأحد أن ينجح أو يفشل فيها. عبارة "يجب تأمين التبعيات" تبدو جيدة وتجتاز المراجعة بنجاح، إلى أن يطلب المدقق الاطلاع على الملف. لكن قائمة التحقق هذه لمتطلبات أمان البرمجيات تقدم لك 12 سطراً مكتوبة بترتيب معكوس.
- لا يمكن التحقق من أي شرط إلا عند وجود ثلاثة أشياء. عنصر مُسمى، ولحظة فحصه، وسلوك مُحدد عند فشل الفحص. معظم متطلبات أمان البرمجيات تفشل في العنصر الأول.
- كل سطر من الأسطر الاثني عشر يقدم دليلاً. شهادة إثبات المنشأ، SBOM مرتبط بإصدار مُعلن، وطابع زمني للإلغاء، وبوابةcisأيون مع مالك. ليس تقريرًا من الماسح الضوئي.
- انقسموا إلى ثلاث مجموعات. ما الذي يدخل إلى برنامجك، وما الذي يبنيه، وما الذي يثبت حالته.
- التحقق منها هو SSCS و ASPM المشكلة ليست في الماسح الضوئي. ست أدوات تنتج ستة dashboardويريد المدقق إجابة واحدة. يجب أن تأتي الأدلة من مصدر واحد وإلا فلن تأتي على الإطلاق.
لماذا تفشل معظم متطلبات أمان تطوير البرمجيات بمجرد أن يقوم شخص ما بمراجعتها؟
افتح أي وثيقة متطلبات أمنية تقريبًا، وستجد جملًا مثل "يجب أن تكون مكونات الطرف الثالث خالية من الثغرات الأمنية المعروفة" و"البناء pipeline يجب تأمينها. إنها جيدة القراءة. تجتاز المراجعة. ثم يقوم مدقق حسابات، أو استبيان أمني للعملاء، أو NIS2 or DORA يطرح المقيم سؤالاً بسيطاً: أرني.
عند هذه النقطة، ينهار الشرط، لأنه لم يحدد أحد معنى "خالٍ من الثغرات الأمنية المعروفة" في أي مرحلة من مراحل دورة حياة المنتج، ومن يقرر ذلك، وما هو الملف الذي يتم تسليمه. يتخبط الفريق، ويصدر تقريرًا للفحص، ويأمل أن يُفسر حجم النتائج على أنه دليل على الحرص.
لا يكمن الخلل في الجهد المبذول، فالفرق التي تستخدم أربع أو خمس أدوات تبذل جهدًا كبيرًا. يكمن الخلل في أن متطلبات أمان البرمجيات كُتبت لوصف حالة مرغوبة بدلًا من حدث قابل للتحقق. الحالة المرغوبة لا يوجد دليل يدعمها، بينما الحدث مدعوم. كل ما يجعل أمان تطوير البرمجيات قابلًا للتدقيق ينبع من هذا التمييز.
ما الذي يجعل متطلبات أمان البرمجيات قابلة للتحقق؟
ثلاث خصائص، ويتطلب الشرط وجود الخصائص الثلاث جميعها:
- قطعة أثرية تحمل اسماً. شهادة، SBOM، سجل موقع، بوابة ديcision. شيء موجود كملف أو سجل ويمكن إنتاجه عند الطلب.
- لحظة. Pull request، بناء، إصدار، أو بشكل مستمر. "في مرحلة ما من SDLC"ليست لحظة."
- سلوك فشل محدد. ماذا يحدث عند فشل الفحص: الحظر، أو التحذير، أو الحجر الصحي، أو التوجيه إلى مالك محدد مع مسار استثناء موثق.
قم بتطبيق متطلباتك الحالية من خلال هذه الخصائص الثلاث. ستفشل معظمها في الأولى، ولهذا السبب ينتهي الأمر بالفرق بالتفاوض مع المدققين بدلاً من الإجابة عليهم.
كُتبت الأسطر الاثنا عشر التالية بحيث يجتاز كل سطر منها المعايير الثلاثة جميعها. وهي مملة عمداً، فالمتطلبات القابلة للتحقق عادة ما تكون كذلك.
قائمة التحقق من متطلبات أمان تطوير البرمجيات: 12 بندًا يمكن التحقق منها فعليًا
يُحدد كل سطر القطعة الأثرية التي تثبت ذلك، والسؤال الذي يختبره، ومصدر الدليل.
المجموعة الأولى: ما الذي يدخل إلى برنامجك
| متطلبات | التحقق من خلال | دليل |
|---|---|---|
| 01يتم فحص كل تبعية بحثًا عن سلوك ضار دون انتظار توقيع منشور | طلب نتيجة الفحص لأي حزمة تمت إضافتها خلال الثلاثين يومًا الماضية | الإنذار المبكر بالبرامج الضارة يكشف عن الحزم الخبيثة في جميع أنحاء التعليمات البرمجية، pipelines, IaC والسجلات قبل وجود توقيع أو توصية، باستخدام الكشف عن الأدلة متبوعًا بالتحقق من صحة الذكاء الاصطناعي |
| 02كل إصدار له... SBOM، قابلة للاسترجاع حسب الإصدار، تم إنشاؤها بواسطة عملية البناء بدلاً من تجميعها يدويًا | تسمية نسخة تم إصدارها وطلبها SBOM في غضون خمس دقائق | SBOM جيل لكل بناءمع إرفاق تقارير الكشف عن الثغرات الأمنية |
| 03لا تمنع الثغرة الأمنية إصدار البرنامج إلا إذا كان الوصول إليها ممكناً في التعليمات البرمجية الخاصة بك | لنأخذ ثلاث نتائج محظورة ونسأل عن مسار الوظيفة الذي يجعلها قابلة للاستغلال | إمكانية الوصول على مستوى الوظيفة، وإمكانية الاستغلال، وEPSS داخل قمع تحديد الأولويات |
| 04المكونات المعروفة بضعفها تحمل مالكًا ومسؤولًا.cisأيون، ليس مجرد تذكرة | اختر أي نتيجة نقدية مفتوحة واسأل من قبل المخاطرة، وإلى متى؟ | يتم تتبع الملكية والحالة مقابل الأصل، وليس مقابل عملية المسح الضوئي. |
| 05تُعامل تبعيات الذكاء الاصطناعي والتعلم الآلي كسلسلة توريد عادية، لأنها | السؤال عن الثغرات الأمنية (CVEs) التي تؤثر على مكتبات التعلم الآلي المستخدمة في الإنتاج اليوم | تحليل التركيب الذي يغطي مجموعة أدوات الذكاء الاصطناعي في نفس المنصة التي تستخدم أصول الذكاء الاصطناعي. |
المجموعة الثانية: ما الذي يبني برنامجك
| متطلبات | التحقق من خلال | دليل |
|---|---|---|
| 06كل عملية بناء تُنتج شهادة إثبات مصدر يمكن التحقق منها بشكل مستقل | استخراج شهادة أحدث منتج إنتاجي ومقارنتها بالمصدر commit | SLSA provenance و شهادات مخصصة شاملة مع التوقيعات الإلكترونية بدون مفتاح، والمخزنة في أي سجل، مع حظر العناصر التي تم التلاعب بها قبل التسليم |
| 07Pipeline يتم فحص التكوين كشفرة، بنفس وتيرة فحص شفرة التطبيق. | السؤال عن تاريخ آخر مراجعة أمنية لتغيير إعدادات GitHub Actions أو Jenkins، ومن قام بذلك. | CI/CD أمن تغطية pipeline سوء التكوين، واختلال سير العمل، ومخاطر سلسلة التوريد، مع SSCS الامتثال مدمج |
| 08يتم إلغاء كل سر يتم العثور عليه في أي مكان في دورة الحياة، وليس مجرد الإبلاغ عنه. | طلب آخر خمسة أسرار تم اكتشافها وتواريخ إلغائها. | الكشف عبر التعليمات البرمجية، والتكوينات، والحاويات، و pipelineمع أكثر من 100 نوع سري، بالإضافة إلى الإلغاء التلقائي playbooks لكل نوع من أنواع بيانات الاعتماد |
| 09نشاط غير طبيعي في pipeline يُصدر تنبيهًا قبل أن يتحول الأمر إلى حادث. | السؤال عن العداء المتضرر أو غير العادي commit النمط الذي سيتم تفعيله، ومن سيستلمه | إكتشاف عيب خلقي بشأن النشاط الذي يسبق الهجوم |
المجموعة الثالثة: ما الذي يثبت حالة برنامجك؟
| متطلبات | التحقق من خلال | دليل |
|---|---|---|
| 10يتم تقييد البنية التحتية كبرنامج قبل الدمج، ولا يتم تصحيحها بعد النشر. | السؤال هو ما إذا كان تغيير غير آمن في Terraform يمكن أن يصل إلى النسخة الرئيسية، وما الذي يمنعه من ذلك؟ | IaC المسح الضوئي مع guardrails في pull request |
| 11تشترك النتائج المستخلصة من جميع الأدوات، سواءً كانت أدواتك أو أدوات جهات خارجية، في نموذج واحد لشدة الحالة. | السؤال عما إذا كانت الإشارة الحرجة من ماسح ضوئي واحد والإشارة الحرجة من ماسح ضوئي آخر تعني الشيء نفسه لفريقك | استخدم ASPM طبقة يستوعب النتائج من SAST, SCA، وDAST و IaC الأدوات التي تستخدمها بالفعل، بغض النظر عمن قام بتطويرها، وتطبق نفس معايير تحديد الأولويات والفرز والشرح والمعالجة التي تطبقها على النتائج الأصلية |
| 12يتم جرد كل أصول الذكاء الاصطناعي في قاعدة التعليمات البرمجية وهي قابلة للتصدير | الاستفسار عن النماذج والوكلاء وخوادم MCP التي تعمل في تطبيقاتك، وطلب الملف | الاكتشاف المستمر من النماذج، والأطر، ومجموعات البيانات، ونقاط نهاية الاستدلال، والوكلاء، وخوادم MCP، والمهارات، والمطالبات، وأدوات برمجة الذكاء الاصطناعي، مع CycloneDX ML-BOM يتم إنشاؤها في كل عملية مسح |
من المسؤول عن كل بند من بنود قائمة التحقق؟
إنّ وثيقة المتطلبات التي لا تحتوي على خانة للمسؤول هي مجرد قائمة أمنيات. لذا، قم بتعيين كل سطر قبل نشرها.
أما العمود الثاني فهو الذي يفشل عملياً. فالتحقق المستمر لا ينجح إلا عندما تتجمع الأدلة من تلقاء نفسها.
كيف يمكنك التحقق من قائمة متطلبات أمان تطوير البرمجيات دون إضافة وحدة تحكم أخرى؟
هنا تتعثر معظم البرامج. المتطلبات الـ 12 المذكورة أعلاه تتعلق بالتبعيات. pipelineقم ببناء العناصر، والأسرار، وشفرة البنية التحتية، وأصول الذكاء الاصطناعي. تحقق منها باستخدام ست أدوات منفصلة، وبذلك تكون قد أنشأت مهمة سابعة: التوفيق بين ستة dashboardتحويلها إلى إجابة واحدة للمدقق الذي يريد رقمًا واحدًا.
هناك قدرتان تجعلان هذا الأمر قابلاً للتنفيذ.
- Software supply chain security (SSCSيغطي هذا القسم المتطلبات التي تقع بين commit والقطعة الأثرية. التبعيات، pipelineإن سلامة البناء والأسرار والنشاط الشاذ هي أحد أسطح الهجوم، وهي أيضًا مصدر أصعب الأدلة التي يصعب تزويرها: فالشهادة الموقعة لها قيمة أكبر بالنسبة للمقيّم من تقرير الماسح الضوئي، لأنه لا يمكن إعادة إنشائها بعد وقوع الحدث.
- ASPM هي الطبقة التي تحول النتائج إلى موقف يمكنك الإبلاغ عنه. هذا الأمر مهم هنا لسبب محدد: فهو يستوعب البيانات التي تنتجها الماسحات الضوئية الموجودة لديك بالفعل. لستَ مضطرًا لاستبدال الأدوات التي دفعت ثمنها مسبقًا لتلبية هذه المتطلبات. تصبح مخرجاته مدخلات، وينطبق عليها نفس الترتيب حسب الأولوية، والفرز باستخدام الذكاء الاصطناعي، والشرح، والمعالجة، كما هو الحال مع النتائج الأصلية. سيفشل برنامج أمان تطوير البرمجيات المبني على منصة لا تفهم إلا الماسحات الضوئية الخاصة بها في كل مرة يتم فيها دمج البيانات، وكلها تُدمج بالفعل.
ما الذي يتغير عندما يقوم وكيل بكتابة الكود؟
كل ما سبق يفترض أن إنسانًا هو من كتب التغيير وأن إنسانًا آخر راجعه. هذا الافتراض آخذ في التلاشي، وهو يُعيد تشكيل ما يجب أن يشمله أمن تطوير البرمجيات.
عندما يُنتج برنامج برمجة ألف ملف في أسبوع، تتوقف مراجعة الكود عن كونها أداة تحكم وتتحول إلى مجرد قائمة انتظار. ثلاثة من الأسطر الاثني عشر تحمل العبء الأكبر في هذا السياق: فحص التبعيات الخبيثة (لأن البرامج تسحب الحزم بسرعة، وأسماء الحزم المُضللة تُعدّ الآن ثغرة أمنية مُسجلة). pull request تم تصنيف التحليل حسب قابلية الاستغلال بدلاً من الخطورة المطلقة، وجرد أصول الذكاء الاصطناعي.
وهناك أيضاً متطلب رابع يستحق الإضافة إلى أي قائمة تحقق لمتطلبات أمان البرامج التي ستُكتب في عام 2026: تتم مراجعة ملفات التكوين التي توجه أدوات الذكاء الاصطناعي الخاصة بك باعتبارها عناصر أمنية. ملفات المهارات، وملفات القواعد، وتكوينات خادم MCP هي commitيتم التعامل معها كنص عادي ومراجعتها كما لو كانت وثائق، وهي تحدد ما يُطلب من المساعد القيام به وما يُسمح له بالوصول إليه.
كيف تنتقل من قائمة التحقق إلى الأدلة؟
لا تبدأ بإعادة كتابة المستند بأكمله. خذ الأسطر الثلاثة التي ستختبرها عملية التدقيق أو استبيان العملاء أو مراجعة مجلس الإدارة التالية، عادةً SBOM عند الطلب، وإلغاء سري، وإثبات المنشأ. أثبت هذه الأمور الثلاثة من البداية إلى النهاية، مع وجود القطعة الأثرية بين يديك. ثم قم بالتمديد.
قائمة التحقق من متطلبات أمان تطوير البرمجيات ليست وثيقة قابلة للتنفيذ.cisهـ. يكمن الفرق بين برنامج أمني قادر على الإجابة عن الأسئلة وآخر لا يستطيع سوى وصف نفسه. اثنا عشر سطراً قابلة للتحقق أفضل من أربعين سطراً طموحاً، لأن اثني عشر منها تبقى صالحة عند طلب الاطلاع على الملف.
إذا لم تتمكن متطلبات أمان برامجك من إنتاج عنصر عند الطلب، فأنت لا تملك متطلبات أصلاً، بل تملك نوايا مع رقم إصدار.
انظر إلى ما تثبته ممتلكاتك بالفعل. قم بتوصيل مستودع، و زيجيني يعيد إليك تبعياتك، pipelines، والأسرار، وحالة سلامة البناء، وجرد الذكاء الاصطناعي في عرض وضعية واحد، مع إرفاق الأدلة بكل نتيجة. ابدأ مجانًا or كتاب التجريبي.
الأسئلة الشائعة
كم عدد متطلبات أمان البرامج التي يجب أن تتضمنها قائمة التحقق؟
أقل مما تتصور. العدد المفيد هو العدد الذي يمكنك التحقق منه عند الطلب، والذي يتراوح عادةً بين 10 و20 لمعظم الفرق. قائمة تضم 60 متطلباً، 45 منها بدون دليل، أضعف من قائمة تضم 12 متطلباً، كل بند فيها يُنتج دليلاً. ابدأ بالبنود التي ستختبرها عملية التدقيق التالية، ثم وسّع نطاقها.
ما الفرق بين أمن تطوير البرمجيات وإطار الامتثال؟
يحدد إطار عمل مثل NIS2 أو DORA أو قانون المرونة السيبرانية النتائج المتوقعة. أما أمن تطوير البرمجيات فيتمثل في كيفية تحويل هذه النتائج إلى معايير يمكن لفريق الهندسة الخاص بك اجتيازها أو الفشل فيها. pull request أو البناء. تُكتب الأطر للمقيّمين، وتُكتب المتطلبات للمطورين، ومعظم المشاكل في برنامج الامتثال تأتي من عدم قيام أي شخص بهذه الترجمة.
هل يمكنني التحقق من قائمة متطلبات أمان البرامج باستخدام الماسحات الضوئية التي أملكها بالفعل؟
جزئياً. تُنتج الماسحات الضوئية نتائج، ويتطلب العديد من هذه المتطلبات وجود وثائق بدلاً من ذلك: مثل شهادة المنشأ، و SBOM مرتبط بإصدار مُعلن، وسجل إلغاء، وبوابةcisمع مالك. ولهذا السبب توجد قائمة التحقق SSCS و ASPM بدلاً من استخدام الماسح الضوئي. يتمثل الحل العملي في الاحتفاظ بالماسحات الضوئية الحالية وإضافة طبقة فوقها تستوعب نتائجها وتطبق نموذج تحديد أولويات واحد عليها جميعها.
ما هو الشرط الذي غالباً ما تخطئ فيه الفرق؟
الأسرار. تنص جميع قوائم التحقق تقريبًا على أنه يجب عدم الكشف عن الأسرار. commitلا يوجد تقريبًا أي شرط ينص على وجوب إلغاء صلاحية السر المكتشف خلال فترة زمنية محددة. يؤدي الاكتشاف دون إلغاء الصلاحية إلى بقاء بيانات اعتماد سارية في سجل المستودع، ويصبح السجل عامًا بمجرد إنشاء المستودع. أعد صياغة هذا الشرط ليصبح شرطًا للإلغاء مع طابع زمني، وبذلك يصبح قابلاً للتحقق.
