owasp/packmanمشروع توثيق وتتبع يهدف إلى جعل أنظمة إدارة الحزم أكثر أمانًا.
مشروع توثيق وتتبع يهدف إلى جعل أنظمة إدارة الحزم أكثر أمانًا. راجع القضايا للحصول على قائمة تقريبية جدًا ببعض القضايا ذات الصلة التي رأيناها.
| اللغة | الاسم | المستوى | الضوابط | قائد باكمان | صفحة باكمان |
|---|---|---|---|---|---|
| JavaScript | npm | 1 | npm | ||
| Ruby | RubyGems | 1 | rubygems | ||
| Python | PyPi | 1 | pip/pypi | ||
| Java | Maven Central | 2 | maven central | ||
| Java | Android Central | ? | |||
| .Net | NuGet | 2 | nuget | ||
| Docker Hub | Docker | 1 | |||
| Golang | go get | 1 | golang | ||
| PHP | Composer | ? | |||
| Cocoa | Cocoa Pods | ? | |||
| Swift | Swift Package Manager | 1 | swiftpm | ||
| Rust | Cargo | 2? | rustcargo |
تصف الأقسام التالية كل ضابط من الضوابط المذكورة في الجدول أعلاه بمزيد من التفصيل.
المصادقة القوية تعني أن النظام يتطلب:
نظرًا لأن القدرة على دفع كود جديد إلى مدير الحزم هي وظيفة قوية، فمن المهم معرفة أنه لا يمكن القيام به بسهولة عن طريق تخمين كلمة مرور المشرف. تنفيذ المصادقة متعددة العوامل
لاستيفاء هذا المتطلب، يجب أن يكون لدى مدير الحزم طريقة لتلقي المعلومات الأمنية من المجتمع وعملية للتعامل مع هذه الملاحظات. البريد الإلكتروني المنشور مثل security@، إلى جانب آلية تضمن تسجيل الملاحظات والرد عليها، سيفي بهذا المتطلب.
قد تحدد الحزم نفسها المشكلات أو يتم إخطارها بها. يجب أن تدعم المنصة طريقة لمشرف الحزمة للإبلاغ عن إصدار به مشكلة أمنية:
يجب ربط الحزم بطريقة ما بنسخة صريحة من الكود (علامة؟) في مستودع عام معروف (bitbucket.org, github.com).
عند تحديث الحزم، يجب إخطار جميع المشرفين على تلك الحزمة.
عند تحديد مشكلات أمنية في حزمة، يجب أن تكون هناك طريقة للمستهلك للتحقق من ذلك. يمكن أن يكون هذا أمرًا يسمح للمستهلك بالتحقق من المشكلات المعروفة.
يجب أن يكون من الممكن للمطورين توقيع كودهم. عندما يفعلون ذلك، يجب على مدير الحزم التحقق من التوقيعات وتوفير طريقة لتوزيعها على مستهلكي الحزمة.
يوفر مدير الحزم طريقة للتحقق من سلامة الحزمة التي تم تنزيلها.
لا - لا يتم التحقق من السلامة جزئي - يتم التحقق من السلامة باستخدام طريقة ضعيفة* نعم - يتم التحقق باستخدام طريقة آمنة بشكل كافٍ
يمكن للمنصة توفير تحليل ثابت للكود لتحديد المشكلات المحتملة بشكل استباقي في المكتبات المهمة.
يمكن للمنصة تتبع الثغرات الأمنية في المكتبات التي تعتمد عليها الحزمة (الحزم الأولية) وإخطار المشرفين بذلك.
يجب ألا ينفذ مدير الحزم كودًا عند تثبيت الحزمة.
يجب ألا يقوم مدير الحزم بجمع معلومات حول المشروع الذي يستخدم التبعية.
يجب أن يحتوي نظام إدارة الحزم على دليل للأدوار في المشروع والذي يجب أن يتضمن خطة خلافة وشروط للمشاركة النشطة.
يجب أن يكون لدى القائمين على نظام إدارة الحزم عملية لمراجعة الأدوار في المشاريع لضمان أن المشرفين نشطون.
يجب أن يكون مستهلكو المكتبات قادرين على وضع علامة على اهتمامهم أو موافقتهم على مكتبة معينة بحيث يمكنهم ضمان أن البنيات تستخدم فقط المكتبات التي وضعوا عليها علامات بطرق معينة. على سبيل المثال، تم وضع علامة كمراجعة الكود.
يوفر مدير الحزم بعض التحكم لمنع تسرب بيانات اعتماد المصادقة / الرمز المميز / الجلسة كجزء من محتويات الحزمة.
لا - لا يوجد تحكم والمستخدم يحمي نفسه جزئي - أدخل تعليقًا نعم - يتم حظر بيانات الاعتماد / الرموز المميزة من النشر أو يتم إبطالها بطريقة آلية يتم تشغيلها عند نشر حزمة. يجب إخطار المستخدمين بطريقة ما بأن الإجراء قد تم.
| الضابط | Tier 1 | Tier 2 | Tier 3 |
|---|
| المصادقة القوية | ☐ | ☑ | ☑ |
| المصادقة متعددة العوامل لدفع القطع الأثرية | ☐ | ☑ | ☑ |
| جهات الاتصال الأمنية | ☐ | ☑ | ☑ |
| يمكن للحزم الإبلاغ عن المشكلات الأمنية | ☐ | ☑ | ☑ |
| ربط حزمة الكود بالكود المصدري | ☐ | ☑ | ☑ |
| منع نشر بيانات الاعتماد | ☐ | ☑ | ☑ |
| إشعارات التحديث | ☐ | ☑ | ☑ |
| توقيع الكود | ☐ | ☐ | ☑ |
| التحقق من السلامة | ☐ | ☐ | ☑ |
| تحليل الكود (ثابت) | ☐ | ☐ | ☑ |
| تحليل تبعيات الكود | ☐ | ☐ | ☑ |
| مدير الحزم لا ينفذ كودًا | ☐ | ☐ | ☑ |
| مدير الحزم لا يجمع معلومات | ☐ | ☐ | ☑ |
| دليل الأدوار في المشروع | ☐ | ☐ | ☑ |
| مراجعة الأدوار في المشروع | ☐ | ☐ | ☑ |
| وضع علامات على المكتبات على مستوى الحساب | ☐ | ☐ | ☐ |
