الانتقال إلى التشفير ما بعد الكمومي: كيف يمكن لأداة PQCensus جرد الأوليات التشفيرية؟

يمكن لحاسوب كمومي قوي أن يكسر أو يُضعف أمان التشفير الحديث، وهذه حقيقة معروفة تضع البنية التحتية لتقنية المعلومات في المؤسسات تحت الخطر [13]. أفضل تخفيف معروف لهذا التهديد هو نقل تقنية المعلومات في المؤسسة إلى حالة التشفير ما بعد الكمومي (Post Quantum Cryptography) [13]. هذا الانتقال صعب لأن تقنية المعلومات في المؤسسات تتألف عادةً من عدة تطبيقات كبيرة ذات ترابطات معقدة [13]. وبسبب تلك الصعوبة، سيتطلب الانتقال خبرة تقنية إلى جانب أدوات جديدة يمكنها أتمتة العملية وتقليل الأخطاء [13]. هذه الحقائق الأربع، مأخوذة بالتسلسل، تصف بدقة الفجوة التي تهدف أداة الجرد إلى سدها: تهديد حقيقي، وعلاج معروف لكنه صعب، وسبب بنيوي يجعل العلاج صعباً، ودعوة إلى أدوات تجعله ممكناً عملياً.

هذا هو السبب العملي وراء الحاجة إلى أداة جرد قبل تغيير أي شفرة: لا يمكن لأحد أن ينقل ما لا يستطيع إيجاده، والتدقيق اليدوي لتطبيقات كبيرة ومترابطة لا يتوسّع (لا يقبل التوسّع). اقتُرحت أداتان في الأدبيات لتلبية هذه الحاجة مباشرة: Inventory Generator الذي ينتج جرداً تشفيرياً لتطبيق مُدخل، وTCS Quantum Risk Analyzer Engine الذي يقيّم تطبيقاً مُدخلاً في مواجهة التهديدات الكمومية [13]. تُقدَّم هاتان الأداتان كزوج: أولاً إيجاد التشفير، ثم تقييم مخاطره [13]. تقسيم العمل هذا مهم لأي بانٍ (builder)، لأنه يفصل بين مشكلتين هندسيتين متمايزتين، الاكتشاف وتصنيف المخاطر، قد يتم دمجهما لولا ذلك في أداة واحدة غامضة.

ثمة قلق منفصل لكنه ذو صلة، وهو أن الشبكات الواسعة (WAN) للمؤسسات تعتمد على تشفير المفتاح العام المعرَّض للخطر الكمومي لمصادقة الأقران وإنشاء المفاتيح لخدمات IPsec وTLS وشبكات WAN المعرَّفة بالبرمجيات [11]. يُظهر هذا أن مشكلة الجرد لا تقتصر على الشفرة المصدرية للتطبيقات: بل تمتد أيضاً إلى إعدادات البروتوكولات على مستوى الشبكة، وهو ما لا يفحصه ماسح على مستوى الشفرة المصدرية مثل PQCensus بشكل مباشر. لذلك، يحتاج أي برنامج انتقال شامل للمؤسسات إلى نوعين على الأقل من عمل الجرد يسيران بالتوازي، أحدهما على مستوى الشفرة المصدرية للتطبيق والآخر على مستوى الشبكة والبروتوكول، ولا يصف أي زعم في هذه الملاحظة أداة توحّد بينهما.

على هذه الخلفية، تضع PQCensus نفسها بشكل ضيق وصريح كإجابة على مستوى الشفرة المصدرية لأربعة أسئلة هندسية: أين يُستخدم التشفير، وما الغرض الذي يخدمه كل استخدام، وأي الاستخدامات ذات صلة بانتقال ما بعد الكمومي، وما الذي يمكن نقله تالياً دون اختلاق هدف عندما تكون الأدلة غامضة [1]. هذا التحديد للنطاق مهم لأي بانٍ: فـ PQCensus ليست مدققاً للشبكة، ولا محرك تصنيف مخاطر عبر مؤسسة كاملة، ولا جهة اعتماد؛ إنها خطوة جرد قائمة على تحليل ساكن يمكن لأدوات أخرى أو مراجعة يدوية أن تُبنى عليها. وقراءة أسئلة PQCensus الأربعة إلى جانب الإطار المذكور على مستوى المؤسسة أعلاه، تُظهر أن PQCensus تجيب فقط على النصف الأول من مشكلة الانتقال الأكبر الموصوفة في أدبيات أدوات المؤسسات، أي نصف "إيجاده"، وليس نصفي "تقييم المخاطر على مستوى المؤسسة" أو "إصلاح طبقة الشبكة".

