سلسلة توريد البرمجيات · معيار OpenSSF

SLSA — سلسلة التوريد التي لم يعد المخترقون قادرين على كسرها.

Supply-chain Levels for Software Artifacts. الإطار الذي يحوّل خطوط البناء إلى أدلة جنائية رقمية — والمعيار الوحيد الذي يلبّي متطلبات CRA وNIS2 وEU AI Act بأدلة إثبات تشفيرية.

L0 → L3 · مسار البناء

CRA · NIS2 · DORA · AI Act

OpenSSF · معيار مفتوح

اطلبوا استشارة أولية اعرفوا المزيد

تذكير موجز

أربعة هجمات — فئة واحدة مشتركة.

التلاعب بين الشيفرة المصدرية والمستخدم النهائي. ولا يفيد أمن الشيفرة التقليدي هنا. وهذه الثغرة بالذات هي ما يسدّه SLSA.

2020

SolarWinds Orion

تعرّضت 18,000 مؤسسة للاختراق. جرى التلاعب بنظام البناء، وتحولت التحديثات الموقّعة إلى سلاح.

2021

Codecov bash-uploader

شهران دون اكتشاف. سُرقت بيانات اعتماد العديد من خطوط CI/CD.

2023

3CX Desktop App

هجوم متعدد المراحل على سلسلة التوريد. وكان المورّد نفسه ضحية هجوم آخر على سلسلة التوريد.

2024

XZ Utils Backdoor

عامان من الهندسة الاجتماعية. CVSS 10.0. اكتُشف فقط بمحض الصدفة على يد شخص واحد.

الوضع الراهن

السؤال ليس «هل»، بل «متى».

أربعة أرقام ينبغي لكل CISO معرفتها اليوم — وتوضح لماذا لم يعد مقبولًا غياب SLSA عن أي استراتيجية لخطوط البناء.

742 %

متوسط الزيادة السنوية في الهجمات على سلسلة التوريد منذ 2019

Sonatype · State of the Software Supply Chain

95 %

من جميع قواعد الشيفرة تحتوي على مكونات مفتوحة المصدر

84 %

من قواعد الشيفرة تحتوي على ثغرة أمنية معروفة واحدة على الأقل

1 / 8

من تنزيلات المصادر المفتوحة يحتوي بالفعل على ثغرة معروفة

سيصل عنصر مُخترَق إلى عملية البناء لديكم — السؤال ليس «هل»، بل «متى».

مقدمة

ما هو SLSA — وما ليس هو.

قبل أن يبدأ النقاش حول المستويات وخطوط البناء، يجدر التوضيح: يحل SLSA مشكلة محددة — وهذه المشكلة فقط.

SLSA

Supply-chain Levels for Software Artifacts

إطار أمني من OpenSSF (Linux Foundation)، أطلقته Google عام 2021. يُنطق «sal-sa». يصنّف خطوط البناء إلى مستويات ثقة قابلة للقياس — من L0 (دون أي ضمان) حتى L3 (مُحصَّن، معزول، موقّع).

ما ليس SLSA

ليس عصا سحرية، وليس أداة للشراء.

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

نموذج التهديدات

التهديدات الثمانية على امتداد سلسلة التوريد.

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

Source

مستودع الشيفرة المصدرية

Submit unauthorized change — يصل commit خبيث إلى المستودع.

Compromise source repo — الاستيلاء على خادم المستودع نفسه.

Build

CI/CD الخاص بكم

Build from modified source — تعتمد عملية البناء على مصدر مُتلاعَب به.

Compromise build process — التلاعب بخطوات البناء.

Package

Registry

Use compromised dependency — إدخال حزمة npm/pip خبيثة.

Upload modified package — استبدال العنصر البرمجي بعد البناء.

Consume

المستخدم النهائي

Compromise package registry — الاستيلاء على خادم السجل نفسه.

Use compromised package — يقبل المستخدم عنصرًا برمجيًا مُخترَقًا.

يتناول SLSA بالدرجة الأولى C, D, F, G — مرحلتي البناء والتوزيع. أما A وB وE وH فتتطلب حوكمة مكمّلة للمصدر وتحققًا من جانب المستهلك.

الفكرة الأساسية

ثلاثة مفاهيم — والباقي تفاصيل.

إذا فهمتم هذه المفاهيم الثلاثة، فقد فهمتم SLSA. وكل ما عدا ذلك هو أشكال مختلفة للتطبيق.

