إثبات مصدر القطع البرمجية والشهادات: من SLSA إلى in-toto

مقدمة

لطالما كان توقيع الكود ركيزة أساسية في أمن البرمجيات. عندما تتحقق من توقيع ما، تعرف من وقّع على القطعة البرمجية. لكن معرفة من وقّع على شيء ما لا تخبرك كيف تم بناؤه، أو أين تم بناؤه، أو ما الكود المصدري الذي دخل فيه. يمكن لمشرف أن يوقّع ملفًا ثنائيًا تم تجميعه على حاسوب محمول مخترق مع حقن تبعيات خبيثة — وسيظل التوقيع صالحًا تمامًا.

هذه هي الفجوة التي يسدها إثبات مصدر القطع البرمجية (artifact provenance). إثبات المصدر هو سجل قابل للتحقق يوضح كيف تم إنتاج قطعة برمجية. يلتقط منصة البناء، ومستودع الكود المصدري، ونقطة الدخول، ومعاملات البناء، والتبعيات المستخدمة. بالاقتران مع التوقيعات، يمنح إثبات المصدر المستهلكين صورة كاملة: ليس فقط “من يضمن هذه القطعة البرمجية”، بل “ما العملية التي أنشأتها فعلاً”.

في هذا الدليل، سنستكشف أهم إطارين في هذا المجال — SLSA (Supply-chain Levels for Software Artifacts) وin-toto — وسنمر عبر التطبيق العملي في أنابيب CI/CD الحديثة. سواء كنت مهندس منصات تعمل على تأمين بنية البناء التحتية أو مطورًا يحاول فهم ما يتطلبه SLSA Level 3 فعلاً، ستمنحك هذه المقالة العمق التقني الذي تحتاجه.

ما هو إثبات مصدر القطع البرمجية؟

إثبات مصدر القطع البرمجية (artifact provenance) هو بيانات وصفية تصف أصل وعملية بناء قطعة برمجية. فكر فيه كإيصال بناء: مستند منظم وموقّع يجيب على ثلاثة أسئلة جوهرية:

• أين تم بناء القطعة البرمجية؟ (أي منصة بناء، أي عامل تشغيل، أي بيئة؟)
• كيف تم بناؤها؟ (أي أمر بناء، أي إعدادات، أي نقطة دخول؟)
• من ماذا تم بناؤها؟ (أي مستودع مصدري، أي commit، أي تبعيات؟)

إثبات المصدر مقابل التوقيعات

التوقيعات وإثبات المصدر متكاملان لكنهما يخدمان أغراضًا مختلفة:

• التوقيع يربط هوية بقطعة برمجية. يثبت أن حامل مفتاح معين وافق على القطعة البرمجية أو أنتجها. لا يقول شيئًا عن عملية البناء.
• إثبات المصدر يربط عملية بناء بقطعة برمجية. يثبت أن نسخة مصدرية معينة تحولت إلى القطعة البرمجية بواسطة منصة بناء معينة باستخدام معاملات محددة.

أنت بحاجة إلى كليهما. التوقيع بدون إثبات المصدر هو مجرد عبارة “ثق بي”. وإثبات المصدر بدون توقيع هو ادعاء غير موثق. معًا، يوفران دليلًا على عدم العبث، وقابلية التدقيق، وأساسًا لإنفاذ السياسات آليًا.

لماذا يهم إثبات المصدر

يعالج إثبات المصدر عدة مخاطر حرجة في سلسلة التوريد:

