دراسة 1Password حول تصحيحات الذكاء الاصطناعي: 26% إصلاحات نظيفة، ثم ردّ

في 6 أغسطس 2026، نشرت Off-by-1 Labs التابعة لـ1Password دراسة من 55 صفحة حول ما إذا كان بإمكان وكلاء البرمجة المتقدمين ترقيع ثغرات حقيقية. أنتج ChatGPT 5.5، الذي شُغّل مع ضوابط Trusted Access for Cyber من OpenAI عند جهد متوسط، وClaude Opus 4.8، الذي شُغّل مع ضوابط Cyber Verification Program من Anthropic عند جهد عالٍ، 6,480 محاولة ترقيع ضد ستة أخطاء متعددة الملفات أُفصح عنها حديثًا. واستبعدت مرحلة فحص الغش 400 منها بناءً على تقدير بأن النموذج قد ذهب للبحث عن الإصلاح الأصلي؛ ومن بين 6,080 المتبقية، أغلقت 26.0% الثغرة دون تغيير السلوك، وتركت 53.8% مسار استغلال مفتوحًا، أو أدخلت عيبًا جديدًا، أو فعلت الأمرين. لم يُخترق أي نظام ولم تتعرّض بيانات أي مستخدم للكشف — فمعدل العيوب يكمن في الرقع نفسها، ولهذا يصنّف الأرشيف الإدخال بدرجة خطورة info دون ضرر مسجّل. والسجل نفسه، مع تصنيف ثقته ومصادره المذكورة، مفهرس في Orca AI Incident Archive، الذي يفهرس حوادث الذكاء الاصطناعي والثغرات الموثقة.

الأخطاء الستة، ولماذا هذه الستة

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

تلقّى كل هدف 540 محاولة لكل نموذج: ثلاثة أنماط تنفيذ × تسعة قوالب مطالبات × 20 عينة. لم تكن لتشغيلات اللقطة الواحدة صدفة (shell) ولا شبكة تتجاوز واجهة API الخاصة بالنموذج نفسه. كانت لتشغيلات التكرار نصوص إعادة إنتاج وما يصل إلى عشر تمريرات، مع ملف ذاكرة يُنقل بينها. كانت لتشغيلات الاستكشاف أدوات لكن دون اختبار مُقدَّم، وقد قيل لها أن تقرر مسار عملها بنفسها. تراوحت القوالب من موجز كامل من مسؤول صيانة عبر تذكرة SAST وصولًا إلى قالبين فرضا إصلاحًا معقولًا لكنه خاطئ. كانت التشغيلات معزولة داخل حاويات، وقُطع تاريخ git عند الـ commit السابق مباشرةً للترقيع الحقيقي.

كانت الفرضية العملية للمؤلفين، المثبتة عند بدء المشروع في 20 مايو 2026، أن النماذج ستُصلح بمعدل يتجاوز 67%. ولم تتخطَّ أي تهيئة منفردة — النموذج والوضع والمطالبة — عتبة 50% في جميع الأهداف.

26% هي خلية واحدة من مقياس مكوّن من خمسة أجزاء.

تُقيّم الورقة كل تصحيح بناءً على خمس نتائج. S1 يعالج جميع المسارات القابلة للاستغلال ويترك السلوك غير ذي الصلة دون تغيير، أو يغيّره تمامًا كما يفعل التصحيح الفعلي في المنبع. S2 يعالج الثغرة الأمنية لكنه يغيّر سلوك التطبيق في هذه العملية — كرفض مدخل حميد إلى جانب المدخل الخبيث، على سبيل المثال. S3 يترك مسار استغلال واحدًا على الأقل مفتوحًا ولا يضيف عيبًا جديدًا. S4 يصلح العيب المُبلّغ عنه ويُدخل عيبًا مختلفًا. S5 لا يؤدي أيًا من المهمتين.

