Leído por una persona, no por un escáner.
El análisis estático encuentra patrones. No puede saber que falta una comprobación de permisos en un endpoint, porque ahí no hay nada que detectar.
Leemos tu código fuente buscando específicamente fallos de seguridad: control de acceso, autenticación, tratamiento de datos y secretos. Nos centramos donde está el riesgo, y cada hallazgo llega con su ubicación exacta y una corrección propuesta, para que se convierta en un pull request. No tenemos certificaciones de seguridad. Para empresas en España.
Actualizado noviembre de 2026
Los fallos más graves suelen ser algo que falta.
El análisis estático es bueno encontrando patrones peligrosos: una consulta insegura, un algoritmo débil. Es malo dándose cuenta de que uno de cuarenta endpoints nunca comprueba si el usuario que pide un registro es su dueño, porque no hay código malo que señalar. Simplemente, no hay código.
Una persona que lee con intención encuentra eso, y es sistemáticamente la categoría más dañina. La falta de autorización es como un cliente acaba viendo los datos de otro.
Complementa a las pruebas de penetración, no las sustituye. Las pruebas enseñan qué se alcanza desde fuera; la revisión de código enseña qué está mal dentro, incluidos caminos a los que un probador no llegaría.
Qué buscamos.
Autorización ausente
Endpoints que comprueban quién eres pero nunca si el registro es tuyo. El hallazgo grave más habitual.
Gestión de la autenticación
Sesiones, tokens, restablecimiento de contraseña, caducidad. Donde se concentran los errores dañinos.
Secretos en el repositorio
Claves y credenciales subidas, también en el historial, donde nadie se acuerda de mirar.
Tratamiento de entradas
Caminos de inyección, deserialización insegura, plantillas que renderizan datos del usuario.
Datos sensibles en los registros
Números de tarjeta, tokens y datos personales escritos en registros que lee mucha gente.
Riesgo en las dependencias
Vulnerabilidades conocidas y paquetes que ya nadie mantiene.
Uso de la criptografía
No los algoritmos, que suelen estar bien, sino cómo se usan, que a menudo no.
Una corrección por hallazgo
Archivo, línea y cambio propuesto. Para que se convierta en un pull request y no en una discusión.
¿Revisión de código o prueba de penetración?
Encuentran cosas distintas. La mayoría de los equipos debería hacer las dos.
| Revisión de código seguro | Prueba de penetración | |
|---|---|---|
| Perspectiva | Desde dentro: leyendo el código | Desde fuera: atacando la aplicación en marcha |
| Comprobaciones de autorización ausentes | Sí: su punto más fuerte | Solo donde se alcanzan |
| Secretos escritos en el código | Sí | Rara vez |
| Código peligroso pero inalcanzable hoy | Sí | No: no se puede alcanzar |
| Fallos de configuración y despliegue | En parte | Sí |
| Demuestra que es explotable | No: enseña el fallo | Sí: demuestra el ataque |
| Necesita acceso al código | Sí | No |
Cómo leemos.
Autorización que falta en un endpoint. Ningún escáner la encuentra, porque no hay nada que encontrar.
Nuestro fundador fue CTO de una fintech de pagos. El código cerca del dinero se lee en consecuencia.
Archivo, línea y el cambio. Debería convertirse en un pull request, no en una conversación.
Cuándo revisar.
Antes de manejar dinero o datos personales
Más barato encontrarlo ahora que después de una brecha que hay que notificar.
Has heredado un código
Una compra o el traspaso de una agencia. No puedes fiarte de lo que no has leído.
Una prueba encontró algo preocupante
Si faltaba una comprobación de autorización, revisa si están las demás.
No como sustituto de las pruebas automáticas
Si nada se verifica automáticamente, arreglar eso primero hará más bien. Te lo diremos.
Cómo trabajamos.
Encontramos dónde está el riesgo
Autenticación, pagos, datos personales. Los leemos a fondo en lugar de leerlo todo por encima.
Las herramientas, de fondo
Atrapan los patrones evidentes y dejan la lectura para lo que las herramientas no ven.
Leemos con intención
Siguiendo cómo se mueven los datos y dónde deberían estar las comprobaciones que faltan.
Verificamos cada hallazgo
En el código, con el camino a la vista. Nadie debería perseguir un problema teórico.
Ordenamos por impacto real
Lo que permite de verdad en tu aplicación, no una puntuación genérica.
Damos una corrección, no un sermón
Archivo, línea, cambio propuesto, para que tu equipo abra un pull request y no un debate.
Revisión de código seguro
6 preguntas respondidas. ¿Tienes otra? Escríbenos.
El análisis automático encuentra patrones peligrosos que existen en el código. No puede encontrar algo que no está, y una comprobación de autorización ausente es exactamente eso. Esa categoría es, sistemáticamente, de donde salen los hallazgos más graves, y necesita a una persona.
Siete categorías. Cuarenta y cinco servicios.
Cuéntanos el proyecto. Te diremos si somos las personas adecuadas.
Escríbenos lo que necesitas, aunque sea a grandes rasgos. Respondemos en un día laborable, y si el proyecto debería ser más pequeño, o lo debería hacer otro, te lo decimos en la primera llamada.