• دليل على عدم العبث: إذا عدّل مهاجم قطعة برمجية بعد بنائها، فلن يتطابق إثبات المصدر. وإذا عدّل عملية البناء، سيعكس إثبات المصدر بانيًا أو إعدادات مختلفة عن المتوقع.
• قابلية التدقيق: عند اكتشاف ثغرة أمنية، يتيح لك إثبات المصدر تتبع أي commit مصدري وأي إعدادات بناء أنتجت القطعة البرمجية المتأثرة بدقة.
• الامتثال: أطر العمل مثل NIST SSDF والأوامر التنفيذية المتعلقة بأمن سلسلة توريد البرمجيات تتطلب بشكل متزايد إثبات المصدر كضابط أساسي.
• السياسات الآلية: يمكن لوحدات التحكم في القبول وبوابات النشر التحقق من إثبات المصدر برمجيًا، مما يفرض أن القطع البرمجية المبنية فقط بواسطة منصات موثوقة من مستودعات معتمدة هي التي يتم نشرها.

إطار عمل SLSA

SLSA (يُنطق “سالسا”) هو إطار أمني طُوّر في الأصل في Google ويُدار حاليًا بواسطة OpenSSF. يحدد نموذج نضج لأمن سلسلة التوريد، مع إثبات المصدر في جوهره. لا يفرض SLSA أدوات محددة — بل يحدد متطلبات يجب أن تلبيها الأدوات والمنصات.

نموذج البناء في SLSA

يصمم SLSA سلسلة توريد البرمجيات كأنبوب بسيط:

المصدر ← منصة البناء ← القطعة البرمجية

لكل مرحلة تهديدات مميزة. يمكن العبث بالمصدر (commits خبيثة، اختراق نظام التحكم في الإصدارات). يمكن اختراق منصة البناء (تعديل سكربتات البناء، حقن تبعيات). يمكن العبث بالقطعة البرمجية بعد البناء (تسميم السجل، هجوم الوسيط). يعالج SLSA كلًا من هذه التهديدات من خلال متطلبات صارمة بشكل متزايد عند كل مستوى.

مستويات SLSA (الإصدار 1.0)

يحدد SLSA v1.0 أربعة مستويات بناء، كل منها يبني على السابق:

Build Level 1 — إثبات المصدر موجود

• تولّد عملية البناء إثبات مصدر يصف كيف تم إنتاج القطعة البرمجية.
• يتبع تنسيق إثبات المصدر مواصفات SLSA.
• لا يحتاج إثبات المصدر إلى أن يكون موقّعًا أو مُولَّدًا بواسطة منصة البناء نفسها.
• التهديد المعالَج: يوفر خط أساس لقابلية التدقيق. لا يمنع العبث.

Build Level 2 — بناء مستضاف وإثبات مصدر موقّع

• يعمل البناء على منصة بناء مستضافة (وليس محطة عمل مطور).
• يتم توقيع إثبات المصدر بواسطة منصة البناء، وليس بواسطة مشرف المشروع.
• يتم توليد إثبات المصدر بواسطة خدمة البناء نفسها ولا يمكن تعديله بواسطة مستأجر البناء.
• التهديد المعالَج: يمنع مستأجر البناء من تزوير إثبات المصدر. يمكن للمستهلكين التحقق من هوية خدمة البناء.

Build Level 3 — منصة بناء محصّنة

• توفر منصة البناء عزلًا قويًا بين مستأجري البناء (مثل البيئات المؤقتة المعزولة).
• إثبات المصدر غير قابل للتزوير: حتى مستأجر البناء المخترق لا يمكنه إنشاء إثبات مصدر مزيف لمشروع آخر.
• تعمل عمليات البناء في بيئات محكمة مع تبعيات معلنة ومُتحكم بها.
• التهديد المعالَج: يمنع البناء المخترق من التأثير على مشاريع أخرى. يمنع عمليات البناء من استخدام تبعيات غير معلنة.

Build Level 4 — مراجعة ثنائية وبناء محكم

• تتطلب جميع تغييرات المصدر مراجعة من طرفين قبل قبولها في البناء.
• عمليات البناء محكمة بالكامل: جميع التبعيات معلنة ويتم جلبها بطريقة قابلة للتكرار.
• منصة البناء معزولة بالكامل وقابلة للتدقيق.
• التهديد المعالَج: يمنع شخصًا داخليًا واحدًا من حقن كود خبيث يتم بناؤه وتوزيعه.