Provenance

شهادة الميلاد

وثيقة قابلة للقراءة آليًا: ما الذي بُني، ومن أي مصدر، وبواسطة أي أداة بناء، وبأي معاملات. الصيغة: in-toto Attestation.

منصة البناء

المكان الموثوق

منصة CI/CD التي تبني العنصر البرمجي. وهي تُنشئ الـ Provenance وتوقّعها. أمثلة: GitHub Actions وGitLab CI وTekton Chains.

Verifier

حارس البوابة

مكوّن يفحص قبل النشر: هل الـ Provenance صحيحة، وهل التوقيع صالح، وهل يستوفي العنصر البرمجي السياسة المحددة.

Build Track

أربعة مستويات — من الفوضى إلى الحصن.

يبني كل مستوى على سابقه. أمان أكبر، واعتماد أقل على الثقة بالكلام.

دون ضمانات

لا معيار للبناء ولا Provenance. الوضع الافتراضي لكثير من المشاريع الداخلية.

الـ Provenance موجودة

عملية البناء موثّقة. وتُنشأ الـ Provenance — بصيغة قابلة للقراءة آليًا.

Provenance موقّعة

البناء على منصة مستضافة. والـ Provenance موقّعة تشفيريًا.

منصة بناء مُحصَّنة

عزل، ولا خطوات يحددها المستخدم، وProvenance غير قابلة للتزوير.

المتطلبات

ما الذي يجب فعله تحديدًا؟ مصفوفة مسار البناء.

ثلاث «—» تتحول إلى ثلاث «✓». وهذا بالضبط هو الطريق من «ثق بي» إلى «أثبت ذلك».

المتطلب	L1	L2	L3
تتبع عملية البناء إجراءً متسقًا	✓	✓	✓
تُنشأ الـ Provenance تلقائيًا	✓	✓	✓
الـ Provenance كاملة (تتضمن جميع مدخلات البناء)	✓	✓	✓
الـ Provenance أصلية (موقّعة من أداة البناء)	—	✓	✓
يجري البناء على منصة بناء مستضافة	—	✓	✓
تعزل منصة البناء عمليات البناء عن بعضها	—	—	✓
الـ Provenance غير قابلة للتزوير (لا يستطيع المستخدم تزويرها)	—	—	✓

التشريح

كيف تبدو الـ Provenance فعليًا؟

قابلة للقراءة آليًا، وموقّعة، وقابلة للتدقيق بالكامل. ما يختبئ وراء الصيغة in-toto Statement v1.

Provenance v1 · in-toto StatementJSON

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{
    "name": "vamisec-app:v1.2.3",
    "digest": { "sha256": "a3f5…e91b" }
  }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://slsa-framework.github.io/…",
      "externalParameters": {
        "source": "git+https://github.com/vamisec/app",
        "ref":    "refs/tags/v1.2.3"
      },
      "internalParameters": { "runner": "ubuntu-22.04" }
    },
    "runDetails": {
      "builder":  { "id": "https://github.com/actions/runner" },
      "metadata": { "invocationId": "…", "startedOn": "2026-05-20T08:14:02Z" }
    }
  }
}

ما تكشفه الـ Provenance

subject
أي عنصر برمجي — الاسم + قيمة التجزئة SHA-256. قابل للتعريف بشكل فريد.
externalParameters
أي مصدر — عنوان Git URL ووسم الـ commit، ويمكن للمستخدم التحكم بها.
builder.id
أي أداة بناء قامت بالبناء — هوية موقّعة تشفيريًا.
metadata
متى، وكم استغرق، وبأي معرّف استدعاء (Invocation-ID) — قابل للتدقيق بالكامل.

Hands-on

SLSA L3 في GitHub Actions — في 15 سطرًا.

لا نظريات ولا جزيرة أدوات جديدة. سير عمل قابل لإعادة الاستخدام من slsa-framework، وتوقيع Sigstore عبر OIDC، وأداة سطر أوامر للتحقق من جانب المستهلك. مفتوح المصدر وجاهز للإنتاج.

.github/workflows/release.ymlYAML

name: release
on:
  push:
    tags: ['v*']

jobs:
  build:
    permissions:
      id-token: write    # Sigstore OIDC
      contents: read
      actions:  read
    uses: slsa-framework/slsa-github-generator/.github/workflows/builder_go_slsa3.yml@v2.0.0
    with:
      go-version:  '1.22'
      config-file: .slsa-goreleaser.yml

