توقيع صور الحاويات والتحقق منها باستخدام Sigstore و Cosign

مقدمة: لماذا يُعدّ توقيع العناصر البرمجية أمرًا بالغ الأهمية في CI/CD

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

هذا ليس مصدر قلق نظري. فقد أظهر هجوم SolarWinds في عام 2020 كيف يمكن للخصوم حقن شفرة خبيثة في عملية البناء، منتجين عناصر برمجية موقَّعة لكنها مخترقة انتشرت إلى آلاف المنظمات. وأظهر اختراق Codecov في عام 2021 كيف يمكن لنص CI مُتلاعَب به تسريب الأسرار من كل مستودع يستخدمه. في كلتا الحالتين، كانت سلسلة التوريد — البنية التحتية بين الشفرة والنشر — هي سطح الهجوم.

يعالج توقيع العناصر البرمجية جزءًا حاسمًا من هذا اللغز: الأصالة والسلامة. من خلال التوقيع التشفيري لصورة حاوية، تُنشئ رابطًا قابلاً للتحقق بين الصورة والهوية (شخص أو فريق أو نظام CI) التي أنتجتها. يمكن لمستهلكي تلك الصورة بعد ذلك التحقق من التوقيع قبل تشغيلها، مما يضمن أنها لم تُعدَّل منذ بنائها.

لسنوات عديدة، كان التوقيع غير عملي في معظم المنظمات. كانت إدارة مفاتيح GPG مرهقة، وتوزيع المفاتيح هشًا، وكانت الأدوات تتطلب خبرة عميقة في التشفير. غيَّر Sigstore ذلك. فقد قدّم مجموعة من الأدوات مفتوحة المصدر تجعل التوقيع والتحقق سهلَي الوصول وآليَّين — والأهم من ذلك — بدون مفاتيح (keyless).

يرشدك هذا الدليل عبر منظومة Sigstore، ويوضح لك كيفية توقيع صور الحاويات والتحقق منها باستخدام Cosign، ودمج التوقيع في خطوط أنابيب CI/CD، وإرفاق الشهادات (attestations) وقوائم مكونات البرمجيات (SBOMs). بنهاية هذا الدليل، ستمتلك فهمًا عمليًا لكيفية جعل توقيع العناصر البرمجية جزءًا معياريًا من عملية التسليم.

ما هو Sigstore؟

Sigstore هو مشروع مفتوح المصدر تابع لمؤسسة Linux Foundation يوفر أدوات مجانية وشفافة وسهلة الاستخدام لتوقيع العناصر البرمجية والتحقق منها وحمايتها. أُنشئ لحل مشكلة محددة: جعل التوقيع التشفيري عمليًا لمنظومة المصادر المفتوحة وما بعدها.

تتكون منظومة Sigstore من ثلاثة مكونات أساسية:

Cosign

Cosign هو أداة جانب العميل لتوقيع صور الحاويات وعناصر OCI الأخرى والتحقق منها. إنه ما يتفاعل معه المطورون وخطوط أنابيب CI/CD مباشرة. يدعم Cosign كلاً من التوقيع التقليدي بزوج المفاتيح والتوقيع بدون مفاتيح (keyless signing) الأحدث.

Fulcio

Fulcio هو جهة إصدار شهادات (CA) مجانية تُصدر شهادات قصيرة العمر بناءً على هوية OpenID Connect (OIDC). عند استخدام التوقيع بدون مفاتيح، يتحقق Fulcio من هويتك من خلال مزود OIDC (مثل Google أو GitHub أو Microsoft) ويُصدر شهادة تربط هويتك بمفتاح التوقيع. تكون الشهادة صالحة لبضع دقائق فقط — وقت كافٍ لتوقيع عنصر برمجي، لكنه قصير بما يكفي لتجنب مخاطر اختراق المفتاح بشكل مستمر.

Rekor

Rekor هو سجل شفافية — دفتر أستاذ ثابت وقابل للإلحاق فقط يسجل أحداث التوقيع. في كل مرة يُوقَّع فيها عنصر برمجي، يُضاف سجل إلى Rekor. يوفر هذا مسارًا عامًا قابلاً للتدقيق يوضح مَن وقَّع ماذا ومتى. وهو مشابه مفاهيميًا لسجلات Certificate Transparency المستخدمة في منظومة TLS.