مواصفات إثبات المصدر في SLSA

يحدد SLSA تنسيق إثبات مصدر محدد يجب أن يتضمن:

• هوية الباني: أي منصة بناء أنتجت القطعة البرمجية (مثل GitHub Actions أو Google Cloud Build).
• إعدادات البناء: نقطة الدخول والمعاملات للبناء (مثل ملف workflow وأمر البناء).
• مرجع المصدر: مستودع المصدر وبصمة commit التي تم بناؤها.
• المواد: قائمة بجميع مدخلات البناء، بما في ذلك التبعيات وبصماتها.
• البيانات الوصفية: الطوابع الزمنية ومعرفات الاستدعاء وبيانات وصفية أخرى للبناء.

يُعبَّر عن إثبات المصدر هذا كمستند JSON منظم، وتحديدًا كـ in-toto attestation — مما يقودنا إلى القسم التالي.

إطار عمل in-toto للشهادات

in-toto هو إطار عمل لتأمين سلاسل توريد البرمجيات من خلال بيانات وصفية موقّعة تشفيريًا. بينما يحدد SLSA ما يجب أن يحتويه إثبات المصدر وأي مستوى أمني يوفره، يحدد in-toto تنسيق البيانات وآلية التوقيع المستخدمة لتمثيل إثبات المصدر والتحقق منه.

Layout و Link Metadata في in-toto

في نموذج in-toto الأصلي، يُوصف سلسلة التوريد بنوعين من البيانات الوصفية:

• Layout: مستند موقّع بواسطة مالك المشروع يحدد خطوات سلسلة التوريد المتوقعة، ومن مخوّل بتنفيذ كل خطوة، وما قواعد الفحص التي يجب تطبيقها أثناء التحقق.
• Link metadata: دليل موقّع يُنتَج في كل خطوة من سلسلة التوريد، يسجل المواد (المدخلات) والمنتجات (المخرجات) لتلك الخطوة.

هذا النموذج قوي لسلاسل التوريد متعددة الخطوات حيث تحتاج إلى التحقق من أن الخطوة A أنتجت المخرج X، الذي استُهلك بعد ذلك بواسطة الخطوة B لإنتاج المخرج Y، مع تنفيذ كل خطوة بواسطة فاعل مخوّل.

تنسيق شهادات in-toto

يُعمّم تنسيق شهادات in-toto الحديث (ITE-6) النموذج الأصلي إلى إطار مرن وقابل للتوسيع. تتكون الشهادة من ثلاث طبقات:

1. Statement: الغلاف الخارجي الذي يربط predicate بموضوع واحد أو أكثر.

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "my-artifact",
      "digest": {
        "sha256": "a1b2c3d4e5f6..."
      }
    }
  ],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": { ... }
}

2. Predicate: البيانات الوصفية الفعلية حول القطعة البرمجية. تخدم أنواع predicate المختلفة أغراضًا مختلفة:

• https://slsa.dev/provenance/v1 — إثبات مصدر SLSA (معلومات البناء)
• https://spdx.dev/Document — SBOM بتنسيق SPDX
• https://cyclonedx.org/bom — SBOM بتنسيق CycloneDX
• https://in-toto.io/attestation/vulns — نتائج فحص الثغرات الأمنية

3. Subject: مرجع واحد أو أكثر للقطع البرمجية، كل منها محدد باسم ومجموعة من البصمات التشفيرية. هذا يربط predicate بقطع برمجية محددة.

DSSE (Dead Simple Signing Envelope)

تُغلَّف شهادات in-toto في DSSE (Dead Simple Signing Envelope) للتوقيع. يحل DSSE عدة مشاكل في أساليب التوقيع السابقة:

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

