شرح مستويات SLSA: قائمة تحقق عملية للامتثال لفرق الهندسة

مقدمة: ما هو SLSA ولماذا يجب أن تهتم؟

Supply-chain Levels for Software Artifacts — SLSA (يُنطق “salsa”) — هو إطار أمني أنشأته Google وتتولى صيانته الآن مؤسسة Open Source Security Foundation (OpenSSF). هدفه بسيط في ظاهره: جعل العبث بالبرمجيات التي تبنيها وتنشرها أكثر صعوبة على المهاجمين.

إذا تابعت الحوادث البارزة مثل SolarWinds أو Codecov أو موجة حزم npm الخبيثة، فأنت تعرف بالفعل لماذا يهم أمن سلسلة التوريد. يمنحك SLSA إطاراً عملياً وتدريجياً يوضح كيف تعالج هذه المشكلة.

قامت مواصفة SLSA v1.0 (صدرت في أبريل 2023) بتبسيط النموذج الأصلي إلى مسار واضح — مستويات البناء من 0 إلى 3 (Build Levels 0-3) — يضيف كل مستوى ضمانات أقوى حول سلامة عملية البناء وبيانات provenance التي تنتجها.

يستعرض هذا الدليل كل مستوى بلغة مبسطة، ويقدم لك قائمة تحقق يمكنك تسليمها لفريقك صباح يوم الإثنين، ويربط كل متطلب بأدوات حقيقية، ويوضح لك شكل provenance الفعلي، ويضع خارطة طريق تبني خطوة بخطوة. لنبدأ.

نظرة سريعة: مسار البناء في SLSA بلمحة واحدة

قبل التعمق في كل مستوى، إليك جدول مقارنة لترى الصورة الكاملة.

الجانب	Build L0	Build L1	Build L2	Build L3
عملية البناء	لا توجد متطلبات	بناء مبرمج ومتسق	خدمة بناء مستضافة	بناة معزولون ومحصنون
Provenance	غير مطلوب	موجود ومتاح	موثق ومولد من الخدمة	غير قابل للتزوير، توقيع معزول
موقّع Provenance	غير متاح	المطور أو CI	خدمة البناء نفسها	خدمة بناء محصنة
الحماية من العبث	لا توجد	الأخطاء والتوثيق	العبث بعد البناء	العبث أثناء وبعد البناء
جهد التبني	صفر	منخفض — ساعات إلى أيام	متوسط — أيام إلى أسابيع	مرتفع — أسابيع إلى أشهر

مستوى البناء 0 — نقطة البداية (بدون ضمانات)

Build L0 ليس مستوى فعلياً — إنه غياب أي compliance مع SLSA. كل مشروع برمجي يبدأ هنا بشكل افتراضي.

ماذا يعني ذلك بلغة بسيطة

ليس لديك أي متطلبات رسمية. قد تتم عمليات البناء على حاسوب المطور المحمول، بدون أي سجل لمصدر الكود المستخدم أو الأوامر التي نُفذت أو ما تم إنتاجه. لا يوجد مستند provenance. لا يوجد شيء للتحقق منه.

قائمة التحقق

☐ لا شيء مطلوب — هذا هو الأساس الذي تتحسن منه.

كيف يبدو Provenance في L0

لا يوجد. لا يوجد attestation، لا بيانات وصفية، لا توقيع. إذا سألك أحدهم “أثبت أن هذا الملف التنفيذي جاء من ذلك الـ commit”، فالإجابة الصادقة هي: لا تستطيع.

الخلاصة: L0 هو المكان الذي تقف فيه معظم المؤسسات اليوم. الخبر الجيد؟ الانتقال إلى L1 سهل بشكل مفاجئ.

مستوى البناء 1 — Provenance موجود

L1 هو أول خطوة ذات معنى. وعده الأساسي: provenance موجود وعملية البناء مبرمجة.

المتطلبات بلغة بسيطة

بناء مبرمج — البناء معرّف في الكود (Makefile أو Dockerfile أو ملف YAML لمسار CI)، وليس سلسلة أوامر يدوية ينفذها المطور من ذاكرته.
إنشاء Provenance — ينتج البناء مستنداً يسجل، كحد أدنى، من بناه وماذا كان المصدر المستخدم وما هي عملية البناء التي نُفذت.
توفر Provenance — يمكن للمستهلكين تحميل وفحص provenance فعلياً.

قائمة التحقق

