استخدام Valint لتطبيق السياسات على SDLC الخاص بك

Valint هي أداة Scribe الرئيسية لإنشاء الأدلة وإدارتها وتوقيعها والتحقق منها. في السابقة آخر، قمنا بتغطية نظرية استخدام التوقيع والتحقق من الأدلة كأداة رئيسية للتحقق من أمان خط أنابيب CI/CD الخاص بك. كتذكير قصير، يتضمن نموذج Scribe المقترح العديد من العناصر الأساسية التي يمكن خلطها وتكديسها بأي طريقة تناسب احتياجاتك. تتضمن اللبنات الأساسية الأدلة التي تم جمعها (SBOMS, SLSA المصدر، وأي نتائج اختبار تابعة لجهة خارجية ترغب في تضمينها)، والسياق البيئي للأدلة التي تم جمعها (من قام بإنشائها وأين ومتى وما إلى ذلك)، والسياسة التي ترغب في تطبيقها على تلك الأدلة.

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

في هذه المقالة، سنتناول السياسة الأساسية التي ابتكرناها (التوقيع والتحقق من المعلومات). سنغطي الشكل الذي يبدو عليه قالب السياسة الأكثر تعقيدًا وسنقدم بعض الأمثلة القياسية للسياسات مثل كيفية التحقق من أن مستخدمًا معينًا هو الذي أنشأ آخر فرع "رئيسي"، أو كيفية التحقق من تشغيل المسار الخاص بك يتضمن اختبار أداة الطرف الثالث الذي يجب تضمينه.

ابدأ هنا: التوقيع والتحقق من الأدلة

فالينت هي أداة متعددة الاستخدامات ولكن لتبسيط هذه المقالة، سنستخدم بشكل أساسي واجهة Valint's CLI كمثال.

ستكون الخطوة الأولى هي تنزيل Valint:

curl -sSfL https://get.scribesecurity.com/install.sh | sh -s -- -t valint

الأمر الخاص بإنشاء SBOM من مستودع أو صورة هو "bom". لذلك، على سبيل المثال، إذا كنت ترغب في ذلك bom صورة busybox:latest سيبدو الأمر هكذا:

$HOME/.scribe/bin/valint bom busybox:latest -o attest -f

نلاحظ أن attest هو اسم مستعار ل attest-cyclonedx-json.

بشكل افتراضي، يستخدم Valint سيجستور التدفق التفاعلي باعتباره المحرك وراء آلية التوقيع المضمنة في مكتبة Scribe's Cocosign. تتعامل هذه المكتبة مع التوقيعات الرقمية للتوقيع والتحقق. بمجرد تطبيق الأمر، ستحتاج أولاً إلى الموافقة على رغبتك في التوقيع على الدليل باستخدام خيار Y/[N]:

يمكنك أيضًا استخدام PKI القياسي للتوقيع (نحن ندعم شهادات x509). هناك خيارات متعددة لتخزين مفتاح التوقيع - على سبيل المثال KMS، ومخزن GitHub السري، ويمكنك بسهولة تكوين Valint لاستخدام أي آلية توقيع ترغب فيها.

بافتراض موافقتك على التوقيع، سيتم توجيهك إلى Sigstore في متصفحك حيث ستحتاج إلى تسجيل الدخول باستخدام حساب GitHub الخاص بك، أو حساب Google الخاص بك، أو حساب Microsoft الخاص بك:

بمجرد تسجيل الدخول سترى أن تسجيل الدخول كان ناجحًا:

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

تتم كتابة الشهادة افتراضيًا إلى ذاكرة التخزين المؤقت المحلية التي يتم توفير موقعها بواسطة ملف --output-directory العلم في ملف التكوين العلم. يمكنك أيضًا استخدام -ملف إلاخراج علامة لتوفير مسار مخصص للشهادة.

الآن بعد أن أنشأنا شهادة موقعة، فلنحاول التحقق من وجودها وتوقيعها. الأمر بالتحقق من الأدلة هو verify. وطريقة استخدامه متطابقة تقريبا مع bom الأمر إلا أننا سنستخدم العلم -iوهو اختصار ل --input-format والافتراضي لذلك هو، كما في bom, تشهد-cyclonedx-json. سيبحث أمر التحقق أولاً عن الدليل الذي يحتاجه في الموقع الافتراضي الذي تستخدمه Valint. يمكنك تحديد موقع مختلف إذا كنت تريد حفظ الدليل والبحث عنه لاحقًا.

لذلك، إذا أردنا التحقق من busybox:latest شهادة الصورة التي قمنا بإنشائها وتوقيعها في المثال السابق سيبدو الأمر كما يلي:

$HOME/.scribe/bin/valint verify busybox:latest -i attest

بافتراض أنك فعلت كل شيء بشكل صحيح، يجب أن تبدو النتيجة كما يلي:

يمكنك الاطلاع على قائمة رسائل البريد الإلكتروني التي تتضمن البريد الإلكتروني للموقع على المصادقة الأصلية ويمكنك أيضًا رؤية نوع المصادقة التي تم التحقق منها، في هذه الحالة، cyclonedx-json. 

يبدو واضحا جدا أليس كذلك؟ دعونا ركلة الأمر إلى أعلى درجة.

قوالب السياسة

A سياسة يتكون من مجموعة من وحدات. يتم التحقق من السياسة إذا تم تقييم جميع الوحدات التي تتضمنها والتحقق منها. يتم التحقق من الوحدة إذا تم العثور على أي دليل يتوافق مع تكوين الوحدة وإعداداتها.  

يتم تكوين السياسات كجزء من ملف تكوين Valint، ضمن قسم السياسات. هذا مثال لجزء من ملف تكوين Valint، الجزء الذي يحتوي على السياسات المحتملة. 

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

يجب تضمين ملف التكوين، المسمى بشكل افتراضي .valint.yaml، في جذر مستودعك. بناءً على السياسات التي تقوم بتضمينها في هذا الملف، عند تشغيل الأمر valint verify سيتم تشغيل أي سياسات ووحدات نمطية ممكّنة. نظرًا لأن سياسة "التحقق" الأساسية هي السياسة الافتراضية، فلن يتعين عليك تكوين أي شيء لـ verify الأمر للعمل بشكل صحيح حتى بدون ملف .valint.yaml.

أيًا كانت السياسة التي تضيفها إلى ملف التكوين، فهي تعتمد على وجود دليل للبحث عنه. افتراضيًا، عند تشغيل الأمر 'bom' في المسار الخاص بك، سيتم تحميل الدليل الناتج إلى مخزن أدلة Scribe. وبالمثل، عند تشغيل أمر "التحقق"، فإنه سيبحث عن الدليل في مخزن أدلة Scribe. يمكنك تغيير هذا الإعداد الافتراضي واستخدام OCI أو ذاكرة التخزين المؤقت كمخزن للأدلة، ولكن بالنسبة لهذه المقالة، سنفترض أنه تم استخدام الإعداد الافتراضي ويتم تحميل جميع الأدلة وسحبها من مخزن أدلة Scribe.

لذلك، بناءً على هذا المثال، دعونا نلقي نظرة على مكونات السياسة. ال سياسة يدعم الحقول التالية:

• الاسم، اسم السياسة (مطلوب).
• تمكين، قم بتمكين الوحدة (الافتراضي هو خطأ).
• نماذج، قائمة تكوينات وحدة السياسة.  

 

إنّ وحدة الأقسام تدعم المجالات التالية:

• الاسم، اسم وحدة السياسة (مطلوب).
• تمكين، قم بتمكين الوحدة (الافتراضي هو خطأ).
• نوع، نوع الوحدة الداعمة حاليًا التحقق من قطعة أثرية git-owner.
• مباراة، تطابق الأدلة مع سياق محدد.
• إدخال، التكوين الخاص بالوحدة النمطية.

يمكن أن تحتوي السياسة على وحدات متعددة وسيتم تشغيل جميع الوحدات الممكّنة بمجرد تنفيذ أمر "التحقق". 

وبما أنني أعلم أن القائمة الجافة للحقول ليست مفيدة للغاية، فلننتقل مباشرة إلى القسم التالي، عينة السياسات.

سياسات العينة

سياسة التحقق من الصورة

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

تشهد: cocosign: السياسات: - الاسم: Vere_policy تمكين: الوحدات النمطية الحقيقية: - الاسم: Sign_sbom النوع: التحقق من قطعة أثرية تمكين: الإدخال الحقيقي: التوقيع: التنسيق الحقيقي: هوية attest-cyclonedx-json: رسائل البريد الإلكتروني: - barak@scribesecurity.com

مرة أخرى، يجب تضمين هذه السياسة في ملف .valint.yaml في جذر مستودعك. لكي يعمل، ستحتاج إلى إنشاء SBOM موقع مسبقًا عن طريق تشغيل ملف valint bom يأمر. بمجرد أن تصبح جاهزًا للتحقق من ذلك، ستحتاج إلى تشغيل valint verify أمر.

بالنظر إلى هذا المثال، يمكننا أن نرى أن السياسة ممكّنة وأنها تحتوي على وحدة نمطية واحدة ممكّنة من النوع ‘verify-artifact‘. تتحقق الوحدة من توقيع الإدخال ومن تنسيقه ‘attest-cyclonedx-json’, وأنه تم التوقيع عليه بالهوية التي يمثلها البريد الإلكتروني ‘barak@scribesecurity.com’.

لتشغيل هذه السياسة، سنحتاج إلى تنفيذ verifyالأمر في خط أنابيبنا مثل هذا:

valint verify busybox:latest

