يستخدم المطورون بشكل روتيني كود الطرف الثالث لبناء تطبيقاتهم من أجل تحقيق الكفاءة وتوفير الوقت. ومع ذلك، فإن هذا الاعتماد على المكونات الخارجية، لا سيما البرمجيات مفتوحة المصدر (OSS)، ينطوي على مخاطر كبيرة، بما في ذلك الثغرات الأمنية ومشاكل الترخيص. وفقاً لاستطلاع GitHub لعام 2023، يعتبر 31% من المطورين أن العثور على الثغرات الأمنية وإصلاحها ثاني أهم مهمة لهم بعد كتابة التعليمات البرمجية (32%).
وبالتالي، فإن العديد من المؤسسات تشعر بالقلق بشأن اعتمادها على برمجيات المصدر المفتوح حيث يتم استهدافها بشكل متكرر من قبل القراصنة. وتواجه المؤسسات تحديات مع زيادة نقاط الضعف في سلسلة توريد البرمجيات وفهم كيفية التخفيف من المخاطر بفعالية في أعقاب الهجمات الأخيرة التي تعرضت لها.
كشف تقرير بحثي صادر عن شركة ESG أن 91% من المؤسسات تعرضت لحوادث في سلسلة توريد البرمجيات خلال الأشهر الـ 12 الماضية. وتشمل الحوادث الأكثر شيوعًا ما يلي:
وقد أدت الثغرات البارزة مثل Log4J و Curl و Apache Struts و OpenSSL إلى العديد من حالات الضرر التشغيلي. وهي تسلط الضوء على التأثير الشديد الذي تتعرض له المؤسسات عند استغلال نقطة ضعف واحدة في سلسلة توريد البرمجيات. استجابةً لهذه المخاطر المتزايدة، تشدد الهيئات التنظيمية حول العالم على شفافية البرمجيات وأمنها. إن اعتماد Software Bill of Materials (SBOM) استراتيجية رئيسية لإدارة مخاطر سلسلة توريد البرمجيات.
لوائح SBOM تكتسب زخمًا
يتزايد انتشار لوائح الرقابة على الصادرات والواردات على نطاق واسع. وقد نشرت العديد من الحكومات توصيات بشأن تنفيذ هذه اللوائح. وفي الولايات المتحدة، ترد التوصيات المتعلقة بالإدارة السليمة بيئياً في العديد من المبادئ التوجيهية الحكومية، بما في ذلك:
في أوروبا، نشرت وكالة الاتحاد الأوروبي للأمن السيبراني (ENISA) "المبادئ التوجيهية لتأمين Supply Chain لإنترنت الأشياء"، والتي تقدم للمؤسسات رؤى قيمة لتحسين الأمن السيبراني وإدارة مخاطر سلسلة التوريد المتعلقة بالبرمجيات.
أصدرت دول أخرى مبادئ توجيهية مماثلة، بما في ذلك:
تنصح المؤسسات باستخدام قائمة برمجيات SBOM لتقييم المخاطر المرتبطة بمكونات البرمجيات التي تستخدمها وتحديد ومعالجة نقاط الضعف في تلك المكونات.
في "دليل أمن المعلومات: إرشادات لتطوير Software "، يوصي مجلس أمن المعلومات باستخدام "دليل أمن المعلومات: إرشادات لتطوير Software " لتعزيز شفافية سلسلة التوريد الإلكترونية، مما يسهل تحديد وإدارة المخاطر الأمنية المرتبطة بمكونات البرمجيات الفردية المستخدمة في التطبيقات.
كيف يستلزم نظام PCI DSS إنشاء قائمة معلومات السلامة والصحة المهنية
وإدراكًا للمخاطر المتزايدة على بيانات بطاقات الدفع، أصبح معيار أمن بيانات صناعة بطاقات الدفع (PCI DSS) قوة دافعة لاعتماد وحدات التشغيل الآمن لبطاقات الدفع. يفرض الإصدار الأخير، وهو الإصدار 4.0 من معيار أمن بيانات صناعة بطاقات الدفع (PCI DSS 4.0)، استخدام نطاقات SBOMs، مما يؤكد دورها الحاسم في حماية المعلومات الحساسة. من خلال توفير قائمة جرد مفصلة لمكونات البرمجيات، تُمكِّن هذه النماذج المؤسسات من تحديد ومعالجة نقاط الضعف بشكل استباقي، مما يقلل من مخاطر اختراق البيانات المكلفة والخسائر المالية.
تم إنشاء PCI DSS في عام 2004، وهو معيار أمني شامل مصمم لحماية معلومات بطاقات الائتمان. وهو يحدد مجموعة من المتطلبات الصارمة للشركات التي تتعامل مع معاملات بطاقات الائتمان، والمصممة خصيصًا لحجم المعاملات التي تتم معالجتها سنويًا. وقد أدخل الإصدار 4.0 من معيار PCI DSS الإصدار 4.0 لعام 2022 تغييرات مهمة، بما في ذلك تفويض SBOM، لمواجهة التهديدات المتطورة. يعد الامتثال للإصدار 4.0 من PCI DSS v4.0 إلزاميًا بحلول أبريل 2024، مع تطبيق متطلبات محددة على مراحل بحلول 31 مارس 2025.
من خلال فرض قواعد بيانات البرمجيات الخاصة بالبرمجيات (SBOMs)، يمكّن PCI DSS المؤسسات من اكتساب فهم شامل لنظامها البيئي للبرمجيات، مما يمكّنها من تحديد ومعالجة نقاط الضعف بشكل استباقي. يقلل هذا النهج بشكل كبير من مخاطر اختراق البيانات المكلفة والخسائر المالية.
تم إصدار إصدار أحدث من PCI DSS، الإصدار 4.0.1، في منتصف عام 2024. وهذا يعني أن الإصدار السابق، 4.0، لن يكون صالحًا بعد 31 ديسمبر 2024. ومع ذلك، فإن الإصدار الجديد لا يضيف أو يحذف أي قواعد ولا يغير المواعيد النهائية. لذلك، تنطبق المعلومات حول متطلبات SBOM في هذه المدونة على كلا الإصدارين 4.0 و4.0.1.
الامتثال لمتطلبات PCI DSS 6.3.2 متطلبات PCI DSS 6.3.2
يعد متطلب SBOM في الإصدار 4.0 من معايير PCI DSS الإصدار 4.0 جزءًا من التحسينات الأوسع نطاقًا التي تم إدخالها على معايير PCI DSS في أحدث إصدار لها. تم تقديمه كجزء من 64 متطلبًا جديدًا تمت إضافتها في الإصدار 4.0، ويتناول شرط SBOM على وجه التحديد حاجة المؤسسات إلى الاحتفاظ بقائمة جرد لمكونات البرامج، مع التركيز بشكل خاص على البرامج المخصصة والمصممة حسب الطلب.
يتم تصنيف هذا المتطلب ضمن المتطلب 6 من متطلبات PCI DSS الذي يفرض إنشاء وصيانة أنظمة وتطبيقات آمنة من خلال تنفيذ تدابير أمنية قوية وإجراء تقييمات وتحديثات منتظمة لنقاط الضعف. هذا الشرط ضروري للحد من المخاطر التي تشكلها الثغرات البرمجية وحماية بيانات حامل البطاقة. يغطي القسم 6 خمسة مجالات أساسية:
- 6-1 تحديد وفهم عمليات وآليات تطوير وصيانة النظم والبرمجيات الآمنة.
- 6.2 يتم تطوير البرامج المصممة حسب الطلب والمخصصة بشكل آمن.
- 6.3 تحديد الثغرات الأمنية ومعالجتها.
- 6.4 حماية تطبيقات الويب الموجهة للجمهور من الهجمات.
- 6.5 تتم إدارة التغييرات على جميع مكونات النظام بشكل آمن.
وبشكل أكثر تحديدًا، يعد المتطلب 6.3.2 تحديثًا مهمًا نتج عن العديد من الاختراقات التي أدت فيها نقاط الضعف في مكونات الطرف الثالث، أو اختراقات موفري مكونات الطرف الثالث، إلى اختراق بيانات حامل البطاقة. ينص الشرط على ما يلي:
6-3-2-ب فحص وثائق البرمجيات، بما في ذلك البرمجيات المخصصة والمصممة حسب الطلب التي تدمج مكونات برمجيات الطرف الثالث، ومقارنتها بقائمة الجرد للتحقق من أن قائمة الجرد تتضمن البرمجيات المخصصة والمصممة حسب الطلب ومكونات برمجيات الطرف الثالث.
يجب أن تقوم المؤسسات بتوثيق وإدارة المكونات والخدمات المحددة المستخدمة في تطبيقاتها بشكل شامل. وفي حين أن بعض هذه المعلومات ربما تمت تغطيتها في مخططات تدفق البيانات، فإن المتطلبات الجديدة تتطلب توثيقاً أكثر تفصيلاً. قد يكون تتبع هذه التفاصيل أمرًا صعبًا مع تحديث المكونات وتغييرها. يُنصح باستخدام قالب قياسي لالتقاط هذه المعلومات. بالإضافة إلى ذلك، قد توفر بعض مستودعات التعليمات البرمجية المصدرية، مثل GIT، أدوات لتصدير قائمة بالمكونات المستخدمة. كحد أدنى، يجب أن يتضمن المخزون الخاص بك:
- مكونات التطبيق (مشاريع المستودعات عادةً)
- قائمة مكونات الطرف الثالث
- قائمة بتبعيات التطبيق (مثل Tomcat، Jboss، Jboss، .NET، Middleware)
- قائمة البرامج النصية لصفحة الدفع المعتمدة
كيف يمكن أن يساعد OPSWAT SBOM على تلبية متطلبات PCI DSS
تدعو اللوائح التنظيمية بشكل متزايد إلى وضع قوائم جرد دقيقة لتكوين شفرات البرمجيات لضمان أمن سلسلة توريد البرمجيات. ومع ذلك، تكافح المؤسسات من أجل بناء قوائم جرد دقيقة لتكوين كود برمجياتها.
ومع ذلك، فإن إنشاء قوائم حصر دقيقة وشاملة لمكونات البرمجيات يمثل تحديًا كبيرًا للمؤسسات. حيث تتطلب هذه الوثائق جرداً دقيقاً لمكونات البرمجيات، مما يستلزم معلومات مفصلة حول أصولها وإصداراتها وأوجه الترابط بينها. فبدون وجود قوائم حصر دقيقة لمكونات البرمجيات في سلسلة توريد البرمجيات الخاصة بها، تجد المؤسسات صعوبة في تحديد المخاطر الكامنة في سلسلة توريد البرمجيات وتقييمها والتخفيف من حدتها.
إرشادات لتوليد قائمة مهام الهيئة الفرعية للمشورة والإرشاد
OPSWAT يعمل نظام SBOM على أتمتة إنشاء نماذج SBOM لكل من التعليمات البرمجية والحاويات، مما يعزز الأمان ويساعد على الامتثال ضمن سلسلة توريد البرمجيات.
- تحديد جميع المكونات والتبعيات
حدد بدقة جميع مكونات البرمجيات، بما في ذلك المكتبات مفتوحة المصدر ومكتبات الجهات الخارجية، بالإضافة إلى إصداراتها وتوابعها. هذا يشكل الأساس ل SBOM قوي. - تقييم مخاطر برمجيات المصدر المفتوح
تقييم المخاطر المحتملة المرتبطة بمكونات برمجيات المصدر المفتوح. ضع في اعتبارك عوامل مثل الامتثال للتراخيص والثغرات الأمنية وحالة الصيانة. تحديد أولويات المكونات بناءً على أهميتها بالنسبة للبرمجيات. - فحص الثغرات الأمنية في برمجيات المصدر المفتوح
الاستفادة من أدوات فحص الثغرات وأدوات توليد قائمة الثغرات الأمنية لتحديد الثغرات المعروفة في مكونات برمجيات المصدر المفتوح. تحديد أولويات نقاط الضعف بناءً على خطورتها وتأثيرها المحتمل على البرمجيات.
استخدام OPSWAT SBOM
OPSWAT يعمل نظام SBOM على أتمتة إنشاء نماذج SBOM لكل من التعليمات البرمجية والحاويات، مما يعزز الأمان ويساعد على الامتثال ضمن سلسلة توريد البرمجيات.
إليك كيف يمكنك الاستفادة من OPSWAT SBOM لتوليد قوائم مهام SBOM بفعالية:
ومن خلال توفير قائمة جرد لجميع المكتبات مفتوحة المصدر والمكونات المستخدمة في التطبيق، يساعد OPSWAT SBOM في إدارة الثغرات التبعية في سلسلة توريد البرمجيات، مما يمكّن المستخدمين من تحديد الثغرات في التطبيقات وإصلاحها بكفاءة.
وبالإضافة إلى تحديد الثغرات، يقوم OPSWAT SBOM بالتحقق من صحة التراخيص المرتبطة بكل مكون من مكونات البرمجيات. وهذا يضمن الامتثال لشروط الترخيص وتجنب المزالق القانونية المحتملة. تعرف على المزيد حول الدور الحاسم للكشف عن التراخيص في برمجيات المصدر المفتوح.
OPSWAT تدعم SBOM أكثر من 10 لغات برمجة، بما في ذلك Java وJava وJava وGo وPHP وPython. يضمن هذا الدعم الواسع النطاق vulnerability detection الشامل عبر مختلف أنظمة تطوير البرمجيات.
عقوبات عدم الامتثال
يمكن للمؤسسات التي لا تمتثل لمعايير PCI DSS، بما في ذلك متطلبات SBOM، أن تتكبد غرامات مالية تتراوح بين 5,000 دولار و100,000 دولار شهريًا. يمكن أن تتصاعد هذه الغرامات بمرور الوقت إذا ظلت مشكلات الامتثال دون حل.
بالإضافة إلى العقوبات المالية، يمكن أن يؤدي عدم الامتثال لنظام PCI DSS إلى تحديات قانونية وتشغيلية كبيرة. قد تشمل العواقب القانونية دعاوى قضائية وتكاليف الدفاع وتسويات كبيرة. علاوة على ذلك، يمكن أن يؤدي عدم الامتثال إلى إجراء عمليات تدقيق فيدرالية من قبل وكالات مثل لجنة التجارة الفيدرالية (FTC)، مما يؤدي إلى فرض عقوبات إضافية.
الخطوات التالية للتوافق مع PCI DSS 4.0 مع PCI DSS 4.0
يشير دمج SBOM في إطار عمل PCI DSS 4.0 إلى تحول محوري نحو سلسلة توريد برمجيات أكثر أمانًا. من خلال الاستفادة من الأدوات المتقدمة مثل OPSWAT SBOM، يمكن للمؤسسات إدارة المخاطر مفتوحة المصدر بفعالية وتعزيز الامتثال والحماية من انتهاكات البيانات المكلفة.
لم يعد استخدام قائمة SBOMs خياراً بل ضرورة. فمن خلال اتخاذ خطوات استباقية لفهم التبعيات البرمجية ومعالجتها، يمكن للمؤسسات بناء أساس أمني قوي يحمي عملياتها ويبني ثقة العملاء.
