Migración a Criptografía Post-Cuántica: ¿Cómo puede PQCensus inventariar primitivas criptográficas?

Una computadora cuántica potente puede romper o reducir la seguridad de la criptografía moderna, y esto se describe como un hecho bien conocido que pone en riesgo la infraestructura de TI empresarial [13]. La mitigación más conocida para esta amenaza es migrar la TI empresarial a un estado de Criptografía Post-Cuántica [13]. Esta migración es difícil porque la TI empresarial generalmente consiste en varias aplicaciones grandes con interdependencias complejas [13]. Debido a esa dificultad, la migración requerirá experiencia técnica junto con nuevas herramientas que puedan automatizar el proceso y reducir errores [13]. Estos cuatro hechos, tomados en secuencia, describen la brecha exacta que una herramienta de inventario pretende llenar: una amenaza real, un remedio conocido pero difícil, una razón estructural por la que el remedio es difícil, y un llamado a herramientas para hacerlo manejable.

Esta es la razón práctica por la que se necesita una herramienta de inventario antes de cambiar cualquier código: nadie puede migrar lo que no puede encontrar, y la auditoría manual de aplicaciones grandes e interdependientes no escala. Se han propuesto dos herramientas en la literatura para satisfacer esta necesidad directamente: un Inventory Generator que produce un inventario criptográfico para una aplicación de entrada, y un TCS Quantum Risk Analyzer Engine que evalúa una aplicación de entrada contra amenazas cuánticas [13]. Estos se presentan como un par: primero encontrar la criptografía, luego evaluar su riesgo [13]. La división del trabajo es importante para un constructor, porque separa dos problemas de ingeniería distintos, el descubrimiento y la puntuación de riesgo, que de otro modo podrían fusionarse en una sola herramienta opaca.

Una preocupación separada pero relacionada es que las redes de área amplia empresariales dependen de la criptografía de clave pública vulnerable a la computación cuántica para autenticar pares y establecer claves para IPsec, TLS y servicios WAN definidos por software [11]. Esto muestra que el problema del inventario no se limita al código fuente de la aplicación: también abarca la configuración de protocolos a nivel de red, que un escáner de código fuente como PQCensus no examina directamente. Por lo tanto, un programa de migración empresarial completo necesita al menos dos tipos de trabajo de inventario en paralelo, uno a nivel de código fuente de la aplicación y otro a nivel de red y protocolo, y ninguna afirmación en esta nota describe una herramienta que unifique ambos.

En este contexto, PQCensus se posiciona de manera estrecha y explícita como una respuesta a nivel de código fuente a cuatro preguntas de ingeniería: dónde se usa la criptografía, qué propósito sirve cada uso, qué usos son relevantes para la migración post-cuántica, y qué se puede migrar a continuación sin inventar un objetivo cuando la evidencia es ambigua [1]. Este alcance es importante para un constructor: PQCensus no es un auditor de red, un motor de puntuación de riesgo en toda una empresa, ni un certificador; es un paso de inventario de análisis estático sobre el cual otras herramientas o la revisión manual necesitarían construir. Leer las cuatro preguntas de PQCensus junto con el marco a nivel empresarial anterior muestra que PQCensus responde solo la primera mitad del problema de migración más grande descrito por la literatura de herramientas empresariales, la mitad de "encontrarlo", no las mitades de "evaluar el riesgo empresarial" o "arreglar la capa de red".

PQCensus es una herramienta local de análisis estático [1]. No requiere clave API, servicio alojado, carga en la nube ni LLM [1]. Esta es una elección de diseño con consecuencias operativas directas: un equipo puede ejecutarla dentro de una red cerrada o un pipeline de compilación aislado sin enviar código fuente a ningún lado, y sin depender de la disponibilidad o el costo de un proveedor de modelos externo. Para organizaciones con requisitos estrictos de residencia de datos o confidencialidad en torno a su propio código fuente, este diseño solo local elimina toda una categoría de preguntas de aprobación y riesgo de proveedor que un escáner alojado en la nube o respaldado por LLM plantearía.

