عيوب GoAhead في خلفيات TLS تحوّل ترقيع الأجهزة المضمّنة إلى مشكلة تتبّع للمصنّعين

ما الذي يغطيه إفصاح GoAhead فعليًا

من السهل إساءة قراءة إفصاح GoAhead باعتباره ثغرة واحدة تؤثر في كل منتج يتضمن خادم الويب. فالمواد المنشورة تصف ثلاثة عيوب منفصلة في دمج TLS، يرتبط كل منها بخلفية تشفيرية معينة أو بمسار تحقق محدد. أبلغ CERT-In عن المشكلة في 28 أكتوبر، بينما تميّز إرشادات EmbedThis والتحليل التقني الذي أجرته FoxIO بين حالات الفشل، وتربط معالجتها بالإصدار GoAhead 6.1.1. ولهذا التمييز أهمية عملية؛ إذ إن السؤال المطروح أمام مالك الجهاز ليس ببساطة ما إذا كان اسم المنتج يظهر في قائمة ثغرات، بل ما إذا كان الجهاز يحتوي على إصدار متأثر من GoAhead، ويستخدم خلفية TLS المعنية، ويفعّل الإعداد أو مسار البروتوكول الذي يجعل العيب مؤثرًا.

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

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

يتعلق العيب الأول بالبُنى المتوافقة مع OpenSSL وبإبطال الشهادات. وتقول إرشادات EmbedThis الخاصة بـ CVE-2026-115881 إن قائمة إبطال شهادات مُعدّة قد تُحمّل من دون أن يجري فرضها. وفي عملية تعتمد على TLS المتبادل، قد يعني ذلك بقاء شهادة عميل كان يُفترض رفضها بعد إبطالها مقبولةً. ومن ثم يرتبط هذا الأمر ارتباطًا وثيقًا بكيفية استخدام الجهاز لمصادقة العملاء والتحقق من الإبطال؛ فهو لا يعني أن كل اتصال HTTPS يجريه GoAhead معطوب.

أما العيب الثاني فيرتبط بمسار التحقق القديم في LibreSSL. وتصف الإرشادات الخاصة بـ CVE-2026-115884 تجاوزًا لعمق سلسلة الشهادات ضمن إعدادات محددة، يتضمن سلسلة عميل تتجاوز العمق المسموح. وهذه الصياغة مهمة في الفرز؛ إذ يعتمد التعرض ذي الصلة على مسار التحقق وإعداد سياسة الشهادات، لذلك لا يكفي أن يستخدم المنتج LibreSSL وحده لإثبات إمكانية الوصول إلى التجاوز. وتؤثر المشكلة الثالثة في مسار Mbed TLS، وتتعلق بمعاملات مشوّهة لـ Diffie–Hellman ذات الحقل المنتهي في بعض جلسات TLS 1.2، إذ يصف البحث إمكانية فك التشفير بصورة سلبية عند تحقق الشروط المنطبقة.

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

أنماط الأعطال الثلاثة الخاصة بالواجهات الخلفية

من الأفضل فهم الإفصاح بوصفه ثلاثة عيوب منفصلة، يعتمد نطاق كل منها على مكتبة TLS المختارة عند بناء GoAhead. وهذا التفصيل مهم، لأن القول إن «المنتج يستخدم GoAhead» لا يكفي لتحديد السلوك المعني: فقد يُجمَّع خادم الويب المضمَّن نفسه باستخدام واجهات خلفية تشفيرية مختلفة، كما أن مسارات الشيفرة المتأثرة ليست قابلة للتبادل. تتعلق حالة OpenSSL المتوافقة بإبطال شهادات العميل، بينما تتعلق حالة LibreSSL بعمق سلسلة الشهادات، وتتعلق حالة Mbed TLS بمعلمات Diffie–Hellman ذات الحقول المنتهية. لذلك يتطلب كل عيب سؤالاً مختلفاً عن مدى التعرض، وقراءة مختلفة لإعدادات أمان الجهاز.

في البناء المتوافق مع OpenSSL، كان بإمكان GoAhead تحميل قائمة إبطال شهادات (CRL) مُعدّة، من دون فرض تطبيقها أثناء مصادقة العميل. وفي عملية نشر تستخدم TLS المتبادلة، ينشأ بذلك فجوة بين السياسة التي تبدو مطبقة للمسؤول والفحص الذي يُجرى فعلياً: فقد تُقبل شهادة مدرجة على أنها ملغاة، لأن قائمة الإبطال كانت موجودة لكنها لم تُطبَّق كقاعدة رفض. يؤثر العيب في إصدارات GoAhead ذات الواجهة الخلفية لـ OpenSSL من 3.4.5 إلى 6.1.0، بينما تستخدم إصدارات Mbed TLS مساراً منفصلاً لقوائم الإبطال ولا تتعرض لهذا الخلل تحديداً. كما تعتمد الحالة على استخدام نقطة النهاية لـ TLS المتبادلة مع إعداد قائمة إبطال؛ وهذا لا يعني أن كل نقطة نهاية GoAhead المعتمدة على OpenSSL تقبل الشهادات الملغاة. والسؤال العملي هو ما إذا كان الجهاز يدعم تلك السياسة ويرفض فعلياً هوية اختبار ملغاة بعد تطبيق الإعدادات ذات الصلة.