PQCensus أداة تحليل ساكن محلية [1]. لا تتطلب مفتاح API ولا خدمة مستضافة ولا رفعاً إلى سحابة إلكترونية ولا نموذج لغوي كبير (LLM) [1]. هذا خيار تصميمي له نتائج تشغيلية مباشرة: يمكن لفريق ما تشغيلها داخل شبكة مغلقة أو خط أنابيب بناء (build pipeline) معزول عن الإنترنت دون إرسال الشفرة المصدرية إلى أي مكان، ودون الاعتماد على توفر مزوّد نموذج خارجي أو تكلفته. بالنسبة للمؤسسات ذات متطلبات صارمة لإقامة البيانات أو سرية شفراتها المصدرية، يزيل هذا التصميم المحلي فئة كاملة من أسئلة الموافقة ومخاطر المورّدين التي كانت لتثيرها أداة مسح مستضافة سحابياً أو مدعومة بنموذج لغوي كبير.

ترسم الأداة أيضاً حدوداً صارمة حول ما يفعله الفحص العادي. لا يقوم المسح العادي للمستودع عمداً باستيراد الحزم المستهدفة، ولا تثبيت التبعيات (dependencies) المستهدفة، ولا تشغيل setup.py، ولا خطاطيف دورة حياة الحزمة (package lifecycle hooks)، ولا ملفات Makefiles، ولا سكربتات shell، ولا الاختبارات، ولا الملفات الثنائية، ولا الحاويات (containers)، ولا عمليات البناء العشوائية، ولا يتتبع روابط رمزية (symlinks) خارج جذر الفحص المطلوب [1]. هذا يعني أن الفحص هو مرور للقراءة فقط على مستوى الشفرة المصدرية: لن ينفّذ أي شفرة، ولن يجلب تبعيات طرف ثالث لفحصها ديناميكياً، ولن يتجول خارج المجلد الذي يوجّه إليه المستخدم. وهذه خاصية أمان مهمة لأي شخص يشغّل الأداة على شفرة غير موثوقة أو تابعة لطرف ثالث، لأنها تزيل خطر أن يؤدي الفحص نفسه إلى تنفيذ شفرة عشوائية.

تُصرّح PQCensus أيضاً بوضوح عمّا لن تدّعيه. فهي لا تدّعي اعتماد NIST، ولن تصف مستودعاً بأنه "آمن كمومياً" لمجرد أن الفحص خرج نظيفاً [1]. هذا قيد مهم يجب توصيله لأي طرف معني قد يقرأ خلاف ذلك "صفر اكتشافات" على أنه "آمن". فحص نظيف بموجب هذا التصميم قد يعني إما عدم وجود تشفير ذي صلة في الشفرة المصدرية المفحوصة، أو أن تغطية المحلل لم تصل إلى الشفرة ذات الصلة، والأداة نفسها لا تميّز بين هاتين الحالتين كما قد تفعل جهة اعتماد.

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

المحلل المستقر للغة المصدر في PQCensus قائم على AST لـ Python [1]. هذا يعني أن الأداة تحلّل شفرة Python المصدرية إلى شجرة تركيبها النحوي المجردة وتفحص تلك البنية، بدلاً من مطابقة النص العادي أو التعابير النمطية (regular expressions)، بالنسبة للغة التي تعاملها كجاهزة للإنتاج. العمل انطلاقاً من AST بدلاً من النص الخام يسمح للمحلل بالتفكير في الرموز والاستدعاءات والبنية بدلاً من الأنماط النصية السطحية، وهذا على الأرجح سبب كونه المحلل الوحيد الموصوف بالاستقرار.

التغطية للغات الأخرى، JavaScript/TypeScript وGo وJava وRust وC/C++، توصف بأنها تغطية نصية، وهي تجريبية صراحةً ومتعمَّد أن تكون أقل ثقة [1]. تنص وثائق الأداة نفسها على أن هذا لا يُقدَّم كمعادل للمحلل الخاص بـ Python [1]. ينبغي أن يقرأ البانون هذا على النحو التالي: عاملوا اكتشافات اللغات غير Python كتلميح أولي للتحقيق اليدوي، وليس كاكتشاف بنفس الوزن الإثباتي لاكتشاف قائم على AST لـ Python. التمييز بين التحليل البنيوي (AST) والتغطية النصية مذكور مباشرة في المادة المصدرية، وهو أوضح إشارة متاحة إلى أين تكمن ثقة الأداة فعلياً اليوم.

