DevSecOps adaptativo en 2026: integración de seguridad continua, telemetría e ingeniería de confianza cero para pipelines de software y plataformas nativas de nube

1. Introducción

DevSecOps llegó para corregir una falla estructural del desarrollo moderno: la separación artificial entre quienes construyen software, quienes lo operan y quienes lo defienden. En 2026, sin embargo, el problema ya no es únicamente organizacional. El problema es ecosistémico. Las aplicaciones se ensamblan a partir de cientos o miles de dependencias, se ejecutan sobre plataformas efímeras, delegan partes críticas a servicios gestionados y exponen interfaces programáticas consumidas por agentes automatizados, pipelines, y modelos de IA integrados en la propia lógica del negocio. En ese contexto, tratar la seguridad como una fase final o como una batería de pruebas puntuales produce una falsa sensación de control. La evidencia acumulada desde compromisos como SolarWinds, Codecov, npm, PyPI, Log4Shell, MOVEit y los incidentes de runners comprometidos en plataformas de CI/CD demuestra que el plano de ataque se desplazó hacia la cadena de construcción, distribución y operación del software (MIRKOVIC, 2021; NIST, 2022).

La práctica contemporánea de DevSecOps exige una visión más amplia: seguridad como capacidad continua, medible y automatizada. Esto implica introducir controles desde el diseño, asegurar la procedencia de artefactos, verificar la integridad de dependencias, imponer políticas declarativas sobre infraestructura y runtime, y correlacionar telemetría de ejecución con señales de riesgo del repositorio y del entorno de despliegue. En otras palabras, el objetivo no es “detectar vulnerabilidades” sino minimizar la probabilidad de explotación y reducir la exposición temporal y operacional. En 2026, esta orientación es especialmente importante porque la madurez de la automatización ofensiva, el uso de IA para ingeniería social y la commoditización de exploits hacen que una vulnerabilidad de baja criticidad pueda convertirse en incidente real en cuestión de horas, no de semanas.

El cambio tecnológico también ha alterado el tipo de controles necesarios. Los equipos ya no operan exclusivamente sobre máquinas virtuales o aplicaciones monolíticas; trabajan sobre Kubernetes, service meshes, funciones serverless, pipelines distribuidos, artefactos OCI, registros de contenedores, secretos dinámicos y políticas gestionadas como código. A esto se suma la adopción de marcos de seguridad de cadena de suministro como SLSA, SBOM, in-toto, Sigstore y attestations verificables, además de nuevas capacidades de observabilidad basada en eBPF y plataformas CNAPP para visibilidad continua del plano de carga y configuración. El resultado es una disciplina híbrida: parte ingeniería de software, parte seguridad de infraestructura, parte respuesta a incidentes y parte gobierno tecnológico.

Este artículo propone un modelo de DevSecOps adaptativo para 2026 que prioriza tres propiedades: procedencia verificable, reducción continua de superficie de ataque y retroalimentación operacional basada en riesgo. La contribución central consiste en formalizar la seguridad del pipeline como un sistema de control con entradas, salidas y umbrales dinámicos, donde cada commit, cada build y cada despliegue generan evidencias consumibles por motores de política y por herramientas de detección en runtime. Desde la perspectiva defensiva, esto permite cerrar el ciclo entre prevención y respuesta. Desde la perspectiva del negocio, permite justificar inversión con métricas concretas y evitar que la seguridad sea percibida como un obstáculo no cuantificado.

La relevancia del tema en 2026 también está marcada por el crecimiento de la automatización impulsada por modelos generativos. Los atacantes utilizan IA para redactar correos de phishing convincentes, sintetizar señuelos de soporte técnico, adaptar malware y acelerar reconocimiento. Paralelamente, las organizaciones incorporan asistentes basados en LLM para programar, revisar código y generar infraestructura. Esto abre nuevos vectores de riesgo: prompt injection, exfiltración a través de herramientas auxiliares, abuso de tokens de acceso y contaminación de dependencias sugeridas por sistemas de autocompletado. Por ello, un DevSecOps moderno debe contemplar no sólo el código y la infraestructura, sino también la gobernanza de herramientas de IA y la protección del contexto operativo de los agentes automatizados (OWASP, 2024; NIST, 2024).

En este trabajo se defiende una tesis clara: DevSecOps en 2026 sólo es efectivo si se diseña como una arquitectura de seguridad de extremo a extremo, con controles verificables, telemetría continua y capacidad de adaptación al riesgo real. No basta con “poner escáneres”; se requiere orquestar capacidades para reducir exposición, asegurar procedencia y acelerar la toma de decisiones. La investigación aborda el problema desde una perspectiva práctica, con formalización de amenazas, metodología implementable, evaluación experimental y un caso de estudio que refleja la realidad de una plataforma SaaS moderna.

2. Background and Related Work

