Lo previsto frente a lo implementado: auditoría de la diferencia

Objetivo

Un linter analiza el código de forma aislada. Puede indicarte que el código es coherente internamente; pero no puede decirte si el código hace lo que tú pretendías, porque no dispone de un modelo de tu intención. Los errores de seguridad y corrección más graves se encuentran en esa brecha: un permiso documentado pero que nunca se aplica, un punto final «solo para cron» al que cualquiera puede acceder, un campo marcado como «solo público» que filtra datos privados.

Esta habilidad es el método para detectar esa brecha. Es el factor diferenciador: solo funciona cuando la intención se ha plasmado por escrito previamente (véase la habilidad «artefactos de entrega»), y esa es precisamente la razón por la que las herramientas genéricas no pueden replicarla.

Contexto

Utilízala cuando exista una intención documentada — permissions.md, architecture.md, variables.md, etc. Si esos documentos faltan o están obsoletos, esa ausencia es en sí misma el primer hallazgo: no se puede auditar una intención que nunca se ha registrado. Se recomienda documentar primero y, a continuación, auditar.

Método

1. Establece la intención. Lee el /documentation/*.md conjunto como la fuente de referencia de lo que debería ser cierto: quién puede acceder a qué, qué límites son fiables, qué datos son públicos. Trata la documentación como afirmaciones que hay que verificar, no como pruebas.

2. Recopila pruebas de la implementación. Lee el código que aplica (o no aplica) cada afirmación. La prueba es un archivo y una línea concretos: la comprobación de autorización real, el filtro de consulta real, el sanitizador real. «Probablemente se gestiona en una fase anterior» no es una prueba; la ruta del código sí lo es.

3. Compara la afirmación con el código, límite por límite. Para cada regla documentada, pregúntate: ¿hay algún punto de aplicación que la implemente realmente, en el servidor, en todas las rutas? Desconfía de comentarios como «solo interno», «solo para administradores» o «validado en otro lugar»: verifícalos en el código.

4. Clasifica cada discrepancia según su importancia. Una discrepancia es relevante cuando, al cruzarla, permite que un actor real acceda a datos, dinero, infraestructura u otro inquilino al que no debería. No es relevante cuando la única persona afectada es el propio actor con respecto a sus propios datos. Descarta las desviaciones superficiales; mantén las que cruzan los límites.

5. Evita los hallazgos vagos. Cada hallazgo debe especificar: la intención documentada (cita el documento), la realidad implementada (cita el código), el atacante y la víctima, y la solución concreta. Si no puedes citar ambos lados de la discrepancia, se trata de una cuestión que hay que investigar, no de un hallazgo que debas notificar.

Lo que cuenta

• Intención: una regla, un límite, un ámbito o una clasificación de público/privado documentados.
• Prueba de implementación: un punto de aplicación citado (o su ausencia demostrable) en el código.
• Una discrepancia relevante: la documentación dice una cosa, el código hace otra, y la diferencia traspasa un límite de confianza, de coste, de datos o de inquilino.

Notas

• «Documentado pero no aplicado» es un hallazgo en sí mismo: clasifícalo según lo que revele el hecho de traspasar esa brecha.
• «No documentado pero aplicado» suele estar bien, pero hay que señalarlo: la documentación está desactualizada, lo que debilita la próxima auditoría.
• Este método alimenta las auditorías de seguridad y rendimiento; no sustituye su análisis a nivel de «sink», sino que añade el eje de la intención del que carecen.
• Nunca inventes una intención para crear una brecha. Si la documentación no dice nada, di que la documentación no dice nada.