DevSecOps وأمن سلسلة التوريد

قوائم مكونات البرمجيات والبيانات الإثباتية

18 دقيقة الدرس 7 من 28

قوائم مكونات البرمجيات والبيانات الإثباتية

لا تعتمد هجمات سلسلة التوريد البرمجية على اختراق كودك مباشرةً، بل تستهدف ما تثق به هذا الكود: اعتمادية خارجية، أو أداة بناء، أو صورة أساسية، أو عداء CI. اشتركت كل من اختراق SolarWinds وثغرة XZ utils وحادثة event-stream في هذا النمط ذاته. وجاء رد الصناعة عبر ثلاثة معايير متشابكة: قائمة مكونات البرمجيات (SBOM)، وشهادات الإثبات، ومستويات SLSA لسلسلة التوريد. تجيب هذه المعايير مجتمعةً عن ثلاثة أسئلة يجب أن يقدر فريق الأمان على الإجابة عنها في أي وقت بعد صدور ثغرة حرجة: ما الذي يحتويه برنامجنا؟ من أين أتى؟ هل تعرضت عملية البناء لأي تلاعب؟

قوائم SBOM: CycloneDX مقابل SPDX

قائمة SBOM هي بيان قابل للقراءة الآلية — جرد شامل لكل مكون في البرنامج، بما في ذلك الاعتماديات غير المباشرة، مع الإصدار ومعرف الترخيص ومعرفات الثغرات. يسيطر على هذا المجال صيغتان رئيسيتان:

CycloneDX — صُمِّمت من قِبَل OWASP تحديدًا لحالات الاستخدام الأمني. تدعم JSON وXML وProtobuf، وتوفر دعمًا من الدرجة الأولى للثغرات والخدمات والصيغ (كيف بُني البرنامج) والشهادات. وهي المعيار الفعلي في أدوات خطوط الأنابيب: Syft وTrivy وcdxgen وGitHub Dependency Submission API، جميعها تُنتج CycloneDX.
SPDX — معيار ISO/IEC 5962:2021، نشأ في مجتمع الامتثال بمؤسسة Linux. تدعم صيغ tag-value وJSON وYAML وRDF، وتتميز بصياغة تعبيرات تراخيص أقوى عبر معرفات SPDX. وهي مطلوبة بموجب الأمر التنفيذي الأمريكي 14028 وقانون المرونة الإلكترونية للاتحاد الأوروبي.

في الواقع العملي، تُنتج المؤسسات الكبرى CycloneDX لأدوات الأمان (مثل Dependency-Track وGrype وOSV-Scanner) وSPDX للجهات القانونية والامتثالية. يستطيع Syft إنتاج كلا الصيغتين من فحص واحد.

العناصر الدنيا وفق NTIA (الأمر التنفيذي 14028): يجب أن تتضمن أي SBOM صالحة: اسم المورد، اسم المكون، الإصدار، المعرف الفريد (PURL أو CPE)، علاقات الاعتماد، المؤلف، والطابع الزمني. أي SBOM تفتقر لهذه العناصر لا يمكن الاحتجاج بها لأغراض الامتثال.

توليد قوائم SBOM في خط أنابيب CI

أفضل وقت لتوليد قائمة SBOM هو مباشرةً بعد بناء صورة الحاوية، قبل رفعها إلى السجل. في تلك اللحظة تعرف بيئة البناء تحديدًا ما دخل في الصورة. Syft هو الأداة الأكثر انتشارًا؛ cdxgen يتعامل بكفاءة مع المستودعات متعددة اللغات؛ أما Trivy فيجمع بين توليد SBOM وفحص الثغرات في خطوة واحدة.

# تثبيت Syft
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh \
  | sh -s -- -b /usr/local/bin

# توليد SBOM بصيغة CycloneDX JSON من صورة حاوية مبنية
syft ghcr.io/myorg/myapp:sha-abc123 \
  -o cyclonedx-json=sbom.cdx.json

# توليد SBOM بصيغة SPDX JSON من شجرة المصدر (يقرأ ملفات القفل والمانيفست)
syft dir:. -o spdx-json=sbom.spdx.json