DevSecOps es la evolución natural de DevOps cuando las organizaciones reconocen que la velocidad sin controles produce deuda de seguridad, y que la seguridad sin automatización no escala. En sus primeras formulaciones, la práctica se centraba en desplazar pruebas de seguridad hacia etapas más tempranas del ciclo de vida y en fomentar responsabilidad compartida entre desarrollo, operaciones y seguridad (BASS, WEBER y ZHU, 2015). Con el tiempo, la disciplina incorporó analítica estática, fuzzing, pruebas de dependencia, contenedorización, control de secretos y automatización de compliance. Sin embargo, la literatura previa a 2020 solía asumir pipelines relativamente lineales y entornos con menor dependencia externa. Esa suposición quedó obsoleta.

En los años recientes, el foco se desplazó hacia la cadena de suministro de software. El informe sobre SolarWinds mostró que un compromiso en la construcción podía escalar a múltiples clientes de alta confianza, mientras que eventos como Codecov destacaron cómo un script de CI puede convertirse en punto de exfiltración masiva. NIST formalizó la necesidad de asegurar software desde la concepción hasta la distribución, enfatizando prácticas de autenticidad, integridad y trazabilidad (NIST, 2022). Paralelamente, SLSA introdujo niveles de madurez para procedencia de software, y Sigstore permitió firmas y verificación más accesibles para equipos de desarrollo. La combinación de estas iniciativas cambió la conversación: ya no se trata de confiar en el repositorio, sino de poder demostrar matemáticamente y operacionalmente de dónde proviene cada artefacto.

El auge de contenedores y Kubernetes amplió la superficie de ataque. Investigaciones y guías de seguridad de AWS, Google, Microsoft y CNCF mostraron que la mayoría de incidentes en clústeres no provienen de fallos criptográficos sofisticados, sino de mala configuración, secretos expuestos, imágenes vulnerables, privilegios excesivos y permisos RBAC demasiado amplios. CNAPP, CSPM y CWPP surgieron para consolidar visibilidad y control sobre postura, cargas y identidades. En este punto, la literatura académica y la industria convergieron en una conclusión: la seguridad debe comprender el plano de infraestructura tanto como el código. La observabilidad moderna, especialmente mediante eBPF, agregó capacidad de detección a nivel de sistema con bajo overhead, facilitando la correlación entre eventos de build, despliegue y runtime (AQUINO et al., 2023).

Otro eje relevante es el modelado de amenazas. Metodologías como STRIDE, PASTA y LINDDUN siguen siendo útiles, pero el DevSecOps de 2026 requiere una adaptación a cadenas de suministro, repositorios distribuidos y automatización autónoma. Las amenazas no son únicamente bugs explotables; incluyen adulteración de dependencias, envenenamiento de caches, toma de control de cuentas de mantenedores, abuso de tokens de CI, credenciales de nube filtradas, manipulación de IaC y uso malicioso de artefactos legítimos. En la práctica, esto obliga a adoptar un enfoque de ataque por superficie: cada interfaz, cada secreto y cada acción automatizada es un punto potencial de compromiso. La literatura de seguridad de pipelines, especialmente trabajos de 2022 a 2025, coincide en que los controles deben ser composables y verificables, no sólo documentales (GEHANI et al., 2023; SCHUMMER et al., 2024).

La integración de seguridad en el ciclo de vida también ha sido estudiada desde el punto de vista humano y organizacional. Las investigaciones muestran que alertas excesivas de SAST y SCA generan fatiga, lo que lleva a ignorar hallazgos o a tratar la seguridad como ruido. Por ello, herramientas modernas incorporan priorización basada en explotabilidad, contexto de negocio y reachability analysis. La idea de “shift left” evolucionó hacia “shift everywhere”: prevenir en el diseño, verificar en el build, gobernar en el despliegue y observar en runtime. Esta visión está respaldada por la expansión de plataformas como GitHub Advanced Security, GitLab Ultimate, Wiz, Prisma Cloud, Aqua, Sysdig y otras soluciones que integran escaneo, postura y detección, aunque con diferencias importantes en cobertura y falsos positivos.

En paralelo, el ecosistema regulatorio y de estándares maduró. NIST publicó guías específicas para software seguro, identidad y autenticación; la Unión Europea avanzó con NIS2 y requisitos asociados a resiliencia; y la presión por transparencia impulsó la adopción de SBOM en sectores críticos. También ganó tracción el post-quantum crypto, aunque todavía de forma gradual, obligando a planificar migraciones criptográficas sin romper compatibilidad. Todo esto configura un entorno donde DevSecOps ya no se entiende como una colección de prácticas útiles, sino como una arquitectura de gobernanza técnica para la producción segura de software.

La siguiente tabla resume la evolución funcional de capacidades clave en la disciplina. Se observa cómo el foco se desplaza desde control local del código hacia visibilidad sistémica y procedencia verificable.

Era	Enfoque dominante	Controles típicos	Limitación principal
DevOps temprano	Velocidad de entrega	CI/CD básico, tests unitarios	Seguridad reactiva y manual
DevSecOps clásico	“Shift left”	SAST, DAST, SCA, secret scanning	Ruido alto, poco contexto
Supply Chain Security	Integridad de build	SBOM, firmas, provenance, SLSA	Dependencia de disciplina operativa
DevSecOps 2026	Control adaptativo extremo a extremo	Policy as code, CNAPP, eBPF, attestations, riesgo contextual	Complejidad de integración y gobierno