يوقّع DSSE على نوع الحمولة والحمولة معًا (باستخدام PAE — Pre-Authentication Encoding)، مما يمنع هجمات الالتباس حيث يُعاد استخدام توقيع لنوع حمولة في نوع آخر. يدعم توقيعات متعددة، مما يتيح سيناريوهات التوقيع متعدد الأطراف.

كيف يرتبط in-toto بـ SLSA

العلاقة مباشرة: إثبات مصدر SLSA هو نوع predicate في in-toto. عندما تولّد منصة بناء متوافقة مع SLSA إثبات مصدر، فإنها تنتج شهادة in-toto مع predicateType: https://slsa.dev/provenance/v1، وتوقّعها بـ DSSE، وتربطها بالقطعة البرمجية المبنية عبر حقل subject. يحدد SLSA المتطلبات ونموذج التهديد؛ ويوفر in-toto تنسيق البيانات وإطار التحقق.

توليد إثبات المصدر في CI/CD

دعونا نمر عبر التطبيقات العملية في أكثر منصات CI/CD شيوعًا.

GitHub Actions: slsa-github-generator

يوفر مشروع slsa-framework/slsa-github-generator workflows قابلة لإعادة الاستخدام تولّد إثبات مصدر بمستوى SLSA Level 3 على GitHub Actions. يتم توليد إثبات المصدر بواسطة workflow مستضاف ومعزول لا يمكن لمستأجر البناء العبث به.

للقطع البرمجية العامة:

name: SLSA Provenance for Generic Artifacts
on:
  push:
    tags:
      - "v*"

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      digests: ${{ steps.hash.outputs.digests }}
    steps:
      - uses: actions/checkout@v4
      - name: Build artifact
        run: |
          go build -o my-binary ./cmd/app
      - name: Generate subject digest
        id: hash
        run: |
          DIGEST=$(sha256sum my-binary | base64 -w0)
          echo "digests=$DIGEST" >> "$GITHUB_OUTPUT"
      - uses: actions/upload-artifact@v4
        with:
          name: my-binary
          path: my-binary

  provenance:
    needs: [build]
    permissions:
      actions: read
      id-token: write
      contents: write
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v2.1.0
    with:
      base64-subjects: ${{ needs.build.outputs.digests }}
      upload-assets: true

لصور الحاويات:

name: SLSA Provenance for Container Images
on:
  push:
    tags:
      - "v*"

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      image: ${{ steps.build.outputs.image }}
      digest: ${{ steps.build.outputs.digest }}
    permissions:
      packages: write
    steps:
      - uses: actions/checkout@v4
      - name: Log in to GHCR
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - name: Build and push
        id: build
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.ref_name }}

  provenance:
    needs: [build]
    permissions:
      actions: read
      id-token: write
      packages: write
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v2.1.0
    with:
      image: ${{ needs.build.outputs.image }}
      digest: ${{ needs.build.outputs.digest }}
      registry-username: ${{ github.actor }}
    secrets:
      registry-password: ${{ secrets.GITHUB_TOKEN }}

GitHub Artifact Attestations

يقدم GitHub الآن شهادات أصلية للقطع البرمجية من خلال actions/attest-build-provenance. هذا أبسط من مولّد SLSA وينتج شهادات موقّعة بـ Sigstore مخزنة في واجهة برمجة تطبيقات الشهادات في GitHub.

name: Build and Attest
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
      attestations: write
    steps:
      - uses: actions/checkout@v4
      - name: Build binary
        run: go build -o my-binary ./cmd/app
      - name: Attest build provenance
        uses: actions/attest-build-provenance@v2
        with:
          subject-path: my-binary
      - name: Attest container image
        uses: actions/attest-build-provenance@v2
        with:
          subject-name: ghcr.io/${{ github.repository }}
          subject-digest: ${{ steps.push.outputs.digest }}
          push-to-registry: true

GitLab CI: توليد بيانات وصفية لإثبات المصدر

