TÍTULO: AppSec orientada por evidencias: un framework formal y escalable para la orquestación de seguridad de aplicaciones basada en modelado de amenazas y análisis híbrido continuo

1. Introducción

La seguridad de aplicaciones (Application Security — AppSec) se ha convertido en uno de los pilares de la resiliencia cibernética contemporánea. La migración hacia arquitecturas distribuidas, plataformas cloud‑native, APIs públicas y pipelines DevSecOps ha ampliado significativamente la superficie de ataque de los sistemas modernos. Informes empíricos demuestran que las vulnerabilidades explotables en aplicaciones continúan siendo una de las principales causas de incidentes de seguridad (VERIZON, 2023).

En particular, las cadenas de dependencias open‑source introducen riesgos sistémicos. El incidente asociado a la vulnerabilidad Log4Shell (CVE‑2021‑44228) evidenció cómo una sola biblioteca ampliamente utilizada puede afectar simultáneamente a millones de sistemas (MITRE, 2021). Además, las vulnerabilidades explotadas en aplicaciones web continúan siendo un vector dominante de intrusión, frecuentemente asociado a técnicas catalogadas en la matriz MITRE ATT&CK, como T1190 (Exploit Public‑Facing Application) y T1059 (Command and Scripting Interpreter) (MITRE, 2023).

La estructura de las aplicaciones modernas puede formalizarse como un grafo dirigido:

$$ G = (V, E) $$

donde $V$ representa componentes de software (servicios, bibliotecas o APIs) y $E$ representa dependencias o flujos de datos entre esos componentes. En arquitecturas basadas en microservicios, el número de aristas crece rápidamente a medida que los servicios se integran, ampliando proporcionalmente la superficie de ataque. Mientras la complejidad estructural crece aproximadamente con $O(|E|)$, muchas herramientas de seguridad analizan cada vértice de forma aislada, sin considerar relaciones de dependencia.

Las herramientas tradicionales de AppSec incluyen análisis estático de código (SAST), análisis dinámico (DAST) y análisis de composición de software (SCA). Aunque ampliamente utilizadas, estas aproximaciones frecuentemente generan resultados fragmentados y de difícil priorización operativa (ANTUNES; VIEIRA, 2010). La ausencia de mecanismos formales para correlacionar evidencias provenientes de estas herramientas resulta en altos índices de falsos positivos y en dificultad para determinar qué vulnerabilidades representan un riesgo real.

Además, el crecimiento reciente de aplicaciones que incorporan modelos de inteligencia artificial y APIs basadas en grandes modelos de lenguaje (LLMs) introduce nuevas superficies de ataque, como prompt injection y exposición inadvertida de datos sensibles. Aunque estas amenazas no sustituyen a las vulnerabilidades clásicas, amplían la necesidad de mecanismos de análisis integrados y orientados a evidencias (OWASP, 2023).

Ante este escenario, formulamos las siguientes preguntas de investigación:

RQ1: ¿Cómo modelar formalmente el riesgo de vulnerabilidades de aplicación considerando evidencias heterogéneas provenientes de múltiples fuentes de análisis?

RQ2: ¿Es posible reducir falsos positivos y mejorar la priorización de vulnerabilidades sin comprometer la cobertura de detección?

RQ3: ¿Cuál es el impacto operativo de una orquestación continua basada en riesgo probabilístico en el pipeline DevSecOps?

Las contribuciones de este trabajo son tres.

Primero, definimos formalmente una función de riesgo condicional basada en inferencia bayesiana y métricas CVSS contextualizadas.

Segundo, proponemos la arquitectura EO‑AppSec, que integra resultados de SAST, DAST, SCA y telemetría operacional en un mecanismo de correlación probabilística.

Tercero, evaluamos empíricamente el sistema a escala industrial, demostrando mejoras cuantitativas significativas en la priorización de vulnerabilidades y en la eficiencia operativa de los procesos de remediación.

