Docker Hub جعل إعادة تعيين التوكن اختبارًا لمساءلة سلسلة توريد الحاويات

الملخص

• أصبح حادث الوصول غير المصرح به لـ Docker Hub في 2019 اختبارًا لمساءلة سلسلة توريد الحاويات لأن التقارير العامة أعادت إنتاج إشعار Docker للمستخدمين الذي يفيد بأن قاعدة بيانات واحدة من Hub تخزن مجموعة فرعية من بيانات المستخدم غير المالية قد تم الوصول إليها، وقد تعرض حوالي 190,000 حساب للخطر، وكانت توكنات GitHub وBitbucket للبناء الآلي لـ Docker ضمن النطاق.
• من كان لديه السيطرة العملية على تخزين توكنات الوصول، ونطاق تكامل المستودعات، وإخطار العملاء، وإبطال التوكن، وثقة البناء الآلي، والأدلة على أن حادث السجل لم يمكن أن يتحول بصمت إلى اختراق أوسع لسلسلة توريد البرمجيات؟
• السجل العام المؤكد المتاح عبر BleepingComputer علىhttps://www.bleepingcomputer.com/news/security/docker-hub-database-hack-exposes-sensitive-data-of-190k-users/والإشعار المحفوظ علىhttps://news.ycombinator.com/item?id=19763413يدعم تسلسل التعرض وإعادة التعيين وإعادة الاتصال ومراجعة سجل الأمان، بينما تشرح وثائق Docker الحالية نموذج البناء الآلي والتوكن.
• الاستدلال المدعوم هو أن الحادث لم يكن مجرد حدث أمان للحساب. نظرًا لأن البناء الآلي لـ Docker Hub يربط Docker Hub بمزودي المصدر، خلق تعرض التوكن سؤال حوكمة عبر GitHub وBitbucket وDocker Hub وCI/CD ونشر الصور واستهلاك الصور النهائي.
• لا تزال المجهولات قائمة: لا يقدم السجل العام تقرير الطب الشرعي الكامل لـ Docker، أو مخطط قاعدة البيانات الدقيق، أو نطاق التوكن لكل حساب، أو سجلات وصول مزود المصدر، أو دليل على عدم تعديل المستودع، أو عدد الذين تم إخطارهم، أو دليل على كل إجراء علاجي للعميل.

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

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

أفضل سجل عام للحادث ليس صفحة إشعار Docker الحية الحالية. عنوان URL القديم لدعم Docker الذي تم الاستشهاد به في تقارير 2019 لم يعد مصدرًا حيًا موثوقًا. لذلك يُبنى السجل العام من نص إشعار المستخدم المُعاد إنتاجه والتقارير المعاصرة. ذكر BleepingComputer علىhttps://www.bleepingcomputer.com/news/security/docker-hub-database-hack-exposes-sensitive-data-of-190k-users/أن Docker أصبح على علم بالوصول غير المصرح به إلى قاعدة بيانات Docker Hub في 25 أبريل 2019، وأن البيانات المتأثرة تضمنت أسماء المستخدمين وكلمات المرور المشفرة لنسبة صغيرة من المستخدمين وتوكنات GitHub وBitbucket المستخدمة للبناء الآلي لـ Docker. أعاد نفس المقال إنتاج نص إشعار المستخدم. يظهر منشور Hacker News المحفوظ علىhttps://news.ycombinator.com/item?id=19763413لغة الإشعار، بما في ذلك العبارات التي تفيد بأن حوالي 190,000 حساب قد تكون تعرضت للخطر، أي أقل من 5 بالمائة من مستخدمي Hub، وأن Docker ألغى توكنات GitHub ومفاتيح الوصول للمستخدمين المتأثرين بالبناء الآلي.

هذه هي الحقائق المؤكدة التي ترتكز عليها هذه المقالة: تم الإبلاغ عن وصول غير مصرح به إلى قاعدة بيانات Docker Hub؛ كانت مجموعة فرعية من بيانات المستخدم غير المالية ضمن النطاق؛ حوالي 190,000 حساب قد تكون تعرضت للخطر؛ تم تضمين بعض أسماء المستخدمين وكلمات المرور المشفرة؛ تم تضمين توكنات GitHub وBitbucket للبناء الآلي لـ Docker؛ طلب Docker من المستخدمين تغيير كلمات المرور حيثما كان ذلك مناسبًا؛ قال Docker إنه ألغى التوكنات ومفاتيح الوصول المتأثرة؛ طلب Docker من مستخدمي البناء الآلي إعادة توصيل المستودعات ومراجعة سجلات أمان مزود المصدر. ذكرت Security Affairs علىhttps://securityaffairs.com/84554/data-breach/docker-data-breach.htmlوThe Hacker News علىhttps://thehackernews.com/2019/04/docker-hub-data-breach.htmlوHelp Net Security علىhttps://www.helpnetsecurity.com/2019/04/29/docker-hub-breach/نفس التسلسل الأساسي.

