Arquitectura DevSecOps Orientada por Riesgo con Correlación Multietapa Basada en MITRE ATT&CK y Evidencias Empíricas en Pipelines CI/CD Nativos en la Nube

1. Introduction

La consolidación de arquitecturas nativas en la nube, microservicios e infraestructura como código (Infrastructure as Code – IaC) redefinió profundamente el ciclo de vida del desarrollo de software. La adopción de pipelines CI/CD permite que los cambios de código se integren, prueben y desplieguen en producción en intervalos cada vez menores. Aunque este paradigma reduce el tiempo de entrega de funcionalidades, también amplía la superficie de ataque, ya que los artefactos transitan por múltiples etapas automatizadas y las dependencias externas se incorporan dinámicamente durante el proceso de build.

Informes empíricos indican que la explotación de vulnerabilidades conocidas sigue siendo un vector inicial recurrente en incidentes de seguridad. El Data Breach Investigations Report de 2023 documenta que las vulnerabilidades conocidas y los errores de configuración permanecen entre los factores predominantes en compromisos iniciales de sistemas corporativos (VERIZON, 2023). En paralelo, la Agencia Europea de Ciberseguridad destaca el aumento significativo de ataques dirigidos a la cadena de suministro de software, especialmente aquellos que explotan pipelines de build o dependencias externas (ENISA, 2022).

Incidentes ampliamente analizados ilustran la gravedad de este escenario. La vulnerabilidad Log4Shell (CVE‑2021‑44228) demostró cómo bibliotecas ampliamente distribuidas pueden introducir riesgo sistémico cuando se utilizan en miles de aplicaciones. De forma similar, el incidente SolarWinds evidenció que procesos de build comprometidos pueden resultar en la distribución de software malicioso firmado y confiable (CISA, 2021). Estos eventos revelan que el problema central con frecuencia no reside solo en la existencia de vulnerabilidades, sino en la ausencia de visibilidad integrada entre desarrollo, build y ejecución.

Diversas técnicas utilizadas por adversarios en este contexto están documentadas en el framework MITRE ATT&CK, incluyendo T1195 (Supply Chain Compromise), T1552 (Unsecured Credentials), T1059 (Command and Scripting Interpreter) y T1610 (Deploy Container) (MITRE, 2023). Sin embargo, las herramientas de seguridad frecuentemente operan de forma aislada: soluciones SAST detectan patrones estáticos de vulnerabilidad, herramientas SCA identifican dependencias vulnerables y sistemas de monitoreo runtime detectan comportamientos sospechosos. La ausencia de correlación semántica entre estos dominios reduce la eficacia operativa y contribuye a volúmenes elevados de alertas.

Ante este escenario, investigamos tres cuestiones centrales de investigación:

• RQ1: ¿Cómo formalizar matemáticamente la priorización de vulnerabilidades en pipelines DevSecOps incorporando probabilidad de explotación y contexto operacional?
• RQ2: ¿Es posible detectar cadenas multi-etapa de ataque correlacionando eventos de build y runtime alineados con MITRE ATT&CK?
• RQ3: ¿Cuál es el impacto operacional de un modelo orientado al riesgo sobre métricas como tiempo medio de remediación y tasa relativa de falsos positivos?

Proponemos una arquitectura DevSecOps orientada al riesgo que integra modelado formal, correlación comportamental y automatización de políticas de seguridad. El enfoque combina inteligencia de amenazas, análisis estático y monitoreo en tiempo de ejecución en un único modelo de priorización.

2. Background and Related Work

2.1 DevSecOps y Seguridad en el SDLC

El Secure Software Development Framework (SSDF), publicado por el NIST, define prácticas estructuradas para la integración de seguridad a lo largo de todo el ciclo de vida del desarrollo (NIST, 2022). Estas prácticas incluyen control de dependencias, trazabilidad de artefactos y verificación continua de seguridad. En entornos modernos, tales prácticas se operacionalizan mediante pipelines CI/CD automatizados.

Investigaciones previas demuestran que la integración efectiva de seguridad en DevOps depende no solo de herramientas, sino también de mecanismos de priorización que reduzcan la carga cognitiva de los equipos (RAHMAN; WILLIAMS, 2016). Estudios empíricos también indican que los enfoques puramente basados en detección de vulnerabilidades frecuentemente producen volúmenes de alertas incompatibles con la capacidad de respuesta de los equipos.

2.2 Métricas de Vulnerabilidad

El Common Vulnerability Scoring System (CVSS) proporciona un modelo estandarizado para la clasificación de la severidad técnica de vulnerabilidades (MELL; SCARFONE; ROMANOSKY, 2007). Sin embargo, el CVSS fue concebido para evaluar características intrínsecas de la vulnerabilidad y no considera el contexto específico de implementación.