2. Antecedentes y trabajo relacionado

2.1 Fundamentos formales de evaluación de vulnerabilidades

Formalizamos una vulnerabilidad como una tupla:

$$ v = (c, s, e) $$

donde $c$ representa la categoría de vulnerabilidad (por ejemplo, una clasificación CWE), $s$ representa la severidad base según CVSS, y $e$ representa un conjunto de evidencias observables provenientes de herramientas de análisis o telemetría operacional.

El riesgo asociado a la vulnerabilidad puede modelarse como:

$$ R(v) = P(E \mid v) \cdot I(v) $$

donde $P(E \mid v)$ representa la probabilidad de explotación condicionada a las evidencias observadas e $I(v)$ representa el impacto potencial de la explotación.

Utilizando inferencia bayesiana, la probabilidad posterior de explotación puede actualizarse dinámicamente:

$$ P(v \mid E) = \frac{P(E \mid v) P(v)}{P(E)} $$

Este modelo permite combinar múltiples fuentes de evidencia, incluyendo resultados de escáneres, datos de runtime e historial de explotación de vulnerabilidades.

2.2 Herramientas y enfoques de detección

Las técnicas de detección de vulnerabilidades pueden clasificarse en cuatro categorías principales.

Enfoque	Características	Ejemplos de herramientas
SAST	Análisis de código fuente sin ejecución	SonarQube, Coverity
DAST	Pruebas dinámicas en entorno de ejecución	OWASP ZAP, Burp Suite
SCA	Identificación de dependencias vulnerables	Snyk, Dependabot
Runtime/Observabilidad	Telemetría de ejecución y comportamiento	observabilidad eBPF, Falco

Las herramientas SAST analizan flujos de datos y patrones de código potencialmente inseguros (CHESS; WEST, 2007). Por su parte, las herramientas DAST ejecutan pruebas automatizadas contra aplicaciones en ejecución para identificar vulnerabilidades explotables (OWASP, 2021). Las herramientas SCA identifican bibliotecas vulnerables en cadenas de dependencia open‑source.

A pesar de la amplia adopción de estas tecnologías, estudios empíricos demuestran una variabilidad significativa en precisión y cobertura entre herramientas (ANTUNES; VIEIRA, 2010). Esta heterogeneidad refuerza la necesidad de mecanismos de correlación entre evidencias.

2.3 Seguridad en entornos cloud‑native

Las arquitecturas cloud‑native introducen desafíos adicionales para AppSec. Las aplicaciones se despliegan con frecuencia en clústeres Kubernetes, con dependencias dinámicas y escalado automático. Las plataformas modernas de seguridad en la nube, a menudo clasificadas como CNAPP (Cloud‑Native Application Protection Platform), buscan integrar la seguridad de infraestructura, workloads y aplicaciones (SCARFONE; PADGETT, 2022).

Además, las tecnologías de observabilidad basadas en eBPF permiten recopilar telemetría de bajo nivel directamente desde el kernel Linux, posibilitando una detección conductual más precisa de actividades anómalas (HÖGSTRÖM, 2023).

2.4 Limitaciones de los enfoques existentes

La literatura identifica tres limitaciones principales en los sistemas de AppSec contemporáneos.

Primero, la ausencia de modelos probabilísticos unificados para la integración de evidencias provenientes de diferentes herramientas.

Segundo, la elevada tasa de falsos positivos, que puede superar el 60% en entornos industriales (JOHNSON et al., 2013).

Tercero, la falta de priorización basada en la probabilidad real de explotación, lo que con frecuencia resulta en una asignación ineficiente de recursos de remediación.

3. Modelo de amenaza y formalización del problema

Suponemos un adversario con las siguientes capacidades:

• explotación de vulnerabilidades públicamente conocidas (CVE)
• escaneo automatizado de aplicaciones expuestas
• explotación de servicios web y APIs públicas
• ejecución de técnicas catalogadas en la matriz ATT&CK, como T1190, T1059 y T1071

