Revisión de seguridad de un cambio
Revisa un cambio por la exposición que añade — cada hallazgo trazado hasta un camino realmente alcanzable, y cada sospecha reportada como sospecha.
Entregable
Un documento Markdown, security-review.md, con la estructura fijada en Salida más abajo. Toma las fronteras dibujadas por Modelado de amenazas y devuelve una decisión que la publicación puede sostener.
Entradas obligatorias
- El conjunto de cambios — el diff, el parche o la rama a revisar, completo y no resumido.
- Qué toca el cambio — los componentes, los datos y las interfaces a los que llega, y cuáles de ellos están sobre una frontera de confianza.
- El código en el que aterriza el cambio — suficiente del sistema alrededor como para trazar una línea modificada hasta el camino que la alcanza.
Si falta cualquiera, repórtalo como ausente y revisa solo lo que el material aportado sostenga. Un diff leído sin el código alrededor muestra qué cambió, no qué expone el cambio.
Entradas opcionales
- El modelo de amenazas, o cualquier registro de por dónde van las fronteras de confianza
- El diseño de autorización: los roles, los ámbitos y dónde se aplica cada uno
- La configuración de registro, de reporte de errores y de monitorización
- Los cambios de infraestructura y de configuración que salen junto al código
- Las pruebas que cubren los caminos modificados y qué comprueban
- El motivo del cambio, en palabras de quien lo escribió
Las entradas opcionales ausentes estrechan lo que se puede concluir, nunca lo que se afirma. Cuando el material no permita establecer la alcanzabilidad, el hallazgo se archiva en Pendiente de verificar.
Ejecución
1 — Establecer hasta dónde llega el cambio. A partir del diff, lista los archivos, puntos de entrada, almacenes de datos y llamadas salientes que toca. Por cada uno, el camino que lo alcanza y si ese camino cruza una frontera de confianza. Un cambio que no toca nada sobre una frontera se revisa igual, y la revisión declara que eso es lo que encontró.
2 — Seguir la entrada. Por cada valor que el cambio acepta desde fuera de una frontera, trázalo hasta donde se usa: una consulta, un comando, una ruta, una plantilla, una redirección, un deserializador, una respuesta. Registra dónde se valida, dónde se codifica para su destino y dónde no se hace ninguna de las dos cosas.
3 — Comprobar la autorización en cada camino, no en cada ruta. Por cada operación que el cambio añade o altera: quién puede invocarla, dónde se hace esa comprobación y si todos los caminos hacia la operación pasan por ella. El defecto habitual no es una comprobación que falta, sino un segundo camino que llega a la misma operación rodeando la que ya existe.
4 — Buscar secretos y credenciales. Claves, tokens, contraseñas, cadenas de conexión y material privado en el diff, en la configuración, en los fixtures, en los datos de prueba y en todo lo que la compilación empaqueta. Registra cada uno con su archivo y si llega a un artefacto de compilación o al historial del repositorio.
5 — Leer lo que el cambio escribe hacia fuera. Registros, respuestas de error, trazas de pila, eventos de analítica y herramientas de soporte. Registra cada campo que sale del sistema llevando datos de usuario, credenciales, direcciones internas o los detalles de un fallo que alguien de fuera no debería recibir.
6 — Dar cuenta de la superficie nueva. Qué hace el cambio accesible públicamente que antes no lo era, qué permiso amplía, qué valor por defecto modifica y qué dependencia añade. Una dependencia añadida aquí se nombra y se pasa a Auditoría de dependencias y cadena de suministro en lugar de valorarse de pasada.
7 — Escribir cada hallazgo con su camino y su corrección. Por hallazgo: el archivo, la condición bajo la que se alcanza el camino, qué gana un atacante en ese punto, la gravedad y su motivo, y el cambio concreto que lo cierra. Un hallazgo que no se pueda trazar hasta un camino alcanzable va a Pendiente de verificar con el paso que lo resolvería.
Salida
security-review.md, en este orden:
- 1. Cambio revisado — qué se revisó, con qué material, por quién y cuándo
- 2. Superficie tocada — los archivos, puntos de entrada y datos a los que llega el cambio, y cuáles cruzan una frontera
- 3. Hallazgos — por hallazgo: archivo, la condición que lo alcanza, impacto, gravedad y su motivo, y la corrección
- 4. Pendiente de verificar — problemas sospechados sin camino trazado, cada uno con el paso que lo resolvería
- 5. Tratamiento de la entrada — por valor externo: dónde entra, dónde se valida, dónde se codifica
- 6. Autorización — por operación añadida o alterada: la comprobación, dónde está y todos los caminos que la alcanzan
- 7. Secretos y salida — credenciales encontradas y cada campo que el cambio escribe en registros o errores
- 8. Superficie y dependencias nuevas — qué pasó a ser accesible, qué se amplió, qué se añadió
- 9. Sin revisar — qué no cubría el material aportado y qué queda por ello sin saber
Validación
La revisión está lista cuando se cumple todo esto:
- Cada hallazgo de la sección 3 nombra un archivo y la condición que lo alcanza
- Cada hallazgo de la sección 3 lleva una corrección que alguien puede aplicar, no un principio
- Cada sospecha sin camino trazado está en la sección 4 y no en la 3
- Cada operación que el cambio añade aparece en la sección 6 con su comprobación o con
sin comprobación encontrada
- La sección 7 declara que no se encontró ninguna credencial cuando así fue, en lugar de quedarse vacía
- La sección 9 no está vacía, o declara que el material cubría el cambio entero
Falla la ejecución si un hallazgo se declara explotable sin un camino alcanzable, o si se asigna una gravedad sin el impacto que la justifica.
Gestión de fallos
- No hay conjunto de cambios — detente. Informa de que no hay nada que revisar y de que revisar el estado actual de un archivo es otro trabajo con otro nombre.
- Sin acceso al código alrededor — revisa el diff solo, coloca en la sección 4 cada hallazgo que dependa de la alcanzabilidad y declara que no se trazó ningún camino.
- El cambio es demasiado grande para revisarlo como una unidad — divídelo por superficie, revisa cada parte y reporta cuáles se revisaron y cuáles no. Nunca muestrees un diff y presentes el resultado como cobertura.
- El relato de quien escribió el cambio y el código no coinciden — revisa el código, registra la intención declarada al lado y eleva la diferencia como un hallazgo sobre el cambio, no sobre la persona.
- Un hallazgo no se puede reproducir — mantenlo en la sección 4 con lo que se observó y lo que hace falta para confirmarlo. Una sospecha registrada con honestidad se investiga; una declarada como hecho se discute y luego se abandona.