La herramienta también traza un límite estricto en torno a lo que hace un escaneo normal. El escaneo normal de repositorios no importa intencionalmente paquetes de destino, instala dependencias de destino, ejecuta setup.py, hooks de ciclo de vida de paquetes, Makefiles, scripts de shell, pruebas, binarios, contenedores o compilaciones arbitrarias, y no sigue enlaces simbólicos fuera de la raíz de escaneo solicitada [1]. Esto significa que un escaneo es un pase de solo lectura a nivel de fuente: no ejecutará código, no extraerá dependencias de terceros para inspeccionarlas dinámicamente y no deambulará fuera del directorio al que un usuario lo apunta. Esta es una propiedad de seguridad importante para cualquiera que ejecute la herramienta contra código no confiable o de terceros, ya que elimina el riesgo de que el escaneo en sí mismo desencadene la ejecución de código arbitrario.

PQCensus también es explícito sobre lo que no afirmará. No afirma la certificación NIST, y no etiquetará un repositorio como "quantum safe" simplemente porque un escaneo haya resultado limpio [1]. Esta es una limitación significativa que debe comunicarse a cualquier parte interesada que de otro modo podría leer "cero hallazgos" como "seguro". Un escaneo limpio bajo este diseño puede significar que no existe criptografía relevante en el código fuente escaneado, o que la cobertura del analizador no alcanzó el código relevante, y la herramienta misma no distingue estos dos casos como lo haría una certificación.

Tomados en conjunto, estos tres hechos de diseño, sin dependencia en la nube, sin ejecución de código durante el escaneo y sin afirmación de certificación, describen una herramienta destinada a ser un primer paso conservador e inspeccionable, no un veredicto final sobre la postura post-cuántica de una aplicación [1]. Un constructor que adopte PQCensus debe tratar su salida como un inventario inicial que debe revisarse y ampliarse, no como un artefacto de cumplimiento que cierra por sí solo una auditoría de migración.

El analizador de lenguaje fuente estable en PQCensus es Python basado en AST [1]. Esto significa que la herramienta analiza el código fuente de Python en su árbol de sintaxis abstracta e inspecciona esa estructura, en lugar de hacer coincidencia de texto plano o expresiones regulares, para el lenguaje que trata como listo para producción. Trabajar desde el AST en lugar de texto sin formato permite que el analizador razone sobre símbolos, llamadas y estructura en lugar de patrones de cadena superficiales, que es presumiblemente la razón por la que este es el único analizador descrito como estable.

La cobertura para otros lenguajes, JavaScript/TypeScript, Go, Java, Rust y C/C++, se describe como cobertura de texto, y es explícitamente experimental y deliberadamente de menor confianza [1]. La documentación de la propia herramienta establece que esto no se presenta como equivalente al analizador de Python [1]. Un constructor debe leer esto como: trate los hallazgos que no son de Python como una pista inicial para investigar manualmente, no como un hallazgo con el mismo peso probatorio que uno basado en AST de Python. La distinción entre análisis estructural (AST) y cobertura de texto se establece directamente en el material fuente, y es la señal más clara disponible sobre dónde reside realmente la confianza de la herramienta hoy.

Cada hallazgo que produce PQCensus preserva un conjunto específico de campos de evidencia revisables: identificadores estables de hallazgo y regla, ruta y extensión de fuente, información de símbolo/llamada, algoritmo y propósito, analizador y confianza, referencias de regla/autoridad, riesgo contextual y entradas HNDL (cosechar ahora, descifrar después), estado de supresión y objetivos de migración, con el objetivo de migración incluido solo cuando la evidencia del propósito respalda el mapeo [1]. Esta lista de campos es el mecanismo central mediante el cual la herramienta respalda la planificación de la migración: cada hallazgo no es solo una bandera, es un registro autónomo y auditable que un revisor o una herramienta posterior puede rastrear hasta un archivo exacto, extensión de línea y clasificación de algoritmo/propósito. Debido a que los identificadores se describen como estables, un equipo puede comparar hallazgos entre escaneos sucesivos del mismo repositorio y rastrear si un hallazgo dado persiste, desaparece o se suprime, sin perder el hilo entre escaneos.

El paso de clasificación de propósito es el eje sobre el cual gira la guía de migración. Cuando el analizador no puede establecer el propósito con confianza, etiqueta el hallazgo como UNKNOWN, y el propósito UNKNOWN no recibe un objetivo de migración PQC automático [1]. Este es el mecanismo concreto detrás de la cuarta pregunta de ingeniería que la herramienta se propone responder, qué se puede migrar a continuación, sin inventar un objetivo cuando la evidencia es ambigua [1]. Este estado UNKNOWN no es una falla del escaneo; es una negativa deliberada a adivinar, lo cual es consistente con la postura general de la herramienta de preferir una brecha honesta sobre una respuesta inventada.