منذ verify يعتمد الأمر الآن على السياسة التي قدمناها وسيبحث عن ملف busybox:latest قطعة من الأدلة في متجر أدلة Scribe الخاص بك. سوف يبحث عن تنسيق SBOM موقع `cyclonedx-json` وسيتم التحقق من أن الهوية التي وقعت على SBOM تستخدم البريد الإلكتروني المنصوص عليه في السياسة `barak@scribesecurity.com`.

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

            المطابقة: context_type: github git_url: github.com/my_org/myimage.git الفرع: الرئيسي

في هذه الحالة، يجب أن يكون الدليل قد تم إنشاؤه بواسطة Github، بواسطة المستودع المسمى بواسطة git_url وقبل main فرع من هذا المستودع. من المهم استخدام السياق الصحيح عند الحاجة للتأكد من أن سياساتك تتحقق بالضبط مما تريد التحقق منه. 

سياسة التحقق الثنائي

دعونا نفحص مثالا آخر. تهدف هذه السياسة إلى التحقق من أن ملف exe الذي نتحقق منه يأتي من مستودع محدد وتم توقيعه بواسطة أحد الأفراد المعروفين. 

تشهد: cocosign: السياسات: - الاسم: Verify_policy تمكين: الوحدات النمطية الحقيقية: - الاسم: نوع Binary_module: التحقق من الأداة الأثرية تمكين: الإدخال الحقيقي: التوقيع: التنسيق الحقيقي: هوية attest-cyclonedx-json: رسائل البريد الإلكتروني: - barak@scribesecurity.com - mikey@scribesecurity.com - adam@scribesecurity.com match: target_type: file context_type: azure git_url: https://dev.azure.com/mycompany/somerepo # Git url للبيئة. اسم الإدخال: my_binary.exe

بالنظر إلى هذا المثال، يمكننا أن نرى أن السياسة ممكّنة وأنها تحتوي على وحدة نمطية واحدة ممكّنة من النوع ‘verify-artifact‘ تتحقق الوحدة من توقيع الإدخال ومن أنه في التنسيق ‘attest-cyclonedx-json’, وأنه تم التوقيع عليه بواسطة 1 من 3 رسائل بريد إلكتروني مسموح بها مدرجة في الوحدة. بالإضافة إلى ذلك، فإنه يتحقق من أن verify يتلقى الأمر إدخالاً للتحقق من تسمية الإدخال ‘my_binary.exe’، أن الإدخال عبارة عن ملف تم إنشاؤه في Azure، وأنه جاء من عنوان URL محدد لـ git: https://dev.azure.com/mycompany/somerepo.

كما ترون، هناك الكثير من المتطلبات في هذا المثال للتحقق من السياسة.

لتشغيل هذه السياسة، سنحتاج إلى تنفيذ verify الأمر في خط أنابيبنا مثل هذا:

valint verify file:my_binary.exe

للتأكد من أن مخزن أدلة Scribe الخاص بك يحتوي على نسخة موقعة من هذا الملف الثنائي، يجب عليك أولاً إنشاء الدليل على النحو التالي:

valint bom file:my_binary.exe -o attest

سياسة التحقق من أدلة الطرف الثالث

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

تشهد: cocosign: السياسات: - الاسم: Verified_policy تمكين: الوحدات النمطية الحقيقية: - الاسم: نوع قاعدة الطرف الثالث: التحقق من الأداة الأثرية: الإدخال الحقيقي: التوقيع: التنسيق الخاطئ: الهوية العامة للشهادة: رسائل البريد الإلكتروني: - bob@scribesecurity. مطابقة com: target_type: نوع السياق العام: azure git_url: https://dev.azure.com/mycompany/somerepo git_branch: اسم الإدخال الرئيسي: 3rd-party-scan.json

في هذا المثال، نتخيل أنه في مرحلة ما من المسار، قمنا بتشغيل أداة تابعة لجهة خارجية والتي أدت، نتيجة لذلك، إلى إنشاء ملف `3rd-party-scan.json`. لتلبية السياسة، يجب أن يكون هذا الملف قد نشأ من Azure DevOps، والذي يتم تشغيله بواسطة الملف `https://dev.azure.com/mycompany/somerepo"المستودع وموقع من قبل".bob@scribesecurity.com`. 

لإنشاء الدليل الذي نبحث عنه، مباشرة بعد تشغيل أداة الطرف الثالث، نحتاج إلى التقاط الملف الناتج وتحويله إلى دليل باستخدام Valint:

valint bom 3rd-party-scan.json -o attest-generic --predicate-type https://scanner.com/scan_format

ماذا تثبت الأدلة؟ 

لذلك رأينا أنه يمكننا استخدام Valine للتحقق من أشياء مختلفة في خط أنابيبنا. ما الذي يمكن أن تستخدمه هذه القدرة حقًا؟

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

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

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