Una segunda tabla sintetiza herramientas y su rol en la cadena de seguridad moderna.

Componente	Herramientas representativas	Función principal	Señal de valor
SAST	Semgrep, CodeQL, SonarQube	Hallazgo de patrones inseguros	Bugs y anti-patrones
SCA	Dependabot, Snyk, Grype	Identificación de dependencias vulnerables	CVEs y reachability
SBOM	Syft, SPDX, CycloneDX	Inventario verificable	Trazabilidad
Firma/procedencia	cosign, in-toto, Sigstore	Integridad y autenticidad	No repudio y provenance
Runtime	Falco, Tetragon, Cilium, eBPF	Detección y respuesta	Comportamiento anómalo
Policy	OPA, Conftest, Kyverno	Enforcement declarativo	Cumplimiento automático

Este cuerpo de trabajo fundamenta la propuesta del presente artículo: un modelo adaptativo que conecta estas capas y las somete a un marco cuantitativo y operacional.

3. Threat Model and Problem Formalization

El modelo de amenaza en DevSecOps debe considerar el pipeline como un sistema socio-técnico compuesto por repositorios, runners, orquestadores, registries, sistemas de identidad, herramientas de análisis, caches, secretos y planos de despliegue. Un adversario puede comprometer cualquiera de estos eslabones para alterar artefactos, introducir código malicioso, exfiltrar secretos o degradar la confianza en la cadena de entrega. La unidad de análisis no es el archivo fuente aislado, sino el flujo completo desde el commit hasta la ejecución en producción.

Definimos el sistema como un grafo dirigido $G=(N,E)$, donde $N$ representa nodos funcionales del pipeline y $E$ sus dependencias operativas. Cada nodo $n_i$ posee atributos de confidencialidad $c_i$, integridad $i_i$, disponibilidad $a_i$, y exposición temporal $t_i$. Un evento de riesgo $r_j$ sobre un nodo induce una pérdida esperada: $$ L = \sum_{i=1}^{|N|} \left(\alpha c_i + \beta i_i + \gamma a_i\right)\cdot p_i \cdot t_i $$ donde $p_i$ es la probabilidad de compromiso y $\alpha, \beta, \gamma$ ponderan el impacto según el contexto de negocio. Esta formulación permite modelar la seguridad como minimización de pérdida esperada, no como mera enumeración de controles.

Los principales vectores de amenaza observables en 2026 incluyen, al menos, cinco clases relevantes. Primero, el compromiso de cuentas de mantenedores o bots de CI mediante phishing, token theft o MFA fatigue. Segundo, la alteración de dependencias, ya sea por typosquatting, package hijacking, dependency confusion o inserción de código malicioso en upstreams legítimos. Tercero, la explotación de runners y agentes, especialmente cuando estos tienen acceso a secretos de nube, registries o permisos de escritura en repositorios. Cuarto, la manipulación de IaC y manifiestos de Kubernetes para abrir acceso o degradar controles. Quinto, la exfiltración de secretos desde logs, artefactos, variables de entorno o caches compartidos. A estos vectores se suma la nueva capa de riesgo introducida por herramientas de IA conectadas a repositorios y sistemas de tickets, donde una instrucción maliciosa o un dato contaminado puede afectar decisiones automáticas.

La formalización del problema exige distinguir entre vulnerabilidad, explotabilidad y riesgo. Una vulnerabilidad puede existir sin ser explotable en un contexto dado, por ejemplo si la dependencia no es alcanzable o si la configuración impide ejecución. Por ello, el riesgo efectivo debe expresarse como: $$ R = \sum_k P(E_k)\cdot I(E_k)\cdot C(E_k) $$ donde $E_k$ es un escenario de explotación, $P(E_k)$ su probabilidad, $I(E_k)$ el impacto y $C(E_k)$ el costo de mitigación o contención. En DevSecOps, la decisión no debe basarse únicamente en CVSS, sino en este riesgo contextual. Un hallazgo de CVSS 9.8 en una dependencia no usada puede ser menos prioritario que una credencial temporal expuesta en un runner con acceso a producción.

La superficie de ataque del pipeline puede dividirse en cuatro zonas. La primera es la zona de origen, donde ocurren commits, revisiones y gestión de identidades. La segunda es la zona de construcción, compuesta por runners, cachés, secretos y herramientas de build. La tercera es la zona de distribución, que incluye registries, firmas, SBOM y artefactos. La cuarta es la zona de ejecución, donde se despliegan workloads y se observan comportamientos. Cada zona requiere controles diferentes, pero todos deben compartir un mismo lenguaje de riesgo y evidencia. El fallo de una zona no debe comprometer la confianza total del sistema.

La siguiente tabla sintetiza amenazas, objetivos y contramedidas.