ما يحدث تلقائيًا

1يجري البناء في آلة افتراضية معزولة من GitHub Runner.
2تُنشأ الـ Provenance تلقائيًا.
3التوقيع عبر Sigstore (دون مفاتيح، OIDC).
4إرفاق الـ Provenance كأحد أصول الإصدار.
5قابلة للتحقق علنًا عبر slsa-verifier.

التحقق من جانب المستهلك — سطر واحد.

التحقق من جانب المستهلكBash

$ slsa-verifier verify-artifact app-binary \
    --provenance-path app-binary.intoto.jsonl \
    --source-uri      github.com/vamisec/app \
    --source-tag      v1.2.3

PASSED: Verified SLSA provenance

✓ التوقيع صالح✓ أداة البناء موثوقة✓ عنوان المصدر (Source-URI) مطابق✓ البناء من الوسم المتوقع

ينبغي أن يكون هذا الفحص جزءًا من كل Admission-Controller، وكل خط CD، وكل غلاف لمدير الحزم. الافتراضي: غير مُتحقَّق منه = غير منشور.

الأدوات

المنظومة — مفتوحة المصدر وجاهزة للإنتاج.

لا تبنون شيئًا من الصفر — بل تُركّبون من مكونات مفتوحة المصدر ناضجة. ولا حاجة إلى ترخيص تجاري.

Builder

GitHub Actions

Provenance أصلية بمستوى SLSA L3 عبر slsa-github-generator. توقيع Sigstore جاهز مباشرةً.

Builder

GitLab CI

إنشاء Provenance مدمج، متوافق مع in-toto، اعتبارًا من GitLab 16+.

Builder

Tekton Chains

منصة بناء أصلية لـ Kubernetes مع دعم أصلي لـ SLSA في البيئات السحابية الأصلية.

التوقيع

Sigstore (Cosign)

توقيع دون مفاتيح عبر OIDC + سجل شفافية. المعيار الفعلي للحاويات والعناصر البرمجية.

Format

in-toto Attestation

الصيغة المعيارية لبيانات Provenance. قائمة على JSON، ومنظمة، وقابلة للتوقيع.

Verifier

SLSA Verifier

أداة سطر أوامر مفتوحة المصدر من OpenSSF. تفحص الـ Provenance مقابل السياسة — سطر واحد، ورمز خروج واحد.

ستة مكونات، دون ارتهان لمورّد. منظومة SLSA بالكامل مفتوحة المصدر ومحايدة تجاه المورّدين.

لمن

لمن تكتسب SLSA أهمية خاصة.

إذا كنتم تتخذون القرار أو تتولون التنفيذ في أحد هذه المواقع، فإن SLSA ينتمي إلى رؤيتكم التقنية المستهدفة — قبل أن تتحول مهلة CRA إلى حالة طوارئ.

مديرو أمن المعلومات (CISO) ورؤساء AppSec

تأمين سلسلة توريد البرمجيات تنظيميًا — دون بناء جزيرة أدوات جديدة.

قادة DevSecOps

تحصين خطوط CI/CD بأنماط تطبيق ملموسة — لا بالنظرية فقط.

الامتثال والمدققون

أدلة إثبات تقنية لـ CRA المادة 13، وNIS2 المادة 21(2)(d)، وEU AI Act المادة 15.

فرق المنصات

بناء منصات بناء مستضافة أو تقييمها — متوافقة مع SLSA منذ اليوم الأول.

السياق التنظيمي

لماذا لن يكون SLSA اختياريًا في موعد أقصاه 2027.

أربع لوائح أوروبية، ومتطلب مشترك واحد: أمن قابل للإثبات لسلسلة التوريد. ويقدّم SLSA الدليل التقني.

EU CRA

اللائحة (EU) 2024/2847

المادة 13 — «الأمن السيبراني بالتصميم». تحديد المكونات وإدارة الثغرات الأمنية على امتداد سلسلة التوريد. التطبيق اعتبارًا من 11 ديسمبر 2027.

NIS2

التوجيه (EU) 2022/2555

المادة 21(2)(d) — أمن سلسلة التوريد كإجراء إلزامي لإدارة المخاطر. نُفّذت في ألمانيا عبر NIS2UmsuCG.