# إرفاق SBOM كشهادة OCI موقَّعة مع cosign (Sigstore بدون مفاتيح)
cosign attest --predicate sbom.cdx.json \
  --type cyclonedx \
  ghcr.io/myorg/myapp:sha-abc123

# التحقق من الشهادة لاحقًا (في بوابة القبول أو خط أنابيب CD)
cosign verify-attestation \
  --type cyclonedx \
  --certificate-identity-regexp \
    "https://github.com/myorg/myapp/.github/workflows/.*" \
  --certificate-oidc-issuer \
    "https://token.actions.githubusercontent.com" \
  ghcr.io/myorg/myapp:sha-abc123

شهادات الإثبات (Provenance Attestations)

تخبرك SBOM بـماذا يحتوي الأثر البرمجي، بينما تخبرك شهادة الإثبات بـكيف بُني — أي commit من المصدر، أي نظام CI، أي عداء، أي أوامر بناء، وبشكل أهم، هل كانت تلك المدخلات موثوقة. شهادة الإثبات هي وثيقة موقَّعة تربط مخرجات البناء بمدخلاتها بطريقة مقاومة للتلاعب.

المعيار الناشئ هو شهادات in-toto مع محمول SLSA Provenance. تُولِّد GitHub Actions شهادة SLSA تلقائيًا عند استخدام الإجراء actions/attest-build-provenance. تُخزَّن الشهادة في سجل شفافية Sigstore (Rekor) ومرتبطة بملخص صورة OCI — وليس وسمًا قابلًا للتغيير، بل بالتجزئة الثابتة للمحتوى.

دائمًا اربط بالملخص (digest) لا بالوسم (tag). صورة موسومة بـ:latest يمكن استبدالها بصمت. أما صورة مرجعها sha256:abc123... فلا يمكن استبدالها. يجب أن تشير شهادات SBOM والإثبات إلى الملخص دائمًا، وإلا أمكن فصلها وإعادة إرفاقها بصورة مختلفة وربما ضارة.

مستويات SLSA لسلاسل التوريد

SLSA (اختصار Supply-chain Levels for Software Artifacts، وينطق "salsa") هو إطار أنشأته Google يحدد أربعة مستويات ضمان لسلامة عملية البناء. يضيف كل مستوى متطلبات تجعل التلاعب أصعب وأقل قابلية للإخفاء.

مستويات SLSA من L0 إلى L3: كل مستوى يضيف متطلبات تجعل التلاعب بسلسلة التوريد أصعب تنفيذًا وأقل قابلية للإخفاء.

تستوفي معظم سير عمل GitHub Actions التي تعمل على ubuntu-latest بتوكنات OIDC متطلبات SLSA L2 اليوم. أما الوصول إلى L3 فيستلزم بيئة بناء معزولة ومؤقتة، حيث تُولِّد خدمة البناء نفسها الشهادة وتوقِّعها دون حقن أي بيانات اعتماد دائمة في عملية البناء. الطريقان العمليان لتحقيق ذلك هما: Google Cloud Build مع منشئ SLSA L3، وslsa-github-generator من إطار SLSA.

خط أنابيب متكامل: SBOM + شهادة إثبات في GitHub Actions

name: Secure Build

on:
  push:
    branches: [main]

permissions:
  id-token: write      # مطلوب للتوقيع بدون مفاتيح عبر Sigstore
  contents: read
  packages: write
  attestations: write  # مطلوب لـ actions/attest-build-provenance

jobs:
  build-sign-attest:
    runs-on: ubuntu-latest
    outputs:
      image-digest: ${{ steps.push.outputs.digest }}

    steps:
      - uses: actions/checkout@v4

      - name: Build and push image
        id: push
        uses: docker/build-push-action@v6
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}

      # توليد شهادة SLSA (تُخزَّن في Sigstore Rekor)
      - name: Attest build provenance
        uses: actions/attest-build-provenance@v1
        with:
          subject-name: ghcr.io/${{ github.repository }}
          subject-digest: ${{ steps.push.outputs.digest }}

      # توليد وإرفاق SBOM بصيغة CycloneDX
      - name: Generate SBOM with Syft
        run: |
          curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh \
            | sh -s -- -b /usr/local/bin
          syft ghcr.io/${{ github.repository }}@${{ steps.push.outputs.digest }} \
            -o cyclonedx-json=sbom.cdx.json

      - name: Attest SBOM
        uses: actions/attest-sbom@v1
        with:
          subject-name: ghcr.io/${{ github.repository }}
          subject-digest: ${{ steps.push.outputs.digest }}
          sbom-path: sbom.cdx.json