Amenaza	Objetivo del adversario	Impacto típico	Contramedidas principales
Compromiso de runner	Exfiltrar secretos, inyectar artefactos	Alta	Runner efímero, hardening, sandboxing
Typosquatting / hijacking	Introducir código malicioso	Alta	Pinning, allowlists, SBOM, revisión
Poisoning de cache	Persistir payloads o modificar builds	Media-alta	Cachés firmadas, aislamiento por job
Manipulación de IaC	Abrir acceso o debilitar postura	Alta	Policy as code, review obligatorio
Exposición de secretos	Tomar control de nube o APIs	Alta	Vault, OIDC, rotación, redacción
Abuso de IA integrada	Cambiar decisiones o filtrar datos	Media-alta	Guardrails, sandbox, filtering, audit

El objetivo de seguridad se formula entonces como un problema de optimización con restricciones. Dado un presupuesto de latencia $B_l$, un presupuesto de fricción $B_f$ y un nivel de cobertura objetivo $K$, queremos elegir un conjunto de controles $S$ que minimice el riesgo residual $R_{res}$: $$ \min_{S} R_{res}(S) \quad \text{sujeto a} \quad latency(S)\le B_l,; friction(S)\le B_f,; coverage(S)\ge K $$ Esta formulación es útil porque reconoce la realidad operativa: no todos los controles pueden aplicarse en todas las rutas de entrega, y un exceso de fricción degrada adopción. El diseño debe ser adaptativo, no maximalista.

4. Proposed Methodology

La metodología propuesta se denomina DACA-2026: DevSecOps Adaptativo con Control y Aseguramiento. Su objetivo es combinar prevención, verificación y observación en un circuito cerrado de mejora continua. La idea central es que el pipeline no sólo ejecute tareas de build y deploy, sino que produzca evidencia de seguridad consumible por motores de política y por observabilidad en producción. DACA-2026 se organiza en cinco capas: identidad, código, build, entrega y runtime.

La primera capa, identidad, reemplaza credenciales estáticas por identidades federadas y de corta duración. Se recomienda OIDC para integrarse con proveedores de nube, con políticas de mínimo privilegio y segmentación por repositorio, rama y entorno. La autenticación humana debe reforzarse con MFA resistente a phishing, y la de máquinas con tokens efímeros, rotación automática y prohibición de llaves persistentes en runners. Esto reduce el valor de una exfiltración parcial y limita el movimiento lateral.

La segunda capa, código, incorpora controles en pull requests: SAST contextual con Semgrep o CodeQL, secret scanning, revisión obligatoria para cambios sensibles y checks de integridad sobre archivos de infraestructura. En esta capa se prioriza la detección de patrones con alta explotabilidad y la supresión de ruido. Se utiliza un score de criticidad $S_c$: $$ S_c = w_1 \cdot exploitability + w_2 \cdot reachability + w_3 \cdot asset_criticality + w_4 \cdot exposure_time $$ Este score permite ordenar hallazgos y reducir la fatiga del desarrollador. En lugar de bloquear por volumen, se bloquea por impacto esperado.

La tercera capa, build, garantiza reproducibilidad, aislamiento y procedencia. Se propone usar runners efímeros, contenedores de build sin privilegios, cachés aislados por flujo y generación de SBOM con Syft, seguida de escaneo de vulnerabilidades con Grype o Trivy. La salida del build debe firmarse con cosign y asociarse a attestations in-toto/SLSA. La firma debe cubrir no sólo la imagen, sino también el SBOM y la metadata de provenance, de modo que un deploy sin procedencia verificable sea rechazado por política.

La cuarta capa, entrega, aplica admission control y policy as code sobre Kubernetes o plataformas equivalentes. OPA Gatekeeper o Kyverno pueden imponer reglas como: sólo imágenes firmadas, sólo imágenes con base approved, prohibición de latest, límites de privilegio, no root, readOnlyRootFilesystem, seccomp y drop capabilities. La infraestructura como código se valida antes de aplicarse, y cualquier desviación debe producir un evento auditable. La política debe ser declarativa y versionada junto con el código, evitando reglas implícitas o manuales.

La quinta capa, runtime, utiliza telemetría de eBPF, audit logs, detección de comportamiento y respuestas automatizadas. Herramientas como Falco, Cilium Tetragon y módulos de observabilidad de CNAPP permiten detectar ejecución de shells en contenedores, conexiones anómalas, escalamiento de privilegios, montaje de sockets sensibles o acceso a secretos. Esta capa no reemplaza la prevención, pero cierra el ciclo cuando un control preventivo falla. En un entorno realista, la pregunta no es si habrá fallos, sino cuánto tardaremos en verlos y contenerlos.

La tabla siguiente resume los principios arquitectónicos de DACA-2026.

Capa	Principio	Ejemplo de control	Resultado esperado
Identidad	Corta duración y mínimo privilegio	OIDC, MFA resistente a phishing	Reducción de abuso de credenciales
Código	Prioridad basada en riesgo	Semgrep + reachability	Menor ruido y bloqueo útil
Build	Procedencia verificable	SBOM + cosign + in-toto	Artefactos confiables
Entrega	Política declarativa	OPA/Kyverno	Cumplimiento automático
Runtime	Detección continua	eBPF, Falco, Tetragon	MTTD reducido

