ملخص

  • أصبح اختراق Bash uploader لشركة Codecov في 2021 اختبارًا للمساءلة بشأن أسرار CI لأن تحديث Codecov الأمني ذكر أن طرفًا ثالثًا عدّل أداة التحميل النصية وقد يصدر متغيرات البيئة ومعلومات Git عن بُعد من بيئات CI للعملاء.
  • ذكر تقرير ما بعد الحادثة لـ Codecov لاحقًا أن المهاجم استخرج مفتاح HMAC لحساب خدمة تخزين Google Cloud من طبقة وسيطة في صورة Docker عامة واستخدم هذا المفتاح لتعديل أداة التحميل المقدمة للمستخدمين النهائيين.
  • ليست المسألة مجرد أن المستخدمين كان ينبغي عليهم التحقق من المجاميع الاختبارية. Codecov كانت تتحكم في مسار توزيع الأداة، وعملية بناء صورة Docker العامة، ومراقبة النص المستضاف، وإخطار العملاء، وخطة الانتقال من نمط الثقة curl-to-shell.
  • التحكم في الأسرار التي كانت متاحة لوظائف CI، وطريقة التحميل المستخدمة، وتطبيق التحقق من المجاميع، وسرعة تدوير المفاتيح بعد الإخطار كان بيد العملاء. لكن تحكمات العملاء تلك لم تلغِ مسؤولية المزود عن سلامة النص البرمجي.
  • تعتبر هذه المقالة تحديث Codecov الأمني وتقرير ما بعد الحادثة كمصادر أولية، واستجابات العملاء كأدلة من طرف أول، ووثائق NIST وCISA وSLSA وSigstore وCI كمفردات تحكم تقنية. لا تدعي الوصول إلى ملفات إنفاذ القانون أو قوائم العملاء الخاصة أو سجلات البنية التحتية الكاملة للمهاجم.

لماذا تنتمي هذه الحالة إلى ملف مخاطر ومساءلة

تنتمي Codecov إلى ملف مخاطر ومساءلة لأن اختراق Bash uploader في 2021 حوّل خطوة تحميل التغطية الروتينية إلى مسار محتمل لكشف أسرار CI. جاء تحديث Codecov الأمني بتاريخ 15 أبريل 2021 علىhttps://about.codecov.io/security-update/أن Codecov علمت في 1 أبريل أن شخصًا ما حصل على وصول غير مصرح به إلى نص Bash uploader وعدّله دون إذن. ذكرت الشركة أن الفاعل حصل على الوصول بسبب خطأ في عملية إنشاء صورة Docker الخاصة بـ Codecov سمح باستخراج بيانات اعتماد لتعديل الأداة. وأضافت أنه بدءًا من 31 يناير 2021 كانت هناك تغييرات غير مصرح بها دورية قد تصدر معلومات مخزنة في بيئات التكامل المستمر للعملاء إلى خادم خارج البنية التحتية لـ Codecov.

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

قصة التحكم توضحها تفاصيل تقرير ما بعد الحادثة علىhttps://about.codecov.io/apr-2021-post-mortem/. ذكر التقرير أن الفاعل استهدف Bash uploader واستخدمه لتوصيل حمولة ضارة للمستخدمين الذين يستخدمون الأداة النصية، وGitHub Action، وCircleCI Orb، وBitrise Step. وأوضح أن المهاجم استخرج مفتاح HMAC لحساب خدمة تخزين Google Cloud من طبقة وسيطة في صورة Docker عامة واستخدمه لتعديل الأداة في التخزين السحابي. كما ذكر أن أحد العملاء اكتشف الحادث بعد فحص SHASUM ولاحظ تباينًا بين التجزئة المبلغ عنها على GitHub والتجزئة المحسوبة للأداة المحملة.

تضع هذه الحقائق المساءلة ضمن نظام مشترك لكن غير متكافيء. Codecov كانت تتحكم في الأداة المستضافة، ومسار الكتابة إلى Google Cloud Storage، وعملية بناء صورة Docker الذاتية، وتدوير المفاتيح بعد الحادث، وإخطار العملاء، والانتقال إلى أداة جديدة. العملاء كانوا يتحكمون في متغيرات CI الحاضرة عند تشغيل الأداة، وجلب النص مباشرة، وتنفيذ التحقق من المجاميع، وسرعة تدوير الأسرار المكشوفة. مزودو CI كانوا يتحكمون في أجزاء من إخفاء الأسرار وعزل الوظائف والتسجيل. المستخدمون النهائيون تحمّلوا المخاطر إذا مكنت الأسرار المكشوفة من الوصول اللاحق إلى الأنظمة أو الكود. السؤال العملي هو ما إذا كان كل طرف قد حصل على أدلة كافية للتصرف في الوقت المناسب.