كيف يختلف التوقيع بدون مفاتيح (Keyless Signing) عن GPG

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

يُلغي التوقيع بدون مفاتيح في Sigstore هذا العبء:

لا مفاتيح طويلة العمر — مفاتيح التوقيع مؤقتة. توجد فقط طوال مدة عملية التوقيع.
ثقة مبنية على الهوية — بدلاً من الوثوق بمفتاح، تثق بهوية (مثل سير عمل GitHub Actions أو عنوان بريد إلكتروني محدد). يربط Fulcio الهوية بالمفتاح المؤقت عبر شهادة قصيرة العمر.
شفافية افتراضية — يُسجَّل كل حدث توقيع في Rekor، مما يُنشئ سجلاً قابلاً للتدقيق دون الحاجة لتشغيل بنيتك التحتية الخاصة.
لا مشكلة في توزيع المفاتيح — لا يحتاج المتحققون إلى الحصول على مفتاح عام خارج النطاق. يتحققون مقابل الهوية وسجل الشفافية.

توقيع صور الحاويات باستخدام Cosign

تثبيت Cosign

يُوزَّع Cosign كملف ثنائي واحد. يمكنك تثبيته على معظم المنصات:

# macOS (Homebrew)
brew install cosign

# Linux (Go install)
go install github.com/sigstore/cosign/v2/cmd/cosign@latest

# Linux (binary release)
curl -LO https://github.com/sigstore/cosign/releases/latest/download/cosign-linux-amd64
chmod +x cosign-linux-amd64
sudo mv cosign-linux-amd64 /usr/local/bin/cosign

# Verify installation
cosign version

التوقيع بزوج مفاتيح

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

الخطوة 1: توليد زوج مفاتيح

cosign generate-key-pair

ينشئ هذا ملفين: cosign.key (المفتاح الخاص، محمي بكلمة مرور) وcosign.pub (المفتاح العام). خزِّن المفتاح الخاص بشكل آمن — في مدير أسرار أو HSM أو خزنة مشفرة.

الخطوة 2: توقيع صورة حاوية

# Sign an image by its digest (always prefer digest over tag)
cosign sign --key cosign.key ghcr.io/myorg/myapp@sha256:abc123...

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

مهم: وقِّع دائمًا باستخدام الخلاصة (digest) وليس بالعلامة (tag). العلامات قابلة للتغيير — يمكن لأي شخص نقل علامة للإشارة إلى صورة مختلفة بعد التوقيع. أما الخلاصات فهي مُعالجة بالمحتوى وغير قابلة للتغيير.

التوقيع بدون مفاتيح (Keyless Signing) باستخدام هوية OIDC

التوقيع بدون مفاتيح هو النهج الموصى به لخطوط أنابيب CI/CD. يُلغي الحاجة لإدارة مفاتيح التوقيع بالكامل.

# Keyless signing (interactive — opens browser for OIDC login)
cosign sign ghcr.io/myorg/myapp@sha256:abc123...

# Keyless signing (non-interactive, for CI/CD)
# The --yes flag skips the confirmation prompt
cosign sign --yes ghcr.io/myorg/myapp@sha256:abc123...

في بيئة CI/CD مثل GitHub Actions، يكتشف Cosign تلقائيًا رمز OIDC المحيط الذي توفره المنصة. لا حاجة لتفاعل عبر المتصفح.

ما يحدث خلف الكواليس

عند تشغيل cosign sign --yes في وضع بدون مفاتيح، يحدث التسلسل التالي:

توليد مفتاح مؤقت — يُنشئ Cosign زوج مفاتيح مؤقتًا في الذاكرة.
مصادقة OIDC — يحصل Cosign على رمز هوية OIDC من البيئة (مثل مزود OIDC لـ GitHub Actions) أو يطلب منك المصادقة عبر المتصفح.
إصدار الشهادة — يرسل Cosign المفتاح العام ورمز OIDC إلى Fulcio. يتحقق Fulcio من الرمز، ويستخرج الهوية (البريد الإلكتروني، URI سير العمل، إلخ)، ويُصدر شهادة X.509 قصيرة العمر تربط الهوية بالمفتاح العام.
التوقيع — يُوقِّع Cosign خلاصة (digest) الصورة باستخدام المفتاح الخاص المؤقت.
تسجيل الشفافية — تُسجَّل التوقيع والشهادة وخلاصة الصورة في Rekor. هذا الإدخال مُختَم بالوقت وغير قابل للتغيير.
رفع التوقيع — يُدفع التوقيع إلى سجل OCI كعنصر مرافق.
تدمير المفتاح — يُتلف المفتاح الخاص المؤقت. لا يُخزَّن أبدًا في أي مكان.