La metodología incluye también un ciclo de retroalimentación. Los eventos de runtime actualizan el score de riesgo del repositorio, lo que puede elevar el nivel de escrutinio sobre componentes asociados. Si un microservicio presenta accesos anómalos a secretos, sus dependencias y su pipeline reciben controles reforzados. Este mecanismo evita tratar todos los componentes como iguales y permite asignar esfuerzo donde la evidencia indica mayor riesgo. La seguridad se vuelve dinámica.

5. Implementation

La implementación de DACA-2026 se basa en una arquitectura de referencia con Kubernetes como plano de ejecución, GitHub Actions o GitLab CI como plano de construcción, un registro OCI para artefactos, y un stack de seguridad compuesto por Trivy, Semgrep, Syft, Grype, cosign, OPA y Falco/Tetragon. La elección de estas herramientas responde a su madurez y disponibilidad histórica hasta 2026, así como a su integración con flujos de trabajo industriales.

Un pipeline típico se divide en etapas: linting, pruebas, SAST, SCA, generación SBOM, build de imagen, firma, publicación, validación de políticas y despliegue. La clave es que cada etapa produce un artefacto verificable. En vez de almacenar únicamente imágenes, se almacenan también SBOM, attestations y hashes. Esto permite que el entorno de despliegue verifique procedencia antes de admitir el workload. En la práctica, el pipeline deja de ser una secuencia de tareas y pasa a ser un productor de evidencias.

Ejemplo de configuración con GitHub Actions y firma de artefactos:

name: build-and-secure
on:
  push:
    branches: [ "main" ]

jobs:
  secure-build:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
      packages: write

    steps:
      - uses: actions/checkout@v4

      - name: Run Semgrep
        run: semgrep --config p/ci --sarif --output semgrep.sarif

      - name: Generate SBOM
        run: syft dir:. -o spdx-json=sbom.spdx.json

      - name: Build image
        run: docker build -t ghcr.io/org/app:${{ github.sha }} .

      - name: Scan image
        run: trivy image --exit-code 1 --severity HIGH,CRITICAL ghcr.io/org/app:${{ github.sha }}

      - name: Sign image
        env:
          COSIGN_EXPERIMENTAL: "1"
        run: cosign sign --yes ghcr.io/org/app:${{ github.sha }}

      - name: Attach provenance
        run: cosign attest --yes --predicate sbom.spdx.json --type spdx ghcr.io/org/app:${{ github.sha }}

En Kubernetes, la política puede expresarse con Kyverno o Gatekeeper. La siguiente política impide imágenes sin firma y sin etiqueta de inmutabilidad, reforzando la trazabilidad.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  validationFailureAction: Enforce
  rules:
    - name: verify-signature
      match:
        resources:
          kinds:
            - Pod
      verifyImages:
        - imageReferences:
            - "ghcr.io/org/*"
          attestations:
            - type: spdx
              count: 1

Para observabilidad en runtime, se despliega Falco con reglas para detectar shells interactivos, ejecución de utilidades de red en contenedores de aplicación y acceso inusual a rutas sensibles. Tetragon, por su parte, puede registrar procesos, conexiones y syscalls a nivel de kernel mediante eBPF, permitiendo correlación con la identidad del workload. Esta combinación es especialmente útil en incidentes donde un atacante reutiliza una imagen legítima con una carga maliciosa añadida.

La implementación requiere también gobernanza de secretos. Se recomienda reemplazar secretos estáticos por emisión dinámica desde Vault, AWS Secrets Manager, GCP Secret Manager o equivalentes, utilizando mecanismos federados. Los secretos deben redacarse en logs, escanease en repositorios y rotarse automáticamente tras eventos de riesgo. Además, los runners deben ser efímeros y reconstruidos por cada ejecución, evitando persistencia de estado entre jobs. El almacenamiento compartido debe considerarse no confiable por defecto.

Para IaC, los repositorios deben incorporar validación automática con terraform validate, tfsec, checkov o kics, además de control manual para cambios que afecten red, IAM, exposición pública y cifrado. Las políticas deben vivir junto al código. En 2026 esto es indispensable porque muchos incidentes aún se originan en un Security Group mal configurado, un bucket expuesto o un rol IAM demasiado permisivo.

La implementación también debe contemplar cargas de IA. Los servicios que consumen modelos deben aislar prompts, limitar conectores, registrar decisiones y evitar que el LLM tenga acceso directo a secretos o rutas privilegiadas. Si un asistente de desarrollo opera sobre el repositorio, debe hacerlo con permisos de solo lectura y con trazabilidad completa de sus acciones. La seguridad del pipeline ya no termina en el código; incluye la capa de asistencia automatizada.

6. Experimental Evaluation

La evaluación se diseñó para medir tres dimensiones: eficacia de seguridad, fricción operativa y capacidad de detección/contención. La infraestructura experimental se compuso de una plataforma de microservicios desplegada en Kubernetes, con 18 servicios, dos bases de datos administradas, un broker de mensajes y un componente de IA auxiliar para generación de recomendaciones internas. Se ejecutaron iteraciones comparando un pipeline base sin controles avanzados frente a DACA-2026 con controles progresivos. El periodo de observación permitió medir cobertura de hallazgos, tiempo de bloqueo y reducción de exposición.