لا يمتلك GitLab حتى الآن مولّد إثبات مصدر SLSA أصلي بنفس نضج GitHub، لكن يمكنك توليد وتوقيع بيانات إثبات المصدر الوصفية باستخدام أدوات إطار SLSA مباشرة.

stages:
  - build
  - provenance

build:
  stage: build
  image: golang:1.22
  script:
    - go build -o my-binary ./cmd/app
    - sha256sum my-binary > checksums.txt
  artifacts:
    paths:
      - my-binary
      - checksums.txt

generate-provenance:
  stage: provenance
  image: ghcr.io/slsa-framework/slsa-generator-generic:v2.1.0
  needs: [build]
  script:
    - |
      cat > provenance.json <<PROV
      {
        "_type": "https://in-toto.io/Statement/v1",
        "subject": [
          {
            "name": "my-binary",
            "digest": {
              "sha256": "$(sha256sum my-binary | awk '{print $1}')"
            }
          }
        ],
        "predicateType": "https://slsa.dev/provenance/v1",
        "predicate": {
          "buildDefinition": {
            "buildType": "https://gitlab.com/gitlab-ci",
            "externalParameters": {
              "repository": "${CI_PROJECT_URL}",
              "ref": "${CI_COMMIT_SHA}"
            }
          },
          "runDetails": {
            "builder": {
              "id": "https://gitlab.com/${CI_PROJECT_PATH}/-/runners/${CI_RUNNER_ID}"
            },
            "metadata": {
              "invocationId": "${CI_PIPELINE_URL}",
              "startedOn": "${CI_PIPELINE_CREATED_AT}"
            }
          }
        }
      }
      PROV
    - cosign attest-blob --predicate provenance.json --type slsaprovenance my-binary
  artifacts:
    paths:
      - provenance.json

تخزين إثبات المصدر في سجلات OCI

بالنسبة لصور الحاويات، يتم عادةً تخزين شهادات إثبات المصدر بجانب الصورة في سجل OCI باستخدام نموذج شهادات Cosign. تُخزَّن الشهادة كقطعة OCI منفصلة مرتبطة بالصورة عبر البصمة:

# Attach provenance to a container image in the registry
cosign attest --predicate provenance.json \
  --type slsaprovenance \
  --key cosign.key \
  ghcr.io/myorg/myimage@sha256:abc123...

# For keyless signing with Sigstore
cosign attest --predicate provenance.json \
  --type slsaprovenance \
  --yes \
  ghcr.io/myorg/myimage@sha256:abc123...

يستفيد هذا النهج من واجهة referrers API في مواصفات توزيع OCI، التي تسمح للعملاء باكتشاف الشهادات المرتبطة بـ image manifest معين. يمكن لأدوات مثل cosign وcrane بعد ذلك جلب هذه الشهادات والتحقق منها أثناء النشر.

التحقق من إثبات المصدر

توليد إثبات المصدر هو نصف القصة فقط. يجب على المستهلكين — سواء مشغلون بشريون أو أنظمة آلية — التحقق من إثبات المصدر قبل الوثوق بقطعة برمجية.

أداة slsa-verifier CLI

تتحقق أداة slsa-verifier من إثبات مصدر SLSA المُولَّد بواسطة بانين موثوقين (حاليًا البانون المبنيون على GitHub Actions).

# Verify a generic artifact
slsa-verifier verify-artifact my-binary \
  --provenance-path my-binary.intoto.jsonl \
  --source-uri github.com/myorg/myrepo \
  --source-tag v1.2.3

# Verify a container image
slsa-verifier verify-image ghcr.io/myorg/myimage@sha256:abc123... \
  --source-uri github.com/myorg/myrepo \
  --source-tag v1.2.3

يتحقق المدقق مما يلي:

• توقيع إثبات المصدر صالح ومرتبط بجذر موثوق (Sigstore لبانيي GitHub Actions).
• هوية الباني تتطابق مع باني موثوق معروف.
• مستودع المصدر يتطابق مع المستودع المتوقع.
• بصمة القطعة البرمجية تتطابق مع الموضوع في إثبات المصدر.