Cuando PQCensus propone un objetivo de migración candidato, es cuidadoso con el estado de esa sugerencia. Los objetivos de migración candidatos se describen como guía de ingeniería, no promesas de compatibilidad directa [1]. La documentación de la propia herramienta enumera lo que aún necesita validación antes de que dicho objetivo pueda adoptarse: protocolo, PKI, HSM/KMS, soporte de pares, tamaño de mensaje, ciclo de vida, reversión y restricciones operativas [1]. Esta es una lista larga y específica, y señala que un campo de objetivo de migración es el comienzo de una investigación de ingeniería, no el final de una.

Este calificador es importante para cualquiera que construya un plan de migración sobre la salida de PQCensus. Un campo de objetivo de migración poblado en un registro de hallazgo le dice a un revisor qué primitiva post-cuántica podría reemplazar la clásica que se está utilizando, dada la evidencia de propósito disponible, pero no verifica que el sistema circundante, una pila TLS, una jerarquía PKI, un módulo de seguridad de hardware o un par que también debe admitir el nuevo algoritmo, pueda realmente aceptar ese intercambio. Cada uno de los ocho elementos de validación enumerados anteriormente corresponde a una dependencia de implementación real que un escáner puramente a nivel de fuente no puede observar solo a partir del código.

Esta restricción es consistente con el diseño central declarado de la herramienta en la primera sección: no inventar un objetivo cuando la evidencia es ambigua [1]. También se conecta directamente con la regla de propósito UNKNOWN: si no se puede establecer el propósito de una llamada criptográfica, no se propone ningún objetivo, en lugar de uno adivinado [1]. Las dos reglas juntas describen una política subyacente única: solo informar un objetivo de migración cuando la cadena de evidencia, desde el sitio de llamada hasta el propósito y el reemplazo plausible, esté intacta de extremo a extremo.

Para un constructor, la conclusión práctica es que los hallazgos de PQCensus deben leerse en dos niveles: los hallazgos con un objetivo de migración poblado son candidatos para un elemento del backlog de migración, que aún requieren el trabajo de validación enumerado, y los hallazgos sin objetivo (propósito UNKNOWN) son candidatos para investigación manual antes de que siquiera se pueda enmarcar una decisión de migración [1]. Tratar estos dos niveles con flujos de trabajo diferentes, en lugar de fusionarlos en un solo backlog, mantiene intacta la precaución probatoria de la propia herramienta a medida que la salida se mueve al proceso de planificación de un equipo.

PQCensus reporta efectividad en tres capas de referencia distintas y cada vez más realistas, y cada capa tiene su propio tamaño de muestra y sus propias condiciones; no deben agruparse en un solo número principal. En la capa de referencia semántica sintética, que consta de 26 casos y 26 hallazgos etiquetados, PQCensus logró 26 verdaderos positivos, 0 falsos positivos y 0 falsos negativos [1]. Esta es una prueba sintética completamente controlada: cada caso tiene una etiqueta conocida, y la herramienta coincidió exactamente con cada uno de ellos. Una puntuación perfecta en una capa sintética construida específicamente para ejercitar patrones semánticos conocidos es un comportamiento esperado para un analizador bien ajustado, y debe leerse como una verificación de que el motor de reglas funciona según lo diseñado, no como evidencia sobre código real arbitrario.

En la capa de referencia de extractos curados de código ascendente, que consta de 5 extractos y 6 sitios de llamada etiquetados, PQCensus logró 6 verdaderos positivos, 0 falsos positivos y 0 falsos negativos [1]. Esta capa pasa de construcciones sintéticas a extractos cortos extraídos de código real ascendente, todavía una muestra pequeña y curada, pero más cercana a la forma del código real que la capa sintética. El tamaño de la muestra aquí, cinco extractos y seis sitios de llamada, es lo suficientemente pequeño como para que un solo sitio de llamada perdido o mal clasificado hubiera producido una puntuación visiblemente peor, por lo que el resultado perfecto debe leerse a la luz de ese pequeño denominador.