كل اكتشاف تنتجه PQCensus يحفظ مجموعة محددة من حقول الأدلة القابلة للمراجعة: معرّفات ثابتة للاكتشاف والقاعدة، ومسار المصدر ومداه، ومعلومات الرمز/الاستدعاء، والخوارزمية والغرض، والمحلل ومستوى الثقة، ومراجع القاعدة/المرجعية، ومدخلات المخاطر السياقية وHNDL (الحصاد الآن وفك التشفير لاحقاً، harvest-now-decrypt-later)، وحالة الكبت (suppression)، وأهداف الانتقال، مع تضمين هدف الانتقال فقط عندما تدعم أدلة الغرض تلك المطابقة [1]. قائمة الحقول هذه هي الآلية الأساسية التي تدعم بها الأداة تخطيط الانتقال: فكل اكتشاف ليس مجرد علم إشارة، بل سجل قائم بذاته وقابل للتدقيق يمكن للمراجع أو أداة تالية تتبعه إلى ملف دقيق ومدى سطري وتصنيف خوارزمية/غرض. وبما أن المعرّفات موصوفة بأنها ثابتة، يمكن لفريق ما مقارنة الاكتشافات (diff) عبر عمليات فحص متتالية لنفس المستودع وتتبّع ما إذا كان اكتشاف معين مستمراً أو اختفى أو تم كبته، دون فقدان الخيط بين الفحوصات.

خطوة تصنيف الغرض هي المفصل الذي تدور عليه توجيهات الانتقال. عندما لا يستطيع المحلل تحديد الغرض بثقة، يضع علامة UNKNOWN على الاكتشاف، ولا يتلقى الغرض UNKNOWN هدف انتقال PQC تلقائياً [1]. هذه هي الآلية الملموسة وراء السؤال الهندسي الرابع الذي تسعى الأداة للإجابة عليه: ما الذي يمكن نقله تالياً، دون اختلاق هدف عندما تكون الأدلة غامضة [1]. حالة UNKNOWN هذه ليست فشلاً في الفحص؛ بل رفض متعمد للتخمين، وهو ما يتسق مع موقف الأداة العام المفضّل لفجوة صادقة على إجابة ملفَّقة.

عندما تقترح PQCensus فعلاً هدف انتقال مرشحاً، فإنها حذرة بشأن حالة ذلك الاقتراح. تُوصف أهداف الانتقال المرشحة بأنها توجيه هندسي، لا وعود توافقية جاهزة للتنفيذ الفوري (drop-in) [1]. تُدرج وثائق الأداة نفسها ما لا يزال يحتاج إلى التحقق منه قبل تبنّي أي هدف كهذا: البروتوكول، والبنية التحتية للمفتاح العام (PKI)، ووحدة أمان الأجهزة/إدارة المفاتيح (HSM/KMS)، ودعم الأقران، وحجم الرسالة، ودورة الحياة، والتراجع (rollback)، والقيود التشغيلية [1]. هذه قائمة تحقق طويلة ومحددة، وتشير إلى أن حقل هدف الانتقال هو بداية تحقيق هندسي، وليس نهايته.

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

هذا التحفظ يتسق مع التصميم الجوهري المُعلَن للأداة في القسم الأول: عدم اختلاق هدف عندما تكون الأدلة غامضة [1]. كما يتصل مباشرة بقاعدة الغرض UNKNOWN: إذا تعذّر تحديد غرض استدعاء تشفيري، فلا يُقترح هدف على الإطلاق، بدلاً من تخمينه [1]. القاعدتان معاً تصفان سياسة أساسية واحدة: لا يُبلَّغ عن هدف انتقال إلا عندما تكون سلسلة الأدلة، من موضع الاستدعاء إلى الغرض إلى البديل المحتمل، سليمة من طرف إلى طرف.

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

تُبلغ PQCensus عن الفعالية عبر ثلاث طبقات معيار مرجعي متمايزة ومتزايدة الواقعية، ولكل طبقة حجم عينة خاص بها وشروطها الخاصة؛ ولا ينبغي تجميعها في رقم إجمالي واحد. على طبقة المعيار المرجعي الدلالي الاصطناعي، المكوّنة من 26 حالة و26 اكتشافاً مُصنَّفاً، حققت PQCensus 26 إيجابية صحيحة، و0 إيجابية كاذبة، و0 سلبية كاذبة [1]. هذا اختبار محكوم بالكامل واصطناعي: كل حالة لها تصنيف معروف، وطابقت الأداة كل واحدة منها بدقة. الحصول على درجة كاملة في طبقة اصطناعية مصمَّمة خصيصاً لممارسة أنماط دلالية معروفة هو سلوك متوقّع لمحلل مضبوط جيداً، وينبغي أن يُقرأ كتحقق من أن محرك القواعد يعمل كما هو مصمَّم، وليس كدليل على شفرة عشوائية من العالم الحقيقي.

