¿Cómo abordas una revisión de código segura?
Respuesta breve
Empieza por entender el modelo de amenazas de la aplicación y dónde maneja entradas no confiables, secretos, autenticación y autorización. Usa SAST para escanear ampliamente y DAST contra la aplicación en ejecución, pero trata la salida de las herramientas como pistas, no como hallazgos — descarta falsos positivos. Luego dedica el tiempo humano a las áreas de alto valor y dependientes del contexto que las herramientas pasan por alto: lógica de autorización, lógica de negocio, uso de criptografía y fronteras de confianza. Rastrea el flujo de datos desde la fuente hasta el sink.
La revisión de código segura es donde el appsec se gana su sitio, porque puede atrapar un fallo antes de que llegue a producirse. Los entrevistadores preguntan sobre ella para ver si sabes usar las herramientas como multiplicador de fuerza sin confundir su salida con el trabajo real — que es el juicio humano sobre el contexto.
Empieza por el contexto
Antes de leer código, entiende la aplicación: ¿qué hace, qué datos son sensibles y por dónde entra la entrada no confiable? Apóyate en (o construye) un modelo de amenazas rápido. Eso te dice dónde gastar tu atención limitada — no hay tiempo de leerlo todo con igual cuidado, así que apuntas a la superficie de riesgo.
Las herramientas: pistas, no veredictos
- SAST lee el código fuente de forma estática y es excelente para la amplitud: secretos codificados, sinks propensos a inyección, deserialización insegura, APIs de criptografía débiles. Pero produce falsos positivos y no puede entender la intención.
- DAST ejercita la aplicación en ejecución desde fuera y confirma la explotabilidad de clases enteras de bugs, pero tiene una visibilidad superficial del código.
Usa ambos para generar pistas y luego tría. Abrir tickets de bug con la salida en bruto de SAST es la forma más rápida de perder la confianza de los desarrolladores — cada falso positivo que reenvías la erosiona.
Dónde ganan los humanos
Dedica el esfuerzo manual a lo que las herramientas estructuralmente no pueden juzgar:
- Lógica de autorización — ¿puede el usuario A alcanzar los datos del usuario B? Las herramientas ven el código, no la intención de control de acceso que hay detrás.
- Lógica de negocio — abusar de funciones legítimas (bugs del tipo saltarse-el-paso-de-pago).
- Uso de criptografía — el algoritmo correcto usado mal (modo ECB, IV estáticos, esquemas caseros).
- Fronteras de confianza — donde los datos pasan de no confiable a confiable, validar que realmente están saneados.
La técnica central es rastrear el flujo de datos desde la fuente hasta el sink: seguir la entrada no confiable desde la entrada hasta la operación peligrosa, comprobando cada transformación por el camino en busca de validación y codificación.
Qué buscan los entrevistadores
Quieren un enfoque guiado por el modelo de amenazas, SAST/DAST tratados como pistas que necesitan triaje, atención manual sobre la authz y la lógica de negocio, y el razonamiento de flujo de datos de fuente a sink — además de la empatía de proteger la confianza del equipo filtrando los falsos positivos.
Posibles preguntas de seguimiento
- ¿Por qué SAST no puede encontrar de forma fiable el control de acceso roto o los fallos de lógica de negocio?
- ¿Qué significa «rastrear de la fuente al sink» en la práctica?
- ¿Cómo evitas que los falsos positivos destruyan la confianza del equipo en tus revisiones?