بدلاً من فتح طلبات السحب على الفور عند إصدار إصدارات تبعية أحدث، ينتظر Dependabot الآن ثلاثة أيام قبل اقتراح الترقيات، مما يزيد من احتمالية التعرف على الإصدارات الضارة وإزالتها قبل أن يتم دمجها.
تشرح كارلين شيري، مديرة منتجات GitHub، سياسة التهدئة الجديدة من خلال الإشارة إلى حادثة تسمم التبعية الحقيقية التي وقعت قبل بضع سنوات، عندما تم استبدال العديد من الحزم المستخدمة على نطاق واسع، والتي تم تنزيلها بشكل جماعي أكثر من 2 مليار مرة في الأسبوع، بإصدارات مخترقة. على الرغم من اكتشاف هذه الإصدارات وإزالتها بسرعة من npm، إلا أن الساعتين تقريبًا اللتين ظلتا متاحتين كانتا “أكثر من كافية لأداة التحديث التلقائي لرؤية الإصدار الجديد، وفتح طلب سحب، ووضعه أمام فريقك”.
وفقا للكرز ،
ويكمن هذا النمط وراء حصة متزايدة من هجمات سلسلة التوريد. تظهر التعليمات البرمجية الضارة في إصدار جديد تمامًا، ويتم نشرها في سجل عام، ويتم سحبها إلى مسارات البناء في غضون دقائق، حتى قبل أن يطلع عليها الإنسان أو الماسح الضوئي.
للمساعدة في منع هذه السيناريوهات، ينتظر Dependabot الآن ثلاثة أيام على الأقل قبل فتح طلب سحب لتحديث التبعية بعد نشر إصدار جديد غير أمني. هذا السلوك قابل للتكوين من خلال cooldown الخيار في dependabot.yml، مما يسمح للفرق بتخصيصها وفقًا لاحتياجاتهم. لا ينطبق التباطؤ على التحديثات الأمنية، مما يضمن عدم تأخير إصلاحات الثغرات الأمنية المعروفة بشكل عام.
ويشير شيري إلى أن التأخير لمدة ثلاثة أيام يظهر كإجماع مجتمعي، “وبالتالي فإن هذا السلوك الافتراضي يبقي Dependabot ثابتًا أثناء تنقل المطورين بين الأدوات”. ومع ذلك، فإن فترة التهدئة لا تحل محل بقية الدفاعات ضد الأنواع الأخرى من هجمات سلسلة التوريد:
نظرًا لأن فترة التهدئة تعالج فقط الحالة سريعة الحركة، فيجب أن تكون طبقة واحدة من بين عدة طبقات. تتضمن بعض الخطوات الإضافية التي يجب اتخاذها تثبيت التبعيات باستخدام ملفات القفل، وتعطيل تثبيت البرامج النصية في CI حيث يمكنك، وتحديد نطاق الرموز المميزة في مسارات البناء الخاصة بك، ومراجعة التحديثات قبل دمجها.
عزز مستخدم Reddit Broaddiscovery_941 فكرة أن فترة التهدئة لمدة ثلاثة أيام فعالة:
يبدو أن ثلاثة أيام مناسبة لالتقاط أسوأ كسر قبل أن يصل إلى CI الخاص بك. يتم وضع علامة على معظم الإصدارات المراوغة على GitHub أو Reddit في غضون يوم أو يومين على أي حال، لذا فإن الانتظار يمنحك الوقت لرؤية الدراما تتكشف قبل دمج أي شيء.
في Hacker News، تساءل المعلق zihotki عما إذا كانت فترات التباطؤ قد تصبح أقل فعالية في النهاية، مشيرًا إلى أنه “إذا قام الجميع بتأخير التحديثات”، فقد تكون هناك “فرص أقل للقبض عليها في الوقت المناسب”. ردًا على ذلك، جادل المستخدم woodruffw بأن نموذج الأمان الكامن وراء عمليات التباطؤ لا يعتمد على المستخدمين النهائيين الذين يواجهون حزمًا ضارة، ولكن على جهود الفحص الأمني المخصصة: “يعتمد الافتراض الأمني وراء عمليات التباطؤ على أطراف المسح الأمني، وليس على المستخدمين الأبرياء الذين يقعون ضحية”. ومع اعترافهم بأن ثلاثة أيام تمثل تأخيرًا قصيرًا نسبيًا، فقد أضافوا أنه لا يزال يتعين توفير مهلة كافية لأنظمة المسح هذه لتحديد التهديدات والإبلاغ عنها.