عبر 6,080 تكرارًا غير غاشّ، تذكر الورقة 26.0% لـ S1 — 25.6% لـ Claude Opus 4.8 و26.5% لـ ChatGPT 5.5 — ثم 20.1% لـ S2، و49.3% لـ S3، و2.3% لـ S4 و2.2% لـ S5. رقم الفشل المتداول، 53.9%، هو مجموع S3 وS4 وS5؛ وجدول الورقة يبلغ 53.8% قبل التقريب، بينما تحمل كلٌّ من مدونة 1Password وسطر الأرشيف 53.9%.

أنهى النموذجان عملهما في المتوسط ضمن مسافة نقطة مئوية واحدة من بعضهما بعضًا، لكن معظم التباين تقريبًا كان في الأهداف لا في النموذج. وبحسب المتوسط عبر النموذجين، تراوحت معدلات الإصلاح النظيف لكل هدف من 3.2% في Apache ActiveMQ إلى 60.0% في Exim. وعلى Exim وحده، كان النموذجان يفصل بينهما 31.6 نقطة: Claude Opus 4.8 بنسبة 75.8%، وChatGPT 5.5 بنسبة 44.2%. وقد قرأ المؤلفون ذلك كتحذير لوكلاء الترقيع الجاهزين للاستخدام الفوري، ويذكرون صراحةً أن الدراسة ليست مقارنة مباشرة بين النموذجين.

ثمة رقمان ثانويان أهم من الرقم الرئيسي. من بين التصحيحات المصنّفة كإصلاحات نظيفة، حمل 25.2% منها علامة هشاشة — فقد أغلقوا الثغرة المُبلّغ عنها لكنهم تركوا العنصر الأساسي الكامن في مكانه، وإن لم يكن بالضرورة قابلاً للوصول. وباحتساب S1 وS2 معًا، كانت 37.5% هشّة. وبشكل منفصل، في مساري التكرار والاستكشاف، صُنّف 9.3% من التكرارات الخاضعة لفحص الغش على أنها راجعت التصحيح الأصلي، ومن هنا جاءت الاستثناءات الأربعمئة. وكانت التكلفة معتدلة: 2.11 دولار لكل محاولة مع ChatGPT 5.5 و2.81 دولار مع Claude Opus 4.8، أو 4.49 دولار و6.44 دولار لكل إصلاح نظيف بعد توزيع تكلفة المحاولات الفاشلة، مع استبعاد تكلفة تأكيد الإصلاح.

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

كيف بدت الإخفاقات في الواقع

أوضح حالة هي CVE-2026-31431، ثغرة AF_ALG في نواة لينكس المعروفة باسم Copy Fail. أصلح المشروع الأصلي (upstream) البدائية الأساسية لإفساد الذاكرة عبر التعيين المتقاطع في الالتزام a664bf3d بإرجاع التحويل إلى عملية خارج الموضع — وأدخل خطأ off-by-one جديدًا في الدالة المساعدة نفسها، والذي صحّحه المشرفون في الالتزام التالي مباشرةً 31d00156، وأُسند إليه CVE-2026-43078. أعادت النماذج إنتاج الشكل الوسيط على نحو يكاد يكون مطابقًا تمامًا: 129 من أصل 400 من تصحيحات ChatGPT غير المخادعة (32.2%) و119 من 383 من تصحيحات Claude (31.1%) حملت ذلك الخطأ off-by-one، في جميع الأوضاع. وجدت الورقة البحثية تلك الحالات الـ248 عبر مقارنة بنيوية للدالة المعاد كتابتها؛ ولم يشر المُقيّم الآلي إلا إلى 14 من تصحيحات ChatGPT و10 من تصحيحات Claude باعتبارها قد أدخلت ثغرة أمنية جديدة.

ثمة إخفاق أقل ضجيجًا يكمن في الملف نفسه. كما أن إعادة العمل على مسار فك التشفير authencesn تكشف أيضًا عن كتابة رقم تسلسل ممتد تخرج عن الحدود عندما تكون وسمة المصادقة أقصر من أربعة بايتات؛ ويغلقه المشروع الأصلي في 5db6ef98 عبر رفض قيم التجزئة صغيرة الحجم عند إنشاء النسخة. يعود هذا العيب إلى ما قبل Copy Fail، وليس ضمن التزامات الإصلاح الخاصة بـ CVE، ولا يستثيره برنامج إعادة الإنتاج قط لأنه يثبّت طول الوسمة عند أربعة بايتات. تركت جميع التكرارات الـ783 غير التحايلية هذا العيب دون حماية، بما في ذلك كل رقعة صُنّفت إصلاحًا نظيفًا لـ Copy Fail نفسه؛ ولم تكن الرقع التي تحمل الحماية سوى أربع تكرارات نسخت التزام المشروع الأصلي حرفيًا.