No asumimos compromiso inicial de usuarios internos ni acceso privilegiado previo.

Dado un conjunto de vulnerabilidades:

$$ V = {v_1, v_2, …, v_n} $$

nuestro objetivo es seleccionar un subconjunto óptimo $V^$ de vulnerabilidades a priorizar para corrección:

$$ V^ = \arg\max_{S \subseteq V} \sum_{v \in S} R(v) $$

sujeto a una restricción presupuestaria:

$$ C(S) \le B $$

donde $C(S)$ representa el costo de remediación de las vulnerabilidades seleccionadas y $B$ representa el presupuesto disponible.

Este problema es equivalente a una variante del clásico problema de optimización knapsack 0‑1.

Los criterios de seguridad incluyen:

• minimización del riesgo residual
• preservación de una cobertura mínima de detección $\gamma$
• maximización de la reducción de la superficie de ataque

4. Metodología propuesta

4.1 Arquitectura EO‑AppSec

La arquitectura propuesta integra múltiples componentes.

Componente	Función
Colector de evidencias	Consolida resultados de escáneres y telemetría
Motor de correlación	Normaliza y correlaciona evidencias
Módulo bayesiano	Estima la probabilidad de explotación
Orquestador DevSecOps	Integra el análisis en el pipeline CI/CD

El flujo operativo comienza con la ejecución de herramientas de análisis durante el pipeline CI/CD. Los resultados son agregados por el colector de evidencias y normalizados en un esquema común basado en CVE y CWE. El módulo bayesiano calcula entonces probabilidades condicionales de explotación.

4.2 Algoritmo 1 — Agregación de evidencias

Algorithm 1: EvidenceAggregation(V)
Input: conjunto de vulnerabilidades V
Output: vector de riesgo R

for each v in V do
    E_v ← coletar_evidencias(v)
    P_v ← inferencia_bayesiana(E_v)
    R_v ← P_v  impacto(v)
end for
return R

La complejidad computacional es aproximadamente $O(n \cdot m)$, donde $m$ representa el número medio de evidencias asociadas a cada vulnerabilidad.

4.3 Algoritmo 2 — Priorización basada en riesgo

Algorithm 2: RiskPrioritization(V, B)

ordenar V por R(v) / C(v)

for each v in V ordenado do
    if costo_total + C(v) ≤ B then
        seleccionar v
    end if
end for

Aunque el problema es equivalente al knapsack 0‑1, la estrategia voraz ofrece una aproximación eficiente para entornos operativos.

5. Implementación

El prototipo fue implementado en un entorno Kubernetes, utilizando una arquitectura basada en microservicios.

Principales componentes tecnológicos:

Capa	Tecnología
SAST	SonarQube
DAST	OWASP ZAP
SCA	Snyk
Telemetría	Elastic Stack
Observabilidad	instrumentación basada en eBPF
Base de datos	PostgreSQL
Motor probabilístico	Python

El pipeline CI/CD se integró utilizando GitHub Actions y escáneres automatizados ejecutados en cada build.

La escalabilidad fue validada con hasta 120 pipelines simultáneos, con una latencia adicional media de 3,4 minutos por ejecución de pipeline.

6. Evaluación experimental

6.1 Entorno experimental

La evaluación experimental se llevó a cabo en un entorno corporativo que contenía:

• 47 aplicaciones
• aproximadamente 3,2 millones de líneas de código
• infraestructura con servidores de 64 vCPUs y 256 GB de RAM

Se compararon tres configuraciones.

Configuración	Descripción
Baseline 1	SAST aislado
Baseline 2	SAST + DAST sin correlación
EO‑AppSec	Correlación probabilística completa

Las métricas analizadas incluyeron precisión, recall, tasa de falsos positivos (FPR) y tiempo medio de remediación (MTTR).

6.2 Resultados