En la capa de referencia de repositorios fijados de extremo a extremo, utilizando python-jose 3.3.0 más PyJWT 2.10.1 en 96 archivos, PQCensus produjo 193 hallazgos y coincidió con 12 de 12 observaciones requeridas [1]. Esta es la más realista de las tres capas: dos paquetes reales con versiones fijadas escaneados en su totalidad, en lugar de extractos aislados. La cifra de 193 hallazgos es un recuento bruto de lo que el escáner encontró, y la cifra de 12 de 12 es el subconjunto de esos hallazgos que el punto de referencia había predefinido como requeridos, ambos coincidieron. Vale la pena señalar explícitamente que 193 hallazgos totales contra 12 observaciones requeridas significa que la mayoría de los hallazgos en esta capa del mundo real no se puntúan directamente contra una verdad fundamental etiquetada en el número reportado; la cifra de 12 de 12 establece que el subconjunto etiquetado requerido se recuperó por completo, pero no establece por sí mismo una cifra de precisión sobre los 193 hallazgos.

Ninguna afirmación establece estos números contra una herramienta de referencia externa, por lo que no se puede reportar aquí ninguna cifra de precisión comparativa (por ejemplo, contra dotnet-cbom u otro escáner); cada número se mantiene solo contra su propia verdad fundamental etiquetada dentro de su propia capa [1]. Un constructor que quiera saber cómo se desempeñaría PQCensus en su propio código base no curado debe tratar los tres números como límites superiores obtenidos bajo condiciones favorables, curadas o fijadas, no como garantías que se transfieren automáticamente a un repositorio arbitrario.

dotnet-cbom es una herramienta separada y relacionada para un ecosistema diferente: utiliza análisis estático Roslyn para inventariar el uso criptográfico, clasificar el riesgo cuántico y demostrar el progreso de la migración post-cuántica, dirigida a código .NET [7]. Descubre criptografía en System.Security.Cryptography, validación JWT, manejo de TLS/certificados y API post-cuánticas (ML-KEM/ML-DSA/SLH-DSA), adjuntando una confianza de detección a cada hallazgo [7]. Clasifica cada hallazgo en dos ejes independientes, debilidad clásica y vulnerabilidad cuántica, en lugar de una sola etiqueta de riesgo [7]. Este diseño de dos ejes es un esquema de clasificación más elaborado que cualquier cosa descrita para PQCensus, que reporta algoritmo, propósito y un objetivo de migración cuando corresponde, pero no reporta una puntuación de riesgo de dos ejes en las afirmaciones disponibles aquí.

dotnet-cbom también produce salidas legibles por máquina y por humanos: CycloneDX 1.6, SARIF 2.1.0, Markdown, HTML y un resumen ejecutivo [7]. Realiza un seguimiento del cambio a lo largo del tiempo con un mecanismo de diff/--baseline que sella cada hallazgo como Nuevo, Sin cambios, Regresado o Eximido [7], y valida sus propios CBOM generados contra el esquema JSON oficial de CycloneDX 1.6 y el perfil de dotnet-cbom [7]. Ve la criptografía de terceros a través de la detección de Bouncy Castle y un inventario de manifiesto de paquetes extraído de project.assets.json / PackageReference [7], y a partir de su readme tiene 17 reglas [7]. Su fórmula de riesgo para un solo hallazgo es 0.45 por Q más 0.35 por C más 0.20 por X, combinando factores cuánticos, de debilidad clásica y de exposición de uso, con pisos de fallo cerrado [7], y su puntuación de Preparación PQC se define como 100 por peso seguro dividido por peso total, calculado solo sobre algoritmos relevantes para la computación cuántica [7]. Mide su propia precisión con un punto de referencia de precisión de corpus etiquetado que ejecuta detectores reales contra una verdad fundamental creada de forma independiente y falla CI en cualquier regresión [7]. Esta última propiedad, una puerta de regresión integrada en CI sobre la precisión, es una forma de validación continua que no se describe para PQCensus en las afirmaciones disponibles aquí; los números de referencia de PQCensus se reportan como resultados puntuales en las tres capas descritas anteriormente.

Dos aclaraciones son importantes aquí. Primero, los pasajes que describen dotnet-cbom no describen a PQCensus en absoluto; describen una tarea de migración basada en contratos para agentes de codificación y el generador separado dotnet-cbom [5]. Segundo, el Inventory Generator y el Quantum Risk Analyzer Engine de TCS se proponen como un par de herramientas para aplicaciones empresariales en general, no como un método de análisis estático con números de precisión/recuperación reportados en el material disponible [13]. Ninguna de estas fuentes reporta un punto de referencia compartido, un código base compartido o una ejecución directa contra PQCensus, por lo que esta sección es una descripción lado a lado de sistemas reportados por separado, no una comparación de precisión medida.