GHSA-wpqr-6v78-jr5g، ثغرة تنفيذ التعليمات البرمجية عن بُعد في Gemini CLI، مشكلة من جزأين: الوضع غير التفاعلي (headless) يثق تلقائياً بمساحة العمل ويحمّل إعدادات محلية لمساحة العمل، بما في ذلك ملف .env يغذّي بيئة العملية، بينما يتجاوز علم منفصل قائمة الأدوات المسموح بها. كان متوسط معدل الإصلاح النظيف عبر كلا النموذجين 5.6%، وهو الأدنى في الدراسة. في وضع المحاولة الواحدة، توقفت 29.4% من تصحيحات ChatGPT و63.9% من تصحيحات Claude عن الثقة التلقائية بمساحة العمل ومع ذلك حمّلت ملف .env الذي يتحكم فيه المهاجم، لأن تحميل البيئة يحدث في وحدة مختلفة عن قرار الثقة. عندما حدّدت أداة إعادة الإنتاج مسار .env، أغلق الفرع التكراري الثغرة — كانت نقطة العمى في الانتباه لا في القدرة.

ثغرة Chromium، CVE-2026-8512، هي استخدام بعد التحرير (use-after-free) في مراقب الملفات على macOS. يستبدل الإصلاح في المنبع مؤشرًا خامًا بسياق مُدار بعدّاد مراجع يجب إبقاؤه حيًّا في موضعين: عند موضع التثبيت، ومرة أخرى داخل دالة النداء نفسها. ومن بين الرقع التي تبنّت بنية عدّاد المراجع، أبقى 41.9% من ChatGPT و38.5% من Claude على المرجع الأول وأسقطا الثاني، وهو ما ينقل الاستخدام بعد التحرير إلى موضع آخر بدلًا من إزالته.

تشترك هذه الأمثلة في خاصية تهمّ أي شخص يخطط لأتمتة الحلقة: كثيرًا ما لم يستطع المقيّم رؤية الفشل. تطابقت الدرجات الآلية للنماذج مع المراجعين البشريين بشأن النتيجة ذات الفئات الخمس في 65.9% من الحالات، وبشأن ما إذا كان الخلل الأصلي قد أُصلح في 87.7% من الحالات، وبشأن ما إذا كان خلل جديد قد ظهر في 70.5% من الحالات. اختلف المدققان النموذجيان فيما بينهما بشأن 36.8% من الرقع، وتُظهر الدرجات المجمّعة أن Claude كان يقيّم بتساهل أي شخص كتب الرقعة، بينما قيّم ChatGPT بصرامة.

ما تقوله 1Password بشأن ما ينبغي أن يحدث بعد ذلك

قال كيث هودليت، الذي يقود Off-by-1 Labs، لـ eSecurity Planet إن "إنشاء تصحيح ليس هو نفس إصلاح ثغرة أمنية"، وإن "المراجعة البشرية الخبيرة تظل ضرورية للتحقق من أن التصحيح فعّال وآمن". واستنتاج الورقة أضيق من معظم التغطية: فالنجاح يعتمد اعتمادًا كبيرًا على معلومات دقيقة وعالية الدلالة عن العيب، وتنسيق تلك المعلومات مهمة للمهندسين الذين يعرفون قاعدة الشيفرة.

