requirements.txt: أداة أساسية أم تهديد خفي؟
كل مشروع بايثون لديه هذا. هذا المظهر البريء requirements.txt يجلس في جذر المستودع الخاص بك، الملف pip install requirements.txt إن الاستهلاك عبارة عن قائمة من التبعيات، بالتأكيد، ولكن إذا لم تكن حذرًا، فقد يكون أيضًا بمثابة باب مفتوح على مصراعيه لعمليات بناء غير مستقرة، وحزم معرضة للخطر، ومشاكل أمنية خطيرة.
في الصميم، requirements.txt يتحكم في حزم الطرف الثالث التي يسحبها تطبيقك. عندما تقوم بتشغيل pip install -r requirements.txtيقوم مدير حزم بايثون بتثبيت جميع التبعيات المدرجة. ولكن إليك المشكلة: إذا لم تُثبّت الإصدارات الدقيقة، فستُحمّل الثقة في PyPI لتقديم إصدار آمن ومتوافق وغير معدّل دائمًا. ليس هكذا يعمل AppSec الحديث.
بدون تثبيت، قد تتعطل عمليات البناء. والأسوأ من ذلك، قد يبتلع تطبيقك حزمًا ضارة دون علمك. إصدارات مفتوحة (القارورة >=1.0, على سبيل المثال) أو قيود الإصدار الفضفاضة (جانجو~=3.2) تُعدّ بيئة خصبة لحقن أكواد غير آمنة. لهذا السبب، تُعدّ الإدارة السليمة requirements.txt هي مهمة أمنية أساسية.
أين يتم تجميد ملف pip وتثبيت ملف pip requirements.txt؟
تجميد النقطة مريحة، لكنها خطيرة أيضًا عند استخدامها دون فهم ما تلتقطه. غالبًا ما يُنشئ المطورون requirements.txt استخدام متطلبات تجميد pip.txt، متوقعين أن يُغلق بيئتهم. لكن التجميد لا يُثبت أمان أو أصل التبعيات؛ بل يُلغي كل ما هو مُثبّت حاليًا، بما في ذلك الحزم الانتقالية والتي قد تكون قديمة.
الآن تخيل أن أحد زملائك في الفريق، أو أحد ضباطك، يركض بشكل أعمى pip install -r requirements.txtإذا كان هذا الملف يتضمن ملفات قديمة أو معرضة للخطر أو حتى حزم بها أخطاء مطبعيةلقد قمت للتو بأتمتة حادثة أمنية.
مثال سريع:
# Developer's freeze output
pip freeze > requirements.txt
boto3==1.24.20
requests==2.27.1
⚠️ مثال غير آمن، لا تستخدمه في الإنتاج
أضف هذا الآن إلى CI الخاص بك pipeline:
- name: Install dependencies
run: pip install -r requirements.txtأنت تثق في أن البيئة قابلة للتكرار، وأن لا شيء قد تغير في PyPI، وأن كل التبعية لا يزال آمنًا. هذا افتراض كبير عند الاعتماد على متطلبات تجميد pip.txt مهام سير العمل.
تهديدات AppSec الحقيقية: أخطاء إملائية وتشويش في التبعيات في ملف requirements.txt
يُحبّ المهاجمون الأنظمة مفتوحة المصدر. لماذا؟ لأنّ المطورين غالبًا ما يعتمدون على الإعدادات الافتراضية والثقة الضمنية. إليكم كيف يستخدمونها للهجوم: requirements.txt:
- Typosquatting:تحميل حزمة ضارة باسم مثل الطلبات بدلا من طلبات. شخصية واحدة فقط وتصبح ملكًا للبناء الخاص بك.
الطلبات # ⚠️ مثال توضيحي، وليس حزمة حقيقية للتثبيت
- ارتباك التبعيةإذا لم تكن الحزمة الداخلية مثبتة أو ذات نطاق خاص، فيمكن للمهاجمين نشر نسخة ضارة على PyPI بنفس الاسم. إذا لم يتحقق تكامل التكوين (CI) من صحة المصادر، فستقوم بتثبيت حزمتهم بدلاً من حزمتك.
يستغل كلا الهجومين عدم وجود تثبيت صارم والتحكم في المصدر في requirements.txt. إذا كان لك يقول فقط بعض المكتبات الداخلية، وأنت تركض متطلبات تثبيت pip.txt في CI، قد يقوم بجلب الحزمة الخاطئة من المكان الخطأ.
تأمين المتطلبات.txt في CI/CD Pipelines مع Hashes والتثبيت
وهنا كيفية التصلب requirements.txt ضد التهديدات في العالم الحقيقي:
- تثبيت الإصدارات الدقيقة: دائما يستخدم == لكل حزمة في الخاص بك requirements.txt. لا توجد أحرف بديلة، ولا نطاقات.
- استعمل –require-hashes:هذا يجعل pip install -r requirements.txt التحقق من سلامة كل حزمة تم تنزيلها.
على سبيل المثال:
flask==2.2.5 \
--hash=sha256:<actual_hash_here> ⚠️ مثال توضيحي، استبدل بالهاش الحقيقي في المشاريع الفعلية
- عزل البنيات الخاصة بك:احرص دائمًا على البناء في حاويات نظيفة وبسيطة. لا تثق أبدًا بالصورة الأساسية بشكل أعمى.
- استخدم فهرس PyPI الخاص:استضيف وكيلك/ذاكرة التخزين المؤقت الخاصة بك ومرآة الحزم الموثوقة فقط.
تشغيل عمليات فحص التبعية:دمج أدوات مثل تدقيق النقاط أو استخدام SBOM- التحليل القائم على أساس في pipelines.
مثال على مقتطف من إجراءات GitHub:
- name: Secure install
run: pip install --require-hashes -r requirements.txt⚠️ تعليمي pipeline على سبيل المثال، التكيف مع بيئتك
التعامل الصارم مع pip install -r requirements.txt in CI/CD تعد إحدى أسهل الطرق لتقليل مخاطر المصدر المفتوح.
الإصدارات القابلة للتكرار: الحفاظ على استقرارها عبر البيئات
إذا كان تطبيقك يعمل محليًا ولكنه يفشل في مرحلة التجهيز أو الإنتاج، فإن التبعيات غير المتسقة في requirements.txt هم المشتبه بهم المعتادون. حتى الانحراف البسيط يُسبب مشاكل كبيرة.
استخدم هذه الاستراتيجيات:
- أدوات الأنابيب: استعمال تجميع pip لتوليد requirements.txt من المتطلبات.في. يحل التبعيات بالتثبيت المناسب.
- علامات البيئة:بالنسبة للحزم الخاصة بنظام التشغيل أو التبعيات الخاصة بإصدار Python، استخدم علامات مثل نظام_المنصة == 'لينكس'.
- تخزين Docker المؤقت:في CI، قم بتخزين طبقات Docker الخاصة بك مؤقتًا بعد تثبيت التبعيات من requirements.txt لتقليل تباين البناء.
مثال مع أدوات pip:
# requirements.in
flask
# Compile
pip-compile requirements.in
⚠️ مثال توضيحي، الناتج الفعلي يعتمد على بيئتك
الإخراج هو مثبت بالكامل requirements.txt.
أدوات مثل تجميد النقطة، عندما يتم دمجه مع pip install -r requirements.txt أثناء عمليات البناء، تتطلب الانضباط والضمانات الإضافية.
الاستنتاج: تأمين متطلباتك بثقة
سوء الإدارة requirements.txt ليس مجرد ممارسة سيئة؛ بل هو خطر أمني فاعل. التثبيت غير الدقيق، والتثبيتات غير المُتحقق منها، والثقة العمياء في السجلات المفتوحة هي طرق استغلال المهاجمين لأمنك. CI/CD pipelineهذه ليست عيوبًا نظرية، بل يتم استغلالها يوميًا.
تثبيت التبعيات ليس مجرد ممارسة فعّالة، بل هو خط دفاعك الأول ضد هجمات سلسلة التوريد في بايثون. أضف إلى ذلك –require-hashes، بناء العزلة، والأدوات القابلة للتكرار مثل أدوات الأنابيب، وتحصل على pipeline وهذا أصعب للتنازل عنه.
سواء كنت تستخدم متطلبات تثبيت pip.txt محليًا أو في CI، تحقق دائمًا من محتويات إصداراتك وراقبها. أدوات مثل زيجيني توفير الرؤية وإنفاذ السياسات والفحوصات الآلية التي تغلق سلسلة توريد Python الخاصة بك من متطلبات تجميد pip.txt طوال عملية الإنتاج.
