Sigstore وثورة سجلات الشفافية

Sigstore مجموعة من الأدوات مفتوحة المصدر، هي Cosign للتوقيع، وFulcio بوصفه سلطة الشهادات، وRekor بوصفه سجل الشفافية، توفر مجتمعةً بنية لأمن سلسلة توريد البرمجيات لم تكن متاحة سابقًا إلا للمؤسسات الكبيرة التي لديها فرق PKI مخصصة. ويتمثل الابتكار الجوهري في Sigstore في التوقيع دون مفاتيح: فبدلًا من مطالبة المطورين بإدارة مفاتيح توقيع خاصة طويلة الأمد (يمكن أن تُسرق أو تُفقد أو تُنسى)، يستخدم Sigstore شهادات قصيرة الأمد تصدر عند الحاجة لكل عملية توقيع، وترتبط بهوية OIDC للموقّع (GitHub Actions أو CI في GitLab أو هوية Google Cloud). وعند اكتمال التوقيع تنتهي صلاحية الشهادة، فلا يوجد مفتاح خاص دائم يتعين حمايته.

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

يتسع نطاق الاعتماد بسرعة. فقد أعلنت منظومات npm وPyPI وMaven Central عن التوقيع القائم على Sigstore لحزمها أو طبّقته. واعتمدت Sigstore كل من Linux Foundation وCNCF ومشروع Kubernetes. وبنت GitHub تكامل Sigstore في GitHub Actions. والأثر العملي لممارسي TPRM هو أن سؤال المورّد عمّا إذا كان يستخدم Sigstore (أو ما يعادله) أصبح على نحو متزايد سؤالًا إجابته نعم أو لا، وترتبط بنضج أمن سلسلة توريد البرمجيات.

لماذا يهم هذا

يهمّ Sigstore TPRM لأنه يوفر معيارًا مجانيًا ومتاحًا لتوقيع سلسلة توريد البرمجيات وشفافيتها، يزيل العائق التقني أمام اعتماده لدى الموردين الأصغر. والمورّد الذي لم يعتمد Sigstore أو ما يعادله في وقت تعتمده فيه منظومة npm افتراضيًا هو مورّد تتأخر استثماراته في أمن سلسلة توريد البرمجيات عن المعيار الحالي للممارسة، ليس بالضرورة مخترقًا، لكنه متأخر.

• غياب الوعي بـSigstore في تقييم أمن سلسلة توريد البرمجيات لدى الموردين
• التوقيع التقليدي بالمفاتيح الخاصة: مفاتيح طويلة الأمد دون شهادات Sigstore قصيرة الأمد
• غياب سجل الشفافية: أحداث التوقيع غير مسجلة في سجل تدقيق عام غير قابل للتغيير
• أعباء إدارة المفاتيح التي تمنع الموردين الصغار من اعتماد التوقيع
• اعتماد Sigstore بوصفه مؤشرًا على نضج أمن سلسلة التوريد

كيف تبدو الممارسة الجيدة

تعتمد برامج التوقيع الناضجة في سلسلة التوريد Sigstore لإصدارات البرمجيات الجديدة، وتحديدًا cosign للتوقيع وRekor للتحقق عبر سجل الشفافية، وتُدرج حالة اعتماد Sigstore سؤالًا ضمن تقييم أمن سلسلة التوريد لدى الموردين.

• استخدام Sigstore cosign لتوقيع البرمجيات، بدلًا من التوقيع التقليدي بالمفاتيح الخاصة
• التسجيل في سجل الشفافية Rekor: سجل تدقيق عام غير قابل للتغيير
• التوقيع دون مفاتيح عبر هوية OIDC في CI/CD، دون مفتاح خاص دائم
• تحقق المستهلك عبر cosign verify مقابل Rekor
• حالة اعتماد Sigstore في تقييم سلسلة التوريد لدى الموردين

الأدوات

Sigstore: أداة cosign للتوقيع والتحقق، وFulcio بوصفه سلطة الشهادات، وRekor بوصفه سجل الشفافية (sigstore.dev)

