Qué abarcan las pruebas de seguridad de aplicaciones
Las pruebas de seguridad de aplicaciones son el conjunto de comprobaciones que una empresa de software hace sobre su propio producto para encontrar vulnerabilidades antes que un atacante. Abarcan cuatro cosas distintas: el código que escriben sus desarrolladores, las librerías de código abierto que incorporan, la aplicación tal como está desplegada y las decisiones de diseño que toman las personas al construir cada funcionalidad. Cada una falla de una forma diferente, así que ninguna técnica cubre las cuatro.
Las pruebas estáticas leen el código sin ejecutarlo, el análisis de dependencias revisa los componentes de terceros frente a vulnerabilidades conocidas, las pruebas dinámicas sondean el sistema en marcha desde fuera y la revisión humana valora la lógica y el diseño. Los puntos ciegos de cada método los cubre otro, y por eso la pregunta útil nunca es qué herramienta ha comprado una empresa. Es cómo encajan los métodos, con qué frecuencia se ejecutan y qué pasa con sus hallazgos.
En una empresa que ya tiene una certificación, la pregunta suele llegar por dos vías. Un auditor pide evidencias de que hay pruebas de seguridad durante el desarrollo y antes de cada versión, o el cuestionario de seguridad de un gran cliente pregunta si la empresa hace SAST y DAST, con qué frecuencia y qué hace con los resultados. Ambos piden lo mismo: la prueba de un proceso que encuentra problemas y los corrige, aplicado a cada versión y no a una demostración.
- SAST. Qué examina: el código fuente, sin ejecutarlo. Detecta bien: inyecciones, funciones inseguras, secretos en el código. No detecta: configuración en ejecución, lógica de negocio.
- SCA. Qué examina: librerías de terceros y sus versiones. Detecta bien: vulnerabilidades conocidas en dependencias. No detecta: fallos en el código propio.
- DAST. Qué examina: la aplicación en marcha, desde fuera. Detecta bien: configuraciones erróneas, cabeceras ausentes, puntos expuestos. No detecta: rutas que no alcanza.
- Revisión de código. Qué examina: los cambios, leídos por una persona. Detecta bien: lógica de autorización, fallos de diseño. No detecta: volumen, porque nadie puede leerlo todo.
SAST: leer el código antes de que se ejecute
Las pruebas estáticas de seguridad de aplicaciones (SAST) analizan el código fuente, o el compilado, en busca de patrones que indican una vulnerabilidad. Como no necesitan un entorno en marcha, pueden ejecutarse en cada commit o pull request, lo que las convierte en la primera comprobación automática del ciclo de desarrollo. Funcionan especialmente bien con fallos que tienen una forma reconocible: datos del usuario que llegan a una consulta a base de datos sin parametrizar, deserialización insegura, funciones de hash débiles o credenciales escritas directamente en los ficheros. Sus hallazgos señalan el fichero y la línea exactos, a menudo con el código afectado, así que un desarrollador puede actuar sin que un especialista en seguridad le traduzca el resultado.
Sus límites están bien documentados, y la propia guía de OWASP sobre estas herramientas es clara al respecto. El análisis estático solo identifica de forma automática una parte relativamente pequeña de los fallos de seguridad de una aplicación, genera muchos falsos positivos y hay categorías muy difíciles de automatizar, sobre todo los problemas de autenticación y de control de acceso. Una herramienta SAST no puede saber que un usuario del cliente A nunca debe ver las facturas del cliente B. Esa regla vive en el negocio, no en la sintaxis, y ninguna búsqueda de patrones detectará que falta.
Los falsos positivos son el problema práctico y deciden si SAST resulta útil o se ignora. Un primer análisis de un código con algunos años de historia puede devolver cientos de hallazgos, y un equipo que tiene que revisarlos todos a mano deja pronto de leer los informes. El valor de SAST depende casi por completo del ajuste: desactivar las reglas que no aplican a la tecnología de la empresa, marcar los hallazgos aceptados para que no vuelvan a aparecer y acordar qué niveles de gravedad bloquean una versión. Una herramienta que da la alarma en cada pull request es peor que no tener ninguna, porque enseña a los desarrolladores a ignorar los avisos.
El patrón que funciona en la mayoría de equipos es analizar cada pull request pero mostrar solo los hallazgos que introduce ese cambio, y bloquear la integración solo ante problemas críticos o altos. El histórico de hallazgos antiguos se trata aparte, como una lista priorizada con responsables y fechas, que se va resolviendo junto al desarrollo normal. Así el código nuevo sale limpio desde el primer día sin pedir a los desarrolladores que corrijan años de historia antes de poder publicar nada, y el auditor recibe un relato claro: el riesgo nuevo se frena en la entrada y el antiguo se reduce con un plan.
Dependencias y secretos: el código que nadie del equipo escribió
La mayor parte del código que se ejecuta en una aplicación web moderna procede de librerías de código abierto, no de los desarrolladores de la empresa, y cada una de esas librerías trae sus propias dependencias. El análisis de composición de software (SCA) las inventaría todas, hasta la versión exacta, y las compara con bases de datos de vulnerabilidades publicadas. Responde a una pregunta que SAST no puede responder: ¿algún componente que distribuye la empresa está afectado por un fallo que ya es público?
Esa pregunta se vuelve urgente cada vez que se divulga una vulnerabilidad crítica en una librería muy usada. Lo primero que preguntan clientes y auditores es si la empresa está afectada y cuánto tardó en saberlo. Un equipo con SCA en su ciclo de desarrollo responde en minutos y enseña la actualización que hizo. Un equipo sin él empieza a buscar en los repositorios a mano, a menudo en servicios que nadie ha tocado en un año, mientras los clientes esperan una respuesta. Además, la mayoría de los hallazgos en dependencias se corrigen con poco esfuerzo, porque basta con actualizar, y por eso SCA suele ser el método de pruebas que antes reduce el riesgo.
El mismo inventario genera una lista de materiales de software (SBOM), un listado legible por máquina de cada componente y versión de una entrega. El SBOM está pasando de buena práctica a requisito. El Reglamento de Ciberresiliencia exige a los fabricantes de productos con elementos digitales identificar y documentar los componentes de sus productos, y cada vez más grandes clientes piden un SBOM durante la compra para poder hacer sus propias comprobaciones cuando se anuncie la próxima vulnerabilidad en una librería.
La detección de secretos cubre un fallo relacionado y muy frecuente: claves de API, contraseñas, tokens y claves privadas subidos al control de versiones. Una credencial en un repositorio sigue en el historial aunque se borre la línea, así que la única corrección real es rotar el secreto, no solo quitarlo del código. Analizar antes de cada commit impide que entren secretos nuevos, y revisar una vez todo el historial encuentra los que ya están dentro. Las credenciales filtradas en el código son una de las vías de entrada más frecuentes a los entornos cloud, y cerrarla es rápido comparado con casi cualquier otro control.
DAST: probar lo que está desplegado de verdad
Las pruebas dinámicas de seguridad de aplicaciones (DAST) envían peticiones a una aplicación en marcha y analizan las respuestas, de forma parecida a como lo haría un atacante automatizado. No necesitan acceso al código fuente y ven la aplicación exactamente como está desplegada, incluidos el servidor web, la configuración del framework y la infraestructura que tiene delante. Por eso son el complemento natural de SAST: uno lee lo que pretendían los desarrolladores y el otro prueba lo que está funcionando.
DAST detecta problemas que solo existen en ejecución. Entre los hallazgos habituales están las cabeceras de seguridad ausentes, las páginas de error que muestran trazas y rutas internas, las cookies sin los atributos de seguridad adecuados, las configuraciones TLS antiguas y los paneles de administración que nunca debieron ser accesibles. También encuentra inyecciones que el análisis estático no vio porque el comportamiento vulnerable venía de la configuración y no del código. Y confirma que una corrección funciona una vez desplegada, algo que ningún análisis de código puede hacer.
Su principal limitación es el alcance: DAST solo prueba lo que alcanza. Las zonas tras el inicio de sesión, los flujos de varios pasos y las API sin documentar tienen que configurarse de forma explícita, con cuentas de prueba y definiciones de la API; si no, el análisis cubre poco más que la página de acceso y la web comercial. Es el motivo más habitual por el que un informe DAST sale limpio y la aplicación no lo está. Cuando un cliente o un auditor revisa evidencias de DAST, la primera pregunta que conviene tener respondida es en qué partes de la aplicación se autenticó realmente el análisis.
DAST es además más lento que el análisis estático y más intrusivo, así que debe ejecutarse sobre un entorno de preproducción que replique producción y no sobre datos reales de clientes. Un análisis programado semanal sobre preproducción, más otro antes de cada versión importante, es un ritmo habitual y fácil de justificar ante un auditor. Los hallazgos entran en el mismo proceso de clasificación que todo lo demás, con las mismas reglas de gravedad y los mismos plazos de corrección.
La revisión de código y los fallos que no ven las herramientas
Todo cambio que se integra en la rama de producción debería leerlo alguien distinto de quien lo escribió. La revisión entre pares es sobre todo una práctica de calidad, pero también es el único control que detecta de forma fiable las vulnerabilidades que se escapan a las herramientas automáticas, porque los fallos más dañinos del software de negocio suelen ser errores de lógica y no errores de programación.
Pensemos en el tipo de problema que acaba en un informe de incidente: un endpoint que comprueba que el usuario ha iniciado sesión pero no que el registro que pide pertenece a su organización, un descuento que puede aplicarse dos veces, un rol que puede aprobar su propia solicitud o una función de exportación que ignora los permisos que se aplican en pantalla. En el OWASP Top 10 aparecen como control de acceso roto, y son invisibles para la búsqueda de patrones. Un revisor que entiende el producto los detecta rápido, siempre que los esté buscando. Una lista breve de seguridad en cada pull request (autorización comprobada, entradas validadas, sin secretos, acciones sensibles registradas) hace la revisión más consistente sin hacerla más lenta.
Algunos cambios merecen algo más que una revisión entre pares. Los nuevos flujos de autenticación, los cambios en la lógica de pagos o permisos, las integraciones nuevas que tratan datos de clientes y las nuevas API públicas tienen riesgo suficiente para justificar una revisión por alguien con experiencia en seguridad antes de publicarse. Definir esa lista de antemano, y dejar constancia de que la revisión se hizo, da al auditor una respuesta clara y proporcionada sobre cómo se controlan los cambios de riesgo. También evita que la revisión de seguridad se convierta en un cuello de botella para cada cambio pequeño.
Para los auditores, el registro importa tanto como la revisión. Las reglas de protección de ramas que exigen una aprobación antes de integrar, junto con el historial de aprobaciones del repositorio, suelen bastar como evidencia para los cambios habituales. En los cambios de alto riesgo, una nota breve de quién los revisó y qué se comprobó completa la evidencia.
Dónde encaja la prueba de intrusión
Una prueba de intrusión es un ejercicio acotado en el tiempo en el que especialistas intentan romper la aplicación, combinando herramientas con la exploración manual de la lógica de negocio y de debilidades que solo son peligrosas cuando se encadenan. Es la mejor comprobación del resultado global, y muchos grandes clientes piden un informe reciente dentro de su revisión de seguridad.
No sustituye a las pruebas durante el desarrollo. Una prueba de intrusión es una foto fija tomada una o dos veces al año, mientras el código cambia cada semana, así que la mayor parte de lo que se publica entre pruebas nunca se ha examinado. Una prueba hecha sin pruebas automáticas previas tiende además a gastar tiempo de especialistas en problemas que SAST, SCA o DAST habrían encontrado antes y con menos coste, como librerías antiguas o cabeceras ausentes, y deja menos tiempo para los fallos de lógica que solo encuentran las personas.
Por eso los programas más sólidos usan ambas cosas juntas. Las pruebas automáticas funcionan de forma continua y mantienen fuera los problemas comunes, y la prueba de intrusión se centra en las zonas donde el criterio humano aporta más: la autorización entre clientes, los flujos de pago, las funcionalidades nuevas y todo lo que no alcanzan las herramientas. Los hallazgos de cada prueba de intrusión vuelven además al ciclo de desarrollo, como nuevas reglas de SAST, nueva configuración de DAST o nuevos puntos en la lista de revisión, para que la próxima vez ese tipo de fallo se detecte automáticamente. Nuestro artículo sobre pentest frente a análisis de vulnerabilidades explica la diferencia con más detalle.
Qué evidencias esperan auditores y clientes
Ninguno de los marcos principales nombra una herramienta concreta. Piden un proceso definido, aplicado de forma constante, con evidencias de que funciona y de que sus hallazgos se tratan.
En ISO 27001:2022, los controles pertinentes del Anexo A están agrupados: 8.25 ciclo de vida de desarrollo seguro, 8.26 requisitos de seguridad de las aplicaciones, 8.27 arquitectura de sistemas y principios de ingeniería seguros, 8.28 codificación segura y 8.29 pruebas de seguridad en el desarrollo y la aceptación. El auditor buscará una política de desarrollo seguro que describa los métodos de prueba, evidencias de que se ejecutan, como registros del ciclo de integración, informes de análisis y registros de revisión, y evidencias de que los hallazgos se corrigieron en los plazos acordados o se aceptaron formalmente. Excluir estos controles en la declaración de aplicabilidad exige una justificación convincente, y una empresa que desarrolla software rara vez la tiene. Nuestra guía sobre ISO 27001 para empresas SaaS explica los demás controles que cambian en una empresa de software.
SOC 2 tampoco menciona SAST, pero su criterio de gestión de cambios (CC8.1) y su criterio de operación de sistemas (CC7.1) esperan que los cambios se prueben y aprueben antes de desplegarse y que las vulnerabilidades se identifiquen y se traten. En un informe Tipo II el auditor toma muestras de cambios de todo el periodo, así que la evidencia tiene que existir para cada pull request de la muestra: la aprobación de la revisión, los resultados de las pruebas y el registro del despliegue. Un proceso que solo funciona cuando alguien se acuerda de ejecutarlo dejará huecos en la muestra. Nuestro resumen de los criterios de servicios de confianza de SOC 2 explica cómo están organizados.
En NIS2, el artículo 21.2.e) exige seguridad en la adquisición, el desarrollo y el mantenimiento de los sistemas de redes y de información, incluida la gestión y divulgación de vulnerabilidades, y nuestro artículo sobre el artículo 21 de NIS2 lo desarrolla por completo. Para las empresas que venden productos de software en la UE, el Reglamento de Ciberresiliencia añade obligaciones de producto sobre la gestión de vulnerabilidades y la documentación de componentes. Los grandes clientes traducen todo esto a las mismas preguntas de su cuestionario: qué métodos de prueba se usan, con qué frecuencia, quién clasifica los hallazgos y en cuánto tiempo se corrigen los críticos.
Cómo hacer que el programa se mantenga
El fallo más habitual en seguridad de aplicaciones no es que falte una herramienta, sino que nadie mire la que hay. Unas pocas decisiones al principio determinan si las pruebas pasan a formar parte de cómo trabaja el equipo o se convierten en ruido que todos aprenden a ignorar.
El orden de implantación importa. Para la mayoría de equipos tiene sentido empezar por la detección de secretos, porque se configura rápido y sus hallazgos no dejan dudas, y seguir con SCA, porque las vulnerabilidades en dependencias son numerosas y se suelen corregir actualizando. Después llega SAST sobre el código nuevo, ajustado antes de permitir que bloquee nada, y por último DAST sobre preproducción, cuando ya existen las cuentas de prueba y las definiciones de la API. La revisión entre pares suele existir ya y solo necesita una lista de seguridad y un registro. Implantarlo todo a la vez suele enterrar al equipo en hallazgos y desacreditar el programa antes de que haya dado ningún resultado.
Las reglas para tratar los hallazgos importan tanto como las herramientas. Conviene dejar por escrito quién revisa los hallazgos nuevos, cómo se fija la gravedad y en qué plazo se corrige cada nivel, por ejemplo los críticos en días, los altos en pocas semanas y los medios dentro del trimestre, con las excepciones aprobadas y registradas en lugar de abiertas sin más. Esos plazos son justo lo que comprueba un auditor y lo que pregunta un cuestionario de cliente, así que deben ser realistas para el equipo y no copiados de una plantilla.
Por último, hay que medir lo que cambia. Conviene seguir los hallazgos abiertos por gravedad, la antigüedad del hallazgo crítico más antiguo y el porcentaje de hallazgos corregidos dentro del plazo acordado. Una tendencia a la baja durante varios trimestres es mejor evidencia que cualquier informe aislado, y es la cifra que debería ver la dirección junto al resto de indicadores del programa de seguridad.
Dónde encaja Qalea
Qalea realiza pruebas de seguridad sobre el código propio del cliente, sus dependencias y sus contenedores, con SAST, DAST, SCA, detección de secretos y generación de SBOM desde el primer commit hasta la aplicación en ejecución, y las pruebas de intrusión manuales cubren lo que no alcanzan las herramientas automáticas. El equipo de Qalea ayuda a priorizar los hallazgos por riesgo real y a acordar planes de corrección que el equipo de desarrollo pueda seguir de verdad.
Los resultados conviven con el resto del programa de seguridad en la plataforma de Qalea, donde las evidencias de desarrollo seguro para ISO 27001, SOC 2 y NIS2 se guardan junto a todos los demás controles. La exposición desde fuera se cubre con la gestión de la superficie de ataque, que explicamos en nuestro artículo sobre la superficie de ataque externa. Hay más sobre pruebas y exposición en nuestra página temática de ataque y pentesting.