EU AI Act

اللائحة (EU) 2024/1689

المادة 15 — الدقة والمتانة والأمن السيبراني. بالنسبة لأنظمة الذكاء الاصطناعي عالية المخاطر، تُعدّ Provenance البناء والتدريب القابلة للتتبع إلزامية.

DORA

اللائحة (EU) 2022/2554

إدارة مخاطر الأطراف الثالثة لمقدمي الخدمات المالية. يجب على مورّدي البرمجيات إثبات عمليات مُحصَّنة.

دراسة حالة

XZ Utils — ولماذا لم يكن SLSA ليمنعه.

نظرة صادقة على حدود الإطار. متى يكفي خط البناء، ومتى يلزم المزيد.

2021

يظهر «Jia Tan». بناء بطيء عبر الهندسة الاجتماعية.

2023

الاستيلاء على صلاحيات المشرف (Maintainer) من المؤلف الأصلي.

فبراير 2024

دسّ شيفرة الباب الخلفي مخفيةً في سكربت البناء.

مارس 2024

نشر الإصدارين 5.6.0 + 5.6.1 مع باب خلفي في SSH.

29.03.2024

يكتشف Andres Freund تأخيرًا قدره 0.5 ثانية. وينجو العالم.

المزالق

ما تخطئ فيه الفرق في المحاولة الأولى.

ستة أخطاء نراها بانتظام في عمليات التدقيق. ومن يعرفها يوفّر على نفسه المحاولة الثانية المكلفة.

إنشاء Provenance دون التحقق منها

دليل الإثبات دون فحص مجرد مسرحية. مكان التحقق هو Admission-Controller، وليس قائمة الأعمال المؤجلة.

ترحيل جميع المستودعات دفعة واحدة

ابدؤوا بالعنصر البرمجي الإنتاجي الأكثر أهمية. تعلّموا. ثم توسّعوا. نهج الدفعة الواحدة يفشل دائمًا.

خطوات بناء مخصصة في مسارات عمل L3

السكربتات التي يحددها المستخدم تجعل الـ Provenance قابلة للتزوير. ومسارات العمل القابلة لإعادة الاستخدام دون شيفرة المستخدم إلزامية.

لا سياسة، بل توقيع فقط

التوقيع الصالح لا يقول شيئًا عن هوية أداة البناء. والسياسة تفرض: من يحق له البناء نيابةً عنا؟

معاملة SBOM وSLSA كمتنافسين

إنهما يكمّلان بعضهما. SBOM = ماذا. SLSA = كيف. قدّموا كليهما، وتحققوا من كليهما.

جذر Sigstore كصندوق أسود

يعتمد Sigstore على جذر ثقة عام. افهموا ما تثقون به ضمنيًا. وللمتطلبات العالية جدًا: جذر ثقة خاص.

Roadmap

من الوضع الراهن إلى L3 — المسار الواقعي.

ستة أشهر من «works on my machine» إلى Provenance غير قابلة للتزوير للعناصر البرمجية الحرجة. ليس دفعة واحدة، بل أربع مراحل.

الأسبوع 1–2

الجرد

ما خطوط البناء الموجودة؟ من يبني العناصر البرمجية الإنتاجية؟ ما عمليات البناء التي تجري محليًا («works on my machine»)؟

الأسبوع 3–6

بلوغ L1

توحيد عمليات البناء. تعريف البناء كشيفرة (YAML). إنشاء الـ Provenance حتى وإن لم تكن موقّعة بعد.

الشهر 2–3

بلوغ L2

عمليات البناء على المنصات المستضافة فقط. توقيع الـ Provenance عبر Sigstore. تحقق المستهلكين.

الشهر 4–6

L3 للعناصر البرمجية الحرجة

أدوات بناء مستضافة مع عزل. مسارات عمل قابلة لإعادة الاستخدام دون خطوات بناء يحددها المستخدم. Provenance غير قابلة للتزوير.

الوضع الراهنSLSA L3 في الإنتاج

Takeaways

خمس جمل — ولا تحتاجون أكثر.

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

SLSA إطار متطلبات لخطوط البناء — ليس أداة ولا منتجًا.

الـ Provenance + المُتحقِّق يحوّلان «ثق بي» إلى «أثبت ذلك».

يمكن بلوغ L1 في أسابيع، وL3 في أشهر. ولا يتوسع أي منهما بنهج الدفعة الواحدة.