يتناسب الحدث مع اقتصادات أدوات التطوير لأن قيمة Codecov كانت التقارير السهلة للتغطية عبر أنظمة CI متعددة. يُظهر مستودع Bash uploader المؤرشف علىhttps://github.com/codecov/codecov-bashالنمط المباشر: يمكن للعملاء جلب وتنفيذ نص عن بُعد، واستخدام نفس الأداة عبر مزودي CI، والتحقق من SHASUMs اختياريًا. كانت الراحة محرك التبني. لكن عندما أصبح النص عن بُعد الموثوق قابلًا للتغيير من مسار يتحكم به مهاجم، ظهرت التكلفة الخفية كمخزون طارئ من المفاتيح، وتدوير، ومراجعة المستودعات، وإخطار العملاء، واستجابة للحوادث.

أنشأت أداة Bash uploader قلبًا للثقة داخل CI

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

توضح وثائق Bash uploader الخاصة بـ Codecov علىhttps://docs.codecov.com/docs/about-the-codecov-bash-uploaderوتعليمات المستودع المؤرشف سبب أهمية ذلك. كانت الأداة مصممة لاكتشاف إعدادات CI وجمع التقارير وإرسال بيانات التغطية. نفس المستودع وثّق عملية تحقق باستخدام ملفات SHASUM، لكن تقرير ما بعد الحادثة أقر بأن العملية لم تكن موثقة بالكامل أو بشكل صحيح قبل الحادث. كما أشار التحديث الأمني إلى أن العملاء الذين أجروا مقارنة المجاميع قبل استخدام الأداة قد لا يتأثرون. هذا حد كاشف: كان التحقق من التكامل دفاعًا صالحًا، لكنه لم يكن حتميًا بسبب نموذج التوزيع.

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

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

تعزز وثائق CI الحديثة نموذج المخاطر المشترك. تتناول إرشادات GitHub Actions علىhttps://docs.github.com/en/actions/security-guides/security-hardening-for-github-actionsالأسرار وأذونات التوكينات والإجراءات الخارجية ومخاطر حقن النصوص. وثائق متغيرات CI/CD في GitLab علىhttps://docs.gitlab.com/ci/variables/ووثائق متغيرات البيئة لـ CircleCI علىhttps://circleci.com/docs/env-vars/تظهر كيف تتعمّد أنظمة CI كشف الأسرار للوظائف تحت ظروف خاضعة للرقابة. هذه الوثائق ليست نتائج تحقيق حول Codecov. إنها تحدد البيئة التي أصبح فيها اختراق Codecov خطيرًا: وظائف CI هي غرف أتمتة متميزة، وليس محطات محايدة.

توقيت الكشف جعل العملاء يتحملون عدم اليقين

توقيت الكشف هو قضية مساءلة مركزية لأن العملاء لم يتمكنوا من معرفة النطاق فورًا. ذكرت Codecov أنها علمت بالمشكلة في 1 أبريل 2021 بعد أن أبلغ عميل قام بالتحقق من SHASUM عن تباين. الكشف العام في 15 أبريل جاء بعد التحقيق والأدلة والتنسيق. قال التحديث الأمني إن الفترة الزمنية بدأت في 31 يناير وأن المستخدمين المتأثرين تم الاتصال بهم عبر البريد الإلكتروني والإشعارات داخل التطبيق. أضاف تحديث 29 أبريل معلومات إضافية حول متغيرات البيئة التي ربما تم الحصول عليها دون إذن وحول المؤسسات والمستودعات المتأثرة.

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

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

تعاملت صفحة تنبيه CISA لـ Codecov علىhttps://www.cisa.gov/news-events/alerts/2021/04/22/codecov-releases-security-updateإشعار المزود على أنه مهم بما يكفي لتضخيمه. هذا دليل عام مفيد على أن الحادث كان متعلقًا بسلسلة توريد البرمجيات ومعالجة العملاء، وليس مجرد حدث داخلي في Codecov. إطار تطوير البرمجيات الآمن من NIST علىhttps://csrc.nist.gov/pubs/sp/800/218/finalمفيد أيضًا لأنه يؤطر مكونات البرمجيات وبيئات البناء والاستجابة للثغرات كضوابط لدورة الحياة. اختراق Codecov يقع عند حدود الثلاثة جميعًا.