cosign verify-attestation

للتحقق الأكثر مرونة، يتيح لك cosign verify-attestation التحقق من شهادات in-toto المرفقة بصور الحاويات مع تصفية النوع:

# Verify SLSA provenance attestation
cosign verify-attestation \
  --type slsaprovenance \
  --certificate-identity "https://github.com/myorg/myrepo/.github/workflows/release.yml@refs/tags/v1.2.3" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/myorg/myimage@sha256:abc123...

# Verify with a CUE policy
cosign verify-attestation \
  --type slsaprovenance \
  --policy policy.cue \
  ghcr.io/myorg/myimage@sha256:abc123...

# Verify with a Rego policy
cosign verify-attestation \
  --type slsaprovenance \
  --policy policy.rego \
  ghcr.io/myorg/myimage@sha256:abc123...

gh attestation verify

للقطع البرمجية المشهود عليها بميزة الشهادات الأصلية من GitHub، يوفر gh CLI تحققًا مدمجًا:

# Verify a local artifact
gh attestation verify my-binary \
  --owner myorg

# Verify a container image
gh attestation verify oci://ghcr.io/myorg/myimage@sha256:abc123... \
  --owner myorg

# Download and inspect the attestation bundle
gh attestation download my-binary \
  --owner myorg \
  --output attestation.jsonl

إثبات المصدر في وحدات التحكم في القبول

لبوابات نشر الإنتاج، يمكن لوحدات التحكم في القبول فرض سياسات إثبات المصدر تلقائيًا. إليك مثالًا باستخدام policy-controller من Sigstore في عنقود Kubernetes:

apiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: require-slsa-provenance
spec:
  images:
    - glob: "ghcr.io/myorg/**"
  authorities:
    - keyless:
        url: https://fulcio.sigstore.dev
        identities:
          - issuer: https://token.actions.githubusercontent.com
            subject: "https://github.com/myorg/*"
      attestations:
        - name: must-have-slsa-provenance
          predicateType: https://slsa.dev/provenance/v1
          policy:
            type: cue
            data: |
              predicateType: "https://slsa.dev/provenance/v1"
              predicate: buildDefinition: {
                buildType: =~"^https://github.com/slsa-framework/slsa-github-generator/"
              }

ما يجب التحقق منه أثناء عملية التحقق

بغض النظر عن الأداة المستخدمة، يجب أن يؤكد التحقق من إثبات المصدر:

• هوية الباني: هل تم بناء القطعة البرمجية بواسطة منصة بناء موثوقة؟ تحقق من معرف الباني في إثبات المصدر مقابل قائمة سماح معروفة.
• مستودع المصدر: هل يشير إثبات المصدر إلى مستودع المصدر و commit المتوقعين؟ هذا يمنع نشر قطع برمجية من forks أو مستودعات غير مصرح بها.
• محفزات البناء: هل تم تشغيل البناء بواسطة حدث متوقع (push إلى tag إصدار، دمج إلى main)؟ هذا يكشف القطع البرمجية المبنية من فروع أو أحداث غير متوقعة.
• بصمة القطعة البرمجية: هل تتطابق القطعة البرمجية التي تتحقق منها مع بصمة الموضوع في إثبات المصدر؟ هذا هو فحص النزاهة الأساسي.
• حداثة إثبات المصدر: هل إثبات المصدر حديث؟ إثبات المصدر القديم لعمليات بناء سابقة قد لا يعكس الوضع الأمني الحالي.

التحديات العملية

إثبات المصدر و SLSA مفاهيم قوية، لكن التبني في العالم الحقيقي يأتي مع تحديات كبيرة. التقييم الصادق يساعد الفرق على التخطيط لاستراتيجيات تبني واقعية.

تحقيق SLSA Level 3+ صعب