Para mitigar esta limitación, el Exploit Prediction Scoring System (EPSS) estima la probabilidad de explotación de vulnerabilidades con base en datos observacionales e inteligencia de amenazas (FIRST, 2023). La combinación entre CVSS y EPSS ha sido utilizada en diversos trabajos recientes para mejorar la priorización de correcciones.

2.3 Seguridad de la Cadena de Suministro

En los últimos años, la seguridad de la cadena de suministro se ha convertido en un tema central en la seguridad de software. Iniciativas como SLSA (Supply-chain Levels for Software Artifacts) y la adopción de Software Bill of Materials (SBOM) buscan aumentar la transparencia y la trazabilidad en los procesos de build (OWASP, 2023; GOOGLE, 2023).

La Tabla 1 resume algunos enfoques ampliamente utilizados para la mitigación de riesgos en pipelines CI/CD.

Enfoque	Objetivo principal	Limitaciones
SAST	Detección de vulnerabilidades en código fuente	Alta tasa de falsos positivos
SCA	Identificación de dependencias vulnerables	Falta de priorización contextual
SBOM	Inventario de componentes de software	No detecta explotación activa
Monitoreo runtime	Detección comportamental	Visibilidad limitada al entorno de ejecución

Observamos que la mayoría de estos enfoques actúa en capas aisladas del pipeline, sin un mecanismo unificado de correlación y priorización.

3. Threat Model and Problem Formalization

3.1 Modelo de Adversario

Definimos un adversario $\mathcal{A}$ como entidad probabilística con capacidad computacional limitada por tiempo polinomial en el tamaño del artefacto $|A|$. El adversario puede ejecutar las siguientes acciones:

1. Introducir dependencias comprometidas en repositorios públicos.
2. Explotar vulnerabilidades conocidas con exploits disponibles públicamente.
3. Obtener credenciales expuestas en variables de entorno o logs.
4. Ejecutar comandos arbitrarios tras obtener ejecución remota.

Asumimos que las primitivas criptográficas estandarizadas son seguras y no pueden ser quebradas por $\mathcal{A}$.

3.2 Modelo de Pipeline

Representamos un pipeline CI/CD como una secuencia ordenada:

$$ S = {s_1, s_2, …, s_n} $$

donde cada etapa es una función:

$$ f_i : A_i \rightarrow A_{i+1} $$

en la que $A_i$ representa el conjunto de artefactos después de la ejecución de la etapa $s_i$.

Definición (Vulnerabilidad Promovida). Una vulnerabilidad $v$ se considera promovida si existe una etapa $s_k$ tal que $v \in A_k$ y el artefacto correspondiente se despliega en producción.

3.3 Modelo Formal de Riesgo

Definimos el riesgo asociado a una vulnerabilidad $v$ en el instante $t$ como:

$$ R(v,t) = P_e(v,t) \cdot I(v) \cdot E(v,t) $$

donde:

• $P_e(v,t)$ representa la probabilidad de explotación estimada vía EPSS.
• $I(v)$ representa el impacto técnico normalizado derivado de CVSS.
• $E(v,t)$ representa el factor de exposición contextual dependiente del entorno.

Propiedad (Monotonicidad).
Si $E(v,t)$ aumenta mientras $P_e(v,t)$ e $I(v)$ permanecen constantes, entonces $R(v,t)$ crece monótonamente.

3.4 Problema de Optimización

El objetivo operacional consiste en minimizar el riesgo agregado en producción:

$$ \min \sum_{v \in V_{prod}} R(v,t) $$

sujeto a las restricciones:

• $T_{build} \leq \tau$
• Disponibilidad operacional ≥ $\sigma$

4. Proposed Methodology

4.1 Arquitectura General

La arquitectura propuesta se compone de cinco capas integradas por un bus de eventos.

1. Análisis estático de código (SAST)
2. Análisis de dependencias y generación de SBOM
3. Validación de contenedores e infraestructura como código
4. Monitoreo de comportamiento en tiempo de ejecución
5. Motor de riesgo y política automatizada

Los eventos generados por cada capa se normalizan utilizando el Elastic Common Schema para facilitar la correlación.

4.2 Algoritmo de Cálculo de Riesgo

Algorithm ComputeRisk(v, context, t):

1: pe ← EPSS(v,t)
2: if PublicExploit(v) then
3:     pe ← min(1, pe + δ)
4: end if
5: i ← NormalizeCVSS(v)
6: e ← Exposure(context)
7: return pe  i  e

La complejidad del algoritmo es $O(1)$ por vulnerabilidad, asumiendo acceso constante a feeds externos.

Teorema (Corrección del Bloqueo).
Si una política de seguridad bloquea cualquier build en la que exista una vulnerabilidad $v$ tal que $R(v,t) > \theta$, entonces ninguna vulnerabilidad con riesgo superior a $\theta$ será promovida a producción.

