فاتورة مكونات البرمجيات SBOM: كيف تعرف ما الذي يختبئ داخل البرامج التي تستخدمها؟

 فاتورة مكونات البرمجيات SBOM: كيف تعرف ما الذي يختبئ داخل البرامج التي تستخدمها؟

عندما تشتري منتجًا غذائيًا، تستطيع قراءة المكونات المكتوبة على العبوة.

تعرف ما الذي يحتويه المنتج، وما المواد الداخلة في تصنيعه.

لكن ماذا عن التطبيقات والبرامج؟

قد يبدو التطبيق برنامجًا واحدًا، بينما يتكوّن في الحقيقة من عشرات أو مئات المكونات والمكتبات البرمجية التي كتبها مطورون وشركات مختلفة.

وهنا تظهر مشكلة مهمة:

ماذا لو اكتُشفت ثغرة أمنية في مكتبة صغيرة موجودة داخل آلاف البرامج؟

كيف تعرف الشركات بسرعة ما إذا كانت تستخدمها؟

من هنا ظهرت فكرة:

SBOM — Software Bill of Materials

أو:

قائمة مكونات البرمجيات.

وتعرّف NIST الـSBOM بأنها سجل رسمي يوضح مكونات البرنامج والعلاقات بينها، بطريقة تشبه قائمة المكونات الموجودة على المنتجات. 

لماذا البرنامج الواحد يحتوي على مكونات كثيرة؟

تطوير البرامج الحديثة لا يبدأ عادة من الصفر.

عندما يبني المطور تطبيقًا، قد يستخدم مكتبات جاهزة لتنفيذ وظائف مثل:

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

وهذا يوفر وقتًا هائلًا.

لكن النتيجة هي أن البرنامج النهائي قد يعتمد على سلسلة طويلة من المكونات.

قد يعتمد التطبيق على مكتبة.

وتعتمد المكتبة نفسها على مكتبة أخرى.

وهكذا تصبح لدينا سلسلة توريد برمجية Software Supply Chain.

ما المقصود بسلسلة توريد البرمجيات؟

في العالم الحقيقي، الهاتف الذي تشتريه لا تصنع شركة واحدة كل قطعة داخله.

هناك شركات للشرائح.

وأخرى للشاشات.

وأخرى للبطاريات.

شيء مشابه يحدث في البرمجيات.

قد يكون التطبيق تابعًا لشركة معينة، لكنه يستخدم:

مكتبات مفتوحة المصدر، حزمًا برمجية، أدوات تطوير وخدمات من جهات أخرى.

ولهذا تؤكد NIST أن أمن البرمجيات أصبح جزءًا أساسيًا من إدارة مخاطر سلسلة التوريد السيبرانية. 

ما هي SBOM بالضبط؟

يمكن تخيل SBOM كأنها:

بطاقة مكونات للتطبيق.

قد تتضمن معلومات مثل:

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

والهدف ليس عرض القائمة للمستخدم العادي في كل مرة يفتح فيها التطبيق.

بل منح الشركات وفرق الأمن رؤية أوضح لما يوجد داخل البرنامج.

وتوضح NIST أن SBOM تساعد في تحسين الشفافية ومعرفة أصل المكونات وتسريع اكتشاف الثغرات وإصلاحها. 

لماذا معرفة المكونات مهمة أمنيًا؟

تخيل أن باحثين اكتشفوا اليوم ثغرة خطيرة في مكتبة اسمها افتراضيًا:

Library X 3.2

تصل الأخبار إلى الشركات.

السؤال الأول يصبح:

هل نستخدم هذه المكتبة؟

شركة لديها SBOM منظمة تستطيع البحث داخل قائمة مكونات برامجها وتحديد الأنظمة المتأثرة بسرعة أكبر.

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

وهذا يضيع وقتًا مهمًا أثناء التعامل مع مشكلة أمنية.

مثال بسيط جدًا

تخيل مطعمًا يبيع 100 نوع من الوجبات.

وفجأة اكتُشف أن أحد المكونات الغذائية يجب سحبه.

إذا كان لدى المطعم سجل واضح للمكونات، يمكنه معرفة:

أي وجبات تحتوي عليه؟

أما إذا لم توجد سجلات، فسيتعين فحص كل وصفة واحدة تلو الأخرى.

SBOM تقوم بفكرة مشابهة، ولكن داخل البرامج.

هل SBOM تكشف الثغرة بنفسها؟

ليس بالضرورة.

وهذه نقطة مهمة.

SBOM تقول لك:

ما المكونات الموجودة؟

أما قواعد بيانات الثغرات وأدوات الأمن فتساعد على الإجابة عن:

هل توجد مشكلة معروفة في أحد هذه المكونات؟

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

أي أن القوة الحقيقية تظهر عندما نجمع:

قائمة المكونات + معلومات الثغرات + التحديث المستمر.

لماذا أصبحت البرامج مفتوحة المصدر جزءًا مهمًا من الموضوع؟

الكثير من التطبيقات الحديثة تستخدم مكونات مفتوحة المصدر.