أدوات Sigstore متاحة مجانًا وتتكامل مع جميع منصات CI/CD الرئيسية. ويوقّع إجراء cosign في GitHub Action المخرجات ويسجلها في Rekor في خطوة واحدة دون الحاجة إلى إدارة المفاتيح. وبالنسبة لممارسي TPRM، فإن التحقق من وجود إصدارات المورّد في سجل Rekor العام يوفر تأكيدًا مستقلًا لاعتماد Sigstore دون الحاجة إلى إقرار من المورّد.

تحديات الحوكمة

يتمثل تحدي الحوكمة في Sigstore في مرحلة الانتقال إلى الاعتماد: فالموردون الذين لديهم بنية توقيع قائمة يحتاجون إلى الانتقال إلى Sigstore دون تعطيل العملاء الذين بنوا التحقق في مسارات النشر لديهم. ويكمن حل الحوكمة في الاعتماد المتوازي: توقيع Sigstore إلى جانب التوقيعات القائمة خلال فترة انتقالية، مع جدول زمني محدد لانتقال العملاء.

• افحص Rekor بحثًا عن إصدارات المورّد: تحقّق من الاعتماد بشكل مستقل
• اسأل الموردين الذين يستخدمون التوقيع التقليدي عن خارطة طريق اعتماد Sigstore
• أدرج اعتماد Sigstore في تقييم أمن سلسلة توريد البرمجيات
• أشِر إلى Sigstore في متطلبات أمن سلسلة التوريد لدى الموردين
• راقب اعتماد منظومتي npm وPyPI للتحقق من الحزم القائم على Sigstore

إذا كنت فريقًا صغيرًا

بالنسبة لأهم ثلاثة موردي برمجيات لديك، افحص سجل الشفافية Rekor التابع لـSigstore (rekor.sigstore.dev) بحثًا عن قيود مرتبطة بإصداراتهم. فإن كانت إصداراتهم في Rekor، فقد اعتُمد Sigstore. وإن لم تكن، فاسأل المورّد عن نهج التوقيع الحالي لديه وعمّا إذا كانت لديه خطة لاعتماد Sigstore. ويستغرق فحص Rekor دقائق، ويوفر تحققًا مستقلًا من اعتماد Sigstore لا يستطيع تأكيد الاستبيان توفيره.

• افحص سجل الشفافية Rekor بحثًا عن قيود إصدارات المورّد
• اسأل عن نهج التوقيع لدى الموردين غير المسجلين في Rekor
• أدرج حالة اعتماد Sigstore في تقييم سلسلة التوريد لدى الموردين
• أشِر إلى Sigstore في متطلبات التوقيع ضمن عقود الموردين

ما الذي ينبغي اشتراطه

اسأل مباشرةً:

"هل توقّعون إصدارات برمجياتكم باستخدام Sigstore cosign مع التسجيل في سجل الشفافية Rekor؟ وإن لم يكن كذلك، فما نهج التوقيع الحالي لديكم، وما جدولكم الزمني لاعتماد توقيع Sigstore دون مفاتيح؟"

ما تتوقعه دليلًا

• تأكيد اعتماد Sigstore cosign أو خارطة الطريق لاعتماده
• التحقق من قيود سجل Rekor للإصدارات الحديثة
• نهج التوقيع الحالي وإدارة المفاتيح إن لم يكن Sigstore
• الجدول الزمني للانتقال إلى التوقيع دون مفاتيح

ينبغي سؤال المورّد الذي يؤكد توقيع الشيفرة عمّا إذا كان ذلك التوقيع يشمل تسجيل الشفافية في Sigstore. فالتوقيع يؤكد أن المفتاح وقّع المخرَج، وتسجيل Rekor يؤكد حدث التوقيع في سجل تدقيق عام غير قابل للتغيير. ويوفر الجمع بينهما ضمان التوقيع في سلسلة التوريد الذي لا يستطيع التوقيع بالمفتاح الخاص وحده تحقيقه.

كيف تُثبت ذلك

• التحقق عبر Rekor من إصدارات الموردين الحيويين
• تقييم اعتماد Sigstore
• تقييم نهج التوقيع لدى الموردين الذين لا يستخدمون Sigstore
• تتبّع خارطة طريق اعتماد Sigstore

الخلاصة الرئيسية

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