Más allá de las herramientas de inventario a nivel de fuente, el desafío de migración más amplio también toca otras dimensiones que estas herramientas no cubren. La migración basada en agentes de codificación, probada a través de una tarea basada en contratos que mueve un firmante de archivo Go de RSA a ML-DSA-44 en 160 intentos en cuatro configuraciones de agentes locales, produjo doce parches finales que pasan la verificación local pero fallan los requisitos externos [5]. El acceso al checker no aumentó la tasa de finalización observada en ninguna comparación en ese estudio [5], reducir la ventana de contexto de un modelo de 128K a 32K redujo los pases completos de 36/40 a 4/40 [5], y cuatro ensayos exploratorios utilizando otras dos combinaciones de modelo/herramienta pasaron las 40 verificaciones, incluidas ambas líneas base [5]. Este es un problema distinto, la transformación automatizada de código, no el inventario, y se reporta en un punto de referencia diferente (una sola tarea de migración de firmante Go) que cualquier número de PQCensus. No obstante, es un contraste útil para un constructor: muestra que incluso cuando un inventario identifica correctamente un sitio de llamada criptográfica y un objetivo de migración plausible, el acto posterior de reescribir realmente el código para usar ese objetivo es una tarea separada y, según este estudio, aún propensa a errores, con doce de 160 intentos pasando verificaciones locales pero fallando requisitos externos [5].

El valor de una herramienta de inventario depende en parte de lo que sucede después de que se identifica un objetivo de migración, y la literatura señala que los algoritmos en sí mismos no son intercambiables en costo. Las necesidades de energía, ancho de banda y latencia de los algoritmos PQC abarcan varios órdenes de magnitud, y esto es lo suficientemente sustancial como para afectar la duración de la batería, la experiencia del usuario y el diseño del protocolo de la aplicación [6]. Esta es una consecuencia directa para cualquier plan de migración construido a partir de un hallazgo de PQCensus: un objetivo de migración propuesto es un algoritmo candidato, pero su perfil de recursos aún necesita una evaluación separada antes de ser adoptado a escala.

Para contextos móviles y conectados a la nube específicamente, los esquemas PQC de retícula estructurada rápida se reportan como la opción preferida para dispositivos móviles conectados a la nube en la mayoría de los casos de uso, incluso cuando el costo de energía de transmisión de datos por bit de tales esquemas es relativamente alto [6]. Este hallazgo ilustra por qué la propia precaución de PQCensus, de que un objetivo de migración es una guía de ingeniería y no una promesa de compatibilidad directa [1], está bien fundada: incluso un algoritmo candidato técnicamente correcto puede conllevar costos operativos muy diferentes dependiendo del contexto de implementación, y un esquema que es rápido en el dispositivo aún puede ser costoso de transmitir, lo que importa de manera diferente para un cliente móvil con batería que para un servidor.

Esto también refuerza por qué PQCensus preserva el riesgo contextual y las entradas HNDL como campos de evidencia en cada hallazgo [1], ya que la exposición a cosechar ahora, descifrar después y el contexto de implementación, móvil versus servidor, por ejemplo, afectan tanto la urgencia como la forma en que se debe migrar un hallazgo determinado, incluso antes de que se sopesen las compensaciones de energía y ancho de banda [6]. Un hallazgo marcado con alta exposición HNDL pero destinado a una implementación móvil con recursos limitados se encuentra en la intersección de dos preocupaciones separadas, la urgencia de la migración y el costo del algoritmo de reemplazo, que un constructor debe sopesar juntos en lugar de por separado.

Ninguna afirmación vincula un hallazgo específico de PQCensus con una medición específica de energía o ancho de banda, por lo que esta conexión se presenta aquí como dos hechos reportados por separado que un constructor debe combinar manualmente: PQCensus le dice dónde se usa una primitiva clásica y qué podría reemplazarla [1]; la literatura de energía móvil le dice que el costo de recursos del reemplazo aún necesita una evaluación separada antes de la implementación [6]. Combinar los dos requiere un paso manual que ninguna de las fuentes realiza por sí sola, y un constructor debe presupuestar tiempo de ingeniería explícito para ello en lugar de asumir que el objetivo de migración de la herramienta de inventario ya tiene en cuenta el costo de implementación.