تسلك مشكلة LibreSSL مساراً مختلفاً. فهي تظهر فقط في الإصدارات المبنية باستخدام أداة التحقق القديمة لـ X.509 في LibreSSL، بما في ذلك فروع LibreSSL 3.2.x و3.3.2–3.3.6 المحددة. في الإعداد المتأثر، يطلب GoAhead شهادة عميل، لكنه لا يتحقق من الثقة في الجهة المُصدرة: إذ يكون VERIFY_PEER=1 مفعلاً، بينما يكون VERIFY_ISSUER=0 معطلاً. في هذه الحالة، يمكن لحالة الخطأ السابقة في أداة التحقق أن تؤدي إلى تجاوز حارس العمق، ما يسمح بمرور سلسلة شهادات عميل يتجاوز عمقها الحد المسموح. ويُفترض أن يقيّد عمق سلسلة الشهادات عدد الشهادات التابعة التي يمكن أن تقع بين شهادة العميل والجهة الموثوقة. وإذا جرى تجاوز هذا الحد، فقد يقبل الخادم سلسلة أطول مما قصده المسؤول، فتضعف سياسة كان هدفها تقييد هياكل الإصدار المقبولة.

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

يؤثر عيب Mbed TLS في التفاوض التشفيري، لا في إبطال الشهادات أو سياسة السلسلة. ففي إصدارات GoAhead المتأثرة، تمرر الواجهة الخلفية لـ Mbed TLS طولاً خاطئاً لمُعامل العدد الأولي في Diffie–Hellman ذي الحقل المنتهي. ونتيجة لذلك، يمكن لتبادل TLS 1.2‏ DHE-RSA أن يرسل معاملاً بحجم بايت واحد بدلاً من المعلمة الأكبر المقصودة. وعندما يقبل العميل تلك المعلمات المعيبة، يمكن لمراقب سلبي استعادة الجلسة الناتجة، ما يهزم حماية السرية الأمامية المتوقعة من ذلك التبادل. وتقتصر المشكلة على مسار Mbed TLS وعلى تفاوض DHE ذي الحقل المنتهي المتأثر؛ أما إصدارات OpenSSL فلا تتعرض لهذا الخطأ في التنفيذ.

وبالتالي فإن نطاق هذا الاكتشاف الأخير أضيق مما قد توحي به عبارة «ثغرة في Mbed TLS». فهو لا يثبت إمكانية فك تشفير كل حركة TLS من جهاز GoAhead يستخدم Mbed TLS، ولا أن كل اتصال TLS 1.2 معرض للخطر. والأسئلة ذات الصلة هي ما إذا كانت نقطة النهاية تسمح بتبادل DHE-RSA المتأثر، وما إذا كان العميل يقبل المعلمات المشوهة، وما إذا كانت الجلسة تستوفي الشروط المعرضة للخطر. ويؤدي تجنب DHE ذي الحقل المنتهي إلى إزالة التفاوض الذي تكون فيه المعلمات المشوهة مؤثرة، لكنه لا يغير وضع الجلسات التي سُجلت بالفعل قبل تصحيح الإعداد أو البرنامج الثابت.

تفسّر هذه الاختلافات لماذا قد تكون المعالجة العامة الواحدة مضلّلة. ففرض التحقّق من الإلغاء يعالج الخلل المتوافق مع OpenSSL، بينما تُعدّ إعدادات التحقّق من جهة الإصدار وسلسلة الشهادات سطح التحكم المعني بمسار LibreSSL، حيثما كانت هذه الخيارات مدعومة. أما في حالة Mbed TLS، فيمكن لسياسة حزم التشفير منع التفاوض على DHE باستخدام الحقول المنتهية. عولجت العيوب الثلاثة في المنبع ضمن GoAhead 6.1.1، لكن رقم الإصدار هذا لا يثبت بحد ذاته حالة البرنامج الثابت في منتج مضمّن. فقد تكون الشركة المصنّعة أدرجت المكتبة المصححة، أو نقلت التغييرات ذات الصلة إلى إصدار أقدم، أو أبقت الجهاز على تكامل أقدم مع تغيير الإعدادات المحيطة. لذلك يجب النظر إلى الواجهة الخلفية والإصدار وسياسة المصادقة وتبادل المفاتيح المتفاوض عليه معاً قبل تصنيف نقطة نهاية ما على أنها متأثرة أو مُعالجة.

كيف تثبت التعرّض من دون تخمين

تعامل مع كلمة «GoAhead» بوصفها بداية للتحقيق، لا دليلاً على تأثر الجهاز. يُستخدم GoAhead خادماً مضمّناً للويب والإدارة، لكن وجوده في منتج لا يثبت إصدار المكتبة الدقيق، أو الواجهة الخلفية لـ TLS، أو خيارات البناء، أو إعدادات التحقّق من الشهادات التي يعتمدها ذلك المنتج. السؤال العملي ليس ما إذا كانت الشركة المصنّعة قد شحنت GoAhead من قبل، بل ما إذا كانت صورة برنامج ثابت محددة تحتوي على إصدار ضعيف من GoAhead وتصل إلى أحد مسارات التعليمات البرمجية المتأثرة.