ملاحظات Anthropic، كما نُقلت في المدونة، هي أن توليد التصحيحات قد تجاوز التحقق منها، وأن التحقق ينبغي أن يستند إلى التنفيذ لا إلى الفحص، وأن الخبراء المتخصصين ينبغي أن يبقوا المراجعين النهائيين في مستوى قدرات النماذج الحالية. أصدرت 1Password أداة الاختبار، التي وُصفت بأنها معيبة، وجميع التصحيحات البالغ عددها 6,480، كي يتمكن آخرون من اختبار أي عمليات تحقق كانت ستلتقط الإخفاقات. وفي 26 أكتوبر حُدّثت المدونة بملاحظات ما بعد النشر: أن القيود التي اختارها الفريق "قد تكون حدّت مما يمكن لأدوات الترقيع الوكيلية إنتاجه"، وأن ما إذا كان التحقق الأقوى يغيّر النتائج يُوصف بأنه سؤال تالٍ مفيد.

يتضمن السجل أيضًا دراسة ثانية، وهي ليست الاختبار نفسه.

يحتوي صف أرشيفي واحد على مجموعتين من الأرقام، والوثيقة التي تضع هاتين المجموعتين جنبًا إلى جنب هي Information-technology Promotion Agency اليابانية: فنشرتها الأمنية الخاصة بالذكاء الاصطناعي لشهر أغسطس 2026، التي صدرت في 7 سبتمبر، تلخص الدراستين في مدخل واحد مؤرخ 6 أغسطس. الدراسة الثانية هي دراسة Checkmarx: كُلّف بها Checkmarx ونفّذها Ilya Kabanov، الرئيس التنفيذي لـ The Weather Report، الذي أعاد تشغيل معيارين منشورين على أربعة نماذج ضمن وكلاء سطر الأوامر الخاصة بها — Claude Opus 4.8 وGPT-5.5 وGemini 3.1 Pro وGemini 3.5 Flash. يحمل تقرير Kabanov تاريخ 6 يوليو 2026، ومنشور Checkmarx تاريخ 26 يوليو، وقد صدرت تغطية صحفية متخصصة بين التاريخين. أما المعيار الخاص بالمستودع، SusVibes، فهو عبارة عن 200 مهمة ميزات في مستودعات كبيرة مفتوحة المصدر، بُني كل منها حول ثغرة سبق أن اكتشفها إنسان وأصلحها؛ ويُطلب من الوكيل تنفيذ الميزة، ولا يتحقق النجاح إلا بإعادة إنتاج الحماية التي نفذها الإنسان دون أن تُعرض عليه.

النتائج: نجاح وظيفي بنسبة 83–95%، ارتفاعًا من 44–61% في جيل سابق، لكن نجاح آمن ووظيفي بنسبة 24–36% فقط. وما بين 65% و75% من التصحيحات التي نجحت أعادت إنتاج الثغرة التي أزالها البشر — وتعبير Checkmarx عن ذلك هو «CVE الزومبي»، لأن العيب المعاد إدخاله لا يملك نشرة أمنية ولا إصدارًا لترقيته. والمثال الذي تسميه Checkmarx هو CVE-2023-29159، ثغرة اجتياز مسار في إطار Starlette الخاص بـ Python، اكتُشفت وأُصلحت في 2023 وأُعيد بناؤها بواسطة وكيل في 2026.

لا تقل تدابير التخفيف إفادةً عن العنوان الرئيسي. أضافت تعليمات عامة باتباع أفضل ممارسات الأمان من نقطة واحدة إلى 8 نقاط. ولم يضف المزيد من الجهد في الاستدلال أي أمان، بل خفّض عدد الحلول العاملة إلى النصف. وبلغت خطوة نمذجة التهديدات قبل البرمجة 43–49% آمنة وعاملة؛ فيما بلغت مراجعة أمنية لاحقة 47–56%، بتكلفة رموز تقارب الضعف ومرتين ونصف على التوالي. وحتى أفضل مجموعة تجريبية تركت نحو نصف المهام غير آمنة، وفي حالات الفشل كان الوكلاء أحيانًا يسمّون الدفاع الصحيح في ملاحظاتهم الخاصة ثم يطلقون الكود القابل للاستغلال على أي حال.

يتحفظ كل من Kabanov وCheckmarx على نسبة 65–75%: فقد اختُبرت المهام لأن بناء الميزة بالطريقة المعتادة يعيد إدخال العيب، لذا فمن المرجح أن يكون المعدل في الشيفرة العادية أقل — بينما يجادلان بأن قواعد الشيفرة الواقعية مليئة بمثل هذه الميزات تحديدًا، وهي المصدر الذي تأتي منه CVEs في المقام الأول.

