لا يتعلق تسريب الأسرار دائمًا بأكواد برمجية خاطئة أو مكتبات ضعيفة. أحيانًا، يتعلق الأمر بكيفية إدارتنا للأسرار أثناء عمليات تكامل النظام، وCVE‑2025‑30066 مثال واضح على كيفية حدوث ذلك. إجراء GitHub tj‑actions/changed‑files، المستخدم على نطاق واسع للكشف عن الملفات المتغيرة في pull requestsأصبحت قناةً صامتةً لتسريب المعلومات السرية. إليك ما حدث وكيف يمكنك تأمين بياناتك. CI/CD أسرار pipeline.
ماذا حدث في CVE‑2025‑30066؟
في منتصف مارس 2025، تم اختراق tj‑actions/changed‑files. قام المهاجم بإعادة كتابة علامات الإصدار الموجودة (حتى الإصدار v45.0.7) للإشارة إلى برنامج ضار commitأدى هذا إلى تغيير سلوك الإجراء دون أن يلاحظه المطورون؛ ولم يتم إصدار أي إصدار جديد، بل مجرد تلاعب غير مرئي بالعلامات.
كانت الحمولة واضحة لكنها خطيرة: فقد سحبت نصًا برمجيًا عن بُعد مُرمَّزًا بلغة بايثون بتنسيق Base64، يفحص ذاكرة المُشغِّل بحثًا عن بيانات الاعتماد، ويُدخلها في السجلات أو يُخرِجها. لم يكن هذا خللًا برمجيًا منطقيًا في ملفات tj-actions/changed-files؛ بل كان إساءة استخدام لكيفية حدوث تسريب الأسرار ضمن سير عمل تكامل التكوين (CI) باستخدام هذا الإجراء القابل لإعادة الاستخدام. لم يكن CVE-2025-30066 يتعلق بتجاوزات المخزن المؤقت؛ بل كان يتعلق بفشل في تصميم تكامل التكوين (CI) سمح بتسريب الأسرار.
التأثير: أي مستودع يستخدم الإصدارات المتأثرة من tj‑actions/changed‑files معرض لخطر تسريب السرية، وخاصة إذا تم التعامل مع الرموز أو الملفات الحساسة بشكل غير آمن في أنماط الملفات أو مخرجات CI.
لماذا يؤثر هذا على سير العمل الذي يعتمد على الإجراءات القابلة لإعادة الاستخدام
سير عمل DevSecOps الاعتماد بشكل كبير على tj‑actions/changed‑files لـ:
- إنسان آلي pull request الشيكات
- تحديد الملفات المتغيرة في مسارات محددة
- تجنب وظائف CI المكررة
لكن غالبًا ما تغفل سير العمل هذه أمرًا واحدًا: كيف يمكن لأنماط البيانات العالمية أن تتضمن بيانات حساسة. يفترض المطورون أن tj-actions/changed-files تعمل بشكل آمن افتراضيًا. ومع ذلك، إذا استخدمتَ بيانات عالمية التكوينات/** ويتم تخزين الأسرار في configs/secrets.envلقد أضفت للتو ملفًا سريًا إلى مخرجات أو سجلات CI. هذا ليس خطأً في الإجراء؛ إنه CI/CD فشل في التصميم يؤدي إلى تسريب سري. CVE‑2025‑30066 مثال واضح على ذلك.
كيف حدث التسريب السري (تحليل الثغرات الأمنية)
دعونا نكشف سبب الفشل الأساسي وراء CVE‑2025‑30066:
- أنماط متلألئة مثل **/*.env مطابقة الملفات السرية عن غير قصد
- تعامل tj‑actions/changed‑files مع تلك الأسرار على أنها ملفات متغيرة
- انتهت الأسرار في مخرجات الخطوة أو السجلات أو الوظائف اللاحقة
حدث هذا لأن الأسرار كانت مُخزَّنة في مسارات مُتحكَّم فيها بالإصدارات (فكرة سيئة)، ولم يستبعدها تكوين تكامل التكوين (CI) صراحةً من التجميع (وهو أمر سيئ أيضًا). لذا، ليس خللًا في الكود، بل هو سوء تصميم تكامل التكوين (CI) يُسبِّب تسريب الأسرار مع مُخرَجات tj-actions/changed-files.
مسار الاستغلال العملي: من وظيفة التكامل المستمر إلى التعرض لبيانات الاعتماد
مثال على إعداد CI الذي تسبب في تسرب سري من خلال tj‑actions/changed‑files:
yaml jobs: detect_changes: runs‑on: ubuntu‑latest steps: ‑ uses: actions/checkout@v3 ‑ name: Check changed files id: changed uses: tj‑actions/changed‑files@v45 with: files: configs/** If configs/secrets.env تغير:
- تم وضع علامة عليه بواسطة tj‑actions/changed‑files
- لقد تم تضمينه في الخطوات.المخرجات.جميع_الملفات_المتغيرة
- الخطوات اللاحقة سجلتها أو مررتها إلى البرامج النصية، مما أدى إلى تسريب الأسرار
حدث هذا التسريب لأن منطق التكامل المستمر (CI) تعامل مع الأسرار كملفات عادية. وهنا يبدأ تسريب الأسرار، ليس بسبب تجاوز سعة المخزن المؤقت، بل بسبب سوء استخدام إجراءات tj/الملفات المتغيرة في تصميم تكامل مستمر معيب.
يحدث الانتشار مع مخرجات مثل:
yaml ‑ name: Use changed file list run: echo "Changed files: ${{ steps.changed.outputs.all_changed_files }}" If secrets.env إذا كان موجودًا في تلك القائمة، فقد يظهر اسم الملف، وربما محتوياته، في سجلات البناء. حتى المنطق الشرطي مثل:
yaml if: contains(steps.changed.outputs.all_changed_files, 'secrets.env') يمكن الكشف عن القطع الأثرية الحساسة. هذا هو CI/CD فشل في التصميم يسمح بالتسريب السري، وليس عيبًا في كود الإجراء.
كيفية استخدام سير العمل القابلة لإعادة الاستخدام بأمان ومنع التسرب
لا داعي للتخلي عن tj-actions/changed-files. استخدم إجراءات قابلة لإعادة الاستخدام مع التركيز على الأسرار أولاً:
أسرار - أفضل ممارسات التعامل
- لا تقم بإصدار أسرار التحكم أبدًا
- تجنب أنماط الكرة الأرضية التي تتطابق مع المسارات الحساسة
- استخدام الأسرار المستندة إلى البيئة (GITHUB_ENV، الخزائن، أسرار GitHub)
CI/CD الاعداد Guardrails
- قم دائمًا بتثبيت الإجراءات على SHAs غير القابلة للتغيير، وليس العلامات (لا تستخدمها أبدًا @ V45)
- التعامل مع مخرجات tj-actions/changed-files على أنها ملوثة أو تطهيرها أو تصفيتها
- اضبط المخرجات فقط إذا تم تطهيرها
⚠️ مثال غير آمن:
yaml jobs: detect_changes: runs‑on: ubuntu‑latest steps: ‑ uses: actions/checkout@v3 ‑ name: Detect all changes id: changed uses: tj‑actions/changed‑files@v45 with: files: '**/*' # ⚠️ This glob includes secrets.env, which may leak credentials ما ورد أعلاه هو بالضبط سوء الاستخدام وراء التسريب السري وCVE‑2025‑30066.
البديل الآمن:
yaml jobs: detect_changes: runs‑on: ubuntu‑latest steps: ‑ uses: actions/checkout@v3 ‑ name: Detect non‑sensitive file changes id: changed uses: tj‑actions/changed‑files@<SHA> # pinned to SHA with: files: 'src/**' files‑ignore: '**/secrets.env' # ⚠️ Excludes secret file من خلال القيام بذلك، يمكنك تجنب CI/CD فشل في التصميم يؤدي إلى تسرب سري عبر tj‑actions/changed‑files.
بالإضافة إلى:
- تعطيل أو تقييد التسجيل في الأماكن التي قد تظهر فيها الأسرار
- استخدم ميزات إخفاء الهوية السرية في GitHub
- تقييد الوصول إلى سجلات البناء والتحف
أسرار سريعة - قائمة التحقق من الاستخدام الآمن لـ CI
| أفضل الممارسات |
|---|
| لا تخزن الأسرار في ملفات يتم التحكم في إصدارها |
| استخدم الخزائن أو أسرار GitHub للحصول على بيانات الاعتماد |
| قم دائمًا بتثبيت tj‑actions/changed‑files على SHAs غير القابلة للتغيير |
| تصفية أو تطهير المخرجات من tj‑actions/changed‑files |
| لا تقم أبدًا بتضمين المسارات السرية في أنماط الكرة الأرضية |
| إخفاء أو تقييد السجلات التي قد تعرض البيانات الحساسة |
| قم بمراجعة تكوينات CI الموروثة بشكل متكرر |
دور Xygeni: إنفاذ أسرار التكامل المستمر على نطاق واسع
زيجيني يؤمن CI/CD pipelineمن خلال التركيز على كيف يتم التعامل مع الأسرار واستخدامها وكشفها في العالم الحقيقي سير عمل DevOps. لا يقتصر الأمر على مسح الكود فحسب، بل يشمل أيضًا تطبيق أفضل ممارسات إدارة السرية من خلال التفاعل المباشر pipeline التحليل.
اكتشاف استخدام المخرجات غير الآمن
- مسح إجراءات GitHub لاستخدامات صدى، تشغيل، ومخرجات حيث ${{ steps.*.outputs.* }} قد تتضمن قيمًا حساسة
- يحدد متى تتم الإشارة إلى الأسرار أو طباعتها بشكل مباشر أو عن قصد أو عن طريق الخطأ
مراقبة الأسرار المسربة
- يكتشف قيم الإنتروبيا العالية (مفاتيح API والرموز) داخل السجلات ومخرجات الخطوة
- يتم تشغيل التنبيهات عند ظهور الأسرار في pipeline السجلات، حتى لو كانت مقنعة في اتجاه مجرى النهر
استخدام الإجراء غير صحيح
- يتتبع جميع إجراءات GitHub عبر pipelines للكشف عن استخدام الإصدارات المخترقة (على سبيل المثال، tj-actions/changed-files@v45)
- يقوم بمراجعة أنماط مطابقة الملفات التي تتضمن أسرارًا محتملة مثل **/*.env، *.key، أو .env.*
CI القائمة على السياسات Guardrails
- يفرض تثبيت SHA لإجراءات الطرف الثالث
- يحظر استخدام ملفات globs غير الآمنة التي قد تؤدي إلى نقل الأسرار إلى السجلات
- يمنع pipelineمن إصدار قيم حساسة كجزء من مخرجات سير العمل
من خلال التعامل مع سير العمل كجزء من سطح التهديد الخاص بك، تضمن Xygeni أن النظافة السرية ليست مجرد أفضل ممارسة، بل هي دفاع مدمج.
النتيجة: يمكن أن يبدأ التسرب السري بإساءة استخدام فعل بسيط
لم يكن CVE‑2025‑30066 خطأً في المكتبة؛ بل كان CI/CD فشل في التصميم ناتج عن سوء استخدام ملفات tj-actions/changed-files. ما يجب على فرق DevSecOps تعلمه:
- تعامل مع كل مرجع glob/file في CI باعتباره نقطة تسرب محتملة
- قم بمراجعة سير العمل بانتظام بحثًا عن أي إدراج غير مقصود للأسرار
- استخدم خزائن آمنة أو أسرار البيئة، ولا تقم أبدًا بفحص الأسرار في نظام التحكم في الإصدار
- تطهير أو تصفية جميع مخرجات سير العمل
- تسجيل نشاط سير العمل الحساس للحفاظ على إمكانية التدقيق
التكامل المستمر هو الكود. سير العمل هو الكود. السجلات والمخرجات هي الكود. احمِ أسرارك في كل خطوة، وإلا ستواجه خطر تسريب أسرار لا يتطلب تدخلًا من مخترق، بل مجرد خدعة. CI/CD اختيار التصميم.