وهذا ليس أمرًا سيئًا بحد ذاته.

البرمجيات مفتوحة المصدر تشكل أساسًا مهمًا جدًا من الإنترنت والتطبيقات الحديثة.

لكن المشكلة أن المؤسسة قد تستخدم مكونات كثيرة دون أن تمتلك رؤية كاملة حول:

من يحافظ عليها؟

ما الإصدار المستخدم؟

هل توقفت صيانتها؟

هل توجد ثغرة معروفة فيها؟

ولهذا تضع NIST فهم استخدام المكونات مفتوحة المصدر ومصدرها وسلامتها ضمن العناصر المهمة لأمن سلسلة توريد البرمجيات. 

وهل يمكن لمكتبة صغيرة أن تؤثر في آلاف البرامج؟

نعم.

هذه إحدى الخصائص المهمة لعالم البرمجيات.

قد تصبح مكتبة صغيرة شائعة للغاية لأنها تحل مشكلة محددة بكفاءة.

ثم تُستخدم داخل:

تطبيقات، خوادم، منتجات شركات وخدمات سحابية.

إذا ظهرت مشكلة فيها، قد يكون التأثير واسعًا جدًا.

وهذا يوضح لماذا لم يعد كافيًا أن تسأل الشركة:

هل الكود الذي كتبناه نحن آمن؟

بل يجب أن تسأل أيضًا:

وماذا عن الكود الذي نعتمد عليه ولم نكتبه نحن؟

ما الفرق بين SBOM ومضاد الفيروسات؟

مضاد الفيروسات يحاول اكتشاف برمجيات أو سلوكيات ضارة.

SBOM ليست أداة لمكافحة الفيروسات.

هي أقرب إلى خريطة.

تخبر فرق الأمن بمكونات النظام، ثم يمكن استخدام هذه الخريطة لاتخاذ قرارات أفضل.

مثلاً:

ظهر تحذير عن مكتبة معينة.

بدل فحص المؤسسة كاملة بلا اتجاه، يمكن البحث فورًا عن البرامج التي تحتوي عليها.

هل SBOM تمنع الاختراق؟

لا.

وجود قائمة مكونات لا يجعل البرنامج آمنًا تلقائيًا.

قد تمتلك شركة SBOM ممتازة لكنها تتأخر في تثبيت تحديث أمني.

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

أو تكون إعدادات الخادم ضعيفة.

لذلك SBOM هي جزء من استراتيجية أمنية أوسع وليست حلًا سحريًا.

وتضع NIST معها ممارسات أخرى مثل تقييم مخاطر الموردين وإدارة الثغرات والتحكم في مكونات المصادر المفتوحة. 

ما علاقة SBOM بعملية تطوير البرنامج؟

الأفضل ألا تنتظر الشركة انتهاء التطبيق ثم تحاول معرفة مكوناته.

يمكن إنشاء وتحديث SBOM أثناء بناء البرنامج نفسه.

تمر البرامج الحديثة عادة عبر مراحل مثل:

كتابة الكود، البناء، الاختبار، التغليف ثم النشر.

NIST توصي بدمج إجراءات أمن سلسلة التوريد داخل خطوط CI/CD التي تستخدمها فرق DevSecOps لبناء البرامج ونشرها. 

وهكذا يمكن تحديث قائمة المكونات تلقائيًا كلما تغير التطبيق.

ما هي CI/CD؟

هي طريقة يستخدمها المطورون لأتمتة مراحل تطوير البرامج.

بدل بناء كل إصدار يدويًا، تمر التغييرات عبر سلسلة من الخطوات الآلية:

بناء → اختبار → فحص → تجهيز → نشر.

وعندما تُدمج أدوات الأمن داخل هذه العملية، يظهر مفهوم:

DevSecOps

أي جعل الأمن جزءًا من دورة التطوير نفسها بدل إضافته في النهاية.

وهنا تستطيع SBOM أن تصبح واحدة من النتائج التي يتم توليدها مع كل إصدار.

وماذا عن مصدر البرنامج نفسه؟

معرفة اسم المكون ليست كل شيء.

نحتاج أحيانًا إلى معرفة:

من أين جاء؟

وهذا ما يسمى:

Provenance — مصدر أو منشأ البرنامج.

فقد يكون لدينا مكون بالاسم نفسه، لكن السؤال هو:

هل جاء من المصدر الرسمي؟

هل تم تعديله؟

هل مر عبر عملية البناء المتوقعة؟

ولهذا تدخل معلومات المنشأ والتوقيع والتحقق من البرمجيات ضمن الجهود الحديثة لحماية سلسلة التوريد.

لماذا أصبحت هجمات سلسلة التوريد مقلقة؟

لأن المهاجم لا يحتاج دائمًا إلى استهداف كل شركة بصورة منفصلة.

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

وهذا ما يجعل الثقة في المورد والمكونات ومسار البناء مهمة جدًا.

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

ما هي Dependency؟

من الكلمات التي ستظهر كثيرًا في هذا المجال:

Dependency — تبعية برمجية.

تعني أن برنامجك يحتاج إلى مكون آخر لكي يعمل.