☐ البناء معرّف بالكامل في سكريبت بناء أو ملف تكوين CI (بدون خطوات يدوية).
☐ كل عملية بناء تنتج بيانات provenance وصفية (يُفضل تنسيق in-toto / SLSA provenance).
☐ يسجل Provenance: منصة البناء، ومستودع المصدر، ونقطة الدخول، وتجزئات الـ artifact الناتج.
☐ يُنشر Provenance بجانب الـ artifact (مثلاً في registry أو OCI artifact أو رابط عام).
☐ تنسيق provenance يتبع مخطط SLSA Provenance v1.

الأدوات التي تحقق L1

GitHub Actions — استخدم workflows القابلة لإعادة الاستخدام من slsa-github-generator. تولد SLSA provenance تلقائياً.
GitLab CI — يدعم GitLab 15.x+ artifact attestation بشكل أصلي.
SLSA Verifier — أداة CLI slsa-verifier للتحقق من provenance على جانب المستهلك.
Sigstore / Cosign — وقّع وخزّن provenance في سجل الشفافية Rekor من Sigstore.
in-toto — يوفر إطار in-toto مواصفة ومكتبات لتوليد attestations.

كيف يبدو Provenance في L1

مستند SLSA v1 provenance بسيط في L1 قد يبدو هكذا (JSON مبسط):

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{
    "name": "my-app",
    "digest": { "sha256": "a1b2c3d4..." }
  }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://github.com/slsa-framework/slsa-github-generator/...",
      "externalParameters": {
        "source": {
          "uri": "git+https://github.com/acme/my-app@refs/heads/main",
          "digest": { "sha1": "abc123..." }
        }
      }
    },
    "runDetails": {
      "builder": {
        "id": "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@refs/tags/v1.9.0"
      }
    }
  }
}

النقطة الأساسية: في L1 قد يكون provenance ذاتي التصديق — المطور أو مهمة CI الخاصة به هي من توقعه. هذا مقبول في هذا المستوى؛ الهدف هو الوجود.

مستوى البناء 2 — Provenance مستضاف وموثق

يرفع L2 المستوى: يجب أن يعمل البناء على خدمة بناء مستضافة، ويجب أن يتم توليد وتوقيع provenance بواسطة تلك الخدمة — وليس بواسطة المطور.

المتطلبات بلغة بسيطة

منصة بناء مستضافة — تعمل عمليات البناء على خدمة مُدارة (GitHub Actions أو GitLab CI أو Google Cloud Build أو Jenkins على بنية تحتية مُدارة، إلخ)، وليس على حاسوب المطور المحمول.
Provenance موثق — خدمة البناء نفسها تولد وتوقع provenance. لا يمكن للمطور تزويره أو تعديله.
مولد من الخدمة — توليد provenance هو ميزة في منصة البناء، وليس سكريبت يمكن للمطور تعديله في مستودعه.

قائمة التحقق

☐ جميع عمليات البناء للإصدارات تعمل على خدمة CI/CD مستضافة (لا بناء محلي لـ artifacts الإنتاج).
☐ خدمة البناء تولد provenance — وليس سكريبت يتحكم فيه المستخدم.
☐ يتم توقيع Provenance بهوية خدمة البناء (مثل توقيع Sigstore بدون مفاتيح عبر OIDC).
☐ يتضمن Provenance هوية الباني الموثقة (يمكنك التحقق من أي خدمة أنتجته).
☐ يمكن للمستهلكين التحقق من توقيع provenance مقابل الهوية المعروفة لخدمة البناء.
☐ مستودع المصدر ونقطة الدخول في provenance تُملأ بواسطة الخدمة، وليس قيم يقدمها المستخدم.

الأدوات التي تحقق L2

GitHub Actions + slsa-github-generator — عند استخدام reusable workflow (وليس composite action)، يوقع OIDC token الخاص بـ GitHub على provenance. هذا يحقق L2 مباشرة.
Google Cloud Build — ينتج بشكل أصلي provenance موثق لصور الحاويات المخزنة في Artifact Registry.
Sigstore Fulcio + Rekor — توقيع بدون مفاتيح مع شهادات قصيرة العمر مرتبطة بهوية OIDC الخاصة بـ CI. يوفر سجل الشفافية (Rekor) سجلاً مقاوماً للعبث.
Tekton Chains — لـ CI الأصلي في Kubernetes. يولد Tekton Chains ويوقع SLSA provenance تلقائياً لتشغيلات خطوط Tekton.
SLSA Verifier — على جانب المستهلك، يتحقق slsa-verifier verify-artifact من التوقيع وهوية الباني.

كيف يبدو Provenance في L2