تظهر قصة الكشف أيضًا قيمة وضعف التحقق من جانب العميل. اكتشف عميل التباين لأنه فحص الأداة المحملة مقابل SHASUM المتوقع. هذه إشارة قوية على أن التحقق فعال. لكنه تحكم ضعيف إذا كان فقط العملاء الحذرون بشكل غير عادي هم من يقومون به. التصميم الأقوى هو جعل التنفيذ غير الموقّع أو غير القابل للتحقق استثناءً، وليس الافتراضي. قال تقرير ما بعد الحادثة إن الأداة الجديدة ستُشحن كملفات ثنائية قابلة للتحقق من SHASUM وموقّعة، وأن إهمال الأداة النصية كان جزءًا من الإجراء التصحيحي. إعلان الأداة الجديدة علىhttps://about.codecov.io/blog/introducing-codecovs-new-uploader/ينتمي إلى ملف الإصلاح لهذا السبب.

كان تدوير المفاتيح عبء العمل الحقيقي على العملاء

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

قد تُستخدم هذه الأسرار عبر مستودعات متعددة أو تُورث من إعدادات CI على مستوى المؤسسة.

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

تظهر استجابات العملاء العامة سبب أهمية ذلك. إشعار HashiCorp الأمني علىhttps://discuss.hashicorp.com/t/hcsec-2021-12-codecov-security-event-and-hashicorp-gpg-key-exposure/23512وصف تعرّض مفتاح GPG خاص يُستخدم لتوقيع الإصدارات وعملية الإبطال والاستبدال. استجابة Twilio علىhttps://www.twilio.com/en-us/blog/company/communications/response-to-the-codecov-vulnerabilityوصفت تحقيقها وتقييم تأثير العملاء. استجابة Rapid7 علىhttps://www.rapid7.com/blog/post/2021/05/13/rapid7s-response-to-codecov-incident/وصفت مراجعتها ومعالجتها. تقرير حادث Mercari علىhttps://about.mercari.com/en/press/news/articles/20210521_incident_report/وصف تعرض بيانات العملاء والموظفين المتصل بحادث Codecov. هذه ليست دليلًا على أن كل عميل Codecov كانت له نفس النتيجة. إنها أدلة تظهر أن معالجة العملاء كانت حقيقية ومتنوعة وذات عواقب.

مثال HashiCorp مفيد بشكل خاص لأن مفاتيح التوقيع ليست توكينات API عادية. مفتاح التوقيع يمكن أن يؤثر على أصالة البرمجيات. استبداله يتطلب الإبطال، توزيع ثقة جديد، تواصل مع العملاء، ووقتًا. هذا لا يعني أن Codecov اخترقت كل أثر موقّع. يعني أن كشف أسرار CI يمكن أن يصل إلى سلسلة توريد البرمجيات إذا كانت المواد المكشوفة تشمل مفاتيح تُستخدم لتوثيق أو توزيع البرمجيات. نصف قطر الانفجار يعتمد على نوع السر واستخدامه وعمره ودليل الإبطال.

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

سلامة التوزيع كانت مطالبة الإصلاح المركزية

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

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

طبقات صورة Docker هي نقطة أدلة مهمة. قال Codecov إن المهاجم استخرج مفتاح HMAC من طبقة وسيطة في صورة Docker عامة مستضافة ذاتيًا. وثائق Docker الخاصة حول البناء متعدد المراحل علىhttps://docs.docker.com/build/building/multi-stage/تشرح لماذا يجب إبقاء القطع الأثرية والمواد الوسيطة خارج الصور النهائية. الإجراء التصحيحي في تقرير Codecov لضغط أو استخدام بنى متعددة المراحل كان متصلاً مباشرة بفئة السبب الجذري. سر في طبقة صورة ليس محميًا بمجرد أن تبدو الحاوية النهائية نظيفة.