النتيجة هي صورة مُوقَّعة بسلسلة قابلة للتحقق: يُثبت سجل Rekor أن التوقيع أُنشئ في وقت محدد بواسطة هوية محددة، وتُثبت شهادة Fulcio أن الهوية كانت مُصادَق عليها وقت التوقيع.

التحقق من التوقيعات

التوقيع مفيد فقط إذا تحقق المستهلكون منه. يوفر Cosign أوامر تحقق مباشرة لكل من السيناريوهات المبنية على المفاتيح وبدون مفاتيح.

التحقق باستخدام مفتاح عام

إذا وُقِّعت الصورة بزوج مفاتيح، تحقق باستخدام المفتاح العام:

cosign verify --key cosign.pub ghcr.io/myorg/myapp@sha256:abc123...

يجلب Cosign التوقيع من سجل OCI، ويتحقق منه مقابل المفتاح العام، ويُخرج النتيجة. إذا كان التوقيع صالحًا، يطبع حمولة التوقيع. إذا لم يكن كذلك، يخرج بخطأ.

التحقق بدون مفاتيح (Keyless Verification)

للصور المُوقَّعة بدون مفاتيح، يعتمد التحقق على الهوية بدلاً من المفتاح. تُحدد مَن تتوقع أن يكون قد وقَّع الصورة:

# Verify that a specific GitHub Actions workflow signed the image
cosign verify \
  --certificate-identity "https://github.com/myorg/myapp/.github/workflows/release.yml@refs/heads/main" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/myorg/myapp@sha256:abc123...

يتحقق هذا الأمر من أن:

الصورة تحمل توقيعًا صالحًا.
شهادة التوقيع صادرة من Fulcio.
الهوية في الشهادة تتطابق مع --certificate-identity المحدد.
مُصدر OIDC يتطابق مع --certificate-oidc-issuer.
حدث التوقيع مسجل في سجل شفافية Rekor.

يمكنك أيضًا استخدام مطابقة التعبيرات النمطية (regex) لسياسات أكثر مرونة:

cosign verify \
  --certificate-identity-regexp "https://github.com/myorg/.*" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/myorg/myapp@sha256:abc123...

فرض التحقق في وحدات التحكم بالقبول (Admission Controllers)

التحقق اليدوي مفيد لتصحيح الأخطاء، لكن بيئات الإنتاج تحتاج إلى فرض آلي. يمكن لوحدات التحكم بالقبول في Kubernetes رفض أي صورة لا تحمل توقيعًا صالحًا.

Kyverno هو محرك سياسات شائع مع دعم مدمج للتحقق عبر Cosign:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signatures
spec:
  validationFailureAction: Enforce
  background: false
  rules:
    - name: verify-cosign-signature
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "ghcr.io/myorg/*"
          attestors:
            - entries:
                - keyless:
                    subject: "https://github.com/myorg/myapp/.github/workflows/release.yml@refs/heads/main"
                    issuer: "https://token.actions.githubusercontent.com"
                    rekor:
                      url: https://rekor.sigstore.dev

يوفر Sigstore Policy Controller (المعروف سابقًا بـ Cosign Policy Webhook) وظائف مشابهة بنهج أصلي لـ Sigstore:

apiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: require-signed-images
spec:
  images:
    - glob: "ghcr.io/myorg/**"
  authorities:
    - keyless:
        identities:
          - issuer: "https://token.actions.githubusercontent.com"
            subject: "https://github.com/myorg/myapp/.github/workflows/release.yml@refs/heads/main"
        ctlog:
          url: https://rekor.sigstore.dev

مع أي من النهجين، سيُرفض أي pod يشير إلى صورة غير مُوقَّعة (أو مُوقَّعة بشكل غير صحيح) من سجلك عند وقت القبول.

دمج التوقيع في خطوط أنابيب CI/CD