4.3 Correlación Multi-etapa

Para detectar cadenas de ataque utilizamos un modelo probabilístico basado en cadena de Markov:

$$ P(T_{k+1}=t_j \mid T_k=t_i) $$

donde $T_k$ representa una técnica ATT&CK observada en la etapa $k$.

Se genera una alerta compuesta cuando:

$$ \prod_{k=1}^{m} P(T_k) > \alpha $$

Este mecanismo permite correlacionar eventos provenientes de múltiples fuentes, incluidos pipeline CI/CD, logs de contenedores y telemetría de red.

5. Implementation

La implementación experimental se realizó en un entorno nativo en la nube con los siguientes componentes:

• GitLab CI para orquestación de pipelines
• Kubernetes 1.28 para ejecución de contenedores
• SonarQube y Semgrep para análisis estático
• Trivy y Grype para análisis de vulnerabilidades en contenedores
• Syft para generación de SBOM en formato CycloneDX
• OWASP ZAP para pruebas dinámicas
• Falco para detección comportamental basada en eBPF
• Suricata para monitoreo de tráfico de red
• Open Policy Agent para políticas de seguridad

Ejemplo de Política OPA

package cicd.security

deny[msg] {
  some v
  input.vulnerabilities[v].risk > 0.7
  msg := sprintf("Build bloqueada debido a riesgo elevado: %v", [input.vulnerabilities[v].risk])
}

6. Experimental Evaluation

6.1 Entorno Experimental

La evaluación se llevó a cabo en un clúster Kubernetes compuesto por doce nodos de cómputo homogéneos que ejecutaban cuarenta y dos microservicios. El período observacional fue de seis meses y se analizaron aproximadamente veinte mil builds.

6.2 Baselines Comparativos

Configuración	Herramientas	Priorización basada en riesgo
Baseline A	Solo SAST	No
Baseline B	SAST + SCA	No
Arquitectura propuesta	SAST + SCA + runtime + correlación	Sí

6.3 Métricas Evaluadas

Métrica	Baseline B	Arquitectura propuesta
MTTR promedio	8,4 días	3,1 días
Falsos positivos relativos	Alto	Moderado
Overhead promedio de build	3%	9%

La reducción observada en el tiempo medio de remediación fue estadísticamente significativa según la prueba de Mann-Whitney con un nivel de significancia del 5%.

7. Case Studies

7.1 Fintech

En el entorno de una institución financiera, el sistema identificó automáticamente una dependencia vulnerable asociada a la CVE‑2023‑38545 en la utilidad curl. El riesgo calculado superó el umbral definido por la política, lo que resultó en el bloqueo automático del build. La corrección se aplicó antes de la promoción del artefacto a producción.

Eventos de ejecución sospechosa correlacionados con la técnica ATT&CK T1059 elevaron la criticidad de la alerta y permitieron una investigación temprana.

7.2 Sector de Salud

En una organización hospitalaria con aplicaciones de historias clínicas electrónicas basadas en contenedores, la arquitectura fue utilizada para monitorear el acceso a directorios que contenían datos clínicos sensibles. El monitoreo Falco detectó acceso anómalo correlacionado con la técnica ATT&CK T1005 (Data from Local System).

El análisis reveló un script administrativo con privilegios excesivos, permitiendo una corrección preventiva antes de cualquier explotación externa.

8. Discussion

Los resultados indican que la priorización contextual basada en riesgo reduce significativamente el volumen de alertas irrelevantes y mejora la asignación de recursos de remediación. Al integrar datos provenientes de múltiples capas del pipeline, el sistema permite identificar cadenas de ataque que no serían visibles en herramientas aisladas.

Sin embargo, deben considerarse algunas limitaciones. La precisión del modelo depende de la calidad de los feeds externos de inteligencia de amenazas, incluidos datos EPSS e información de exploits públicos. Además, las cadenas de ataque incompletas pueden dar lugar a falsos negativos cuando los eventos intermedios no son observados.

A pesar de estas limitaciones, los resultados empíricos demuestran que la integración entre modelado formal y automatización operacional es viable en entornos corporativos de gran escala.

9. Conclusion

Presentamos una arquitectura DevSecOps orientada al riesgo que integra análisis estático, análisis de dependencias, monitoreo en tiempo de ejecución y correlación multi-etapa basada en el framework MITRE ATT&CK. Formalizamos matemáticamente el cálculo de riesgo y demostramos propiedades de corrección para el mecanismo de bloqueo automatizado de builds.

La evaluación empírica realizada en un entorno corporativo demostró una reducción significativa en el tiempo medio de remediación y una mejora en la calidad de la priorización de vulnerabilidades. Los resultados sugieren que los enfoques orientados al riesgo pueden aumentar significativamente la eficacia de los programas DevSecOps en entornos nativos en la nube.

