Algunas vulnerabilidades no dejan rastro en el comportamiento de un sistema en funcionamiento hasta el día en que se explotan: una comprobación que falta en una rama poco usada, un generador aleatorio débil, un secreto en el historial del repositorio. Son visibles en el código.
Leemos el código como lo haría un atacante si se filtrara. Las herramientas de análisis estático señalan los candidatos, y los especialistas siguen los datos desde el punto de entrada hasta el punto donde se usan y deciden qué es real. La revisión abarca el código que usted escribió, las dependencias que importó y el pipeline que los compila, incluido el código generado con asistentes de IA.
01Alcance
Qué ponemos a prueba
Lógica de autenticación y autorización, incluida la configuración del framework
Gestión de entradas: inyección, deserialización, operaciones con archivos y rutas
Criptografía: algoritmos, modos, gestión de claves y de números aleatorios
Secretos en el código, la configuración, las definiciones de infraestructura y el historial
Dependencias de terceros y si son alcanzables desde su código
Pipeline de compilación y entrega: permisos, runners, integridad de los artefactos
Gestión de errores, datos sensibles en los registros, concurrencia
Infraestructura como código: Terraform, manifiestos de Kubernetes, charts de Helm
02Enfoque
Cómo se realiza el trabajo
01
Punto de partida basado en amenazas
Empezamos por lo que importa: las funciones que manejan dinero, identidades y secretos. Primero se lee la arquitectura y después el código.
02
Análisis automatizado
El análisis estático, el análisis de dependencias y la búsqueda de secretos generan candidatos. Para los patrones propios de su código se escriben reglas personalizadas.
03
Seguimiento manual
Cada candidato se sigue desde el punto de entrada hasta el punto donde se usan los datos. Los falsos positivos se descartan; los problemas reales se confirman en una instancia en funcionamiento cuando es posible.
04
Análisis de variantes
Cuando se encuentra un fallo, se buscan sus variantes en todo el código. Un hallazgo suele tener parientes.
El acceso se concede a especialistas designados por su nombre, el código se analiza en un entorno aislado y no se copia fuera de él. Las copias de trabajo se destruyen 30 días después del cierre del proyecto. El código nunca se envía a servicios públicos de IA.
Ya usamos un analizador estático. ¿Qué aporta una revisión manual?
Un analizador informa de patrones. No sabe cuáles de ellos son alcanzables ni ve una comprobación de autorización que falta, porque una línea que falta no coincide con ningún patrón. La revisión responde a ambas preguntas.
¿Se puede limitar la revisión a una parte del código?
Sí. La revisión de un solo componente, de los cambios desde una versión o de un único pull request es un alcance habitual.