الفحص المستمر للثغرات عبر SBOM

توليد SBOM عند البناء ليس سوى نصف الصورة. يجب إعادة فحص القائمة باستمرار مقابل قواعد بيانات الثغرات المحدَّثة بعد نشر الصورة — فمكون كان آمنًا يوم الاثنين قد يظهر له ثغرة منشورة يوم الأربعاء. Dependency-Track هو المنصة المتكاملة لهذا الغرض في بيئات الإنتاج: تستقبل قوائم CycloneDX، وتحتفظ بنسخ مرآة من قواعد بيانات الثغرات (NVD وOSV وGitHub Advisory)، وتوفر REST API وwebhooks للتكامل مع منظومة التنبيهات.

فخ الإنتاج — نضارة SBOM: لا تحتفظ بقوائم SBOM فقط كحفائظ CI، فحفائظ CI تنتهي صلاحيتها. خزِّن SBOM في سجل OCI كشهادات مرتبطة بملخص الصورة (باستخدام cosign أو actions/attest-sbom) لتبقى متاحة مهما قدُم عمر الصورة. عند ظهور ثغرة حرجة، تحتاج للإجابة في ثوانٍ عن: "أيّ الصور المشغَّلة تحتوي libssl 3.0.2؟" — لا لتفتيش حفائظ منتهية الصلاحية.

الاستعلام عن قوائم SBOM في أوقات الحوادث

عند الإعلان عن ثغرة يوم الصفر — مثل ثغرة بحجم Log4Shell — يكون سؤالك الأول هو نطاق التأثير: أي الخدمات مصابة؟ مع خط أنابيب SBOM المُدار جيدًا وDependency-Track، الإجابة هي استدعاء API واحد. بدونه، ستجد نفسك تبحث يدويًا في آلاف ملفات pom.xml وpackage-lock.json عبر مئات المستودعات تحت ضغط الوقت — وهي عملية معروفة بارتفاع معدل الخطأ فيها ما يؤدي إلى تفويت حالات مصابة. في بيئات بحجم Google وNetflix، تستغرق استعلامات نطاق التأثير المبنية على SBOM أقل من ثانية واحدة عبر عشرات الآلاف من إصدارات الخدمات.

اعتمد PURL (Package URL) كمعرف أساسي للمكونات. PURL مثل pkg:npm/%40angular/core@17.3.2 أو pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1 محايد لبيئة التطوير، مقروء بشريًا، ومدعوم من كل أدوات SCA وSBOM الرئيسية. استخدم PURLs في قوائمك؛ وتجنب CPEs لاعتماديات التطبيقات إذ صُمِّمت CPEs لحزم نظام التشغيل وهي ملتبسة للمكتبات البرمجية.

الخلاصة

تجيب SBOM عن ماذا؛ وتجيب شهادات الإثبات عن كيف ومن أين؛ وتقيس مستويات SLSA مدى موثوقية عملية البناء.
ولِّد قوائم CycloneDX من صور الحاوية عند البناء، وأرفقها كشهادات OCI موقَّعة مرتبطة بملخص الصورة.
SLSA L2 قابل للتحقيق اليوم مع GitHub Actions القياسية؛ أما L3 فيتطلب خدمة بناء معزولة مثل slsa-github-generator أو Google Cloud Build.
خزِّن قوائم SBOM في السجل مع الصورة، وأطعِم Dependency-Track بها لمراقبة CVE مستمرة.
في حوادث يوم الصفر، يُقلِّص خط أنابيب SBOM الناضج تقييم نطاق التأثير من ساعات إلى ثوانٍ.