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

ملخص

• حادثة الوصول غير المصرح به لـ Docker Hub في 2019 أصبحت اختبارًا للمساءلة في سلسلة توريد الحاويات لأن التقارير العامة أعادت نشر إشعار Docker الذي يفيد بالوصول إلى قاعدة بيانات واحدة تخزن مجموعة فرعية من بيانات المستخدم غير المالية، وتعرض حوالي 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 الحالية. رابط دعم 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 ومستودع التعليمات البرمجية. يمكن أن يكون لهذا الجسر آثار قراءة أو كتابة اعتمادًا على أذونات المزود ونموذج التكامل. توثيق GitHub لـ OAuth على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/يشرح توليد الرمز وانتهاء الصلاحية والأذونات والإدارة. توثيق رمز الوصول للمؤسسة علىhttps://docs.docker.com/enterprise/security/access-tokens/يؤكد على أذونات المستودع المحددة وأذونات الإدارة والتدوير ومراقبة استخدام الرمز والتخزين الآمن. مقال 2019 لـ Docker حول رموز الوصول الشخصية علىhttps://www.docker.com/blog/docker-hub-new-personal-access-tokens/أطر الرموز كبديل لكلمات المرور ولبنة بناء للتحكم المتقدم في الوصول. مقال 2021 لـ Docker حول الرموز المحددة النطاق على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يعكس الاتجاه العام نحو ممارسات تطوير آمنة مدعومة بالأدلة. ورقة OWASP لأمان CI/CD على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. إذا أثار تعرض رمز أولي عدم يقين حول المصدر أو سلامة الصورة، قد لا يعرف المستهلك النهائي أي افتراض يجب اختباره.

العمل الأكاديمي يعزز بيئة المخاطر الأوسع. تحليل الثغرات لصور Docker Hub لعام 2020 على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، والأنظمة النهائية المتأثرة بتلك الحسابات. يمكن أن تكون فئة صغيرة حسب نسبة المنصة مهمة إذا كانت بعض الحسابات تدير صورًا مستخدمة على نطاق واسع أو بناءات مؤسسة خاصة.

ما كان يجب أن يتمكن العملاء من التحقق منه

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

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

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

رابعًا، احتاج العملاء إلى التحقق من نظافة بيانات الاعتماد. إعادة تعيين كلمة المرور مهمة إذا كانت كلمات المرور المشفرة في النطاق. لكن رموز 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 خلقت واجب مساءلة أوسع من حدث كلمة مرور عادي. السؤال الصحيح ليس "هل تم تأكيد كل سيناريو أسوأ حالة؟" السؤال الصحيح هو "ما الأدلة التي أغلقت كل سيناريو، ومن يمكنه رؤيتها؟"

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