مفردات سلسلة توريد البرمجيات الأوسع تساعد أيضًا. إطار SLSA علىhttps://slsa.dev/وSigstore علىhttps://www.sigstore.dev/يعالجان التكامل والأصل والتوقيع وقابلية التحقق للقطع الأثرية البرمجية. ليسا اختبارات امتثال بأثر رجعي لأداة Codecov في 2021. يحددان لماذا النص المستضاف القابل للتغيير هو نموذج توزيع أضعف من قطعة أثرية موقعة ومحددة الإصدار وقابلة للتحقق مع أصل. Scorecard من OpenSSF علىhttps://scorecard.dev/يؤطر صحة التبعيات والمستودعات كضوابط قابلة للقياس لسلسلة التوريد. النقطة المهمة ليست أن إطارًا واحدًا كان سيمنع كل جزء من الحادث. النقطة هي أن سلامة القطعة الأثرية يجب أن تُصمم بحيث لا يُتوقع من العملاء اكتشاف التلاعب يدويًا.

تظهر وثائق الأداة الحالية علىhttps://docs.codecov.com/docs/codecov-uploaderومستودع الأداة علىhttps://github.com/codecov/uploaderاتجاه الانتقال بعيدًا عن النموذج النصي القديم. لا يزال مستودع GitHub Action علىhttps://github.com/codecov/codecov-actionمهمًا لأن العديد من المستخدمين استهلكوا Codecov عبر تكاملات المنصة بدلاً من الاستدعاء النصي المباشر. أظهر الحادث أن الواجهات والأوربات والخطوات قد ترث حدود الثقة لأداة تحميل أساسية مشتركة. قد يعتقد العملاء أنهم يستخدمون تكاملًا محليًا لـ CI، لكن الخطر قد يظل يتدفق عبر نفس النص أو البرنامج الثنائي عن بُعد.

مزودو CI والعملاء ما زالوا مضطرين لتقليل نصف قطر الانفجار

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

GitHub Actions، وGitLab CI، وCircleCI، وBuildkite، وJenkins، وغيرها من أنظمة CI توفر للمؤسسات طرقًا لتحديد نطاق المتغيرات، وفصل الوظائف، وإخفاء الأسرار، وتقييد وصول الفروع، وطلب بيئات محمية، وتحديد أذونات التوكينات. لكن هذه الضوابط مفيدة فقط إذا كان تصميم خط الأنابيب يستخدمها. وظيفة متجانسة تشغل الاختبارات، وتبني القطع الأثرية، وتنشر البنية التحتية، وتوقّع الإصدارات، وتنشر الحزم، وتحمل التغطية تخلق تعرضًا ذا نمط مشترك. إذا كانت خطوة التغطية النهائية يمكنها قراءة كل متغير بيئة تستخدمه الخطوات السابقة، يتم تحديد نصف قطر الانفجار بالراحة بدلاً من الحاجة.

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

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

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

حدود الأدلة وانضباط عدم المبالغة

تدعم الأدلة العامة استنتاجًا قويًا لكن ليس ادعاءات غير محدودة. تدعم أن نص Bash uploader الخاص بـ Codecov تم تعديله دون إذن، وأن التعديل يمكن أن يصدر متغيرات البيئة ومعلومات Git عن بُعد من بيئات CI، وأن الفترة الزمنية بدأت في 31 يناير وانتهت بالمعالجة في 1 أبريل 2021، وأن تباين المجموع الاختباري لدى عميل ساعد في اكتشاف المشكلة، وأن طبقة صورة Docker عامة كشفت بيانات اعتماد استخدمت لتعديل الأداة، وأن Codecov أوصت بتدوير المفاتيح للمستخدمين المتأثرين. تدعم أن بعض العملاء كشفوا علنًا عن معالجتهم أو تعرضهم.

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

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

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

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

اختبار المساءلة الدائم هو إثبات الثقة المُصلَحة

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

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

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

غير الحادث أيضًا معنى "أتمتة الأمان". الأتمتة ليست آمنة لأنها مؤتمتة. إنها آمنة عندما تكون للأتمتة صلاحية محدودة، ومدخلات قابلة للتحقق، وقطع أثرية قابلة للتكرار، وسجلات قابلة للتدقيق، وإبطال سريع. أظهر اختراق Bash uploader لـ Codecov أن خطوة أتمتة صغيرة يمكن أن تصبح حد ثقة كبيرًا إذا تشغلت أينما تعيش الأسرار.

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

الأداة كانت صغيرة، لكن سياق تشغيلها كان كبيرًا

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

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

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

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

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

التحقق يجب أن يكون افتراضيًا ومرئيًا ومملًا

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

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

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

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

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

يجب على المشتريات معالجة أدوات CI ككود مميز

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

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

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

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

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