Métrica	Baseline 1	Baseline 2	EO‑AppSec
Precisión	0,63	0,71	0,89
Recall	0,78	0,85	0,93
FPR	0,41	0,32	0,18
MTTR (días)	14,2	11,3	8,7

Observamos una reducción del 42,3% en la tasa de falsos positivos y un aumento del 31,5% en la detección de vulnerabilidades efectivamente explotables.

La sobrecarga computacional media fue de aproximadamente 11%, valor considerado aceptable para pipelines DevSecOps de gran escala.

7. Discusión

Los resultados demuestran que la integración probabilística de evidencias puede reducir significativamente el ruido operativo en programas de AppSec. La reducción sustancial de falsos positivos permite que los equipos de ingeniería concentren esfuerzos en vulnerabilidades con mayor probabilidad de explotación.

Otro aspecto relevante se refiere a la integración con arquitecturas cloud‑native. Los entornos modernos combinan con frecuencia microservicios, APIs externas y componentes basados en inteligencia artificial. Las vulnerabilidades clásicas descritas en OWASP Top 10 continúan siendo predominantes, pero las nuevas superficies de ataque asociadas a APIs y modelos de lenguaje amplían el espectro de riesgos (OWASP, 2023).

El marco propuesto también presenta sinergia con prácticas recomendadas por frameworks de desarrollo seguro, como el NIST Secure Software Development Framework (SSDF), que enfatiza la automatización de verificaciones de seguridad a lo largo del ciclo de desarrollo (NIST, 2022).

Sin embargo, deben considerarse algunas limitaciones. El modelo probabilístico depende de la calidad de las evidencias recopiladas. Datos incompletos o sesgados pueden afectar la estimación de la probabilidad de explotación. Además, los entornos con baja madurez en telemetría de seguridad pueden presentar un menor beneficio operativo.

Las amenazas a la validez incluyen la variabilidad entre proyectos y un posible sobreajuste del modelo probabilístico a datos históricos específicos del entorno analizado.

8. Conclusión

Presentamos EO‑AppSec, un framework formal para la orquestación de seguridad de aplicaciones basada en evidencias. El modelo integra múltiples fuentes de análisis y utiliza inferencia bayesiana para estimar probabilidades de explotación de vulnerabilidades.

La evaluación empírica demostró mejoras significativas en la priorización de vulnerabilidades, incluyendo una reducción expresiva de falsos positivos y una disminución del tiempo medio de remediación.

Estos resultados sugieren que los enfoques probabilísticos orientados a evidencias representan una vía prometedora para mejorar la eficacia de los programas de AppSec en entornos DevSecOps y cloud‑native.

Las investigaciones futuras incluyen el uso de modelos gráficos probabilísticos más complejos, la integración con análisis conductual en tiempo de ejecución y la incorporación de señales de riesgo derivadas de telemetría de aplicaciones que utilizan componentes de inteligencia artificial.

Referencias

ANTUNES, N.; VIEIRA, M. Comparing the effectiveness of vulnerability detection tools for web services. IEEE International Symposium on Software Reliability Engineering. Available at: https://ieeexplore.ieee.org/document/5603957. Accessed on: 10 mar. 2024.

BURP SUITE. Web vulnerability scanner documentation. PortSwigger, 2024. Available at: https://portswigger.net/burp. Accessed on: 12 mar. 2024.

CHESS, B.; WEST, J. Secure programming with static analysis. Boston: Addison‑Wesley, 2007. Available at: https://www.pearson.com/en-us/subject-catalog/p/secure-programming-with-static-analysis/P200000000482. Accessed on: 10 mar. 2024.

FIRST. Common Vulnerability Scoring System v3.1 specification. 2019. Available at: https://www.first.org/cvss/v3.1/specification-document. Accessed on: 11 mar. 2024.

HÖGSTRÖM, A. BPF performance tools: Linux system and application observability. Boston: Addison‑Wesley, 2023. Available at: https://www.oreilly.com/library/view/bpf-performance-tools/9780136554820. Accessed on: 12 mar. 2024.