بنية JSON مشابهة لـ L1، لكن الفرق الجوهري هو غلاف التوقيع. يتم تغليف provenance في DSSE (Dead Simple Signing Envelope):

{
  "payloadType": "application/vnd.in-toto+json",
  "payload": "<base64-encoded provenance statement>",
  "signatures": [{
    "keyid": "",
    "sig": "MEUCIQD...base64...signature"
  }]
}

التوقيع يأتي من هوية خدمة البناء — يتم التحقق منه عبر سجل شفافية الشهادات في Sigstore — وليس من مفتاح شخصي للمطور. هذا ما يجعل provenance موثقاً.

مستوى البناء 3 — بناءات محصنة

L3 هو المعيار الذهبي في SLSA v1.0. يضيف ضمانات العزل: بيئة البناء محصنة بحيث لا يمكن حتى لسكريبت بناء مخترق أو تبعية خبيثة العبث بـ provenance أو بالمستأجرين الآخرين على نظام البناء.

المتطلبات بلغة بسيطة

منصة بناء محصنة — توفر خدمة البناء عزلاً قوياً بين مهام البناء (مثل أجهزة افتراضية مؤقتة، وليس حاويات مشتركة). لا يمكن لمهمة واحدة التأثير على أخرى.
Provenance غير قابل للتزوير — يتم توليد provenance بطريقة لا تمكن مهمة البناء نفسها (الكود المعرف من المستخدم) من تعديله أو تزويره. مفتاح التوقيع أو هوية OIDC غير متاحة لسكريبت البناء.
أسرار معزولة — مواد التوقيع (المفاتيح، رموز OIDC المستخدمة للتوقيع) خارج سيطرة المستأجر. حتى لو تم اختراق سكريبت البناء بالكامل، لا يمكنه إنتاج attestation provenance صالح لـ artifact لم يبنه.

قائمة التحقق

☐ مهام البناء تعمل في بيئات مؤقتة ومعزولة (أجهزة افتراضية، وليس runners مشتركة طويلة العمر).
☐ بيئات البناء تُجهز حديثاً لكل عملية بناء وتُدمر بعدها.
☐ خطوات البناء المعرفة من المستخدم لا يمكنها الوصول إلى مفتاح أو رمز توقيع provenance.
☐ المنصة تمنع بناء مستأجر من التأثير على بناء مستأجر آخر.
☐ يتم توليد Provenance بواسطة المنصة بعد اكتمال البناء — وليس أثناء تنفيذ كود المستخدم.
☐ تُستخدم عمليات بناء محكمة أو معزولة حيثما أمكن (بدون وصول عشوائي للشبكة أثناء البناء).
☐ هوية الباني في provenance هي قيمة محققة وتتحكم فيها المنصة.
☐ تحققت من أن نموذج التهديد لمنصة البناء الخاصة بك يوثق كيف تحقق عزل SLSA L3.

الأدوات التي تحقق L3

GitHub Actions (مع reusable workflows من slsa-github-generator) — تستخدم GitHub-hosted runners أجهزة افتراضية مؤقتة. يعمل reusable workflow في مهمة منفصلة لا يمكن لـ workflow المُستدعي العبث بها. هذه البنية تحقق L3 عند استخدام slsa-github-generator الرسمي.
Google Cloud Build — تعمل عمليات البناء على أجهزة افتراضية مؤقتة مع توقيع معزول. توثق Google بشكل صريح توافق Cloud Build مع SLSA L3.
Tekton Chains على Kubernetes محصن — عندما يعمل Tekton على عقد ذات عزل على مستوى VM (مثل gVisor أو Kata Containers) ويتولى Chains التوقيع خارجياً.
Buildkite مع agents معزولة — عندما تعمل الـ agents على بنية تحتية مؤقتة (مثيلات EC2 ذاتية التوسع تُنهى بعد كل مهمة).

كيف يبدو Provenance في L3

تنسيق مستند provenance هو نفسه في L2 — عبارة in-toto مغلفة في DSSE envelope. الفرق ليس في التنسيق بل في خصائص الثقة وراء التوقيع. في L3:

هوية التوقيع مرتبطة بشكل قابل للتحقق بمنصة بناء محصنة.
حقل builder.id يشير إلى باني معروف بتلبية متطلبات عزل L3.
أدوات التحقق مثل slsa-verifier تتحقق من هوية الباني مقابل قائمة مسموحة من البناة المتوافقين مع L3.

# Verify an artifact at SLSA Build L3
slsa-verifier verify-artifact my-app-linux-amd64 \
  --provenance-path my-app-linux-amd64.intoto.jsonl \
  --source-uri github.com/acme/my-app \
  --builder-id https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@refs/tags/v1.9.0