GitHub Actions مع التوقيع بدون مفاتيح

يتمتع GitHub Actions بدعم أصلي لـ OIDC، مما يجعله البيئة المثالية للتوقيع بدون مفاتيح. فيما يلي سير عمل كامل يبني ويدفع ويوقع صورة حاوية:

name: Build and Sign Container Image

on:
  push:
    branches: [main]

permissions:
  contents: read
  packages: write
  id-token: write  # Required for keyless signing

jobs:
  build-sign:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - 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 image
        id: build
        uses: docker/build-push-action@v6
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}

      - name: Install Cosign
        uses: sigstore/cosign-installer@v3

      - name: Sign the image
        env:
          DIGEST: ${{ steps.build.outputs.digest }}
        run: |
          cosign sign --yes \
            ghcr.io/${{ github.repository }}@${DIGEST}

النقاط الرئيسية:

صلاحية id-token: write تُفعِّل مزود OIDC لـ GitHub Actions، الذي يستخدمه Cosign للتوقيع بدون مفاتيح.
تُوقَّع الصورة بالخلاصة (digest) وليس بالعلامة (tag)، باستخدام مخرجات خطوة البناء.
لا حاجة لأسرار أو مفاتيح — رمز OIDC من GitHub هو الهوية.

مثال GitLab CI

يدعم GitLab CI أيضًا رموز OIDC للتوقيع بدون مفاتيح. النهج مشابه لكنه يستخدم آلية رمز المعرف الخاصة بـ GitLab:

stages:
  - build
  - sign

variables:
  IMAGE: ${CI_REGISTRY_IMAGE}:${CI_COMMIT_SHORT_SHA}

build:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker build -t $IMAGE .
    - docker push $IMAGE
    - echo "DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' $IMAGE | cut -d@ -f2)" >> build.env
  artifacts:
    reports:
      dotenv: build.env

sign:
  stage: sign
  image: alpine:3.19
  id_tokens:
    SIGSTORE_ID_TOKEN:
      aud: sigstore
  before_script:
    - apk add --no-cache cosign
  script:
    - cosign sign --yes ${CI_REGISTRY_IMAGE}@${DIGEST}

كتلة id_tokens تُوجِّه GitLab لتوليد رمز OIDC بالجمهور sigstore. يلتقط Cosign الرمز من متغير البيئة SIGSTORE_ID_TOKEN تلقائيًا.

تخزين التوقيعات في سجلات OCI

افتراضيًا، يُخزِّن Cosign التوقيعات في نفس سجل OCI الذي يحتوي على الصورة المُوقَّعة. يُدفع التوقيع كعلامة منفصلة وفقًا للاصطلاح sha256-<digest>.sig. هذا يعني:

لا حاجة لبنية تحتية إضافية لتخزين التوقيعات.
تنتقل التوقيعات مع الصورة عند النسخ المتطابق أو التكرار.
معظم السجلات الرئيسية (GHCR، Docker Hub، ECR، GCR، ACR، Harbor) تدعم عناصر OCI وتعمل مع Cosign مباشرة.

إذا كنت بحاجة لتخزين التوقيعات في سجل مختلف (مثل مخزن توقيعات مخصص)، يمكنك استخدام متغير البيئة COSIGN_REPOSITORY:

export COSIGN_REPOSITORY=ghcr.io/myorg/signatures
cosign sign --yes ghcr.io/myorg/myapp@sha256:abc123...

الشهادات (Attestations) وإرفاق قوائم مكونات البرمجيات (SBOMs)

تُثبت التوقيعات مَن بنى الصورة. أما الشهادات (attestations) فتذهب أبعد من ذلك — تُثبت كيف بُنيت وماذا تحتوي. يدعم Cosign إرفاق بيانات وصفية منظمة بالصور في شكل شهادات in-toto.

إرفاق إثبات مصدر SLSA باستخدام `cosign attest`

يصف إثبات مصدر SLSA (Supply-chain Levels for Software Artifacts) عملية البناء: ما المصدر المستخدم، ما المُنشئ الذي عمل، ما الخطوات التي نُفِّذت. يمكنك إرفاق شهادة إثبات مصدر SLSA بالصورة:

# Create a provenance statement (simplified example)
cat > provenance.json <<'EOF'
{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "ghcr.io/myorg/myapp",
      "digest": {
        "sha256": "abc123..."
      }
    }
  ],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://github.com/myorg/myapp/.github/workflows/release.yml",
      "resolvedDependencies": [
        {
          "uri": "git+https://github.com/myorg/myapp@refs/heads/main",
          "digest": {
            "sha1": "def456..."
          }
        }
      ]
    },
    "runDetails": {
      "builder": {
        "id": "https://github.com/actions/runner"
      }
    }
  }
}
EOF

# Attest the image with the provenance statement (keyless)
cosign attest --yes \
  --predicate provenance.json \
  --type slsaprovenance \
  ghcr.io/myorg/myapp@sha256:abc123...

في الممارسة العملية، ستستخدم مُولِّد SLSA (مثل slsa-github-generator) لإنتاج إثبات المصدر تلقائيًا بدلاً من صياغته يدويًا.

إرفاق قوائم مكونات البرمجيات (SBOMs)

قائمة مكونات البرمجيات (SBOM) تسرد كل مكون داخل صورة الحاوية. يمكن لـ Cosign إرفاق SBOM بالصورة حتى يتمكن المستهلكون من فحص محتوياتها:

# Generate an SBOM using Syft
syft ghcr.io/myorg/myapp@sha256:abc123... -o spdx-json > sbom.spdx.json

# Attach the SBOM as an attestation (recommended approach)
cosign attest --yes \
  --predicate sbom.spdx.json \
  --type spdxjson \
  ghcr.io/myorg/myapp@sha256:abc123...

بدلاً من ذلك، يمكنك استخدام أمر cosign attach sbom الأقدم، رغم أن نهج الشهادات مُفضَّل لأنه مُوقَّع وقابل للتحقق:

# Older approach (attached but not signed)
cosign attach sbom --sbom sbom.spdx.json \
  ghcr.io/myorg/myapp@sha256:abc123...

التحقق من الشهادات (Attestations)

يمكن للمستهلكين التحقق من الشهادات تمامًا مثل التوقيعات. يتحقق أمر cosign verify-attestation من كل من التوقيع على الشهادة وهوية المُوقِّع:

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

# Verify SBOM attestation
cosign verify-attestation \
  --type spdxjson \
  --certificate-identity "https://github.com/myorg/myapp/.github/workflows/release.yml@refs/heads/main" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/myorg/myapp@sha256:abc123...

يمكنك أيضًا استخدام محركات السياسات مثل Kyverno للتحقق من الشهادات عند وقت القبول، مما يضمن نشر الصور ذات إثبات المصدر الصالح أو SBOMs فقط في مجموعاتك.

اعتبارات الأمان والمقايضات

توقيع العناصر البرمجية أداة قوية، لكن من المهم فهم ما يحمي منه وما لا يحمي منه.

ما يحمي منه التوقيع

التلاعب بعد البناء — إذا عدَّل شخص ما صورة بعد توقيعها، فلن يعود التوقيع صالحًا للتحقق. يكشف هذا عن اختراقات السجل وهجمات الوسيط والتلف العرضي.
انتحال الهوية — مع التوقيع بدون مفاتيح، تُربط هوية المُوقِّع تشفيريًا بالتوقيع. لا يستطيع المهاجم تزوير توقيع يدّعي أنه من خط أنابيب CI الخاص بك دون اختراق مزود OIDC.
الإنكار — يوفر سجل شفافية Rekor سجلاً مقاومًا للتلاعب لأحداث التوقيع. لا يمكن للمُوقِّعين إنكار توقيعهم لعنصر برمجي.

ما لا يحمي منه التوقيع

الشفرة المصدرية الخبيثة — يُثبت التوقيع أن الصورة بُنيت بواسطة خط أنابيب مُخوَّل. لا يُثبت أن الشفرة المصدرية خالية من الثغرات أو الأبواب الخلفية. حساب مطور مخترق يدفع شفرة خبيثة سينتج صورة مُوقَّعة بشكل شرعي.
بيئات البناء المخترقة — إذا اختُرق مُشغِّل CI نفسه (كما في سيناريو SolarWinds)، يمكن للمهاجم إنتاج عناصر برمجية مُوقَّعة. يُثبت التوقيع الهوية، لا سلامة بيئة البناء.
الثغرات في التبعيات — يمكن أن تحتوي صورة مُوقَّعة على ثغرات CVE معروفة. التوقيع وفحص الثغرات متكاملان وليسا بديلين.
تجاوز السياسات — يعمل التوقيع فقط إذا فُرض التحقق. إذا كانت وحدة التحكم بالقبول لديك بها استثناءات، أو إذا كانت الفرق تنشر دون المرور عبرها، فلا يوفر التوقيع حماية لتلك المسارات.