على طبقة معيار المقاطع الفوقية المنسّقة (curated upstream excerpts)، المكوّنة من 5 مقاطع و6 مواضع استدعاء مُصنَّفة، حققت PQCensus 6 إيجابيات صحيحة، و0 إيجابية كاذبة، و0 سلبية كاذبة [1]. هذه الطبقة تنتقل من الإنشاءات الاصطناعية إلى مقاطع قصيرة مأخوذة من شفرة فوقية حقيقية، لا تزال عينة صغيرة ومنسّقة، لكنها أقرب إلى شكل الشفرة الواقعي من الطبقة الاصطناعية. حجم العينة هنا، خمسة مقاطع وستة مواضع استدعاء، صغير بما يكفي لجعل أي موضع استدعاء واحد مفقود أو مُصنَّف خطأً ينتج عنه درجة أسوأ بشكل واضح، لذا ينبغي قراءة النتيجة الكاملة في ضوء ذلك المقام الصغير.

على طبقة معيار المستودعات الشاملة (end-to-end) ذات الإصدارات المثبتة (pinned)، باستخدام python-jose 3.3.0 مع PyJWT 2.10.1 عبر 96 ملفاً، أنتجت PQCensus 193 اكتشافاً وطابقت 12 من أصل 12 ملاحظة مطلوبة [1]. هذه هي الأكثر واقعية من الطبقات الثلاث: حزمتان حقيقيتان مثبَّتتان بإصدار محدد تم فحصهما بالكامل، بدلاً من مقاطع معزولة. رقم 193 اكتشافاً هو عدد خام لما أظهره الماسح، ورقم 12 من 12 هو مجموعة فرعية من تلك الاكتشافات كان المعيار المرجعي قد حددها مسبقاً كمطلوبة، وقد طابقتها جميعاً. من الجدير ذكره صراحةً أن 193 اكتشافاً إجمالياً مقابل 12 ملاحظة مطلوبة يعني أن غالبية الاكتشافات في هذه الطبقة الواقعية لا تُقيَّم مباشرة مقابل حقيقة أرضية (ground truth) مُصنَّفة في الرقم المُبلَّغ عنه؛ رقم 12 من 12 يثبت أن المجموعة الفرعية المطلوبة والمُصنَّفة استُعيدت بالكامل، لكنه لا يثبت بمفرده رقم دقة (precision) عبر كل الاكتشافات الـ193.

لا يذكر أي زعم هذه الأرقام مقابل أي أداة مرجعية خارجية، لذا لا يمكن الإبلاغ هنا عن رقم دقة مقارن (مثلاً، مقابل dotnet-cbom أو ماسح آخر)؛ فكل رقم يقف فقط مقابل حقيقته الأرضية المُصنَّفة الخاصة به ضمن طبقته الخاصة [1]. ينبغي لأي بانٍ يريد معرفة كيف ستعمل PQCensus على قاعدة شفراته غير المنسّقة الخاصة به أن يعامل الأرقام الثلاثة جميعها كحدود عليا (upper bounds) تم الحصول عليها في ظروف مواتية أو منسّقة أو مثبَّتة، وليست ضمانات تنتقل تلقائياً إلى مستودع عشوائي.

dotnet-cbom أداة منفصلة وذات صلة لنظام بيئي مختلف: تستخدم تحليلاً ساكناً بـ Roslyn لجرد الاستخدام التشفيري، وتصنيف المخاطر الكمومية، وإظهار تقدم الانتقال إلى ما بعد الكمومي، مستهدفةً شفرة .NET [7]. تكتشف التشفير عبر System.Security.Cryptography، والتحقق من JWT، والتعامل مع TLS/الشهادات، وواجهات برمجة ما بعد الكمومي (ML-KEM/ML-DSA/SLH-DSA)، وتُرفق مستوى ثقة اكتشاف لكل نتيجة [7]. تصنّف كل اكتشاف على محورين مستقلَّين، الضعف الكلاسيكي والضعف الكمومي، بدلاً من علامة خطر واحدة [7]. هذا التصميم ثنائي المحور أكثر تفصيلاً من أي مخطط مذكور بخصوص PQCensus، التي تُبلغ عن الخوارزمية والغرض وهدف انتقال حيثما كان مبرَّراً، لكنها لا تُبلغ عن درجة خطر ثنائية المحور في الزعوم المتاحة هنا.