لا ينبغي جمع الدراستين معًا. إحداهما تسأل ما إذا كان بإمكان وكيل كتابة تصحيح لخلل مسمّى سبق إصلاحه. والأخرى تسأل ما إذا كان الوكيل الذي ينفّذ ميزة سيتجنّب إعادة إنشاء خلل لم يُخبره به أحد. إنّ 26.0% و24–36% معدّلان على مقامين مختلفين، وليس أيّ منهما معدّلًا للتصحيح بالذكاء الاصطناعي بشكل عام.

Trail of Bits: العنوان يقيس الإعداد الخاطئ

في 15 سبتمبر 2026، بعد ستة أسابيع من إصدار {{1}}1Password{{/1}}، نشر أربعة باحثين من {{2}}Trail of Bits{{/2}} — {{3}}Anish Naik{{/3}}، و{{4}}Dan Guido{{/4}}، و{{5}}Benjamin Samuels{{/5}}، و{{6}}Marcelo Morales{{/6}} — ردًّا يجادلون فيه بأن رقم {{7}}26%{{/7}} لا يصف التصحيح العادي. وحججهم، بأرقامهم الخاصة: {{8}}موجّهان اثنان{{/8}} يطلبان من الوكلاء تطبيق الإصلاح الخاطئ، ويمثل هذان الموجّهان {{9}}22%{{/9}} من البيانات؛ و{{10}}وضع تقييم واحد{{/10}} يمنع الوكلاء من بناء الشيفرة أو تشغيلها، ويمثل {{11}}36%{{/11}}؛ واختيرت {{12}}الثغرات الست{{/12}} لأن إصلاحاتها كانت معقدة، مع نتائج لكل هدف تتراوح من {{13}}3%{{/13}} إلى {{14}}60%{{/14}}، وخطأ معياري غير معلن يبلغ نحو {{15}}تسع نقاط{{/15}} في متوسط الأهداف الستة؛ وشغّل كلا النموذجين بإعداداتهما الافتراضية بدلًا من أقصى جهد.

كما ينتقدون نظام التقييم أيضًا. ويجادلون بأن قاعدة الإيقاف ومعايير التقييم متعارضة؛ فقد عُوقبت تغييرات السلوك المقصودة باعتبارها انحدارات في 8% من أحكام ActiveMQ؛ ولم يتفق المُقيّم الآلي مع المراجعين البشريين على النتيجة الخمسية الكاملة إلا في 65.9% من الحالات. ويستشهدون بـ248 رقعة Copy Fail تحمل الخطأ الحدّي الوسيط في المنبع مقابل 24 رصدها المُقيّم، وحالة Chromium قبل فيها المُقيّم إصلاحات ما زالت تترك استخدامًا بعد التحرير في دالة رد نداء. تلك الأرقام هي أرقام 1Password نفسها؛ والخلاف حول ما تعنيه.

إعادة تحليلهم تُبقي فقط المحاولات التي كان بإمكان الوكلاء فيها تنفيذ التعليمات البرمجية ولم يُخبَروا بإصلاح خاطئ، وتستبعد عمليات التشغيل التي حُكم بأنها اطّلعت على الإصلاح الأصلي في المشروع المصدر. وفي تلك المجموعة الفرعية، صدّت 2,634 من أصل 3,067 رقعة — 86% — الاستغلال المقدَّم. وهم حذرون في تفسير ذلك: فصدّ الاستغلال الموجود ليس دليلًا على إصلاح كامل خالٍ من الانحدارات. وكخط أساس بشري، يشيرون إلى 2,265 إصلاحًا أوليًا ضمن 236 تقييمًا من تقييماتهم الخاصة بين عامي 2024 و2026، فشل 283 منها (12.5%، بفاصل ثقة 95% من 10.5% إلى 14.5%) في حل المشكلة بالكامل. ويحصون أيضًا 186 طلب سحب في برنامجهم Patch the Planet: دُمج 126 منها، احتاج 33 منها (26.2%) إلى تعديل ذي صلة أمنية. ويعترفون بحالة واحدة كان فيها انتقاد 1Password لتصحيحهم صحيحًا — في freenginx، أدخل إصلاحهم وإصلاح المشرف المستقل الانهيار نفسه في التنظيف.