افتراضات نموذج الثقة

يعتمد التوقيع بدون مفاتيح على عدة افتراضات ثقة:

الثقة في مزود OIDC — أنت تثق بأن GitHub أو GitLab أو Google يُصادق الهويات بشكل صحيح. اختراق مزود OIDC يُقوِّض النموذج بأكمله.
الثقة في Fulcio — أنت تثق بأن مثيل Fulcio في Sigstore يتحقق من رموز OIDC بشكل صحيح ويُصدر شهادات فقط للهويات المُصادَق عليها.
الثقة في Rekor — أنت تثق بأن سجل الشفافية قابل للإلحاق فقط ومقاوم للتلاعب. مثيل Rekor العام في Sigstore يُشغَّل بواسطة المجتمع؛ للبيئات عالية الضمان، قد ترغب في تشغيل مثيلك الخاص.

للمنظمات ذات متطلبات الامتثال الصارمة، يوفر تشغيل بنية Sigstore تحتية خاصة (جهة إصدار شهادات Fulcio خاصة، سجل Rekor خاص) تحكمًا كاملاً في سلسلة الثقة.

اعتبارات إدارة المفاتيح

إذا اخترت التوقيع المبني على المفاتيح بدلاً من التوقيع بدون مفاتيح:

خزِّن المفاتيح الخاصة في KMS (مثل AWS KMS أو GCP KMS أو Azure Key Vault أو HashiCorp Vault). يتمتع Cosign بدعم أصلي لـ KMS: cosign sign --key awskms:///arn:aws:kms:...
دوِّر المفاتيح وفق جدول منتظم وضع خطة للإلغاء.
تجنب تخزين المفاتيح الخاصة كأسرار CI/CD — عادة ما تُسجَّل وتُخزَّن مؤقتًا وتُنسخ بطرق تزيد من التعرض.
استخدم مفاتيح منفصلة لبيئات مختلفة (التجهيز مقابل الإنتاج) لتقليل نطاق الضرر.

الخلاصة

يُعدّ توقيع صور الحاويات باستخدام Sigstore و Cosign من أكثر الخطوات تأثيرًا التي يمكنك اتخاذها نحو تأمين سلسلة توريد البرمجيات. لم يعد الأمر صعبًا، ولم يعد يتطلب خبرة عميقة في التشفير، ولم يعد يستدعي بنية تحتية معقدة لإدارة المفاتيح. مع التوقيع بدون مفاتيح، يمكن لخط أنابيب CI/CD توقيع كل صورة ينتجها بدون أسرار لإدارتها وبقابلية تدقيق كاملة من خلال سجل شفافية Rekor.

لكن التوقيع هو لبنة بناء وليس حلاً سحريًا. يُجيب على سؤال "هل أُنتجت هذه الصورة بواسطة عملية مُخوَّلة؟" لا يُجيب على "هل هذه الصورة آمنة للتشغيل؟" تجمع استراتيجية أمان سلسلة التوريد الكاملة بين التوقيع وفحص الثغرات وتوليد SBOMs وإثبات مصدر SLSA وفرض السياسات عند القبول ومراقبة الأمان أثناء التشغيل وضوابط الوصول الصارمة على مستودعات المصدر وبنية البناء التحتية.

ابدأ بإضافة cosign sign --yes إلى خط أنابيب CI/CD الخاص بك. ثم أضف التحقق في وحدة التحكم بالقبول. ثم أضف طبقة الشهادات و SBOMs. كل خطوة تُضيِّق الفجوة بين بناء البرمجيات والوثوق بها.

الأدوات ناضجة، والمنظومة تنمو، وتكلفة عدم التوقيع أصبحت أصعب في تبريرها. لم يعد السؤال هل توقِّع عناصرك البرمجية — بل كم بسرعة يمكنك جعله الخيار الافتراضي.