الاستدلال المدعوم هو أن هذا كان حدث حوكمة سلسلة التوريد، حتى لو لم يثبت مصدر عام اختراقًا نهائيًا. تشرح وثائق البناء الآلي الحالية لـ Docker علىhttps://docs.docker.com/docker-hub/repos/manage/builds/أن Docker Hub يمكنه بناء الصور تلقائيًا من مستودعات الشفرة المصدرية ودفع الصور المبنية إلى مستودعات Docker. تشرح وثائق ربط المصدر علىhttps://docs.docker.com/docker-hub/repos/manage/builds/link-source/أن المستخدمين يربطون مزودي مصدر GitHub أو Bitbucket حتى يتمكن Docker Hub من الوصول إلى مستودعات الشفرة المصدرية. يقول صفحة الإعداد علىhttps://docs.docker.com/docker-hub/repos/manage/builds/setup/إن البناء الآلي يمكنه بناء صورة عند دفع الشفرة إلى مزود المصدر. هذا التصميم يجعل توكنات مزود المصدر جزءًا من سلسلة البناء، وليس مجرد راحة للحساب.

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

الحقائق المؤكدة والاستدلالات المدعومة والمجهولات

يبدأ الجدول الزمني العام المؤكد في 25 أبريل 2019، عندما قال إشعار Docker إنه اكتشف وصولاً غير مصرح به إلى قاعدة بيانات Hub واحدة. نص الإشعار المحفوظ علىhttps://news.ycombinator.com/item?id=19763413قال إن قاعدة البيانات تخزن مجموعة فرعية من بيانات المستخدم غير المالية وأن Docker تصرف للتدخل وتأمين الموقع. قال الإشعار إن بيانات حساسة من حوالي 190,000 حساب قد تكون تعرضت للخطر. ووصف تلك الفئة بأنها أقل من 5 بالمائة من مستخدمي Hub. وحدد فئات البيانات كأسماء المستخدمين وكلمات المرور المشفرة لنسبة صغيرة من المستخدمين، بالإضافة إلى توكنات GitHub وBitbucket للبناء الآلي لـ Docker.

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

الاستدلال المدعوم هو أن Docker تعامل بشكل صحيح مع إبطال التوكن كأهم من مجرد إعادة تعيين كلمة المرور. كلمة المرور المكشوفة تهدد حساب Docker Hub. تعرض توكن مزود المصدر يهدد الجسر بين Docker Hub ومستودع الشفرة. يمكن أن يكون لهذا الجسر آثار قراءة أو كتابة اعتمادًا على أذونات المزود ونموذج التكامل. تحذر وثائق OAuth الخاصة بـ GitHub علىhttps://docs.github.com/en/apps/oauth-apps/using-oauth-apps/reviewing-your-authorized-oauth-appsالمستخدمين من مراجعة التطبيقات المصرح بها والتحقق من الأذونات الواسعة، بما في ذلك الوصول إلى المستودعات الخاصة. تشرح وثائق سجل الأمان الخاص بـ GitHub علىhttps://docs.github.com/en/authentication/keeping-your-account-and-data-secure/reviewing-your-security-logأن المستخدمين يمكنهم مراجعة الإجراءات المتعلقة بحسابهم. يشرح دليل سجل التدقيق لـ Bitbucket Cloud علىhttps://support.atlassian.com/bitbucket-cloud/kb/bitbucket-cloud-audit-log-events/أن سجلات تدقيق مساحة العمل تتبع الأنشطة الرئيسية. تدعم هذه المصادر نموذج الإصلاح العملي: الإبطال، إعادة الاتصال، مراجعة السجلات، والتحقق.

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

جعلت حيازة التوكن السجل تابعًا للتحكم بالمصدر

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

