عن SBOMs و BitBucket و OWASP Dependency Track

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

1. عرضة للاستغلال، أو
2. مرخصة بشروط غير مقبولة، مثل كونها تجارية للغاية أو جائرة للغاية.

ستشرح هذه المقالة كيفية السيطرة على مثل هذه الضعف باستخدام:

1. أنابيب BitBucket لتوليد SBOM، و
2. كيف يمكن ل Dependency Track من OWASP تحليلها.

تعرف على مخاطرك

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

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

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

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

ثم يُظهر القسم العلوي ثغرات الحافظة، المشاريع المعرضة للخطر، المكونات المعرضة للخطر، ودرجة المخاطر على مر الزمن.

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

يُعد BitBucket SBOM

تحدث عملية إعداد SBOM في خط أنابيب CI/CD الخاص بـ BitBucket الذي يتم تنفيذه بعد دمج طلبات السحب في الفرع الرئيسي. وهذا يضمن أن لوحات المعلومات دائمًا محدثة بحالة الأمور.

استخدمت أنبوب BitBucket الذي يلتف حول syft لإنشاء SBOM من نوع CycloneDX. تختلف أوامر syft لتحليل الشيفرة والحاويات قليلاً.

تحليل الشيفرة

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

syft --output cyclonedx-json=code-cdx-sbom.json -v --java-use-network true .

هذا الأمر يخرج SBOM إلى ملف يسمى code-cdx-sbom.json ويستخدم الشبكة لاسترداد معلومات الترخيص من الإنترنت؛ على سبيل المثال، من مستودعات Maven المركزية.

أنبوب syft BitBucket من shiftleftcyber (شكرًا لك!) يتم تكوينه ثم في كتلة النص من أنبوب BitBucket ليقوم بتغليف هذا الأمر syft على النحو التالي:

- pipe: docker://ccideas/syft-bitbucket-pipe:1.0.0

  variables:

    SYFT_CMD_ARGS: '. --output cyclonedx-json=code-cdx-sbom.json'

    SYFT_JAVA_USE_NETWORK: 'true'

يقوم دليل مشروع syft بتحديد مجموعة مذهلة من اللغات المدعومة، لكنني استخدمته فقط على Java و JavaScript مع مشروع Python في الاحتياط.

ما الذي يكمن في حاوياتك؟

لفحص حاوية من سجلك، يُشغل الشخص الأمر التالي ضمن نطاق “تسجيل الدخول إلى دوكر”:

syft --output cyclonedx-json=container-cdx-sbom.json docker.s2c.co.za/container:latest --from registry

الأنبوب المقابل في BitBucket هو:

- pipe: docker://ccideas/syft-bitbucket-pipe:1.0.0

  variables:

    SYFT_REGISTRY_AUTH_USERNAME: sadilar

    SYFT_REGISTRY_AUTH_PASSWORD: $DOCKER_PWD

    SYFT_CMD_ARGS: 'docker.s2c.co.za/container:latest --output cyclonedx-json=container-cdx-sbom.json --scope all-layers'

تعليمة التبديل all-layers توجه syft لتفحص جميع الطبقات في صورة الحاوية وليس فقط المنتج النهائي.

BitBucket كوسيلة للإيداع

كل ما تبقى هو لـ Dependency Track استيعاب SBOM. استخدمت أنبوب الشقيقة للأنبوب BitBucket الذي أنشأ SBOM:

- pipe: docker://ccideas/sbom-utilities-pipe:1.5.0

  variables:

    PATH_TO_SBOM: code-cdx-sbom.json

    SEND_SBOM_TO_DTRACK: 'true'

    DTRACK_URL: https://deptrack.test.s2c.co.za

    DTRACK_PROJECT_ID: df3327b2-5439-43ab-bb33-1f24228b6074

    DTRACK_API_KEY: $DTRACK_TEST

حددت ثلاثة معلمات إدخال:

1. عنوان URL لنسخة Dependency Track
2. معرف مشروع Dependency Track لتحميل SBOM
3. مفتاح API للمصادقة على التحميل

يمكن العثور بسهولة على معرف المشروع عن طريق النقر على “عرض التفاصيل” من عرض المشروع:

ثم نسخ معرف الكائن في الأسفل:

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

الاستنتاج

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

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

لذلك يتحمل كل مطور مسؤولية تنفيذ ودعم استراتيجيات نشطة لمواجهة هذه المخاطر. في حال كان كودك على BitBucket، يمكن أن يساعد النهج الموضح أعلاه أنظمتك على الانضمام إلى البرنامج. ومع ذلك، فإن واجهة برمجة تطبيقات Dependency Track لا تقتصر على الوصول إلى BitBucket حصراً ويجب أن تكون هناك طرق للحصول على مواد البرمجيات من تقنيات أخرى لأنابيب CI/CD.