حماية سلسلة التوريد البرمجية في خطوط GitOps: SLSA وSigstore وسياسات توقيع CI/CD عمليًا

مقدمة: لماذا تحتاج GitOps إلى حماية سلسلة التوريد؟

GitOps يبسّط النشر عبر جعل الحالة المرجعية للمُنتَج في مستودع Git، لكن البساطة هذه قد تخفي مخاطر: صور حاويات مُعدّلة، سلاسل بناء مخترقة، أو مُصدِّرون خبيثون يمكنهم إدخال تغييرات إلى الإنتاج عبر إجراءات آلية. لحماية هذا المسار ينبغي توثيق منشأ البرمجيات، توقيعها بشكل موثوق، والتحقق من الأدلة (attestations) قبل نشرها — وهنا تظهر أهمية أُطر مثل SLSA وأدوات مثل Sigstore في خلق دليل موثوق من المصدر حتى الخدمة.

ملاحظة عملية: SLSA هو إطار تعريف لمستويات أمان سلسلة التوريد، وSigstore تقدّم أدوات لتوقيع الحاويات والملفات وتخزين دلائل الشفافية (transparency log).

مفهومي — SLSA، Sigstore، وشفافية Rekor

SLSA باختصار

SLSA (Supply-chain Levels for Software Artifacts) يعرّف مستويات نضج تمنع الإختراقات في عملية البناء: بدءًا من إثباتات بسيطة للمصدر إلى متطلبات بيئات بناء معزولة ومتحكم بها. اعتماد مستوى SLSA معين يعني أن لديك مجموعة متفق عليها من ضوابط أمان للبناء والتوزيع.

Sigstore وCosign وFulcio وRekor

Sigstore هو مشروع تهدف لتبسيط توقيع والتحقق من البرمجيات: Cosign أداة توقيع للحاويات والملفات، Fulcio هي سلطة شهادات قصيرة العمر تُصدر شهادات توقيع (تدعم توقيع keyless)، وRekor هو سجل شفاف (transparency log) يسجل إدخالات التوقيع بحيث يمكن التحقق من شمول الإدخال وعدم التلاعب. استخدام Sigstore يسهّل إدارة المفاتيح عبر شهادات قصيرة العمر والأدلة المسجلة في Rekor.

خريطة تنفيذ عملية في GitOps — من البناء حتى التحقق

في نهج GitOps محمي، نوصي بخطوات قابلة للتطبيق التالية (مخطط عملي):

• بناء داخل CI مع قيود SLSA: نفّذ خطوات بناء معزولة (مثلاً runners مخصصة، لا وصول لحسّاسيات)، سجّل الثوابت (commit SHA، builder id، workflow run) لإثبات السلسلة.
• توقيع الصورة وإرفاق إثبات provenance: بعد بناء الصورة استخدم cosign لتوقيع الصورة ورفع الإدخال إلى Rekor، ثم أنشئ attestation بصيغة SLSA provenance أو in-toto.
• دفع الصورة وملفات التبليغ (SBOM/attestations): ادفع الصورة إلى registry ورفق SBOM وملفات provenance/attestation مرتبطة بالـ digest.
• التحقق عند مرحلتي GitOps وAdmission: عند استدعاء الـ reconciler (ArgoCD/Flux) أو عند admission في الكلاستر، تحقق من توقيع الصنف ووجود إثبات في Rekor وأن الـ provenance يطابق الـ commit/branch المتوقع.

أمثلة للأنظمة التي تدعم هذه الخطوات: Tekton Chains لإصدار attestations، وسياسات مثل Kyverno أو OPA Gatekeeper لفرض التحقق قبل القبول.

أمثلة عملية وأوامر سريعة

توقيع صورة بالحاوية باستخدام cosign (مفتاح أو keyless)

# keyless (OIDC) signing
cosign sign --keyless ghcr.io/org/app:1.2.3

# key-based signing (KMS أو ملف مفتاح)
cosign sign --key k8s://gcp-kms/keyring/... ghcr.io/org/app:1.2.3

# التحقق
cosign verify --keyless ghcr.io/org/app:1.2.3

بعد التوقيع سيُنشأ/يُحمّل إدخال إلى Rekor ويمكن البحث عنه لاحقًا كدليل على التوقيع. للاعتبارات القانونية والحوكمة قد تفضل رفع الـ SBOM والـ attestation بصيغة slsa-provenance أو in-toto وربطها مع الـ image digest.

مقتطف GitHub Actions لخط بناء يوقّع ويصدر provenance

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: |
          docker build -t ghcr.io/${{ github.repository }}/app:${{ github.sha }} .
      - name: Push image
        run: |
          echo ${{ secrets.GHCR_TOKEN }} | docker login ghcr.io -u ${{ github.actor }} --password-stdin
          docker push ghcr.io/${{ github.repository }}/app:${{ github.sha }}
      - name: Sign image with cosign (keyless)
        env:
          COSIGN_EXPERIMENTAL: "1"
        run: |
          cosign sign --keyless ghcr.io/${{ github.repository }}/app:${{ github.sha }}

ملاحظة: إضافة خطوة لتوليد SLSA provenance (أو استخدام مولدات slsa-provenance) تزيد من قابلية التحقق لاحقًا في البيئات التي تطلب مستوى SLSA محدد. عند الرجوع للإدخالات في Rekor ستتمكن سياسات Admission من التحقق من الشمول والهوية.

فرض السياسات في الكلاستر (Admission) واعتبارات عملية

بعد توقيع ونشر الأدلة، يحتاج GitOps reconciler/Admission controller إلى القدرة على التحقق: سياسات Kyverno/OPA يمكنها التحقق من وجود توقيع صالح على الصورة، نوعية الـ attestation، ومطابقة الـ builder identity مع قائمة موثوقة. تُقدّم Kyverno تكاملات جاهزة مع Sigstore للتحقق من التوقيعات وإلغاء القبول إذا فشل التحقق. كما أن وجود بنية Rekor عامة أو داخلية يسمح بالتتبع والحوكمة.

نصائح عملية سريعة:

• ابدأ بتطبيق توقيع الصور في CI ثم أضف التحقق في البيئات غير الانتاجية قبل فرضه في الإنتاج.
• استخدم شهادات قصيرة العمر أو KMS للمفاتيح الخاصة لتقليل تعرض المفاتيح الدائمة للخطر.
• سجّل كل شيء (SBOM، provenance، Rekor entry) في نظام تسجيل مركزي لتبسيط التحقيق عند الحوادث.
• حدد مستويات SLSA قابلة للقياس وارتقِ تدريجيًا (على سبيل المثال: السعي أولًا لمستوى SLSA 2 ثم 3).

الخلاصة والمرحلة التالية

تأمين سلسلة التوريد في خطوط GitOps عملية قابلة للتنفيذ تدريجيًا: ابدأ بحماية بنية البناء (SLSA)، أدخل توقيعات وattestations عبر Sigstore/Cosign، ثم فرض سياسات تحقق عند نقطة النشر باستخدام Kyverno/OPA أو admission controllers. النتائج: قدرة تحقق قابلة للتدقيق، تقليل مخاطر إدخال برمجيات غير موثوقة، وتحسين الاستجابة للحوادث.

مصادر للقراءة السريعة والمراجع: وثائق SLSA لإطارات المستويات، وثائق Sigstore (Cosign/Fulcio/Rekor)، ودليل Tekton Chains لمنصات Kubernetes التي تحتاج إنتاج attestations.