Infraestructura, despliegue y prueba dinámica

Una prueba dinámica interactúa con una aplicación en marcha, y por eso solo se hace sobre lo que alguien autorizó por escrito. La autorización dice contra qué sistema, quién la aprobó y qué queda fuera. Que la prueba haya salido en verde en un entorno no es una autorización para otro: el entorno de pruebas y el de producción tienen datos, permisos y consecuencias distintos.

Antes de apuntar una herramienta a otro destino, se lee el documento que la ampara.

Un manifiesto de Kubernetes es una decisión de despliegue escrita en texto. Cada contenedor declara con qué permisos corre y qué toca del nodo que lo aloja. Un contenedor privilegiado, o con un volumen que monta un recurso del nodo, no es un fallo de la aplicación: rompe el aislamiento entre el contenedor y la máquina que lo ejecuta. Se lee en el manifiesto, antes de que exista en el clúster.

Un manifiesto con varios contenedores obliga a mirar cada uno por separado: el bueno no disculpa al otro.

En la infraestructura como código cada recurso tiene un identificador que lo nombra en el archivo y un nombre que verá la nube. El informe de la revisión señala el archivo; el recurso concreto se lee dentro de él. Un almacenamiento de acceso público con datos de clientes viola cualquier política de datos personales, y el cifrado no lo arregla: cifrar un recurso que cualquiera puede leer sigue siendo dejarlo leer.

El informe señala dos fallas sobre el mismo archivo; solo una de ellas implica exposición.

Una prueba en verde cuenta lo que encontró, no lo que no vio. La cifra que le da sentido es la cobertura: qué parte de la superficie conocida alcanzó. Una prueba sin autenticar solo llega a lo que responde sin sesión, y una API tiene mucho detrás de la sesión. Se compara lo alcanzado con el contrato de la API y se dice el resultado como un porcentaje.

Un resultado limpio sobre un tercio de la superficie es un tercio de una buena noticia.

Un modelo de amenazas envejece el día que alguien cambia el diseño sin tocarlo. La regla de revisión del propio modelo dice cuándo reabrirlo: cuando cambia un flujo que cruza una frontera de confianza. Para comprobarlo se leen los cambios fusionados desde la última revisión y se busca el que añade una entrada o una salida entre zonas.

No basta con que un cambio «toque la API»: importa de dónde vienen los datos que ahora entran.