تنتج dotnet-cbom أيضاً مخرجات قابلة للقراءة الآلية والبشرية: CycloneDX 1.6، وSARIF 2.1.0، وMarkdown، وHTML، وملخصاً تنفيذياً [7]. تتبع التغيّر عبر الزمن بواسطة آلية diff/--baseline تختم كل اكتشاف بأنه جديد (New) أو غير متغيّر (Unchanged) أو متراجع (Regressed) أو معفى (Waived) [7]، وتتحقق من صحة CBOMs التي تولّدها بنفسها مقابل مخطط JSON الرسمي لـ CycloneDX 1.6 ومقابل ملف تعريف dotnet-cbom [7]. تكتشف التشفير من طرف ثالث عبر اكتشاف Bouncy Castle وجرد لبيان الحزمة (package manifest) مأخوذ من project.assets.json / PackageReference [7]، وحسب ملف readme الخاص بها فإنها تضم 17 قاعدة [7]. صيغة الخطر الخاصة بها لاكتشاف واحد هي 0.45 ضرب Q زائد 0.35 ضرب C زائد 0.20 ضرب X، تجمع عوامل الخطر الكمومي والضعف الكلاسيكي وتعرّض الاستخدام، مع حدود دنيا فاشلة مغلقة (fail-closed floors) [7]، ودرجة PQC Readiness معرَّفة على أنها 100 ضرب الوزن الآمن مقسوماً على الوزن الإجمالي، محسوبة فقط على الخوارزميات ذات الصلة الكمومية [7]. تقيس دقتها الخاصة عبر معيار دقة قائم على مجموعة نصوص مُصنَّفة (labeled-corpus accuracy benchmark) يشغّل كواشف حقيقية مقابل حقيقة أرضية مؤلَّفة بشكل مستقل، ويُفشل التكامل المستمر (CI) عند أي تراجع [7]. هذه الخاصية الأخيرة، أي بوابة تراجع دقة مدمجة في CI، هي شكل من التحقق المستمر لا يُوصف بخصوص PQCensus في الزعوم المتاحة هنا؛ إذ تُبلَّغ أرقام معيار PQCensus كنتائج نقطية في زمن معين عبر الطبقات الثلاث الموصوفة أعلاه.

هناك توضيحان مهمان هنا. أولاً، المقاطع التي تصف dotnet-cbom لا تصف PQCensus على الإطلاق؛ بل تصف مهمة انتقال قائمة على عقود (contract-based) لوكلاء ترميز (coding agents)، ومولّد dotnet-cbom المنفصل [5]. ثانياً، تُقترح Inventory Generator وQuantum Risk Analyzer Engine الخاصتان بـ TCS كزوج من الأدوات لتطبيقات المؤسسات عموماً، وليس كطريقة تحليل ساكن ذات أرقام دقة/استدعاء (precision/recall) مُبلَّغ عنها في المادة المتاحة [13]. لا يُبلغ أي من هذه المصادر عن معيار مرجعي مشترك، أو قاعدة شفرة مشتركة، أو تشغيل مباشر متكافئ مقابل PQCensus، لذا فإن هذا القسم عرض جنباً إلى جنب لأنظمة مُبلَّغ عنها بشكل منفصل، وليس مقارنة لدقة مقيسة.

خارج نطاق أدوات الجرد على مستوى المصدر، تمس تحديات الانتقال الأوسع أيضاً أبعاداً أخرى لا تغطيها هذه الأدوات. الانتقال القائم على وكلاء الترميز (coding agents)، الذي جُرِّب عبر مهمة قائمة على عقد تنقل موقّع ملفات Go من RSA إلى ML-DSA-44 عبر 160 محاولة في أربعة إعدادات وكلاء محليين، أنتج اثنتي عشرة رقعة (patches) نهائية تجتاز التحقق المحلي لكنها تفشل في المتطلبات الخارجية [5]. لم يزد وصول الفاحص (checker access) من معدل الإتمام الملحوظ في أي مقارنة في تلك الدراسة [5]، وخفض نافذة السياق (context window) لأحد النماذج من 128K إلى 32K خفض عمليات الاجتياز الكاملة من 36/40 إلى 4/40 [5]، وأربع تجارب استكشافية باستخدام مزيجين آخرين من النماذج/الأدوات اجتازت جميع الفحوصات الأربعين، بما في ذلك كلا خطي الأساس [5]. هذه مشكلة متمايزة، أي التحويل الآلي للشفرة، وليست جرداً، وتُبلَّغ عن معيار مرجعي مختلف (مهمة انتقال موقّع Go واحد) عن أي رقم لـ PQCensus. إنها مع ذلك تباين مفيد لأي بانٍ: تُظهر أنه حتى عندما يحدد الجرد بشكل صحيح موضع استدعاء تشفيري وهدف انتقال محتمل، فإن الفعل اللاحق المتمثل في إعادة كتابة الشفرة فعلياً لاستخدام ذلك الهدف هو مهمة منفصلة، ووفقاً لهذه الدراسة، لا تزال عرضة للأخطاء، حيث اجتازت اثنتا عشرة من أصل 160 محاولة الفحوصات المحلية لكنها فشلت في المتطلبات الخارجية [5].