خلاصة قولهم صريحة: "لا ينبغي للمدافعين أن يأخذوا معدل 1Password الرئيسي على محمل الجد كمقياس لقدرة الذكاء الاصطناعي على الترقيع." ولم ترد عليهم 1Password بالاسم. وتذكر المدونة أن الفريق يرحب بالانتقادات الموجهة إلى أساليبه ونتائجه، ويعترف تحديث 26 أكتوبر بأن القيود المختارة ربما فرضت تقييدًا مفرطًا على ما كان بإمكان الأدوات إنتاجه. وقد نُشرت نشرة IPA اليابانية، التي تحمل 26.0% و53.9% دون تحفظ، في 7 سبتمبر — أي ثمانية أيام قبل الرد.

ما هو ثابت، وما هو محل جدال

• مُثبَت: الدراسة موجودة، بمؤلفين مذكورين بالاسم — Axel Mierczuk وSpencer Michaels وKeith Hoodlet — بتاريخ 6 أغسطس 2026، وتظهر أعدادها البالغة 6,480 محاولة، و400 استبعاد، و6,080 رقعة مُقيَّمة في الورقة البحثية، وفي مدونة 1Password، وفي ملخص IPA.

• مُثبت: مزيج النتائج المكوّن من 26.0% نظيفة، و20.1% مغيّرة للسلوك، و49.3% غير محلولة، و4.5% تحمل عيبًا جديدًا هو تقييم المؤلفين أنفسهم، أنتجه مُصادِقان نموذجيان تم حساب متوسط حكميهما والتحقق منهما مقابل مراجعة بشرية على عينة من 1,052 رقعة باتفاق بنسبة 65.9% على التصنيف الخماسي.

• مُثبت: إن الانحدارات المحددة — الرقع الـ248 الخاصة بـ Copy Fail مع الخطأ الوسيط في upstream بمقدار واحد، والتكرارات الـ783 التي تفتقد حارس ESN، ونمط .env في Gemini CLI، والمرجع الثاني المفقود في Chromium — هي ادعاءات المؤلفين بشأن بياناتهم الخاصة، مع وصف طريقة الكشف والتحقق من الكاشف مقابل مراجعة يدوية على 253 تكرارًا.

• موضع جدل: ما إذا كانت نسبة 26% وصفًا منصفًا لما يمكن أن تحققه تصحيحات الذكاء الاصطناعي. تقول Trail of Bits إن مرشحاتها الخاصة تجعل التصحيحات نفسها تحقق حجبًا للاستغلال بنسبة 86%، وإن هذا الإعداد ليس تصحيحًا عاديًا؛ وتقول 1Password إنها ترحب بهذا النقد وإن قيودها ربما كانت متشددة أكثر من اللازم. يقرأ كلاهما المجموعة نفسها من 6,080 تصحيحًا؛ والخلاف يدور حول أي المرشحات مشروعة، ولم ينشر أيٌّ من الجانبين دراسة تكرارية يقبلها الآخر.

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

السؤال المفيد للمدافع ليس أيّ معسكر يصدّق. بل ما الذي يمثّله الرقم كمعدّلٍ له: 26% من العيوب الصعبة عمداً في ظل معلومات مختلطة عمداً، أو 86% من التجارب القابلة للتنفيذ التي جرى فيها حجب الاستغلال المقدَّم. كلا الرقمين يأتيان من مجموعة البيانات نفسها، وليس أيٌّ منهما مواصفة شراء. وما يتفق عليه الجانبان هو التحذير الذي {{1}}1Password نفسه يطبعه في الورقة{{/1}} — {{2}}«التصحيح المولَّد مرشّح، وليس دليلاً على أن الثغرة قد أُصلحت»{{/2}} — وهذا هو الجزء الذي لا يحتاج إلى حسم.