لا تزال وثائق Docker الحالية تظهر شكل هذا الاعتماد. نظرة عامة على البناء الآلي علىhttps://docs.docker.com/docker-hub/repos/manage/builds/تقول إن Docker Hub يمكنه بناء الصور تلقائيًا من الشفرة في مستودع خارجي ودفع الصورة المبنية إلى مستودعات Docker. صفحة ربط المصدر علىhttps://docs.docker.com/docker-hub/repos/manage/builds/link-source/تقول إن المستخدمين يربطون خدمة شفرة مصدر مستضافة بـ Docker Hub حتى يتمكن Docker Hub من الوصول إلى مستودعات الشفرة المصدرية. صفحة الإعداد علىhttps://docs.docker.com/docker-hub/repos/manage/builds/setup/تذكر GitHub وBitbucket كمزودي مصدر. هذه الصفحات هي وثائق منتج حالية، وليست أدلة على حادث 2019، لكنها تشرح لماذا تعتبر توكنات مزود المصدر كائنات عالية القيمة.

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

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

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

حوّل البناء الآلي الراحة إلى نصف قطر انفجار

البناء الآلي هو ميزة إنتاجية كلاسيكية بتكلفة خفية للمرونة. تصف وثائق Docker علىhttps://docs.docker.com/docker-hub/repos/manage/builds/قاعدة فرع أو علامة تشغل بناء عندما تتغير الشفرة المصدرية. ينتج البناء بعد ذلك صورة ويدفعها إلى Docker Hub. هذا يقلل الاحتكاك اليدوي للإصدار. كما يعني أن بيانات الاعتماد المرتبطة بمسار الأتمتة يمكن أن تجلس في المنبع من قطعة أثرية منشورة. إذا كانت بيانات الاعتماد ذات نطاق واسع، وطويلة العمر، ومرتبطة بمستخدم يتمتع بصلاحيات واسعة، أو ضعيفة المراقبة، يمكن أن يخلق اختراق السجل حالة عدم يقين بشأن التحكم بالمصدر وسلامة الصورة.

حادث 2019 لم يثبت علنًا نشر صور ضارة. النقطة الخاضعة للمساءلة هي أن الاحتمال كان يجب التحقيق فيه. حذر BleepingComputer علىhttps://www.bleepingcomputer.com/news/security/docker-hub-database-hack-exposes-sensitive-data-of-190k-users/من أن التوكنات يمكن أن تسمح بالوصول إلى شفرة المستودع الخاص والتعديل المحتمل اعتمادًا على الأذونات. هذه العبارة مؤطرة كسيناريو مخاطرة، وليس نتيجة مؤكدة. Help Net Security علىhttps://www.helpnetsecurity.com/2019/04/29/docker-hub-breach/شددت بالمثل على خطر التوكن. يجب أن تحافظ مقالة منضبطة على هذا الحد: تعرض التوكن خلق مخاطرة لسلسلة التوريد؛ الأدلة العامة لا تظهر أن المخاطرة تحققت.

تأثير الإصلاح صعب. إعادة تعيين كلمة المرور ليست كافية. إبطال التوكن ضروري لكن غير كافٍ. إعادة الاتصال يمكن أن تستعيد البناءات، لكنها يمكن أن تخفي أيضًا أعمال تدقيق مفقودة إذا سارعت الفرق لجعل خطوط الأنابيب خضراء. كان على العميل المسؤول مراجعة سجلات أمان GitHub علىhttps://docs.github.com/en/authentication/keeping-your-account-and-data-secure/reviewing-your-security-log، ومراجعة تطبيقات OAuth المصرح بها علىhttps://docs.github.com/en/apps/oauth-apps/using-oauth-apps/reviewing-your-authorized-oauth-apps، ومراجعة سجلات تدقيق Bitbucket علىhttps://support.atlassian.com/bitbucket-cloud/kb/bitbucket-cloud-audit-log-events/، وإلغاء أو استبدال توكنات الوصول المخترقة حيثما كان ذلك مناسبًا باستخدام إرشادات مثلhttps://support.atlassian.com/bitbucket-cloud/docs/revoke-a-workspace-access-token/.

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

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

نقل الإشعار أعمال الإصلاح إلى المشرفين

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

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

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

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

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

أصبحت سجلات مزود المصدر طبقة أدلة العميل

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

