تعتقد معظم الفرق أن مخاطر سلسلة التوريد تكمن في "هل وجد `npm audit` أي شيء سيئ؟"
هذه جزء صغير من المشكلة.
تثق قناة تسليم JavaScript الحديثة بـ:
- الحزم التي تقوم بتثبيتها
- الحزم الثانوية التي تقوم بتثبيتها
- إجراءات GitHub التي تنفذها
- الرموز المميزة التي يمكن أن تصل إليها تلك السيرورات
هذه واجهة هجوم ذات مغزى، خاصةً عندما تحصل CI على إذن للتعليق على طلبات السحب، ونشر الحزم، ونشر البنية التحتية، أو الدفع إلى الفرع الافتراضي.
## أول فوز سهل: تثبيت الإجراءات الخارجية
هذا أضعف مما تدركه العديد من الفرق:
```yaml
uses: vendor/example-action@v2
يمكن أن يتحرك التعليق.
إذا كنت تعتمد على إجراءات الطرف الثالث، قم بالتثبيت على SHA الالتزام الكامل وراجع التحديثات بشكل متعمد:
uses: vendor/example-action@8f4b7f84864484a7bf31766abe9204da3cbe65b3
هذا لا يجعل الإجراء آمنًا. بل يجعل قرار الثقة واضحًا وقابلًا للمراجعة.
فصل التنفيذ غير الموثوق عن التنفيذ المتميز
واحد من أنماط سير العمل الأفضل هو:
- تشغيل الاختبارات وخطوات البناء في سير عمل غير متميز
- تحميل الآثار
- السماح لسير عمل موثوق آخر باستهلاك تلك الآثار إذا كان يحتاج إلى أسرار أو صلاحيات كتابة
هذا يقلل من احتمال تنفيذ كود طلب السحب غير الموثوق برمز يمكنه تغيير المستودع أو بيئة النشر.
تقليص نطاق الرمز المميز
إذا كان سير العمل يحتاج فقط إلى صلاحيات القراءة، امنحه صلاحيات القراءة.
إذا كان يحتاج إلى التعليق على طلب سحب، فلا تسمح له أيضًا بكتابة المحتويات، إدارة الحزم، أو نشر البنية التحتية.
تفشل العديد من قنوات الأنابيب في أبسط قاعدة في هندسة الأمان: اجعل دائرة الانفجار صغيرة.
أمان الحزم لا يزال جزءًا منه
يجب أن تعامل أيضًا نظافة الاعتماد كعمل تشغيلي طبيعي:
- احتفظ بملفات القفل المرتبطة
- راجع التغييرات الرئيسية في الاعتماديات
- أزل الحزم التي لا تحتاجها
- فضّل وصيانة المعتمدين المعروفين للمسارات الحرجة
هذا ليس عملًا مهيبًا. إنه الطريقة التي تبقى بها البرمجيات دفاعية.
قراءة إضافية