قيمة أداة الجرد تعتمد جزئياً على ما يحدث بعد تحديد هدف انتقال ما، وتشير الأدبيات إلى أن الخوارزميات نفسها ليست قابلة للتبادل من حيث التكلفة. احتياجات الطاقة وعرض النطاق الترددي والكمون لخوارزميات PQC تمتد عبر عدة رتب من الحجم، وهذا كبير بما يكفي للتأثير على عمر البطارية وتجربة المستخدم وتصميم بروتوكول التطبيق [6]. هذه نتيجة مباشرة لأي خطة انتقال تُبنى انطلاقاً من اكتشاف لـ PQCensus: هدف الانتقال المقترح هو خوارزمية مرشحة، لكن ملفها التعريفي للموارد لا يزال يحتاج إلى تقييم منفصل قبل اعتماده على نطاق واسع.

بالنسبة لسياقات الأجهزة المحمولة والمتصلة بالسحابة تحديداً، تُذكر مخططات PQC الشبكية المهيكلة السريعة (fast structured-lattice PQC schemes) كخيار مفضّل للأجهزة المحمولة المتصلة بالسحابة في معظم حالات الاستخدام، حتى عندما تكون تكلفة طاقة إرسال البيانات لكل بت لتلك المخططات مرتفعة نسبياً [6]. تُبيّن هذه النتيجة سبب صحة حذر PQCensus نفسها، أي أن هدف الانتقال هو توجيه هندسي وليس وعداً توافقياً جاهزاً للتنفيذ الفوري [1]: فحتى الخوارزمية المرشحة الصحيحة تقنياً يمكن أن تحمل تكاليف تشغيلية مختلفة جداً بحسب سياق النشر، والمخطط السريع على الجهاز نفسه قد يظل مكلفاً في الإرسال، وهو ما يهم بشكل مختلف لعميل محمول يعمل بالبطارية عنه بالنسبة لخادم.

هذا يعزز أيضاً سبب حفاظ PQCensus على مدخلات المخاطر السياقية وHNDL كحقول أدلة لكل اكتشاف [1]، بما أن التعرّض لخطر الحصاد الآن وفك التشفير لاحقاً (HNDL) وسياق النشر، محمول مقابل خادم على سبيل المثال، كلاهما يؤثر على مدى إلحاح وكيفية انتقال اكتشاف معين، حتى قبل موازنة تكاليف الطاقة وعرض النطاق الترددي [6]. اكتشاف موسوم بتعرّض مرتفع لـ HNDL لكنه موجَّه إلى نشر محمول محدود الموارد يقع عند تقاطع اهتمامين منفصلين، إلحاح الانتقال وتكلفة الخوارزمية البديلة، يجب على البانين موازنتهما معاً بدلاً من كل على حدة.

لا يربط أي زعم اكتشافاً محدداً لـ PQCensus بقياس محدد للطاقة أو عرض النطاق الترددي، لذا تُعرض هذه العلاقة هنا كحقيقتين مُبلَّغ عنهما بشكل منفصل يجب على البانين دمجهما يدوياً: تخبرك PQCensus أين تُستخدم أولية كلاسيكية وما الذي قد يحل محلها [1]؛ وتخبرك أدبيات طاقة الأجهزة المحمولة أن تكلفة موارد البديل لا تزال بحاجة إلى تقييم منفصل قبل النشر [6]. يتطلب الجمع بين الاثنين خطوة يدوية لا يقوم بها أي من المصدرين بمفرده، وينبغي على البانين تخصيص وقت هندسي صريح لذلك بدلاً من افتراض أن هدف انتقال أداة الجرد يأخذ تكلفة النشر في الحسبان بالفعل.

القيد الأكثر مباشرة هو حالة الإصدار: لا يوجد حالياً أي دليل على إصدار رسمي (canonical release) ثابت لـ PQCensus، ولا إصدار على GitHub Release أو PyPI معتمد حسب المادة المصدرية [1]. أي بانٍ يقيّم هذه الأداة اليوم ينظر إلى مشروع دون قطعة إصدار مستقرة وقابلة للاستشهاد بها، وهذا يؤثر على مقدار الاعتماد طويل الأمد الذي ينبغي أن يضعه فريق ما على سلوك إصدار معين دون تثبيت (pin) على التزام (commit) أو بناء (build) محدد.

القيد الثاني هو تغطية اللغات. المحلل الخاص بـ Python فقط هو الموصوف بالاستقرار وبكونه قائماً على AST [1]؛ أما دعم JavaScript/TypeScript وGo وJava وRust وC/C++ فهو تجريبي، قائم على النص، ومتعمَّد أن يكون أقل ثقة، وصريحاً بأنه غير معادل للمحلل الخاص بـ Python [1]. ينبغي على أي مؤسسة ذات قاعدة شفرة متعددة اللغات أن تتوقع ضمانات أضعف بشكل جوهري خارج Python، وألا تفترض أن معدلات الإيجابيات الكاذبة والسلبيات الكاذبة نفسها المُبلَّغ عنها في المعايير المرجعية الموجَّهة نحو Python ستصمد على مستودع Go أو Java.

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