يجيب SBOM عن ماذا، ويجيب SLSA عن كيف. وتحتاجون إلى كليهما.

CRA وNIS2 وDORA وAI Act — جميعها تتطلب أمنًا قابلًا للإثبات لسلسلة التوريد. ويقدّمه SLSA.

خبير ومؤلف

Valeri Milke

الرئيس التنفيذي والمستشار الرئيسي · VamiSec GmbH

«الأمن ليس منتجًا — بل عملية. والعملية غير القابلة للإثبات لا وجود لها في التدقيق.»

مدقق رئيسي ISO 27001 (Lead Auditor)مدقق رئيسي ISO 42001مسؤول الذكاء الاصطناعي (EU AI Act)خبير NIS2 وDORAخبير CRABSI IT-Grundschutzلـ Wiz

مرجعيات في الندوة الإلكترونية

معايير ستعرفونها بعد ذلك عن ظهر قلب.

SLSA v1.0

Framework

in-toto

Attestation

Sigstore

توقيع دون مفاتيح

SBOM

CycloneDX · SPDX

OpenSSF

مجموعة عمل

ENISA

مشهد التهديدات الأوروبي

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

FAQ.

كم يستغرق تطبيق SLSA L3 عادةً؟

لخط GitHub Actions أو GitLab CI حديث دون أعباء تاريخية: 4–8 أسابيع حتى الوصول إلى Provenance-Attestations موقّعة في الإنتاج. ولبيئات البناء المتراكمة مع Runner مستضافة ذاتيًا وأدوات مخصصة: 3–6 أشهر. والعامل الحاسم ليس الشيفرة، بل منصة البناء.

ما الأدوات التي أحتاجها تحديدًا لـ SLSA L3؟

في المنظومة المعيارية لـ OpenSSF: slsa-github-generator أو slsa-verifier للـ Provenance، وcosign/sigstore للتوقيعات، واختياريًا in-toto للـ Attestations متعددة المراحل. لا حاجة إلى ترخيص تجاري — فالمنظومة بالكامل مفتوحة المصدر ومتوافقة مع GitHub وGitLab وBuildkite.

بماذا يختلف SLSA عن SBOM؟

يجيب SBOM عمّا يحتويه العنصر البرمجي (المكونات، الإصدارات، التراخيص). ويجيب SLSA عن كيفية بنائه (سلامة البناء، الـ Provenance، التوقيعات). وكلاهما مكوّنان متكاملان لبرنامج حديث لسلسلة التوريد — لا متنافسان.

هل أحتاج إلى SLSA إذا لم أكن خاضعًا لـ CRA بعد؟

من الناحية القانونية البحتة اليوم غالبًا لا. أما عمليًا: إذا بدأتم اليوم، ستكون خطوط البناء الحرجة لديكم في الإنتاج على L2/L3 بحلول 2027. ومن يبدأ في 2027 يبني تحت ضغط التدقيق — وهذا سيكون مكلفًا.

كيف تدعم VamiSec التطبيق تحديدًا؟

ثلاث خطوات: تقييم خط البناء (مستوى النضج الحالي، الفجوات نحو L2/L3، تقدير الجهد)، وخارطة طريق بحزم Sprint محددة لمنصة البناء لديكم، وتطبيق عملي أو تدريب فريق DevSecOps لديكم. واختياريًا كورشة عمل ليوم واحد للفرق الداخلية. تواصلوا معنا عبر نموذج الحجز.

الخطوة التالية

يصمد أمام التدقيق.قابل للإثبات.في الإنتاج.

قبل أن تبدؤوا، تحدّثوا مع خبير. استشارة أولية لمدة 30 دقيقة مع خطة محددة لخط البناء لديكم — دون التزام ومجانًا.

اطلبوا استشارة أولية

في المحادثة الأولية

فحص مستوى النضج لخط البناء الحالي لديكم
خارطة طريق L0 → L3 مع تقدير الجهد
أنماط شيفرة محددة لـ GitHub Actions / Verifier
ربط التزاماتكم: CRA · NIS2 · DORA · AI Act
ملخص مكتوب وتوصيات

VamiSec GmbH · خبراء أمن تقنية المعلومات وGRC المدعومون بالذكاء الاصطناعي · Bornheimer Str. 127 · 53119 Bonn ·بيانات الناشر ·حماية البيانات