اكتشاف الثغرة أمر سهل؛ مهمة الأمان هي دمج التصحيح ونشره، لذا بالنسبة للتبعيات الضعيفة، يفتح Coroid التحديث pull request بنفسه، ويتولى فريقك مراجعته ودمجه.
عندما يفتح Coroid واحدًا من هذه التحديثات
باستخدام تصحيح التبعيات الضعيفة ، عند تفعيله، تؤدي أي نتيجة تبعية بدرجة خطورة تصل إلى مستوى التصحيح (عالية بشكل افتراضي) إلى فتح مهمة تصحيح في مشروعها:
- مهمة واحدة وpull request لكل حزمة، لتغطية كل التحذيرات التي تؤثر عليها.
- النتائج الحرجة أولاًثم العالية.
- بحد أقصى 5 طلبات سحب تصحيح مفتوحة لكل مشروع بشكل افتراضي (حتى 50). تنتظر المهمة التالية دورها حتى يتوفر مساحة.
يمكن للمالكين والمشرفين أيضًا اختيار تصحيح على أي نتيجة تبعية مفتوحة يكون تحذيرها عامًا. وعند عدم صدور إصدار ثابت بعد، يقدم خيار التصحيح مهمة تخفيف بدلاً من ذلك: إزالة الحزمة أو استبدالها، أو تثبيت نسخة مُصححة، أو حماية الاستدعاء الضعيف.
تعمل التحديثات التلقائية لمشاريع npm اليوم؛ أما بالنسبة لأنظمة البيئات الأخرى، فتوضح النتيجة "لا يوجد تصحيح تلقائي لهذه البيئة بعد"، ويقدم خيار التصحيح مهمة تخفيف.
ما الذي يغطيه تكلفة هذا؟
تستخدم مهام التصحيح نموذج AI، لذا تستهلك ساعات الوكلاء مثل أي عمل آخر. وتعمل ضمن الالتزام المدمج بـ تصحيحات الأمان ، والذي تمتلكه كل مؤسسة:
- النطاق: تحديثات التبعيات وتخفيف الثغرات الأمنية، ولا شيء غير ذلك.
- الميزانية: ساعات الوكلاء فقط، وبشكل افتراضي ربع ساعات الوكلاء المتاحة في خطتك شهريًا. يمكن للمالكين تغيير عدد الساعات، وما إذا كانت تُحتسب أسبوعيًا أم شهريًا، عبر قسم الأمان ← إعدادات ← تصحيح التبعيات الضعيفة.
- لا انتهاء لفترة المراجعة. إنه إعداد افتراضي دائم، لا يحتاج إلى تجديد.
- الأولوية: تُعطى تصحيحات الأمان الأولوية على أي عمل آخر ذاتي البدء.
إيقاف تشغيل خيار تصحيح التبعيات الضعيفة على مستوى المؤسسة يوقف هذا الالتزام. يظهر الالتزام مع غيره في ضبط الجودة ← الالتزامات.
عندما تحصل مؤسسة لديها مستودعات متصلة مسبقًا على خدمة الأمان، يتلقى المالكون إشعارًا في جرس الإشعارات: "تبدأ تصحيحات الأمان بعد سبعة أيام". تبدأ مهام التصحيح بعد سبعة أيام من إرسال هذا الإشعار، حتى يتمكن المالك من إيقافها قبل أول pull request. أما المؤسسات الجديدة فتبدأ فورًا.
لماذا قد تنتظر عملية التصحيح؟
يوضح قسم التصحيح للنتيجة ما الذي تنتظره؛ الأسباب الشائعة هي:
- وصول الحد المفتوح لـ pull request في المشروع إلى أقصاه؛
- نفاد ميزانية الالتزام أو ساعات الوكلاء المتاحة في الخطة (مع استمرار عمليات الكشف)؛
- توقف عمل الوكلاء في Mission Control، أو عدم توفر مساحة لوكلاء؛
- لم تنتهِ فترة الإشعار البالغة سبعة أيام؛
- عدم صدور تصحيح متوافق، أو عدم وجود تصحيح تلقائي للبيئة المستخدمة؛
- تفعيل خيار تصحيح التبعيات الضعيفة موقوف.
كيف يتم اختيار التحديث؟
لكل مكان تم تثبيت الحزمة الضعيفة فيه، يختار Coroid أصغر إصدار أعلى من الإصدار المثبت يصلح كل التحذيرات المؤثرة عليه، مع الالتزام بالنطاق المعلن وإصدار رئيسي ممكن. ولا يقوم بخفض الإصدار أبدًا. يحصل مساح العمل الذي يحتاج إصدارًا رئيسيًا واحدًا ومساح العمل الآخر الذي يحتاج إصدارًا آخر على نسخة مُصححة منفصلة ضمن نفس pull request. تتحرك الحزمة الانتقالية عبر تحديث الأصل أو تجاوز مدير الحزم. أي تغيير رئيسي أو توحيد لإصدار واحد يأتي مع سبب مذكور في pull request. وعند عدم وجود تحديث واحد يصلح كل شيء، يتم إدراج ما يمكن تصحيحه في طلب السحب ويُذكر الباقي على أنه غير مصحح.
ما الذي يحمله pull request؟
- التحذيرات التي يصلحها، مع درجة خطورتها.
- قائمة الحزم قبل وبعد التغيير، لإظهار اختفاء الإصدار الضعيف.
- فحوصات مشروعك: عندما تحتوي رسوم بيانية التسليم للمشروع على فحوصات يمكن تشغيلها، يجب أن تحصل على نتيجة "موافقة" على التغيير المُرسل قبل أن يفتح Coroid طلب pull request؛ وإلا تنتهي المهمة بذكر السبب. وعند عدم تهيئة فحوصات للمشروع، يظل pull request مفتوحًا ويوضح أن Coroid لم يشغل فحوصات المشروع، وأن نظام CI الخاص بمستودعك يعمل على pull request، وأين يمكن تهيئة الفحوصات في ضبط الجودة.
- أسباب أي تغيير رئيسي أو في النطاق.
- أي تحذير لم يتمكن من تصحيحه، مدرج كغير مصحح.
ينتهي الأمر بما يلي: "يقوم الأشخاص بمراجعة الطلبات ودمجها، ولا يتم تحديد حالة النشر إلا من خلال مسح للنسخة المنشورة." تُثبت النتيجة في الكود ابتداءً من جرد كامل تالي، وتُثبت لكل بيئة من خلال مسح للنسخة التي تعمل بها تلك البيئة. انظر إلى النتائج ودورة حياتها.
نتائج الكود
عند وجود نتيجة كود، إصلاح يقوم بإنشاء مهمة لإصلاحها ضمن مشروعه. يمكن للمالكين والمشرفين استخدامها على أي نتيجة كود مفتوحة. تطلب المهمة من المطور وصف الإصلاح، وليس طريقة الهجوم، في رسائل الالتزام وpull request، بالإضافة إلى إضافة اختبار انحدار. تتم معالجة هذه المهمة وفقًا لنفس القواعد المطبقة على المهام الأخرى، وتستهلك ساعات عمل الوكلاء.
في المستودع العام، أو في مستودع لا يستطيع Coroid التأكد من درجة شفافيته، لا يتم إرسال إصلاح النتيجة غير العامة بعد إلى ذلك المستودع. يحتفظ Coroid بالتغيير المُعد بشكل خاص ليقوم المالك أو المشرف بنشره. انظر إلى الكشف.
بيانات اعتماد مسربة
يتم إصلاح بيانات الاعتماد المسربة عبر تغييرها، وهو أمر لا يمكن لـ Coroid القيام به نيابة عنك. يؤدي الإصلاح على نتيجة بيانات اعتماد إلى إنشاء مهمة قائمة على قائمة تحقق. انظر إلى بيانات اعتماد مسربة.