صفحة سجل أمان GitHub علىhttps://docs.github.com/en/authentication/keeping-your-account-and-data-secure/reviewing-your-security-logتشرح أن مستخدمي الحساب يمكنهم مراجعة الإجراءات المتعلقة بهم. صفحة مراجعة تطبيقات OAuth في GitHub علىhttps://docs.github.com/en/apps/oauth-apps/using-oauth-apps/reviewing-your-authorized-oauth-appsتخبر المستخدمين بالتحقق من عدم تفويض تطبيقات جديدة بأذونات واسعة. إرشادات تقييد الوصول إلى OAuth في GitHub علىhttps://docs.github.com/en/organizations/managing-oauth-access-to-your-organizations-data/about-oauth-app-access-restrictionsتشرح كيف يمكن للمؤسسات التحكم في وصول تطبيق OAuth إلى موارد المؤسسة. هذه الضوابط أساسية عندما يكون تكامل بناء طرف ثالث ضمن النطاق.

وثائق OAuth لـ Bitbucket علىhttps://support.atlassian.com/bitbucket-cloud/docs/use-oauth-on-bitbucket-cloud/تشرح تدفقات التوكن وتفويض المزود. دليل سجل تدقيق Bitbucket Cloud علىhttps://support.atlassian.com/bitbucket-cloud/kb/bitbucket-cloud-audit-log-events/يصف التسجيل على مستوى مساحة العمل. إرشادات إلغاء توكن Bitbucket علىhttps://support.atlassian.com/bitbucket-cloud/docs/revoke-a-workspace-access-token/https://support.atlassian.com/bitbucket-cloud/docs/revoke-a-repository-access-token/تشرح كيف يمكن إزالة الوصول. تظهر هذه المستندات الأدلة وأعمال الإصلاح التي كان على العملاء تنسيقها خارج Docker.

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

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

يظهر التوجيه الحديث للتوكن كيف يجب أن يكون مسار الإصلاح

توجيهات Docker اللاحقة للتوكن تساعد في تحديد كيف يجب أن يبدو الإصلاح الدائم. وثائق توكن الوصول الشخصي لـ Docker علىhttps://docs.docker.com/security/access-tokens/تشرح إنشاء التوكن وانتهاء الصلاحية والأذونات والإدارة. وثائق توكن الوصول للمؤسسة لـ Docker علىhttps://docs.docker.com/enterprise/security/access-tokens/تؤكد على أذونات المستودع ذات النطاق، وأذونات الإدارة، والتدوير، ومراقبة استخدام التوكن، والتخزين الآمن. مدونة Docker لعام 2019 حول توكنات الوصول الشخصي علىhttps://www.docker.com/blog/docker-hub-new-personal-access-tokens/أطرت التوكنات كبديل لكلمات المرور ولبنة بناء للتحكم المتقدم في الوصول. مدونة Docker لعام 2021 حول التوكنات ذات النطاق علىhttps://www.docker.com/blog/level-up-security-with-scoped-access-tokens/جعلت اتجاه الأقل صلاحية واضحًا.

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

وثائق ترحيل Docker علىhttps://docs.docker.com/docker-hub/repos/manage/builds/migrate/ذات صلة أيضًا لأنها تقول إن البناء الآلي لـ Docker Hub مهمل وسيتم إيقافه في 1 أبريل 2027. تنصح الصفحة بالترحيل إلى سير عمل CI، مع إنشاء توكن وتخزين آمن في مديري أسرار منصة CI/CD. هذا الاتجاه المستقبلي لا يمحو حادث 2019. إنه يعزز النقطة القائلة بأن بيانات اعتماد البناء الآلي المستضافة على السجل هي مصدر قلق خاص للحوكمة. نقل الأتمتة إلى CI/CD لا يزيل مخاطرة التوكن. يغير من يخزن التوكن، ومن يسجل الاستخدام، ومن يمكنه إثبات البناء.

يوصي NIST SP 800-218 علىhttps://csrc.nist.gov/pubs/sp/800/218/finalبممارسات تطوير برمجيات آمنة يمكن دمجها في دورات حياة تطوير البرمجيات. نموذج التصديق على تطوير البرمجيات الآمنة من CISA علىhttps://www.cisa.gov/resources-tools/resources/secure-software-development-attestation-formيعكس الاتجاه العام نحو ممارسات تطوير مدعومة بالأدلة. ورقة الغش لأمن CI/CD من OWASP علىhttps://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.htmlتعالج خطوط أنابيب CI/CD كأسطح هجوم عالية القيمة. ورقة الغش لإدارة الأسرار من OWASP علىhttps://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.htmlتؤكد على المركزية والتدوير والتدقيق والتحكم في دورة الحياة للأسرار. لا شيء من هذه المصادر هو نتائج حول بيئة Docker الخاصة. إنها تحدد معيار الأدلة الذي يجب أن يفي به نظام توكن سلسلة البناء الحديثة.