يتطلب SLSA Level 3 بيئات بناء محصّنة ومعزولة — وهنا تواجه معظم المؤسسات احتكاكًا. البناء المحكم يعني أن كل تبعية يجب أن تكون معلنة صراحة ويتم جلبها عبر قنوات متحكم بها. لا تحميل حزم عشوائية من الإنترنت أثناء البناء. لا وصول شبكي إلى خدمات غير معلنة.

بالنسبة للعديد من المشاريع، يتطلب هذا تغييرات جوهرية في طريقة عمل عمليات البناء. اللغات ذات أنظمة الحزم الغنية (Node.js و Python و Go) غالبًا ما تحتوي على عمليات بناء تحمّل التبعيات ضمنيًا. الانتقال إلى نموذج محكم يعني تضمين التبعيات محليًا، أو استخدام ملفات قفل مع فحوصات نزاهة، أو تشغيل عمليات البناء خلف وكيل تبعيات يفرض قائمة سماح.

البانون المعزولون يضيفون تكلفة تشغيلية. بيئات البناء المؤقتة التي تُدمَّر بعد كل بناء تمنع التلوث المتبادل لكنها تزيد أوقات البناء وتكاليف البنية التحتية. عوامل التشغيل المستضافة ذاتيًا على GitHub Actions، مثلاً، لا توفر نفس ضمانات العزل التي توفرها عوامل التشغيل المستضافة من GitHub.

نضج الأدوات وفجوات النظام البيئي

النظام البيئي لـ SLSA ينضج بسرعة لكنه لا يزال يحتوي على فجوات:

• البانون الموثوقون محدودون. حتى الآن، توجد مولّدات إثبات مصدر SLSA Level 3 بشكل أساسي لـ GitHub Actions. أما GitLab و Jenkins و CircleCI ومنصات أخرى فلديها حلول أقل نضجًا أو يديرها المجتمع.
• أدوات التحقق مجزأة. أدوات مختلفة تتحقق من تنسيقات إثبات مصدر مختلفة، ولا يوجد أمر عالمي “تحقق من جميع إثباتات المصدر”. غالبًا ما تحتاج الفرق إلى أدوات متعددة في أنبوب التحقق الخاص بها.
• لغات السياسات متنوعة. بعض الأدوات تستخدم CUE وأخرى تستخدم Rego، ووحدات التحكم في القبول في Kubernetes لكل منها تنسيق سياسات خاص بها. التوحيد لا يزال قيد التقدم.

إثبات المصدر للقطع البرمجية غير الحاويات

بينما يمتلك إثبات مصدر صور الحاويات نموذجًا واضحًا للتخزين والتوزيع (سجلات OCI و referrers)، تواجه أنواع القطع البرمجية الأخرى تحديات:

• حزم npm: يدعم npm إثبات المصدر منذ مايو 2023، ويُولَّد تلقائيًا للحزم المنشورة من GitHub Actions. لكن أدوات التحقق على جانب المستهلك لا تزال محدودة.
• حزم Python (PyPI): يعمل PyPI على دعم الشهادات مع Trusted Publishers، لكن النظام البيئي لا يزال في مراحل التبني المبكرة.
• قطع Maven البرمجية: إثبات مصدر نظام Java البيئي أقل نضجًا. مشاريع مثل Sigstore for Java ناشئة، لكن التبني الواسع يتطلب دعم السجلات.
• الملفات الثنائية العامة: بالنسبة للملفات الثنائية المستقلة، يُرفق إثبات المصدر عادةً كملف مرافق (.intoto.jsonl) بجانب الملف الثنائي في أصول الإصدار. هذا يعمل لكنه يتطلب من المستهلكين معرفة مكان العثور عليه وكيفية التحقق منه.

الموازنة بين الصرامة وسرعة المطورين

متطلبات إثبات المصدر الصارمة يمكن أن تبطئ سير عمل التطوير:

• التطوير المحلي: يحتاج المطورون إلى اختبار عمليات البناء محليًا، لكن عمليات البناء المحلية لا يمكنها إنتاج إثبات مصدر بمستوى SLSA Level 2+. تحتاج الفرق إلى التمييز بين “عمليات بناء التطوير” و”عمليات بناء الإصدار” دون إنشاء عملية معقدة جدًا بحيث يتجاوزها المطورون.
• التبني التدريجي: الانتقال من صفر إثبات مصدر إلى SLSA Level 3 في خطوة واحدة نادرًا ما يكون ممكنًا. الفرق التي تحاول ذلك غالبًا ما تتخلى عن الجهد. النهج المرحلي — Level 1 أولاً، ثم Level 2، ثم Level 3 للمسارات الحرجة — أكثر استدامة.
• قابلية تكرار البناء: إثبات المصدر يخبرك كيف تم بناء شيء ما، لكنه لا يضمن أن نفس المدخلات تنتج دائمًا نفس المخرجات. عمليات البناء غير القابلة للتكرار تجعل التحقق المستقل من ادعاءات إثبات المصدر أصعب.
• عمليات النشر الطارئة: في سيناريوهات الاستجابة للحوادث، قد تحتاج الفرق إلى النشر بسرعة من مسارات بناء غير قياسية. سياسات إثبات المصدر تحتاج إلى مخارج طوارئ (مع تسجيل ومسارات تدقيق مناسبة) لتجنب حجب الإصلاحات الحرجة.

الخلاصة

يسد إثبات مصدر القطع البرمجية فجوة جوهرية في أمن سلسلة توريد البرمجيات. بينما تثبت التوقيعات من وافق على قطعة برمجية، يثبت إثبات المصدر كيف تم بناؤها فعلاً. إلى جانب نموذج نضج إطار SLSA وتنسيق شهادات in-toto، لدينا الآن نهج عملي وموحد لنزاهة البناء.

النقاط الرئيسية للفرق التي تبدأ هذه الرحلة:

• ابدأ بـ SLSA Level 1. ولّد بيانات وصفية لإثبات المصدر لعمليات البناء الخاصة بك، حتى لو لم تكن موقّعة بعد بواسطة منصة البناء. هذا يمنحك قابلية التدقيق ويرسّخ الممارسة.
• انتقل إلى Level 2 مع بانين مستضافين. استخدم GitHub Actions أو Google Cloud Build أو منصة مستضافة أخرى يمكنها توقيع إثبات المصدر نيابة عنك. هنا يصبح إثبات المصدر قابلًا للتحقق بشكل فعلي.
• استهدف Level 3 للمسارات الحرجة. لأكثر قطعك البرمجية حساسية — صور حاويات الإنتاج والإصدارات الموقّعة والمكتبات الأمنية الحرجة — استثمر في البناء المحكم وبيئات البناء المعزولة.
• تحقق من إثبات المصدر في أنبوب النشر الخاص بك. توليد إثبات المصدر دون التحقق منه هو مسرح أمني. أضف التحقق إلى وحدات التحكم في القبول أو سكربتات النشر أو سير عمل GitOps المبني على السحب.
• تبنَّ شهادات in-toto كتنسيق بياناتك الوصفية. تنسيق شهادات in-toto يصبح المعيار لبيانات سلسلة التوريد الوصفية، داعمًا ليس فقط إثبات مصدر SLSA بل أيضًا SBOM وفحوصات الثغرات الأمنية و predicates مخصصة.

أمن سلسلة التوريد ليس أداة واحدة أو فحصًا واحدًا. إنه نهج متعدد الطبقات حيث يعزز كل ضابط — نزاهة المصدر ونزاهة البناء وإثبات المصدر والتحقق — الضوابط الأخرى. إثبات المصدر هو النسيج الضام الذي يجعل النظام بأكمله قابلًا للتدقيق والتحقق. ابدأ بتوليده اليوم، وتقدم تصاعديًا.