Ningún escáner lo encuentra todo: control de acceso deficiente, lógica de negocio y el límite del análisis automático
Por qué la categoría de riesgo que ocupa el primer puesto del OWASP Top 10:2025 es a la vez la que peor ve un escáner, dónde termina exactamente la búsqueda de patrones y qué comprobación se encarga de lo que no tiene patrón: el test de penetración como contraparte del escaneo continuo.
Qué ve un escáner
Un escáner de código trabaja con patrones y listas conocidas. Una contraseña en el código fuente tiene una forma reconocible. Una biblioteca con un fallo conocido está en una base de datos. Una entrada que va sin comprobar a una consulta de base de datos sigue una estructura identificable, igual que una llamada que compone comandos del sistema a partir de entradas de usuario. Para estas clases, un escaneo en cada commit es la herramienta adecuada, porque las encuentra en cuanto aparecen y, bien clasificadas, las documenta con fecha.
Los controles de acceso ausentes también entran aquí, pero solo en una forma estrecha: un endpoint alcanzable sin ninguna comprobación de permisos llama la atención. Esa es la parte del control de acceso deficiente que los patrones captan. No es la parte que más daño causa en la práctica.
Por qué el primer puesto del Top 10 sigue siendo en parte invisible
El control de acceso deficiente ocupa el primer puesto de la edición 2025 del OWASP Top 10. La categoría abarca mucho más que un endpoint sin proteger. Abarca el caso en que existe una comprobación y aun así está mal: se verifica al usuario, pero no si el registro solicitado le pertenece. El empleado puede ver facturas, pero solo las de su sede, y el software nunca pregunta por la sede. El cliente puede modificar su contrato, pero no el precio, y el campo está oculto en el formulario en lugar de bloqueado en el servidor.
Para cada uno de esos casos existe código que realiza un control de acceso. El escáner ve la comprobación y se da por satisfecho. Si la comprobación hace la pregunta correcta no está escrito en ningún patrón, sino en el modelo de negocio. Por eso en nuestra página sobre seguridad del código escribimos que los errores de lógica de negocio escapan al análisis automático, y por eso no lo tratamos como letra pequeña.
El segundo límite: el diseño
Junto a la lógica de negocio hay una segunda clase de fallos sin patrón: las decisiones tomadas antes del código. Si un componente debería ser alcanzable directamente desde la red. Si dos servicios deberían compartir el mismo usuario de base de datos. Si un token pensado para una hora en realidad nunca caduca, porque nadie lo especificó así. En todos esos casos el código fuente es impecable a ojos del escáner. El fallo está en lo que el código fuente implementa.
A eso se añade lo que todo escáner hace a la inversa: también notifica hallazgos que en el caso concreto no son explotables. Una persona que clasifica cada hallazgo mantiene esos falsos positivos fuera del informe. Pero no hace que el escáner vea lo que no tiene patrón.
De qué se encarga el test de penetración
Un test de penetración parte desde fuera. Toma el sistema en funcionamiento como un todo, incluidos red, configuración, permisos y personas, e intenta superarlo. Un tester que ha iniciado sesión como usuario A y quiere ver las facturas del usuario B simplemente lo intenta. No necesita un patrón, necesita la pregunta de negocio. Justo por eso una buena prueba encuentra los fallos que el escaneo pasa por alto, y justo por eso los encuentra solo el día de la prueba.
La prueba en sí no nos la adjudicamos a nosotros mismos, y por una razón: quien opera el escaneo no debería ser también quien certifica que nada se le escapó. Nuestro papel está antes y después de la prueba. Antes: aclarar si una prueba es siquiera el instrumento adecuado ahora mismo, y entregarte los criterios para comparar proveedores. Después: convertir los hallazgos del informe en medidas cerradas. Más en nuestra página sobre el test de penetración.
Cómo encajan ambos
El reparto de tareas es sencillo una vez dicho en voz alta. El escaneo mantiene fuera del código, de forma continua, las clases de fallos con patrón y lo documenta con fecha: secretos, dependencias vulnerables, patrones inseguros, endpoints sin proteger. La prueba comprueba periódicamente si los controles que existen hacen la pregunta correcta y si el diseño aguanta. Quien solo hace pruebas tiene un año sin comprobación entre dos fechas. Quien solo escanea tiene el primer puesto del Top 10 solo a medias a la vista.
Para la evidencia eso significa: un auditor que quiere ver un pentest no acepta un informe de escaneo como sustituto. Y un auditor que quiere ver gestión de vulnerabilidades en el desarrollo y el mantenimiento según el artículo 30 del BSIG no acepta una prueba anual como evidencia del proceso intermedio.
Preguntas frecuentes
¿Encuentra el escaneo de CAVRIX el control de acceso deficiente?
La parte con patrón, sí: endpoints sin ninguna comprobación de permisos y construcciones inseguras conocidas. La parte sin patrón, es decir, si una comprobación existente hace la pregunta de negocio correcta, no la encuentra ningún escáner. Para eso la herramienta es el test de penetración.
¿Por qué dejáis este límite tan claro?
Porque una evidencia que fingiera que el escaneo lo cubre todo sería falsa en una auditoría o tras un incidente. Preferimos escribir de antemano lo que el escaneo no puede hacer antes que explicar después por qué algo se coló.
¿Ofrece CAVRIX tests de penetración?
No. Te decimos si necesitas uno, en qué fijarte al elegir, y asumimos lo que viene después del informe. El escaneo continuo es nuestra parte; la prueba, la de un proveedor especializado.