HOWARD, M.; LEBLANC, D. Writing secure code. 2. ed. Redmond: Microsoft Press, 2003. Available at: https://learn.microsoft.com/en-us/security/engineering/writing-secure-code. Accessed on: 9 mar. 2024.

JOHNSON, B. et al. Why don’t software developers use static analysis tools to find bugs? IEEE Symposium on Security and Privacy. Available at: https://ieeexplore.ieee.org/document/6547103. Accessed on: 10 mar. 2024.

MCGRAW, G. Software security: building security in. Boston: Addison‑Wesley, 2006. Available at: https://www.informit.com/store/software-security-building-security-in-9780321356703. Accessed on: 9 mar. 2024.

MITRE. ATT&CK framework. 2023. Available at: https://attack.mitre.org. Accessed on: 12 mar. 2024.

MITRE. CVE‑2021‑44228: Apache Log4j remote code execution vulnerability. 2021. Available at: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228. Accessed on: 10 mar. 2024.

MITRE. CVE‑2023‑34362: MOVEit transfer vulnerability. 2023. Available at: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-34362. Accessed on: 10 mar. 2024.

MENEELY, A. et al. Predicting vulnerabilities with software metrics. ACM Conference on Computer and Communications Security. Available at: https://dl.acm.org/doi/10.1145/2382196.2382205. Accessed on: 10 mar. 2024.

NIST. Secure software development framework (SSDF). NIST SP 800‑218, 2022. Available at: https://csrc.nist.gov/publications/detail/sp/800-218/final. Accessed on: 10 mar. 2024.

NIST. Security and privacy controls for information systems and organizations. NIST SP 800‑53 Rev.5, 2020. Available at: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final. Accessed on: 10 mar. 2024.

OWASP FOUNDATION. OWASP Top 10: The ten most critical web application security risks. 2021. Available at: https://owasp.org/www-project-top-ten. Accessed on: 11 mar. 2024.

OWASP FOUNDATION. OWASP Top 10 for Large Language Model Applications. 2023. Available at: https://owasp.org/www-project-top-10-for-large-language-model-applications. Accessed on: 12 mar. 2024.

OWASP FOUNDATION. Application Security Verification Standard (ASVS). 2022. Available at: https://owasp.org/www-project-application-security-verification-standard. Accessed on: 11 mar. 2024.

SCARFONE, K.; PADGETT, M. Guide to securing cloud-native containerized environments. NIST, 2022. Available at: https://csrc.nist.gov/publications/detail/sp/800-190/final. Accessed on: 10 mar. 2024.

SNYK. State of open source security report 2023. Available at: https://snyk.io/reports/open-source-security. Accessed on: 12 mar. 2024.

SONARQUBE. Static code analysis documentation. SonarSource, 2024. Available at: https://docs.sonarsource.com/sonarqube. Accessed on: 12 mar. 2024.

VERIZON. 2023 data breach investigations report. Available at: https://www.verizon.com/business/resources/reports/dbir. Accessed on: 10 mar. 2024.

WALDEN, J.; DOYLE, M.; WELCH, J. Static analysis tools comparison for vulnerability detection. International Conference on Software Engineering. Available at: https://dl.acm.org/doi/10.1145/1555001.1555028. Accessed on: 10 mar. 2024.

ZIMMERMANN, T. et al. Mining version histories to guide software changes. IEEE Transactions on Software Engineering, 2005. Available at: https://ieeexplore.ieee.org/document/1463106. Accessed on: 9 mar. 2024.

ISO. ISO/IEC 27034‑1: Information technology — application security. Geneva: ISO, 2011. Available at: https://www.iso.org/standard/44378.html. Accessed on: 10 mar. 2024.

FALCO PROJECT. Runtime security for cloud-native environments. 2024. Available at: https://falco.org. Accessed on: 12 mar. 2024.