فإذا كان تطبيقك يعتمد على مكتبة لتحليل الصور مثلًا، تصبح هذه المكتبة Dependency.

لكن هذه المكتبة قد تعتمد بدورها على مكتبة ثالثة.

ولهذا يمكن أن تتكون شجرة تبعيات معقدة جدًا.

SBOM تساعد على كشف هذه العلاقات بدل بقاء أجزاء منها غير مرئية.

هل يحتاج المستخدم العادي إلى إنشاء SBOM؟

لا.

هذا الموضوع موجه أكثر إلى:

المطورين، الشركات، المؤسسات، الموردين وفرق الأمن.

المستخدم العادي لن ينشئ قائمة مكونات لكل تطبيق في هاتفه.

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

هل SBOM مفيدة فقط للشركات الكبيرة؟

لا.

حتى مشروع برمجي صغير يمكن أن يعتمد على عشرات الحزم الخارجية.

وعندما تكبر المشاريع، يصبح تتبعها يدويًا أصعب.

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

لكن مستوى التطبيق المطلوب يختلف حسب حجم المشروع والمخاطر.

ماذا يحدث عند اكتشاف ثغرة جديدة؟

في نموذج أكثر نضجًا يمكن أن تكون العملية كالتالي:

1. تظهر ثغرة جديدة مرتبطة بمكون معين.

2. النظام يقارن المكون بقوائم SBOM.

3. يحدد التطبيقات التي تستخدم الإصدار المتأثر.

4. تُرتب الأنظمة حسب أهميتها وخطورتها.

5. يبدأ التحديث أو الاستبدال.

وهذا أسرع بكثير من السؤال اليدوي:

“هل لدينا هذا المكون في مكان ما؟”

وتوصي NIST بدمج SBOM مع قواعد بيانات الثغرات وآليات الإبلاغ لتلقي إشعارات المخاطر بسرعة. 

هل يمكن أن تصبح SBOM مثل ملصق المكونات على المنتجات؟

هذه بالفعل إحدى أشهر طرق شرح الفكرة.

NIST نفسها تشبه SBOM بقائمة المكونات الموجودة على الأغذية. 

لكنها ليست مطابقة تمامًا.

قائمة الطعام ثابتة نسبيًا.

أما البرامج فتتغير باستمرار.

قد يضاف مكون اليوم.

ويتم تحديث آخر غدًا.

ويتغير الإصدار بعد أسبوع.

ولهذا يجب أن تكون SBOM محدثة باستمرار وليس مجرد ملف يتم إنشاؤه مرة واحدة ثم نسيانه.

وما علاقة الذكاء الاصطناعي؟

أصبحت أنظمة AI نفسها تعتمد على سلاسل تقنية معقدة:

مكتبات، أطر عمل، حزم Python، نماذج، بيانات، أدوات تشغيل وخدمات خارجية.

ومع انتشار تطبيقات الذكاء الاصطناعي قد يصبح تتبع مكونات هذه الأنظمة ومصدرها أكثر أهمية.

وقد يتوسع مفهوم “قائمة المكونات” مستقبلًا ليشمل ليس فقط البرنامج التقليدي، بل أجزاء أوسع من منظومة AI نفسها.

وهذه زاوية يمكن أن تصبح موضوعًا مستقلًا لاحقًا.

هل يكفي أن تثق باسم الشركة؟

ليس دائمًا.

حتى الشركة الموثوقة قد تعتمد على مكونات من عشرات الجهات الأخرى.

وهذا هو الدرس الأساسي في Supply Chain Security:

أمن المنتج لا يعتمد فقط على الشركة التي يظهر اسمها على الشاشة.

بل على سلسلة كاملة من المكونات والموردين والأدوات التي شاركت في بنائه.

ماذا سيحدث مستقبلًا؟

قد يصبح من الطبيعي أن تطلب الشركات والمؤسسات:

SBOM قبل شراء البرامج.

دليلًا على ممارسات التطوير الآمن.

معلومات عن مصدر المكونات.

وطريقة واضحة للإبلاغ عن الثغرات.

NIST تضع بالفعل SBOM وتقييم الموردين وإدارة المكونات مفتوحة المصدر وإدارة الثغرات ضمن الممارسات الأساسية لأمن سلسلة توريد البرمجيات. 

وهذا يعني أن الأمن ينتقل من سؤال:

“هل هذا البرنامج آمن الآن؟”

إلى سؤال أكبر:

“كيف تم بناء هذا البرنامج، وما الذي بداخله، وهل نستطيع متابعة المخاطر طوال عمره؟”

الخلاصة

البرنامج الذي تراه كأيقونة واحدة قد يحتوي خلفها على شبكة ضخمة من المكونات.

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

وهنا تأتي SBOM.

فهي لا تمنع الثغرات، لكنها تمنح المؤسسات رؤية تساعدها على معرفة المكونات المتأثرة والاستجابة بسرعة أكبر عندما تظهر مشكلة.

وباختصار:

لا تستطيع حماية ما لا تعرف أنك تستخدمه.

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