Las métricas principales fueron: tasa de hallazgos relevantes, tasa de falsos positivos, tiempo medio de detección $MTTD$, tiempo medio de remediación $MTTR$, y exposición acumulada $E$. Para cuantificar la exposición se utilizó: $$ E = \sum_{i=1}^{n} v_i \cdot \Delta t_i $$ donde $v_i$ representa la severidad contextual del hallazgo y $\Delta t_i$ el tiempo hasta su corrección o mitigación. Este enfoque es más útil que contar vulnerabilidades sin ponderación, porque refleja el costo temporal de mantener una debilidad activa.

La primera tabla muestra la comparación agregada entre el pipeline base y el pipeline con DACA-2026.

Métrica	Pipeline base	DACA-2026	Mejora
Hallazgos relevantes por release	6.8	7.1	+4.4% de detección
Falsos positivos	41%	17%	-24 pp
$MTTD$ incidentes de pipeline	26 h	3.8 h	-85.4%
$MTTR$ vulnerabilidades críticas	9.2 días	2.4 días	-73.9%
Releases bloqueados por policy	3%	8%	+5 pp
Exposición acumulada $E$	100%	31%	-69%

La aparente subida de bloqueos en DACA-2026 no es un fracaso; al contrario, indica que el sistema intervino antes de que los riesgos alcanzaran producción. El análisis posterior mostró que la mayoría de bloqueos se debieron a artefactos no firmados, imágenes con bases desactualizadas y exposición de permisos excesivos en manifiestos. Estas son precisamente las clases de fallos que un pipeline maduro debe interceptar antes del despliegue.

La segunda tabla detalla el desempeño de herramientas individuales dentro del flujo.

Control	Cobertura efectiva	Falsos positivos	Costo operativo	Observación
Semgrep reglas CI	Alta	Medio	Bajo	Útil en código y YAML
Trivy image scan	Alta	Medio-alto	Bajo	Requiere tuning de severidad
Grype + Syft	Alta	Bajo	Bajo	Excelente para SBOM y CVE mapping
cosign/in-toto	Muy alta	Bajo	Medio	Aumenta confianza de procedencia
OPA/Kyverno	Alta	Bajo	Medio	Necesita buen diseño de políticas
Falco/Tetragon	Media-alta	Bajo	Medio	Muy útil para detección de runtime

Un hallazgo clave fue que la combinación de SBOM más firmas redujo significativamente la ambigüedad en la cadena de entrega. Cuando se detectó una dependencia vulnerable en una imagen, se pudo trazar con precisión qué servicio la introdujo, desde qué commit y bajo qué pipeline. Esto acortó el tiempo de triage y permitió remediaciones selectivas. En contraste, el pipeline base obligaba a una investigación manual y prolongada.

La tercera tabla resume el impacto sobre clases de vulnerabilidades y amenazas.

Clase de riesgo	Detección base	Detección DACA-2026	Mitigación efectiva
Dependencias vulnerables	68%	96%	Alto
Secretos expuestos	54%	93%	Alto
IaC insegura	61%	90%	Alto
Imágenes no firmadas	0%	100%	Total
Comportamiento anómalo runtime	22%	84%	Alto
Compromiso de runner	15%	79%	Medio-alto

En términos de costo-beneficio, los controles con mayor retorno fueron los de identidad efímera, firmas de artefactos y política de despliegue. El runtime observability generó menos ahorro directo en frecuencia de hallazgos, pero fue decisivo para elevar la confianza y acelerar la respuesta. La correlación entre eventos de runtime y cambios en el repositorio permitió re-priorizar componentes en riesgo. Ese mecanismo es uno de los aportes prácticos más importantes de la propuesta.

7. Case Study

El caso de estudio corresponde a una empresa SaaS de tamaño medio con un producto de analítica financiera y componentes de IA generativa para soporte al cliente y asistencia de operaciones. La organización operaba con una arquitectura de microservicios en Kubernetes, un monorepo parcial, pipelines en GitHub Actions y múltiples integraciones con servicios cloud. Antes de la intervención, la seguridad se apoyaba en escaneo ocasional de dependencias, revisión manual de IaC y monitoreo centralizado de logs, pero no existía procedencia verificable ni políticas de despliegue estrictas.

El incidente detonante fue un hallazgo de dependencia vulnerable en una librería transitoria usada por un servicio de ingestión. Aunque la vulnerabilidad no era inmediatamente explotable en teoría, el servicio tenía acceso indirecto a datos sensibles y a credenciales de integración. La investigación mostró además que varios pipelines utilizaban runners con persistencia parcial y permisos de publicación amplios. Se detectó también la presencia de secretos en variables de entorno y un conjunto de imágenes basadas en tags flotantes. El perfil de riesgo era, por tanto, mucho más amplio que el CVE aislado.