La limitación más inmediata es el estado de lanzamiento: actualmente no hay evidencia de lanzamiento canónico establecida para PQCensus, y no hay un lanzamiento de GitHub o PyPI autorizado según el material fuente [1]. Un constructor que evalúa esta herramienta hoy está mirando un proyecto sin un artefacto de lanzamiento estable y citable, lo que afecta cuánta confianza a largo plazo debe depositar un equipo en el comportamiento de una versión particular sin fijarla a un commit o compilación específica.

La segunda limitación es la cobertura de lenguaje. Solo el analizador de Python se describe como estable y basado en AST [1]; el soporte para JavaScript/TypeScript, Go, Java, Rust y C/C++ es experimental, basado en texto y deliberadamente de menor confianza, explícitamente no equivalente al analizador de Python [1]. Cualquier organización con una base de código de varios lenguajes debe esperar garantías materialmente más débiles fuera de Python, y no debe asumir que las mismas tasas de falsos positivos y falsos negativos reportadas en los puntos de referencia orientados a Python se mantendrían para un repositorio Go o Java.

La tercera limitación es el alcance. La herramienta no ejecuta dependencias instaladas, pasos de compilación, pruebas o contenedores durante un escaneo normal [1], por lo que cualquier criptografía cuyo uso solo aparezca en tiempo de ejecución, dentro del comportamiento compilado de una dependencia, o a través de una configuración no visible en la fuente estática, queda fuera del alcance de este método por diseño. Tampoco hace ninguna afirmación sobre certificación o un estado general de "quantum safe" [1], y ninguna afirmación en el material disponible establece una cifra de precisión para repositorios reales no curados más allá del único punto de referencia de dos paquetes fijados reportado [1]. Esto significa que la precisión demostrada de la herramienta se basa en una capa sintética, una pequeña capa de extractos curados y una sola capa de extremo a extremo con dos paquetes fijados; ninguno de estos establece una cifra de precisión general en repositorios arbitrarios, no vistos y no curados.

Finalmente, esta nota no puede reportar una comparación medida directa entre PQCensus y cualquier otra herramienta, dotnet-cbom, el Inventory Generator de TCS o los métodos de migración basados en agentes de codificación, porque ninguna afirmación proporciona una. Los números de cada herramienta se mantienen solo contra su propio punto de referencia y condiciones reportados: las tres capas de PQCensus [1], el punto de referencia de precisión de corpus etiquetado de dotnet-cbom [7] y el estudio de agente de codificación de 160 intentos y cuatro configuraciones [5]. Un constructor que necesite una decisión comparativa entre estos enfoques tendría que ejecutar dicha comparación directamente, en el mismo código base, ya que actualmente no existe ninguna en la evidencia citada.

