توقيع SBOM: حل اللغز المتغير باستمرار

جميع المشاركات

لقد كتب الكثير من الكلمات في السنوات القليلة الماضية حول سبوم – فاتورة المواد البرمجية. مع كل هذا التعرض، يشعر الأشخاص أنهم يعرفون ما هو جيد بما يكفي لشرحه - إنها قائمة بمكونات البرامج، وهي مهمة للشفافية والأمن، وتساعد في كشف التبعيات العابرة. كل هذا صحيح.

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

وماذا عن مفهوم "المعلوم والمجهول"؟ إذا علم المطورون أنهم يفتقدون شيئًا ما، فيمكنهم إدخاله كـ "معروف-غير معروف" وملء الفراغات لاحقًا (أو عدم إدخاله على الإطلاق).

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

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

كل هذا جيد وجيد ولكن ما الفرق الذي سيحدث لأي شخص إذا لم يكن SBOM أو جزء من SBOM دقيقًا أو محدثًا قدر الإمكان؟ ما الذي يمكننا فعله للحفاظ على مصدر SBOM ودقته؟

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

ابدأ هنا: ما هو التوقيع المشفر على أي حال؟

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

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

كيف يعمل؟ تعتمد التوقيعات الرقمية على التشفير غير المتماثل حيث يكون لدى الكيان مفتاحين - مفتاح خاص ومفتاح عام. يتم ربط المفتاحين معًا بطريقة يمكن من خلالها التحقق من المستند الموقع بالمفتاح الخاص باستخدام المفتاح العام. ويعني التحقق عدم التلاعب بالمستند بأي شكل من الأشكال (حتى تغيير جزء واحد من شأنه أن يجعل التوقيع غير قابل للتحقق)، وإثبات هوية الموقّع، أو على الأقل هوية المفتاح المستخدم.

ماذا تفعل بهذا SBOM؟ 

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

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

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

يعتبر كل هذا العمل وتوثيق الثغرات الأمنية وعلاجها أمرًا مهمًا بالنسبة لك كمنتج برامج، ولكنه مهم أيضًا لعملائك وشركائك والمدققين المحتملين. 

إنهم يريدون أن يعرفوا أنك على دراية بنقاط الضعف المحتملة وأنك على رأسها، وتقوم بتصحيح العيوب وتصحيحها، بحيث لا تؤثر عليهم كعملاء أو شركاء لك.

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

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

أين أوقع؟

الآن دعونا نستبدل ملف قائمة المكونات البسيط هذا بإحدى حالات الاستخدام الأكثر تعقيدًا الموضحة في بداية المقالة. بمجرد دمج عدة SBOMs لتكوين نسخة مجمعة أكبر لوصف القطعة الأثرية الكاملة، يصبح التوقيع والتحقق من كل جزء فردي من تلك النسخة المجمعة أكثر أهمية من أي وقت مضى. لنفترض أنك تقوم ببناء إصدار جديد من قطعة أثرية برمجية معقدة. في هذا الإصدار الجديد، الشيء الوحيد الذي تغير هو الجزء الأول من قطعة أثرية مكونة من 1 أجزاء. يتم ترك الجزأين الآخرين كما هو تمامًا. لماذا يجب عليك إضاعة الوقت والموارد في بناء SBOM الكامل المكون من ثلاثة أجزاء، وفحص الثلاثة جميعًا بحثًا عن نقاط الضعف ورسم الخرائط الثلاثة جميعًا بحثًا عن عمليات الاستغلال ذات الصلة؟ كانت التغييرات الوحيدة في الجزء الأول، لذا فهذا هو الجزء الوحيد الذي يجب أن تضع العمل فيه. إذا قمت بالتوقيع على جميع SBOMs الثلاثة وعمليات فحص الثغرات الأمنية في المرة الأخيرة التي قمت بإنشائها، فيمكنك تضمين معلومات الجزأين الآخرين مع العلم أنه لا يمكن ذلك. لم يتم تعديلها. يمكنك بعد ذلك أن تثبت في أي وقت أن SBOMs للأجزاء 3 و3 متطابقة مع الإصدارات الأصلية. يمكنك بالطبع إجراء عمليات الفحص مرة أخرى إذا كنت قلقًا بشأن الثغرات الأمنية الجديدة، ولكن هذا الأمر متروك لك ولبرنامجك تمامًا تحليل المخاطر

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

صورة تمثل الملاذ الآمن

أين أذهب من هنا 

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

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

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

يتم تقديم هذا المحتوى إليك بواسطة Scribe Security، وهي شركة رائدة في مجال توفير حلول أمان سلسلة توريد البرامج الشاملة - حيث توفر أحدث الأمان لعناصر التعليمات البرمجية وعمليات تطوير التعليمات البرمجية وتسليمها عبر سلاسل توريد البرامج. تعرف على المزيد.