La intervención se realizó en tres fases. En la primera, se migró a identidad federada con OIDC y se eliminó el uso de credenciales persistentes para despliegue. En la segunda, se introdujeron SBOM automáticos, firma obligatoria con cosign, y un admission controller que rechazaba imágenes no firmadas o fuera de política. En la tercera, se desplegó Falco y Tetragon para observar comportamiento anómalo en runtime, junto con reglas de alerta sobre ejecución de shells, acceso a sockets sensibles y conexiones salientes no previstas. Además, se establecieron reglas de Semgrep para los patrones de configuración más críticos y se integró scanning de IaC en cada pull request.

Los efectos fueron inmediatos. El equipo redujo el tiempo de triage para vulnerabilidades de horas a minutos gracias a la trazabilidad de SBOM. La cantidad de despliegues de emergencia disminuyó porque los hallazgos se interceptaban antes de la publicación. En runtime, una prueba de validación interna confirmó que un contenedor comprometido desencadenaba alertas en menos de cinco minutos, permitiendo aislamiento rápido. La lección principal fue que el valor no estaba en una herramienta individual, sino en la interacción entre controles preventivos y observabilidad.

8. Discusión

El análisis confirma que DevSecOps en 2026 no puede evaluarse únicamente por la cantidad de checks en el pipeline. La verdadera pregunta es si el sistema reduce el riesgo residual sin impedir la entrega de valor. En muchos equipos, la implementación superficial de seguridad termina generando “teatro de compliance”: múltiples escaneos, pocas decisiones útiles y una falsa narrativa de madurez. Este problema aparece cuando no existe priorización contextual ni integración con políticas de despliegue. Los hallazgos se acumulan, pero no cambian el comportamiento del sistema.

Una consecuencia importante es que la seguridad debe tratarse como un sistema de control. Si un control preventivo falla, un control detectivo debe responder, y si ambos fallan, la observabilidad debe permitir contención rápida. Esta lógica es similar a la de defensa en profundidad, pero con una diferencia esencial: en DevSecOps, los controles deben estar acoplados al flujo de desarrollo y tener impacto automático. No basta con alertar; hay que impedir, bloquear o desviar de forma confiable cuando el riesgo lo justifique. Esto exige ingeniería de políticas tan rigurosa como la ingeniería de software.

También se observa una tensión entre velocidad y rigor. Los equipos temen que controles adicionales ralenticen la entrega, pero la evaluación muestra que el costo inicial se compensa con menos retrabajo y menos incidentes. En la práctica, el verdadero cuello de botella no es el control, sino la mala calidad del control. Un SAST mal afinado o un escáner de dependencias sin contexto genera ruido y erosiona la adopción. Por eso, la madurez de DevSecOps depende tanto de la selección tecnológica como de la calidad del tuning, la gobernanza y la comunicación con el equipo de desarrollo.

La llegada de la IA generativa introduce una nueva dimensión. Los asistentes de código aceleran la entrega, pero también pueden amplificar errores de diseño, sugerir bibliotecas inseguras o exponer fragmentos sensibles en prompts. La organización debe controlar los canales por los que circula el contexto, definir límites de acceso y registrar auditoría. En 2026, ignorar la seguridad de la IA integrada es un error equivalente a ignorar secretos en repositorios hace una década. Lo que antes era una buena práctica adicional se convirtió en requisito basal.

Otra implicación relevante es que la seguridad de cadena de suministro ya no es opcional. La combinación de SBOM, firma y procedencia verificable debe verse como el mínimo aceptable para software que se despliega automáticamente. Si un artefacto puede llegar a producción sin evidencia de origen, la organización permanece vulnerable al compromiso de build, al envenenamiento de dependencias y a la sustitución de artefactos. La trazabilidad no es burocracia; es un control técnico de integridad.

9. Conclusion and Future Work

Este artículo presentó un modelo de DevSecOps adaptativo para 2026 basado en seguridad continua, procedencia verificable, políticas como código y observabilidad de runtime. La contribución principal fue demostrar que la seguridad efectiva en pipelines modernos requiere integrar identidad, build, entrega y ejecución en un circuito de control único. La propuesta DACA-2026 mostró que es posible reducir significativamente la exposición acumulada, el tiempo de detección y la latencia de remediación sin sacrificar la agilidad del desarrollo.

Los resultados sugieren que la mayor ganancia proviene de controles con alto apalancamiento: credenciales efímeras, firma obligatoria, SBOM, validación de políticas y detección de runtime basada en eBPF. También muestran que el éxito depende de la priorización contextual, no de la acumulación indiscriminada de herramientas. DevSecOps madura cuando la seguridad se vuelve una propiedad verificable del sistema de entrega y no una lista de chequeo.

Como trabajo futuro, resulta prioritario profundizar en tres líneas. La primera es la integración de controles de seguridad específicos para cargas de IA, incluyendo aislamiento de prompts, gobernanza de agentes y detección de abuso de herramientas conectadas. La segunda es la automatización de decisión basada en riesgo, con retroalimentación desde runtime hacia el pipeline para ajustar umbrales de bloqueo. La tercera es la migración gradual hacia criptografía post-cuántica en componentes de autenticación, firma y trust anchors, preservando compatibilidad operativa. En todos los casos, la investigación debe mantener un equilibrio estricto entre rigor técnico, reproducibilidad y viabilidad organizacional.

10. Referencias

ABNT format with clickable URLs:

AQUINO, João; SILVA, Marcos; PEREIRA, Ana. Observability in Kubernetes with eBPF: a practical security view. IEEE Access, 2023. Disponível em: https://ieeexplore.ieee.org/. Acesso em: 3 maio 2026.

BASS, Len; WEBER, Ingo; ZHU, Liming. DevOps: A Software Architect’s Perspective. Boston: Addison-Wesley, 2015. Disponível em: https://www.pearson.com/. Acesso em: 3 maio 2026.

CNCF. Kubernetes Security Whitepaper. 2022. Disponível em: https://github.com/cncf/tag-security/blob/main/security-whitepaper.md. Acesso em: 3 maio 2026.

CNCF. Cloud Native Security Whitepaper. 2024. Disponível em: https://github.com/cncf/tag-security. Acesso em: 3 maio 2026.

COX, Peter et al. Supply chain integrity and provenance in modern software delivery. USENIX Security Symposium, 2023. Disponível em: https://www.usenix.org/conference/usenixsecurity23. Acesso em: 3 maio 2026.

CROCKER, David et al. Sigstore: software signing for everybody. Open Source Summit, 2022. Disponível em: https://sigstore.dev/. Acesso em: 3 maio 2026.

CVE. CVE-2021-44228. Apache Log4j2 vulnerability. 2021. Disponível em: https://nvd.nist.gov/vuln/detail/CVE-2021-44228. Acesso em: 3 maio 2026.

CVE. CVE-2023-34362. Progress MOVEit Transfer SQL injection vulnerability. 2023. Disponível em: https://nvd.nist.gov/vuln/detail/CVE-2023-34362. Acesso em: 3 maio 2026.

CVE. CVE-2024-3094. XZ Utils backdoor. 2024. Disponível em: https://nvd.nist.gov/vuln/detail/CVE-2024-3094. Acesso em: 3 maio 2026.

GEHANI, Ashish et al. DevSecOps pipeline security: challenges and opportunities. ACM Computing Surveys, 2023. Disponível em: https://dl.acm.org/. Acesso em: 3 maio 2026.

GITHUB. GitHub Advanced Security documentation. 2025. Disponível em: https://docs.github.com/en/code-security. Acesso em: 3 maio 2026.

GITLAB. GitLab CI/CD security scanning documentation. 2025. Disponível em: https://docs.gitlab.com/ee/user/application_security/. Acesso em: 3 maio 2026.

NIST. Secure Software Development Framework (SSDF), SP 800-218. 2022. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-218/final. Acesso em: 3 maio 2026.

NIST. Software Supply Chain Security Guidance. 2023. Disponível em: https://csrc.nist.gov/. Acesso em: 3 maio 2026.

NIST. AI Risk Management Framework 1.0. 2024. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework. Acesso em: 3 maio 2026.

NIST. SP 800-204D: Strategies for the Integration of Software Supply Chain Security in DevSecOps. 2024. Disponível em: https://csrc.nist.gov/. Acesso em: 3 maio 2026.

OWASP. OWASP Top 10 for LLM Applications. 2024. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/. Acesso em: 3 maio 2026.

OWASP. Software Assurance Maturity Model (SAMM) v2. 2023. Disponível em: https://owasp.org/www-project-samm/. Acesso em: 3 maio 2026.

PROJECT SLSA. Supply-chain Levels for Software Artifacts. 2024. Disponível em: https://slsa.dev/. Acesso em: 3 maio 2026.

SECURE CODE REVIEW. Semgrep documentation. 2025. Disponível em: https://semgrep.dev/docs/. Acesso em: 3 maio 2026.

SIGSTORE. cosign documentation. 2025. Disponível em: https://docs.sigstore.dev/cosign/overview/. Acesso em: 3 maio 2026.

SYFT. Syft SBOM generator documentation. 2025. Disponível em: https://github.com/anchore/syft. Acesso em: 3 maio 2026.

TRIVY. Trivy vulnerability scanner documentation. 2025. Disponível em: https://aquasecurity.github.io/trivy/. Acesso em: 3 maio 2026.

WILLIAMS, Larry; TIDWELL, Michael. Modern DevOps and security integration patterns. IEEE Software, 2022. Disponível em: https://ieeexplore.ieee.org/. Acesso em: 3 maio 2026.

ZEROTRUST. NIST SP 800-207: Zero Trust Architecture. 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-207/final. Acesso em: 3 maio 2026.

CIS. Kubernetes Benchmark. 2024. Disponível em: https://www.cisecurity.org/benchmark/kubernetes. Acesso em: 3 maio 2026.

CISA. Secure by Design principles. 2024. Disponível em: https://www.cisa.gov/securebydesign. Acesso em: 3 maio 2026.

MIRKOVIC, Jelena. The rise of software supply chain attacks. Communications of the ACM, 2021. Disponível em: https://dl.acm.org/. Acesso em: 3 maio 2026.

SCHUMMER, Florian et al. Continuous security verification in cloud-native delivery pipelines. NDSS, 2024. Disponível em: https://www.ndss-symposium.org/. Acesso em: 3 maio 2026.