1. Confirme el lenguaje principal de la base de código objetivo antes de comenzar. Si es Python, planee confiar en el analizador estable basado en AST de PQCensus [1]; si incluye JavaScript/TypeScript, Go, Java, Rust o C/C++, planee que esos resultados sean experimentales, de menor confianza y basados en texto, que necesitan seguimiento manual en lugar de confianza automática [1].
2. Configure el escaneo para que se ejecute localmente, sin clave API, servicio alojado, carga en la nube ni dependencia de LLM, para que la base de código nunca salga de su entorno [1]. Esto también significa que puede ejecutarlo dentro de un pipeline de CI cerrado sin llamadas de red externas, lo cual es útil para bases de código bajo requisitos estrictos de confidencialidad.
3. Antes de ejecutar, verifique que el escaneo no ejecutará nada: no debe importar ni instalar paquetes de destino, ejecutar setup.py, hooks de ciclo de vida de paquetes, Makefiles, scripts de shell, pruebas, binarios, contenedores o compilaciones arbitrarias, y no debe seguir enlaces simbólicos fuera de la raíz de escaneo [1]. Si su envoltorio de compilación hace alguna de estas cosas automáticamente, deshabilite ese comportamiento para el pase de escaneo, de modo que el escaneo siga siendo una operación pura de solo lectura a nivel de fuente.
4. Ejecute el escaneo contra la raíz del repositorio y recoja el conjunto de hallazgos. Cada hallazgo debe llevar: un identificador estable de hallazgo y regla, ruta y extensión de fuente, información de símbolo/llamada, algoritmo y propósito, analizador y confianza, referencias de regla/autoridad, riesgo contextual y entradas HNDL, estado de supresión y, solo cuando la evidencia del propósito lo respalde, un objetivo de migración [1]. Almacene estos como su línea base de evidencia, indexados por los identificadores estables para que los escaneos posteriores puedan compararse con ella.
5. Separe los hallazgos en dos grupos inmediatamente: aquellos con un objetivo de migración poblado y aquellos etiquetados como propósito UNKNOWN sin objetivo [1]. Enrute el grupo UNKNOWN a revisión manual de código; no intente migrarlo automáticamente, ya que la propia herramienta se negó a proponer un objetivo precisamente porque la evidencia no lo respaldaba.
6. Para cada hallazgo con un objetivo de migración, trátelo estrictamente como guía de ingeniería, no como un reemplazo directo [1]. Abra una lista de verificación de validación por hallazgo que cubra protocolo, PKI, HSM/KMS, soporte de pares, tamaño de mensaje, ciclo de vida, reversión y restricciones operativas [1], y no cierre el elemento de migración hasta que cada uno esté verificado.
7. Compare el contexto de implementación de cada hallazgo validado con los costos de recursos conocidos: si el entorno de destino es móvil o está conectado a la nube, tenga en cuenta que los esquemas PQC varían en energía, ancho de banda y latencia en órdenes de magnitud [6], y que los esquemas de retícula estructurada rápida generalmente se prefieren para dispositivos móviles conectados a la nube incluso a un costo de energía de transmisión por bit relativamente alto [6]. Registre esto como un elemento de línea separado, ya que PQCensus mismo no mide el costo de recursos.
8. Valide la salida de la herramienta contra las capas de referencia reportadas antes de confiar en ella en su propia base de código: verifique si sus casos de prueba se asemejan a la capa semántica sintética (26 casos/26 hallazgos etiquetados, VP 26 FP 0 FN 0) [1], la capa de extractos curados de código ascendente (5 extractos/6 sitios de llamada, VP 6 FP 0 FN 0) [1], o la capa de extremo a extremo fijada (python-jose 3.3.0 más PyJWT 2.10.1, 96 archivos, 193 hallazgos, 12/12 observaciones requeridas coincidentes) [1]. No asuma que estas cifras se transfieren a una base de código no relacionada y no curada, ya que cada una se obtuvo bajo sus propias condiciones controladas o curadas.
9. No reporte un escaneo limpio (cero hallazgos) como una certificación o una afirmación de seguridad general. PQCensus mismo no afirma la certificación NIST ni etiqueta un repositorio como quantum safe a partir de un escaneo estático limpio [1], y cualquier informe posterior que produzca su equipo debe llevar la misma advertencia en lugar de actualizar silenciosamente un escaneo limpio a una garantía de seguridad.
10. Si la base de código también depende de la infraestructura de red empresarial, como IPsec, TLS o servicios WAN definidos por software que autentican pares con criptografía de clave pública vulnerable a la computación cuántica, trate eso como una tarea de inventario separada fuera del alcance de PQCensus [11], ya que el escaneo a nivel de fuente no examina la configuración de red o protocolo directamente.
11. Cuando se haya validado un objetivo de migración y la base de código sea Python, considere si se utilizará un paso de transformación automatizada de código (un agente de codificación, por ejemplo) para aplicar el cambio; de ser así, presupueste fallos de verificación incluso después de que las comprobaciones locales pasen, ya que un estudio de una tarea análoga de migración de RSA a ML-DSA-44 encontró que doce de 160 intentos en cuatro configuraciones de agente pasaron la verificación local pero fallaron los requisitos externos [5].
12. Mantenga el registro de evidencia completo, no solo un resumen de aprobado/fallado, para cada hallazgo que entre en un backlog de migración. Debido a que PQCensus preserva identificadores estables de hallazgo y regla, ruta y extensión de fuente, y estado de supresión como parte de sus campos de evidencia [1], un revisor meses después puede reabrir el razonamiento exacto detrás de una decisión de migrar, suprimir o dejar un hallazgo como UNKNOWN, que es el punto de preservar evidencia revisable en primer lugar.

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)