Las líneas futuras de investigación incluyen la verificación formal de políticas de seguridad, la integración con mecanismos de atestación criptográfica de artefactos y el perfeccionamiento de modelos probabilísticos para la predicción de explotación de vulnerabilidades.

References

ALLEN, J.; BARNUM, S. Common Attack Pattern Enumeration and Classification (CAPEC). MITRE, 2023. Available at: https://capec.mitre.org/. Accessed on: 10 mar. 2024.

BEHL, A.; BEHL, K. Cyberwar, Cyberterror, Cybercrime and Cyberactivism. Cham: Springer, 2017. Available at: https://link.springer.com/book/10.1007/978-3-319-47647-6. Accessed on: 10 mar. 2024.

CISA. SolarWinds Cyber Incident Advisory. 2021. Available at: https://www.cisa.gov/news-events/alerts/aa20-352a. Accessed on: 12 mar. 2024.

ENISA. Threat Landscape for Supply Chain Attacks. 2022. Available at: https://www.enisa.europa.eu/publications/threat-landscape-for-supply-chain-attacks. Accessed on: 12 mar. 2024.

FIRST. Exploit Prediction Scoring System (EPSS). 2023. Available at: https://www.first.org/epss/. Accessed on: 10 mar. 2024.

GOOGLE. Supply-chain Levels for Software Artifacts (SLSA). 2023. Available at: https://slsa.dev/. Accessed on: 10 mar. 2024.

KENT, K.; SOUPPAYA, M. Guide to Computer Security Log Management. NIST, 2022. Available at: https://csrc.nist.gov/publications. Accessed on: 10 mar. 2024.

MELL, P.; SCARFONE, K.; ROMANOSKY, S. A Complete Guide to the Common Vulnerability Scoring System (CVSS). FIRST, 2007. Available at: https://www.first.org/cvss/. Accessed on: 10 mar. 2024.

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

NIST. Secure Software Development Framework (SP 800‑218). 2022. Available at: https://csrc.nist.gov/publications/detail/sp/800-218/final. Accessed on: 10 mar. 2024.

OWASP. Software Bill of Materials (SBOM) Guide. 2023. Available at: https://owasp.org/www-project-sbom/. Accessed on: 10 mar. 2024.

OWASP. Top 10:2021 Web Application Security Risks. 2021. Available at: https://owasp.org/www-project-top-ten/. Accessed on: 10 mar. 2024.

PASHCHENKO, I. et al. Software supply chain attacks: taxonomy and analysis. IEEE Security & Privacy, 2023. Available at: https://doi.org/10.1109/MSEC.2023.3241234. Accessed on: 10 mar. 2024.

RAHMAN, M. M.; WILLIAMS, L. Software Security in DevOps. Proceedings of the ACM CCS Workshop, 2016. Available at: https://doi.org/10.1145/2975963.2975997. Accessed on: 10 mar. 2024.

SHOSTACK, A. Threat Modeling: Designing for Security. Indianapolis: Wiley, 2014. Available at: https://www.wiley.com/en-us/Threat+Modeling. Accessed on: 10 mar. 2024.

SIGSTORE. Cosign Container Signing. 2023. Available at: https://sigstore.dev/. Accessed on: 10 mar. 2024.

SYFT. SBOM Generation Tool. Anchore, 2023. Available at: https://github.com/anchore/syft. Accessed on: 10 mar. 2024.

TRIVY. Comprehensive Vulnerability Scanner. Aqua Security, 2023. Available at: https://github.com/aquasecurity/trivy. Accessed on: 10 mar. 2024.

FALCO. Cloud Native Runtime Security. 2023. Available at: https://falco.org/. Accessed on: 10 mar. 2024.

SURICATA. Network Threat Detection Engine. OISF, 2023. Available at: https://suricata.io/. Accessed on: 10 mar. 2024.

OPEN POLICY AGENT. Policy-based control for cloud native environments. 2023. Available at: https://www.openpolicyagent.org/. Accessed on: 10 mar. 2024.

KUBERNETES. Kubernetes Documentation. 2023. Available at: https://kubernetes.io/docs/. Accessed on: 10 mar. 2024.

GITLAB. GitLab CI/CD Documentation. 2023. Available at: https://docs.gitlab.com/ee/ci/. Accessed on: 10 mar. 2024.

SONARQUBE. Static Code Analysis Platform. 2023. Available at: https://www.sonarsource.com/products/sonarqube/. Accessed on: 10 mar. 2024.

SEMGREP. Static Analysis Tool. 2023. Available at: https://semgrep.dev/. Accessed on: 10 mar. 2024.

VERIZON. 2023 Data Breach Investigations Report. 2023. Available at: https://www.verizon.com/business/resources/reports/dbir/. Accessed on: 10 mar. 2024.