خارطة طريق التبني خطوة بخطوة

لا تحاول القفز مباشرة إلى L3. صُمم SLSA للتبني التدريجي. إليك خارطة طريق عملية.

المرحلة 1: الوصول إلى Build L1 (الأسبوع 1-2)

راجع عمليات البناء. أدرج كل artifact تشحنه. كيف يتم بناء كل واحد؟ على حاسوب من؟ في أي مهمة CI؟
برمج كل شيء. إذا كانت أي خطوة بناء يدوية، انقلها إلى تكوين CI. كل عملية بناء يجب أن تكون قابلة لإعادة الإنتاج من أمر أو محفز واحد.
أضف توليد provenance. لـ GitHub Actions، أضف reusable workflow من slsa-github-generator. للمنصات الأخرى، ادمج توليد attestation من in-toto في خط الأنابيب الخاص بك.
انشر provenance. أرفق provenance بـ artifacts الإصدار. لصور الحاويات، ادفعه كـ OCI artifact بجانب الصورة. للملفات التنفيذية، انشر ملف .intoto.jsonl.
تحقق من أنه يعمل. استخدم slsa-verifier لتأكيد أن provenance صالح وأن تجزئة artifact متطابقة.

المرحلة 2: الوصول إلى Build L2 (الأسبوع 3-6)

تخلص من البناء المحلي. فرض سياسة: لا يتم بناء artifacts الإنتاج خارج CI. استخدم قواعد حماية الفروع وفحوصات الحالة المطلوبة.
انتقل إلى provenance مولد من الخدمة. انتقل من provenance ذاتي التصديق إلى provenance مولد من المنصة. مع GitHub Actions، هذا يعني استخدام reusable workflow (وليس composite action). مع GCB، فعّل attestation المدمج.
فعّل التوقيع بدون مفاتيح. استخدم Sigstore Fulcio لشهادات قصيرة العمر مبنية على OIDC. هذا يربط التوقيع بهوية CI، وليس بمفتاح طويل العمر تديره أنت.
أضف التحقق إلى خط النشر. قبل النشر، شغّل slsa-verifier أو محرك سياسات (مثل Kyverno أو OPA Gatekeeper) للتحقق من provenance لكل artifact يدخل الإنتاج.

المرحلة 3: الوصول إلى Build L3 (الشهر 2-4)

تحقق من نموذج عزل منصتك. اقرأ وثائق الأمان لمزود CI الخاص بك. هل يستخدم أجهزة افتراضية مؤقتة؟ هل يمكن لمهمة الوصول إلى بيئة مهمة أخرى؟ بالنسبة لـ GitHub-hosted runners، الإجابة نعم (مؤقتة) — بالنسبة لـ self-hosted runners، ستحتاج على الأرجح لإعادة التكوين.
انتقل من runners المشتركة أو self-hosted (أو حصّنها). إذا كنت تستخدم self-hosted GitHub Actions runners، انتقل إلى مثيلات مؤقتة ذاتية التوسع (مثل Actions Runner Controller مع pods مؤقتة أو مجموعات التوسع التلقائي في AWS).
أغلق مسار التوقيع. تأكد من أن مفتاح التوقيع أو رمز OIDC المستخدم لـ provenance غير متاح لخطوات بناء المستخدم. مع reusable workflows من slsa-github-generator، يتم فرض هذا بالتصميم.
وثّق نموذج التهديد الخاص بك. اكتب ما تحمي منه منصة البناء وما لا تحمي منه. شاركه مع فريق الأمان للمراجعة.

الأخطاء الشائعة

حتى الفرق حسنة النية تتعثر في هذه المشكلات. تجنبها مبكراً.

استخدام composite action بدلاً من reusable workflow على GitHub. يعمل composite action داخل مهمة المُستدعي، مما يعني أن المُستدعي يمكنه العبث بتوليد provenance. فقط reusable workflow يعمل في مهمة منفصلة ومعزولة. هذا هو الفرق بين L1 و L2+ على GitHub Actions.
التعامل مع provenance كخانة اختيار. توليد provenance لا يعني شيئاً إذا لم يتحقق منه أحد. أنشئ تحققاً آلياً في خط النشر — وليس فقط في تقرير تدقيق.
تخزين مفاتيح التوقيع في المستودع أو متغيرات بيئة CI. هذا يبطل الغرض. استخدم التوقيع بدون مفاتيح (Sigstore) أو KMS خارجي. لا يجب أن تكون هوية التوقيع متاحة لسكريبت البناء.
تجاهل self-hosted runners. غالباً ما تكون self-hosted runners أجهزة افتراضية طويلة العمر مشتركة بين المهام. هذا يكسر عزل L3. إما انتقل إلى runners مؤقتة أو استخدم عزل على مستوى VM.
تخطي التحقق من المصدر. يركز SLSA Build Track على البناء. لكن إذا تمكن مهاجم من دفع كود خبيث إلى مستودعك، فإن بناء متوافق تماماً ينتج فقط artifact معدل مع provenance صالح. اقرن SLSA بضوابط مصدر قوية (حماية الفروع، مراجعة الكود، توقيع commits).