أخيراً، لا يمكن لهذه الملاحظة الإبلاغ عن مقارنة مباشرة مقيسة بين PQCensus وأي أداة أخرى، سواء dotnet-cbom أو Inventory Generator الخاصة بـ TCS أو طرق الانتقال القائمة على وكلاء الترميز، لأنه لا يوجد أي زعم يقدّم ذلك. تقف أرقام كل أداة فقط مقابل معيارها المرجعي وظروفها الخاصة المُبلَّغ عنها: طبقات PQCensus الثلاث [1]، ومعيار دقة مجموعة النصوص المُصنَّفة الخاص بـ dotnet-cbom [7]، ومهمة دراسة وكلاء الترميز ذات 160 محاولة وأربعة إعدادات [5]. أي بانٍ يحتاج إلى قرار مقارن بين هذه الأساليب سيحتاج إلى إجراء مقارنة كهذه مباشرة، على نفس قاعدة الشفرة، إذ لا توجد حالياً في الأدلة المستشهد بها.

1. تأكد من اللغة الأساسية لقاعدة الشفرة المستهدفة قبل البدء. إذا كانت Python، خطط للاعتماد على محلل PQCensus المستقر القائم على AST [1]؛ وإذا كانت تتضمن JavaScript/TypeScript أو Go أو Java أو Rust أو C/C++، خطط لأن تكون نتائج تلك اللغات تجريبية، وأقل ثقة، واكتشافات قائمة على النص تحتاج إلى متابعة يدوية بدلاً من الثقة الآلية [1].
2. هيّئ الفحص ليعمل محلياً، دون مفتاح API أو خدمة مستضافة أو رفع سحابي أو اعتماد على نموذج لغوي كبير، بحيث لا تغادر قاعدة الشفرة بيئتك أبداً [1]. هذا يعني أيضاً أنه يمكنك تشغيله داخل خط أنابيب تكامل مستمر (CI) مغلق دون استدعاءات شبكية خارجية، وهو مفيد لقواعد الشفرات ذات المتطلبات الصارمة للسرية.
3. قبل التشغيل، تحقق من أن الفحص لن ينفّذ أي شيء: يجب ألا يستورد أو يثبّت الحزم المستهدفة، ولا يشغّل setup.py، ولا خطاطيف دورة حياة الحزمة، ولا ملفات Makefiles، ولا سكربتات shell، ولا الاختبارات، ولا الملفات الثنائية، ولا الحاويات، ولا عمليات البناء العشوائية، ويجب ألا يتتبع روابط رمزية خارج جذر الفحص [1]. إذا كانت أداة البناء الخاصة بك تفعل أياً من هذا تلقائياً، عطّل ذلك السلوك خلال مرحلة الفحص، بحيث يبقى الفحص عملية قراءة فقط على مستوى الشفرة المصدرية.
4. شغّل الفحص على جذر المستودع واجمع مجموعة الاكتشافات. يجب أن يحمل كل اكتشاف: معرّفاً ثابتاً للاكتشاف والقاعدة، ومسار المصدر ومداه، ومعلومات الرمز/الاستدعاء، والخوارزمية والغرض، والمحلل ومستوى الثقة، ومراجع القاعدة/المرجعية، ومدخلات المخاطر السياقية وHNDL، وحالة الكبت، وحيثما تدعم أدلة الغرض ذلك فقط، هدف انتقال [1]. خزّن هذه كخط أساس للأدلة، مفهرَساً بالمعرّفات الثابتة بحيث يمكن مقارنة الفحوصات اللاحقة به.
5. افصل الاكتشافات إلى دلوين على الفور: تلك ذات هدف انتقال مملوء، وتلك الموسومة بغرض UNKNOWN دون هدف [1]. وجِّه دلو UNKNOWN إلى المراجعة اليدوية للشفرة؛ لا تحاول نقله تلقائياً، إذ أن الأداة نفسها رفضت اقتراح هدف لأن الأدلة بالضبط لم تدعم واحداً.
6. لكل اكتشاف ذي هدف انتقال، عامله بصرامة كتوجيه هندسي، وليس بديلاً جاهزاً للتنفيذ الفوري [1]. افتح قائمة تحقق لكل اكتشاف تغطي البروتوكول، وPKI، وHSM/KMS، ودعم الأقران، وحجم الرسالة، ودورة الحياة، والتراجع، والقيود التشغيلية [1]، ولا تُغلق عنصر الانتقال حتى يتم التحقق من كل بند.
7. قارن سياق النشر الخاص بكل اكتشاف مُتحقَّق منه مع تكاليف الموارد المعروفة: إذا كانت بيئة الهدف محمولة أو متصلة بالسحابة، لاحظ أن مخططات PQC تتفاوت في الطاقة وعرض النطاق الترددي والكمون بعدة رتب من الحجم [6]، وأن المخططات الشبكية المهيكلة السريعة تُفضَّل عموماً للأجهزة المحمولة المتصلة بالسحابة حتى عند تكلفة طاقة إرسال نسبية مرتفعة لكل بت [6]. سجّل هذا كبند منفصل، إذ أن PQCensus نفسها لا تقيس تكلفة الموارد.
8. تحقق من مخرجات الأداة مقابل طبقات المعيار المرجعي المُبلَّغ عنها قبل الوثوق بها على قاعدة شفراتك الخاصة: تحقق مما إذا كانت حالات اختبارك تشبه الطبقة الدلالية الاصطناعية (26 حالة/26 اكتشافاً مُصنَّفاً، TP 26 FP 0 FN 0) [1]، أو طبقة المقاطع الفوقية المنسّقة (5 مقاطع/6 مواضع استدعاء، TP 6 FP 0 FN 0) [1]، أو الطبقة الشاملة المثبَّتة (python-jose 3.3.0 مع PyJWT 2.10.1، 96 ملفاً، 193 اكتشافاً، 12/12 ملاحظة مطلوبة مُطابَقة) [1]. لا تفترض أن هذه الأرقام تنتقل إلى قاعدة شفرة غير ذات صلة وغير منسّقة، إذ حصل كل رقم في ظل ظروفه الخاصة المحكومة أو المنسّقة.
9. لا تُبلّغ عن فحص نظيف (صفر اكتشافات) على أنه اعتماد أو ادعاء أمان شامل. لا تدّعي PQCensus نفسها اعتماد NIST ولا تصف مستودعاً بأنه آمن كمومياً استناداً إلى فحص ساكن نظيف [1]، وأي تقرير لاحق ينتجه فريقك ينبغي أن يحمل نفس التحفظ بدلاً من ترقية فحص نظيف بصمت إلى ضمان أمان.
10. إذا كانت قاعدة الشفرة تعتمد أيضاً على بنية تحتية شبكية للمؤسسة، مثل IPsec أو TLS أو خدمات WAN المعرَّفة بالبرمجيات التي تصادق الأقران بتشفير مفتاح عام معرَّض للخطر الكمومي، عامل ذلك كمهمة جرد منفصلة خارج نطاق PQCensus [11]، إذ أن الفحص على مستوى المصدر لا يفحص إعدادات الشبكة أو البروتوكول مباشرة.
11. حيثما تم التحقق من هدف انتقال وكانت قاعدة الشفرة بـ Python، فكّر فيما إذا كانت خطوة تحويل شفرة آلية (وكيل ترميز، مثلاً) ستُستخدم لتطبيق التغيير؛ وإن كان كذلك، خصّص ميزانية لفشل التحقق حتى بعد اجتياز الفحوصات المحلية، إذ وجدت دراسة لمهمة انتقال مماثلة من RSA إلى ML-DSA-44 أن اثنتي عشرة محاولة من أصل 160 عبر أربعة إعدادات وكلاء اجتازت التحقق المحلي لكنها فشلت في المتطلبات الخارجية [5].
12. احتفظ بسجل الأدلة الكامل، لا مجرد ملخص نجاح/فشل، لكل اكتشاف يدخل قائمة انتظار انتقال. وبما أن PQCensus تحفظ معرّفات ثابتة للاكتشاف والقاعدة، ومسار المصدر ومداه، وحالة الكبت كجزء من حقول أدلتها [1]، يمكن لمراجع بعد أشهر إعادة فتح المنطق الدقيق وراء قرار نقل اكتشاف أو كبته أو تركه كـ UNKNOWN، وهذا هو الغرض الأساسي من حفظ أدلة قابلة للمراجعة أساساً.

for file in repository (Python, AST-parsed):
    for call_site in file:
        classify(algorithm, purpose)
        if purpose == UNKNOWN:
            record finding (no migration target)
        else:
            record finding (migration target = candidate PQC primitive)
    attach: id, rule id, path, span, symbol/call info,
            analyzer, confidence, rule/authority refs,
            contextual risk, HNDL inputs, suppression state
review UNKNOWN bucket manually
for each finding with a target:
    validate protocol, PKI, HSM/KMS, peer support,
             message size, lifecycle, rollback, ops constraints
    check resource cost for deployment context (mobile/server)