أقل امتياز مفيد فقط إذا كان قابلاً للمراقبة

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

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

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

مواد توكن الوصول اللاحقة لـ Docker علىhttps://docs.docker.com/security/access-tokens/https://docs.docker.com/enterprise/security/access-tokens/تشير نحو نموذج أكثر مساءلة لأنها تؤكد على الأذونات والإدارة والمراقبة والتخزين الآمن. نفس الفكرة تظهر في ضوابط مؤسسة GitHub وBitbucket. ليس كافيًا إعطاء المستخدمين طريقة لإنشاء التوكنات. يجب على المنصات جعل نطاق التوكن مفهومًا قبل الإنشاء، ومرئيًا أثناء الاستخدام، وقابلاً لإعادة البناء بعد التعرض.

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

تحمل صور الحاويات الثقة النهائية

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

يعزز العمل الأكاديمي بيئة المخاطرة الأوسع. تحليل نقاط الضعف لعام 2020 لصور Docker Hub علىhttps://arxiv.org/abs/2006.02932درس آلاف الصور ووصف Docker Hub كمستودع صور رئيسي. دراسة 2023 للأسرار في صور الحاويات علىhttps://arxiv.org/abs/2307.03958وجدت أن الأسرار المكشوفة في صور الحاويات يمكن أن يكون لها تأثير في العالم الحقيقي عبر الشهادات وأسرار API والمضيفين. لا تثبت هذه الدراسات أي شيء عن حادث قاعدة بيانات Docker Hub لعام 2019. تظهر لماذا تعتبر سجلات الصور وقطع أثر الحاويات أسطح عالية العواقب لسلسلة توريد البرمجيات.

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

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

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

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

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

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

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

رابعًا، احتاج العملاء إلى التحقق من نظافة بيانات الاعتماد. إعادة تعيين كلمة المرور مهمة إذا كانت كلمات المرور المشفرة ضمن النطاق. لكن توكنات OAuth لمزود المصدر، وتوكنات الوصول إلى Docker Hub، وأسرار CI/CD، ومفاتيح النشر، وأسرار خطافات الويب، وبيانات اعتماد السجل لها دورات حياة مختلفة. ورقة الغش لإدارة الأسرار من OWASP علىhttps://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.htmlمفيدة هنا لأنها تعالج إدارة الأسرار كتخزين وتوفير وتدقيق وتدوير والتحكم في دورة الحياة، وليس إعادة تعيين لمرة واحدة.

خامسًا، احتاج العملاء إلى التحقق من الحوكمة المستقبلية. قيود الوصول لتطبيقات OAuth في مؤسسة GitHub علىhttps://docs.github.com/en/organizations/managing-oauth-access-to-your-organizations-data/about-oauth-app-access-restrictionsيمكن أن تمنع وصول تطبيق OAuth غير المدار. توكنات الوصول لمؤسسة Docker علىhttps://docs.docker.com/enterprise/security/access-tokens/يمكن أن تكون محددة النطاق للمستودعات وإجراءات الإدارة. أذونات توكن على مستوى المستودع في Bitbucket علىhttps://support.atlassian.com/bitbucket-cloud/docs/repository-level-access-token-permissions/يمكن أن تحد من سلطة التوكن. هذه الضوابط تقلل نصف قطر الانفجار عند تعرض التكامل التالي.

ما يجب أن يثبته الإصلاح الدائم

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

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

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

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

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

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

المساءلة تتبع بيانات الاعتماد وليس الحساب فقط

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

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

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

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

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

ليس الافتراض المخالف عدم وقوع حادث، بل عدم وجود مسار صامت لسلسلة التوريد

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

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

هذا التخصيص لا يدعم اللوم غير المدعوم. السجل العام لا يثبت أن مستودعات مصدر Docker Hub تم تغييرها أو أن الصور تم اختراقها. يثبت أن حيازة توكن التكامل لـ Docker خلقت واجب مساءلة أوسع من حدث كلمة مرور عادي. السؤال الصحيح ليس "هل تم تأكيد كل سيناريو أسوأ حالة؟" السؤال الصحيح هو "ما الأدلة التي أغلقت كل سيناريو، ومن كان يمكنه رؤيتها؟"

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