الأسئلة الشائعة

هل SLSA فقط لصور الحاويات؟

لا. ينطبق SLSA على أي artifact برمجي — ملفات تنفيذية، حزم npm، Python wheels، Helm charts، وحدات Terraform، والمزيد. تنسيق provenance (in-toto) لا يعتمد على نوع الـ artifact.

هل يحل SLSA محل SBOM؟

لا. هما متكاملان. يخبرك SBOM (Software Bill of Materials) بما يحتويه الـ artifact. يخبرك SLSA provenance كيف تم بناؤه ومن أين جاء. استخدمهما معاً لرؤية شاملة لسلسلة التوريد.

هل أحتاج L3 لأكون “متوافقاً”؟

ليس بالضرورة. SLSA هو إطار نضج، وليس لائحة نجاح/رسوب. L1 هو بالفعل تحسين ذو معنى مقارنة بـ L0. تستهدف العديد من المؤسسات L2 كنقطة توازن عملية. L3 مخصص لبيئات الأمان العالي أو المشاريع ذات متطلبات سلسلة التوريد الصارمة (مثل الحكومة، البنية التحتية الحرجة).

كيف يرتبط SLSA بـ NIST SSDF أو EO 14028؟

يدعو كل من Executive Order 14028 وإطار تطوير البرمجيات الآمن من NIST (SSDF) إلى ممارسات أمن سلسلة التوريد التي يدعمها SLSA مباشرة. يعد provenance وسلامة البناء في SLSA تطبيقات عملية لممارسات SSDF مثل PS.1 (حماية البرمجيات) و PW.4 (أرشفة وحماية عمليات البناء). يساعدك تبني SLSA في تحقيق العديد من متطلبات هذه الأطر.

ماذا لو كانت منصة CI الخاصة بي لا تدعم SLSA بشكل أصلي؟

لا يزال بإمكانك توليد provenance باستخدام مكتبات in-toto وتوقيعه بـ Sigstore. هذا يوصلك إلى L1. لـ L2+، ستحتاج على الأرجح لإضافة خطوة توليد provenance تعمل في مهمة أو خدمة منفصلة وموثوقة لا يمكن للبناء الرئيسي العبث بها.

مراجع وموارد إضافية

مواصفة SLSA الرسمية: slsa.dev/spec/v1.0
تنسيق SLSA Provenance: slsa.dev/provenance/v1
slsa-github-generator: مستودع GitHub
slsa-verifier: مستودع GitHub
Sigstore: sigstore.dev
in-toto: in-toto.io
دليلنا لـ SLSA Provenance: تعمق في SLSA Provenance
مختبر عملي: مختبر SLSA Provenance — ولّد وتحقق من أول attestation لك

الخاتمة: ابدأ من L1، وانشر يوم الإثنين

SLSA ليس إطاراً يعمل بمبدأ الكل أو لا شيء. الهدف الكامل من نظام المستويات هو أنك تستطيع البدء صغيراً والتحسن تدريجياً.

إليك خطة عمل صباح يوم الإثنين:

اختر artifact واحد — أهم ملف تنفيذي أو صورة حاوية لديك.
أضف توليد provenance إلى خط CI الخاص به باستخدام slsa-github-generator أو ما يعادله على منصتك.
انشر provenance بجانب الـ artifact.
تحقق منه باستخدام slsa-verifier.
احتفل. أنت الآن في SLSA Build L1 — متقدم على الغالبية العظمى من المشاريع البرمجية.

ثم كرر. انتقل إلى L2 بالتأكد من أن خدمة البناء توقع provenance. حصّن الـ runners الخاصة بك لـ L3. كل خطوة تقلل بشكل ملموس من مخاطر سلسلة التوريد.

هجمات سلسلة التوريد ستستمر في القدوم. السؤال ليس هل تتبنى SLSA — بل كم بسرعة يمكنك الوصول إليه. ابدأ اليوم.