ابدأ بجرد يربط كل منتج بالطراز ومراجعة العتاد وإصدار البرنامج الثابت وواجهة الإدارة وقناة التحديث. ابحث في وثائق المنتج وملاحظات إصدارات البرنامج الثابت وملفات SBOM وبيانات الحزم والتنبيهات الأمنية الصادرة عن الشركة المصنّعة عن مراجع GoAhead أو EmbedThis. إذا كانت الشركة المصنّعة تنشر صورة قابلة للتنزيل، فاحتفظ بالملف الدقيق وبيانات الإصدار الخاصة به؛ إذ إن اسم عائلة المنتج وحده عامّ أكثر من اللازم لإثبات التعرّض. يصف إشعار CERT-In وتنبيهات EmbedThis إصدارات GoAhead المتأثرة والظروف الخاصة بكل واجهة خلفية، بينما يمثّل إصدار GoAhead 6.1.1 نقطة المعالجة ذات الصلة في المنبع. وينبغي مطابقة هذه الأدلة مع البرنامج الثابت المنشور فعلياً، لا مع قائمة بأسماء الشركات المصنّعة أو ادعاء غير موثّق بأن منتجاً ما «يستخدم GoAhead». يوفّر التنبيه الصادر عن CERT-In وملاحظات إصدار GoAhead 6.1.1 خط الأساس لهذه المقارنة.

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

وتكتسب مراجعة الإعدادات أهمية مماثلة. بالنسبة إلى الخلل المرتبط بـ OpenSSL، حدّد ما إذا كان الجهاز يستخدم قوائم إلغاء الشهادات ضمن مصادقة TLS المتبادلة، وما إذا كانت هذه القوائم تُحمّل فقط أم تُفرض فعلياً أثناء التحقّق من الشهادة. وبالنسبة إلى حالة LibreSSL، افحص ما إذا كانت سلاسل شهادات العملاء تُراجَع عبر مسار المدقّق القديم المتأثر، وما إذا كان قد جرى ضبط حدّ لعمق السلسلة. أما في عمليات نشر Mbed TLS، فتحقّق مما إذا كان TLS 1.2 يستطيع التفاوض على تبادل مفاتيح Diffie-Hellman باستخدام الحقول المنتهية، وما إذا كان DHE مفعّلاً لخدمة الإدارة. تحصر هذه الأسئلة التقييم في الظروف الواردة في التنبيهات؛ ولا تبرّر إعلان تأثر كل جهاز تابع للشركة المصنّعة نفسها أو لخط المنتجات نفسه أو يستخدم خادم الويب نفسه. وينبغي استخدام تنبيه OpenSSL وتنبيه LibreSSL وتنبيه Mbed TLS كقائمة تحقق للإعدادات.

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

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

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

ملكية التصحيح والضوابط التعويضية والاستجابة

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

عندما لا تكون الشركة المصنّعة قد نشرت إصلاحاً، اطلب جدولاً زمنياً محدداً للمعالجة، إلى جانب إصدار GoAhead والواجهة الخلفية لـ TLS المضمّنين في البرنامج الثابت المخطط له. ينبغي أن يكون السؤال دقيقاً: هل يستخدم البناء OpenSSL أم LibreSSL أم Mbed TLS؟ وما إصدار GoAhead المضمّن؟ وهل جرى تغيير إعدادات التحقق من الشهادات أو تبادل المفاتيح ذات الصلة؟ يساعد ذلك في التمييز بين التزام حقيقي بإصدار تصحيح وبين تصريح عام بأن المنتج «غير متأثر». كما يمنح المدافعين أساساً لترتيب أولوية الأجهزة التي تكشف واجهات إدارة خارج الشبكات الموثوقة، أو تستخدم TLS متبادلة، أو تحمي جلسات إدارية حساسة.

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

في عمليات نشر LibreSSL، يعتمد نطاق التعرّض على مسار التحقّق القديم والإعدادات التي تسمح بتحقّق شرط عمق سلسلة الشهادات. وتتمثل الاستجابة العملية في تأكيد سياسة التحقّق التي يستخدمها المنتج، وتجنّب افتراض أن ضبط حدّ لعمق السلسلة وحده يوفّر الحماية المقصودة. أما إصدارات Mbed TLS، فتوصية التخفيف الواردة في النشرة أكثر مباشرة: حيثما كان ذلك مدعومًا من المنتج، عطّل تبادل المفاتيح DHE ذي الحقول المحدودة، وفضّل بديلًا متاحًا لا يعتمد على معالجة المعاملات المتأثرة. هذا إجراء مؤقت، وليس بديلًا عن إصلاح البرمجية الثابتة، وينبغي التحقق منه مقابل إعداد TLS الذي يدعمه المنتج قبل نشره.

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

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

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