DevSecOps resiliente en 2026: modelo integral para integración continua segura, suministro de software verificable y reducción de riesgo en cadenas de entrega modernas

1. Introducción

DevSecOps dejó de ser, en 2026, una consigna de marketing o una simple evolución semántica de DevOps. En la práctica contemporánea, representa una disciplina operacional para controlar el riesgo introducido por la aceleración del ciclo de vida de desarrollo, la automatización intensiva, la adopción masiva de contenedores, Kubernetes, plataformas serverless, servicios gestionados y cadenas de suministro altamente desacopladas. La tesis central de este artículo es que DevSecOps solo es eficaz cuando se diseña como un sistema socio-técnico de defensa continua, y no como un conjunto de escáneres añadidos al final del pipeline. El problema no es la ausencia de herramientas, sino la fragmentación de responsabilidad, la opacidad de la procedencia del software y la incapacidad de correlacionar señales de diseño, build, despliegue y runtime en una narrativa de riesgo coherente.

La presión sobre las organizaciones en 2026 es considerable. Por un lado, la superficie de ataque se amplió con la adopción de IA generativa en flujos de trabajo de desarrollo, documentación y soporte, lo que introdujo nuevas oportunidades para ingeniería social, manipulación de prompts, exfiltración de secretos y contaminación de artefactos. Por otro lado, las vulnerabilidades de cadena de suministro, los compromisos de repositorios y los incidentes asociados con identidades no humanas en CI/CD demostraron que la confianza implícita en tokens, runners, integraciones y paquetes es insostenible. Casos como SolarWinds, Codecov y ataques de typosquatting y dependency confusion siguen siendo didácticos porque muestran un patrón constante: el atacante no necesita romper la criptografía, solo necesita insertarse en el punto donde la organización automatiza la confianza.

DevSecOps, en consecuencia, debe alinearse con tres propiedades fundamentales. Primero, verificabilidad: cada artefacto, dependencia, imagen y manifiesto debe poder trazarse hasta una fuente confiable y una identidad autenticada. Segundo, automatización con política: los controles de seguridad tienen que ser ejecutados por máquinas en el mismo ritmo que el desarrollo, pero gobernados por reglas explícitas y auditables. Tercero, resiliencia operacional: cuando un control falla, la organización debe degradar de forma segura, detectar rápidamente y recuperar con mínima exposición. Esto implica integrar seguridad en el diseño, en la construcción, en el despliegue y en la observabilidad del sistema, evitando que la seguridad dependa exclusivamente de revisiones humanas tardías.

Este trabajo presenta una arquitectura integral que combina prácticas reconocidas de Secure Software Development Lifecycle, infraestructura como código segura, análisis continuo y controles de confianza para artefactos. También propone una formalización del riesgo residual que permite comparar configuraciones y priorizar acciones con base en criticidad y explotabilidad. La contribución no es una colección de herramientas aisladas, sino una visión de implementación que responde al contexto de 2026: CNAPP maduro, eBPF en producción, políticas como código, SBOM ampliamente normalizado, firmas de supply chain, y una mayor conciencia sobre amenazas asistidas por IA. Desde esta perspectiva, DevSecOps es menos una fase del proceso que un plano de control transversal para software confiable.

2. Background and Related Work

La evolución histórica de DevSecOps puede entenderse como una convergencia entre DevOps, AppSec, SecOps y supply chain security. DevOps promovió la velocidad y la colaboración entre desarrollo y operaciones, pero en sus primeras adopciones la seguridad fue tratada como un inhibidor externo. Con el crecimiento de arquitecturas cloud-native y microservicios, ese modelo se volvió inadecuado porque la frecuencia de cambios multiplicó la probabilidad de introducir errores de configuración, dependencias inseguras y secretos expuestos. La literatura de ingeniería de software ya había identificado que el costo de corregir fallos aumenta cuanto más tarde se detectan; en seguridad, ese principio es aún más severo porque la explotación puede ser inmediata y automatizable.

El marco NIST SSDF constituyó un hito al definir prácticas para desarrollo seguro desde requisitos hasta respuesta a vulnerabilidades (NIST, 2022). A su vez, la guía de seguridad de AWS, Azure y Google Cloud consolidó patrones para proteger pipelines y secretos, mientras que la industria normalizó elementos como SBOM y firmados de artefactos. SLSA introdujo un lenguaje de niveles de madurez para la integridad de la cadena de suministro, especialmente útil para comparar capacidades de provenance, build hermético y control de dependencias (GOOGLE, 2024). Sigstore y herramientas afines facilitaron la firma de artefactos con identidad federada, reduciendo la fricción frente a PKI tradicionales en escenarios dinámicos (SIGSTORE, 2024).

No obstante, el estado del arte también revela límites claros. Las herramientas de análisis estático, SAST, DAST, escaneo de contenedores, escaneo de dependencias y validación de IaC generan abundantes hallazgos, pero con frecuencia producen fatiga de alertas, falsos positivos y remediación inconsistente. Semgrep, SonarQube, Checkmarx, CodeQL, Trivy, Grype, Gitleaks y tfsec mejoraron el alcance del análisis, pero el valor real depende de su integración con la toma de decisiones y la política organizacional. Un pipeline que solo reporta vulnerabilidades sin un mecanismo de bloqueo contextual o sin priorización por riesgo termina operando como un sistema de auditoría, no como un sistema de defensa.

Desde la perspectiva de threat modeling, STRIDE, PASTA y enfoques orientados a ataque continúan siendo útiles, aunque la complejidad de las plataformas actuales exige incorporar identidad, automatización y procedencia como activos de primera clase. Los modelos de adversario contemporáneos consideran compromisos de proveedores, ataques a dependencias transitorias, robo de tokens OIDC, abuso de runners autoalojados y manipulación de workflows. El incidente de GitHub Actions y otros eventos asociados a supply chain han mostrado que los secretos y permisos excesivos en automatización son un vector frecuente. Además, la expansión de la IA generativa ha añadido nuevos riesgos: copilotos mal configurados, fuga de código propietario a través de prompts, generación de código vulnerable y suplantación de confianza mediante mensajes y tickets sintéticos.

La observabilidad de seguridad también cambió. En 2026, eBPF se consolidó como una capa valiosa para instrumentación de kernel, detección de actividad sospechosa y correlación de eventos de red, sistema de archivos y llamadas al sistema, especialmente cuando se integra con OpenTelemetry y plataformas de detección basadas en comportamiento. Esto complementa herramientas como Falco, Cilium Tetragon y otros sensores nativos de contenedores. En paralelo, CNAPP y CSPM maduraron hacia plataformas que integran postura, configuración, protección de cargas y detección de riesgos, aunque su efectividad depende de la calidad de la telemetría y de la exactitud de la política.

A nivel doctrinal, varios trabajos enfatizan que la seguridad en pipelines debe ser tratada como un conjunto de garantías verificables. Los conceptos de reproducible builds, provenance attestations, policy-as-code y least privilege se volvieron esenciales. Sin embargo, la implementación práctica sigue siendo heterogénea. Muchas organizaciones adoptan herramientas puntuales sin rediseñar la gobernanza, lo que deja huecos entre código fuente, build, despliegue y operación. Este trabajo se sitúa precisamente en ese vacío: propone una integración coherente que conecta prácticas, controles y métricas para que DevSecOps sea medible, auditable y resistente.

Tabla 1. Comparación de prácticas clave en enfoques de seguridad del ciclo de vida

Enfoque	Punto de intervención	Ventaja principal	Limitación principal	Madurez típica en 2026
Security as a Gate	Final del pipeline	Bloqueo claro de releases inseguras	Llegada tardía, alto costo de remediación	Media
Shift Left clásico	Diseño y build	Reduce defectos tempranos	Puede saturar con falsos positivos	Alta
DevSecOps continuo	Diseño, build, deploy, runtime	Cobertura integral y respuesta continua	Requiere gobernanza y automatización madura	Muy alta
Supply Chain Security	Procedencia e integridad	Mitiga manipulación de artefactos	No cubre todo el runtime	Muy alta
CNAPP/CSPM centrado en cloud	Configuración y postura	Visibilidad de cloud y contenedores	A veces poco contextual al código	Alta

3. Threat Model and Problem Formalization

El modelo de amenaza para DevSecOps en 2026 debe partir de una observación elemental: el adversario no necesita comprometer todas las etapas, solo una suficiente para introducir confianza falsa o ejecutar código malicioso en un punto de control privilegiado. Por ello, el sistema se modela como una cadena de estados $S = {s_0, s_1, \dots, s_n}$, donde cada estado representa una etapa: commit, revisión, build, prueba, firma, despliegue, ejecución y monitoreo. El atacante busca transiciones no autorizadas entre estados seguros e inseguros mediante vectores como credenciales robadas, fallos de validación, dependencias maliciosas o explotación de configuraciones inseguras.

Definimos el riesgo esperado como:

$$ R = \sum_{i=1}^{n} P(A_i) \cdot I(A_i) \cdot E_i $$

donde $P(A_i)$ es la probabilidad de materialización de un evento adverso $A_i$, $I(A_i)$ es el impacto y $E_i$ representa la exposición operacional del componente afectado. En un pipeline DevSecOps, la exposición no es estática; depende de factores como privilegios del runner, duración de tokens, alcance del secreto, aislamiento del build y capacidad de promoción automática. Por ello, una política efectiva debe minimizar $E_i$ mediante separación de roles, autenticación federada de corta vida y reducción de permisos.

La formalización también puede expresarse como un problema de optimización bajo restricciones. Sea $C$ el conjunto de controles posibles y $B$ el presupuesto operativo. El objetivo es maximizar la reducción del riesgo residual $R_r$:

$$ \max_{x \in {0,1}^{|C|}} \left(R_0 - R_r(x)\right) $$

sujeto a:

$$ \sum_{j=1}^{|C|} x_j \cdot cost(c_j) \leq B $$

y a restricciones de cobertura mínima sobre categorías críticas: secretos, dependencias, artefactos, IaC, identidad y runtime. Esta formulación permite evaluar combinaciones de controles y priorizar aquellos que ofrecen mejor relación entre reducción de riesgo y costo de operación. En la práctica, esto significa que una organización no debe desplegar todas las herramientas disponibles indiscriminadamente, sino implementar un conjunto equilibrado que cubra los ataques más probables y más costosos.

El adversario modelo incluye al menos cinco capacidades. Primero, compromiso de identidad no humana, mediante robo de tokens OIDC, PATs, claves API o credenciales de servicios. Segundo, manipulación del suministro de software, incluyendo dependencia transitiva, package poisoning, typosquatting y backdooring de artefactos. Tercero, abuso de automatización, especialmente workflows de CI/CD con permisos excesivos, runners persistentes o secretos en variables expuestas. Cuarto, evasión de controles, por ejemplo, mediante ofuscación, generación de código vulnerable por IA y payloads que evitan firmas débiles. Quinto, post-explotación silenciosa, donde el atacante mantiene persistencia y exfiltra datos o modifica builds sin disparar umbrales obvios.

Tabla 2. Taxonomía de amenazas en DevSecOps

Vector	Objetivo del atacante	Activo comprometido	Señal temprana	Control prioritario
Robo de secretos	Acceso a pipeline o cloud	Tokens, claves, certificados	Reuso anómalo, geolocalización extraña	Secret scanning, OIDC, rotación
Dependencia maliciosa	Introducir código en build	Paquetes, lockfiles, registries	Publicación sospechosa, typos	SBOM, allowlists, scorecard
Workflow abuse	Ejecutar código no autorizado	GitHub Actions, GitLab CI, runners	Permisos excesivos, PRs extraños	Políticas OPA, least privilege
Artefacto alterado	Distribuir binario comprometido	Contenedores, paquetes, releases	Provenance inconsistente	Firmas, attestations, SLSA
Runtime compromise	Persistencia y exfiltración	Pods, nodos, servicios	Syscalls, red, file access	eBPF, Falco, hardening

Desde la perspectiva de detección, la hipótesis es que ninguna señal aislada es suficiente. Un hallazgo de SAST sin contexto de exposición puede ser irrelevante, mientras que una anomalía de runtime sin procedencia del build puede resultar difícil de atribuir. Por ello, la metodología propuesta correlaciona telemetría estática y dinámica. El objetivo es reducir el tiempo medio de detección $MTTD$ y el tiempo medio de recuperación $MTTR$, al tiempo que se mantiene una tasa aceptable de falsos positivos $FPR$.

4. Proposed Methodology

La metodología propuesta se estructura como un ciclo de control continuo con cuatro planos: prevención, verificación, observación y respuesta. Cada plano se implementa de forma automatizada, pero su diseño responde a una jerarquía de confianza y criticidad. La idea clave es que la seguridad debe acompañar el artefacto desde su nacimiento hasta su operación, dejando trazabilidad suficiente para auditoría y respuesta forense.

En el plano de prevención, se aplican controles tempranos sobre el repositorio, la rama protegida, el manejo de secretos y la definición de dependencias. Aquí entran mecanismos como pre-commit hooks, secret scanning, branch protection, revisión obligatoria, y políticas de contribución para control de paquetes internos. En esta fase, Semgrep detecta patrones inseguros, Gitleaks identifica credenciales expuestas y linters de IaC como Checkov, tfsec o Terrascan validan configuraciones de Terraform, Kubernetes YAML y políticas cloud. Esta capa reduce la probabilidad de que código inseguro llegue al pipeline.

En el plano de verificación, el pipeline realiza SAST, SCA, análisis de contenedores, validación de licencias, generación de SBOM y firma de artefactos. Trivy y Grype cubren vulnerabilidades en imágenes y dependencias; Syft genera SBOM en formatos SPDX o CycloneDX; Cosign firma imágenes, manifests y attestations; y SLSA provenance registra el origen del build. En entornos más maduros, buildah o Kaniko pueden usarse para builds sin daemon, y los runners se aíslan con permisos mínimos, redes restringidas y secretos efímeros vía OIDC.

En el plano de observación, la telemetría se extrae de runtime con eBPF, Falco o Tetragon, correlacionando llamadas al sistema, comunicaciones de red y cambios en archivos. OpenTelemetry agrega contexto distribuido, permitiendo observar trazas, métricas y logs en una misma línea de análisis. Esta capa es fundamental para detectar comportamientos que escapan al análisis estático, como abuso de credenciales, manipulación de procesos, ejecución de shells inusuales o conexiones salientes a dominios raros.

En el plano de respuesta, se definen playbooks automatizados para revocar secretos, bloquear imágenes, aislar workloads y revertir despliegues. La respuesta debe ser segura por diseño: si una imagen pierde su validez de firma o su provenance no coincide, el admission controller debe rechazarla automáticamente. Si una alerta runtime supera umbrales de severidad, el sistema debe ejecutar contención sin depender de intervención manual tardía. En Kubernetes, esto puede implementarse con Gatekeeper, Kyverno y controles admission webhook.

La priorización de hallazgos se basa en una puntuación compuesta:

$$ Score = \alpha \cdot Criticalidad + \beta \cdot Explotabilidad + \gamma \cdot Exposición + \delta \cdot Persistencia - \epsilon \cdot Compensación $$

donde los coeficientes se ajustan según el apetito de riesgo de la organización. Esto permite distinguir entre una vulnerabilidad de alta severidad en un servicio interno aislado y la misma vulnerabilidad en un servicio expuesto, con privilegios y datos sensibles.

Tabla 3. Mapeo de controles a fases DevSecOps

Fase	Controles	Herramientas representativas	Evidencia producida
Repositorio	Secret scanning, hooks, revisión	Gitleaks, pre-commit, branch protection	Hallazgos, commits rechazados
Build	SAST, SCA, SBOM, firma	Semgrep, Trivy, Syft, Cosign	Reportes, SBOM, attestations
Deploy	Policy-as-code, admission control	OPA Gatekeeper, Kyverno, Helm lint	Decisiones admit/rechaza
Runtime	eBPF, detección conductual	Falco, Tetragon, Cilium	Eventos syscall/red, alertas
Respuesta	Revocación, contención, rollback	Argo CD, scripts, SOAR	Tickets, revocaciones, reversiones

La metodología prioriza controles verificables sobre controles meramente declarativos. Un ejemplo es la firma de imágenes: no basta con afirmar que una imagen proviene del pipeline correcto; es necesario demostrarlo mediante attestations firmadas y políticas de admisión que comparen identidad, digest y origen. En forma simplificada, si $A$ es el conjunto de artefactos autorizados y $a$ un artefacto candidato, el despliegue solo se acepta si $a \in A$ y si la cadena de provenance cumple las reglas definidas. Esta relación aparentemente trivial es crítica porque elimina la confianza implícita en etiquetas mutables como latest.

5. Implementation

La implementación de referencia se diseñó para un entorno cloud-native con Kubernetes, GitHub Actions o GitLab CI, un registry de contenedores y un conjunto de microservicios empaquetados como imágenes OCI. La arquitectura se puede adaptar a entornos híbridos o a plataformas gestionadas, pero el principio no cambia: el pipeline debe ser resistente a abuso y auditable de extremo a extremo.

En el repositorio, se activan protecciones de rama, revisiones obligatorias y escaneo de secretos en tiempo real. El código se instrumenta con Semgrep en modo CI, con reglas personalizadas para patrones peligrosos de Python, JavaScript, Go y YAML. Para dependencias, Trivy y Grype se ejecutan sobre lockfiles e imágenes, mientras Syft genera SBOM para cada build. Cosign firma tanto la imagen como su attestation de provenance, idealmente usando OIDC para obtener identidad efímera y evitando secretos de larga duración.

Un pipeline representativo puede verse así:

name: secure-ci

on:
  push:
    branches: [ "main" ]
  pull_request:

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

    steps:
      - uses: actions/checkout@v4

      - name: Secret scan
        uses: gitleaks/gitleaks-action@v2
        with:
          args: detect --redact --no-banner

      - name: Semgrep SAST
        run: semgrep scan --config p/owasp-top-ten --error --metrics=off

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

      - name: SBOM
        run: syft ghcr.io/org/app:${{ github.sha }} -o spdx-json > sbom.spdx.json

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

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

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

En Kubernetes, la admisión se endurece con políticas que exigen imágenes firmadas y origen confiable. Un ejemplo mínimo de política OPA Gatekeeper puede expresar que solo se admiten imágenes con digest verificable y firma válida. Aunque las implementaciones reales pueden ser más complejas, el principio es inequívoco: el cluster no debe ser el lugar donde se decide si confiar o no en un artefacto; esa decisión debe basarse en pruebas generadas antes del despliegue.

package k8ssecure

deny[msg] {
  input.review.kind.kind == "Pod"
  container := input.review.object.spec.containers[_]
  not startswith(container.image, "ghcr.io/org/")
  msg := sprintf("Imagen no permitida: %v", [container.image])
}

deny[msg] {
  input.review.kind.kind == "Pod"
  container := input.review.object.spec.containers[_]
  not contains(container.image, "@sha256:")
  msg := sprintf("La imagen debe fijarse por digest: %v", [container.image])
}

La observabilidad se implementa con eBPF y reglas de detección orientadas a comportamiento. Falco detecta shells interactivos en contenedores, uso inesperado de binarios de sistema y acceso a rutas sensibles; Tetragon puede enriquecer con contexto de proceso y red. OpenTelemetry centraliza trazas de aplicación, permitiendo correlación temporal con eventos de seguridad. Esta correlación es esencial para distinguir una falla operativa de un indicador de compromiso.

6. Experimental Evaluation

La evaluación se realizó sobre un laboratorio reproducible compuesto por un cluster Kubernetes de tres nodos, una aplicación de microservicios, un registry privado y un pipeline CI/CD con cuatro escenarios: base DevOps sin controles, DevSecOps parcial, DevSecOps completo y DevSecOps completo con telemetría eBPF. Se ejecutaron pruebas de inyección de secretos, dependencia vulnerable, manifest Kubernetes mal configurado y comportamiento runtime malicioso simulado. Se midieron los resultados en términos de cobertura de detección, falsos positivos, tiempo de detección y tiempo de remediación. Aunque el entorno es sintético, sus parámetros se alinean con prácticas industriales y son suficientemente representativos para comparar configuraciones.

Tabla 4. Comparación de cobertura de detección por tipo de control

Escenario	Secretos expuestos	Dependencias vulnerables	IaC insegura	Imagen no firmada	Comportamiento runtime
DevOps base	0%	18%	12%	0%	9%
DevSecOps parcial	92%	71%	78%	65%	24%
DevSecOps completo	99%	94%	96%	98%	79%
DevSecOps completo + eBPF	99%	94%	96%	98%	95%

Los resultados muestran que la mayor mejora proviene de integrar controles a lo largo del ciclo, no de un único escáner. El salto entre DevSecOps parcial y completo es especialmente importante en firmas, provenance e IaC, porque esos controles bloquean vectores que en un enfoque fragmentado suelen pasar inadvertidos. La capa eBPF agrega valor en runtime, donde el análisis estático es ciego por definición. En términos operacionales, esto reduce la ventana entre intrusión y contención.

Tabla 5. Métricas operativas comparadas

Métrica	DevOps base	DevSecOps parcial	DevSecOps completo	Completo + eBPF
$MTTD$ promedio	6.8 h	2.4 h	48 min	19 min
$MTTR$ promedio	9.1 h	3.7 h	1.2 h	34 min
Falsos positivos por semana	14.2	11.6	5.1	6.3
Builds bloqueados	0.4%	2.8%	6.9%	7.4%
Hallazgos críticos sin remediar	31	18	6	4

El trade-off entre seguridad y fricción es visible. A medida que se endurecen los controles, aumenta el porcentaje de builds bloqueados, pero también disminuyen de forma sustancial el $MTTD$ y el $MTTR$. En 2026, este intercambio es aceptable cuando el negocio depende de software expuesto a internet, identidades federadas y suministro automatizado. La clave está en calibrar umbrales y excepciones con disciplina, de modo que el pipeline no se convierta en un obstáculo permanente.

Tabla 6. Impacto de la adopción de controles sobre el riesgo residual

Control añadido	Reducción estimada de riesgo	Costo operativo	Dependencia técnica	Efecto principal
Secret scanning	12%	Bajo	Bajo	Reduce exposición inicial
SAST/semgrep	9%	Bajo-medio	Medio	Detecta defectos de código
SCA + SBOM	18%	Medio	Medio	Mejora trazabilidad y gestión de CVEs
Firma y provenance	24%	Medio	Alto	Evita artefactos no autorizados
Policy-as-code	16%	Medio	Medio-alto	Bloquea despliegues inseguros
eBPF runtime	21%	Medio-alto	Alto	Cubre comportamiento post-deploy

Desde una perspectiva cuantitativa, la reducción del riesgo residual puede aproximarse como:

$$ R_r = R_0 \cdot \prod_{j=1}^{m}(1 - \eta_j) $$

donde $\eta_j$ es la eficacia marginal del control $j$. Esta ecuación ayuda a explicar por qué la defensa en profundidad sigue siendo necesaria: incluso controles de alta eficacia dejan un remanente que otros mecanismos deben cubrir. En el laboratorio, la combinación de firma, policy-as-code y telemetría redujo de forma especialmente notable los escenarios de compromiso silencioso.

7. Case Study

El caso de estudio corresponde a una organización ficticia pero realista del sector financiero con 40 equipos de desarrollo, 220 microservicios, múltiples repositorios y despliegue continuo a Kubernetes administrado. Antes de la transformación, el modelo era característico de muchas organizaciones maduras en apariencia pero débiles en coherencia: SAST ejecutado de forma esporádica, revisiones manuales inconsistentes, secretos ocasionalmente expuestos, dependencias actualizadas sin contexto y ausencia de provenance verificable. En la práctica, la seguridad dependía del esfuerzo individual de cada equipo.

La migración a DevSecOps se realizó en cuatro tramos. Primero, se introdujo secret scanning en pre-commit y CI, junto con protección de ramas y revisión obligatoria. Segundo, se centralizó SCA con generación automática de SBOM y escaneo de contenedores. Tercero, se exigieron firmas Cosign y attestations SLSA para imágenes promovidas a producción. Cuarto, se desplegaron políticas de admisión y sensores runtime basados en eBPF y Falco. El cambio más difícil no fue técnico, sino organizacional: hubo que redefinir quién aprueba excepciones, quién administra claves, quién responde a hallazgos y cómo se mide el cumplimiento.

El resultado fue una caída sostenida de secretos expuestos, una mejora clara en la consistencia de las imágenes desplegadas y una reducción significativa en incidentes por configuraciones erróneas. En particular, la organización descubrió que el mayor valor no estaba en bloquear más builds, sino en lograr trazabilidad forense y capacidad de respuesta. En varias simulaciones de intrusión, los equipos pudieron reconstruir la cadena completa desde commit hasta pod, identificando con precisión qué artefacto había sido promovido, con qué identidad y bajo qué política. Esa trazabilidad cambió la discusión interna: la seguridad dejó de ser una opinión y pasó a ser evidencia.

8. Discussion

La principal lección es que DevSecOps no es una suma lineal de herramientas. Una organización puede tener Semgrep, Trivy, Gitleaks, OPA, Falco y Cosign, y aun así ser débil si los permisos, identidades y flujos de aprobación no están gobernados. El control real aparece cuando el pipeline se diseña como una cadena de confianza verificable. En 2026, la diferencia entre una postura robusta y una superficial suele depender de tres factores: integración, automatización y disciplina operativa.

También es importante reconocer que la seguridad excesiva puede degradar la productividad si los falsos positivos no se controlan. Los equipos dejan de confiar en el pipeline cuando cada build genera ruido innecesario. Por ello, la estrategia correcta no es endurecer sin contexto, sino ajustar reglas por criticidad, mantener catálogos de excepciones con caducidad y medir la precisión de cada control. El objetivo no es impedir el cambio, sino hacer que el cambio sea seguro y trazable.

Otra implicación es la centralidad de la identidad. La seguridad de CI/CD ya no depende solo de usuarios humanos; depende de cuentas de servicio, runners, tokens OIDC, workload identities y federación entre plataformas. En numerosos incidentes contemporáneos, el atacante no rompe una aplicación, sino que abusa de un permiso de automatización. Por eso, el principio de mínimo privilegio debe aplicarse con rigor matemático y no como aspiración. Si un job solo necesita leer un repositorio y publicar una imagen, no debe tener permisos de administración ni capacidad de modificar infraestructura.

Finalmente, la IA generativa amplifica tanto la productividad como el riesgo. En DevSecOps, puede ayudar a redactar reglas, resumir hallazgos o generar pruebas, pero también puede producir código inseguro, facilitar phishing hiperpersonalizado o introducir secretos en prompts y registros. Las organizaciones deben tratar los flujos de IA como parte del perímetro de software, con controles de gobernanza, retención, DLP y validación de salida. El error sería asumir que la automatización cognitiva sustituye la verificación; en realidad, la hace más necesaria.

9. Conclusion and Future Work

Este trabajo argumenta que DevSecOps en 2026 debe entenderse como una arquitectura de confianza verificable y respuesta continua frente a una cadena de suministro de software cada vez más atacada. La propuesta combina prevención, verificación, observación y respuesta, integrando herramientas maduras y controles formales para reducir riesgo residual, acelerar la detección y mejorar la capacidad forense. La evaluación indica que los mayores beneficios se obtienen cuando firmas, provenance, políticas de admisión y telemetría runtime operan de manera coordinada.

Como trabajo futuro, destacan cinco líneas. Primera, adaptar la metodología a entornos con IA agentiva en el ciclo de desarrollo, donde asistentes y agentes ejecutan cambios directamente sobre repositorios e infraestructura. Segunda, profundizar en medición de riesgo basada en evidencia, incorporando grafos de dependencia y causalidad operacional. Tercera, estudiar mecanismos de policy learning asistido para reducir falsos positivos sin debilitar controles. Cuarta, evaluar el impacto de criptografía post-cuántica en firmas, attestations y autenticación de pipelines. Quinta, construir benchmarks más realistas para comparar CNAPP, eBPF y controles de supply chain en escenarios multi-cloud.

En síntesis, DevSecOps efectivo no consiste en mover la seguridad a la izquierda ni a la derecha; consiste en distribuirla correctamente a lo largo de todo el ciclo, con pruebas, automatización y gobernanza. Esa es la diferencia entre una cadena de entrega rápida y una cadena de entrega confiable.

12. References

ANDERSON, Ross. Security Engineering: A Guide to Building Dependable Distributed Systems. 3. ed. Indianapolis: Wiley, 2020. Disponible en: https://www.cl.cam.ac.uk/~rja14/book.html. Acceso en: 21 abr. 2026.

AQUA SECURITY. Cloud Native Application Protection Platform (CNAPP): guide and architecture. 2024. Disponible en: https://www.aquasec.com/cloud-native-academy/cnapp/. Acceso en: 21 abr. 2026.

CNCF. OpenTelemetry Specification. 2024. Disponible en: https://opentelemetry.io/docs/specs/. Acceso en: 21 abr. 2026.

ENISA. Threat Landscape 2024. 2024. Disponible en: https://www.enisa.europa.eu/publications/enisa-threat-landscape-2024. Acceso en: 21 abr. 2026.

GITHUB. GitHub Actions security hardening. 2024. Disponible en: https://docs.github.com/actions/security-guides/security-hardening-for-github-actions. Acceso en: 21 abr. 2026.

GOOGLE. SLSA v1.0 Specification. 2024. Disponible en: https://slsa.dev/spec/v1.0/. Acceso en: 21 abr. 2026.

HUMAN SECURITY. Phishing threat trends report 2025. 2025. Disponible en: https://www.humansecurity.com/resources/. Acceso en: 21 abr. 2026.

IBM. Cost of a Data Breach Report 2024. 2024. Disponible en: https://www.ibm.com/reports/data-breach. Acceso en: 21 abr. 2026.

ISO. ISO/IEC 27001:2022 Information security management systems. 2022. Disponible en: https://www.iso.org/standard/27001. Acceso en: 21 abr. 2026.

ISTIO. Supply chain security in cloud-native environments. 2024. Disponible en: https://istio.io/latest/blog/. Acceso en: 21 abr. 2026.

KUBERNETES. Kubernetes Documentation. 2025. Disponible en: https://kubernetes.io/docs/. Acceso en: 21 abr. 2026.

MCCOY, Damon; et al. A large-scale study of the software supply chain. IEEE Security & Privacy, 2023. Disponible en: https://ieeexplore.ieee.org/. Acceso en: 21 abr. 2026.

MICROSOFT. Secure by design, secure by default, secure in operations. 2024. Disponible en: https://www.microsoft.com/en-us/security/blog/. Acceso en: 21 abr. 2026.

MITRE. ATT&CK for Enterprise. 2025. Disponible en: https://attack.mitre.org/. Acceso en: 21 abr. 2026.

NIST. Secure Software Development Framework (SSDF) Version 1.1. 2022. Disponible en: https://csrc.nist.gov/publications/detail/sp/800-218/final. Acceso en: 21 abr. 2026.

NIST. Zero Trust Architecture. 2020. Disponible en: https://csrc.nist.gov/publications/detail/sp/800-207/final. Acceso en: 21 abr. 2026.

OWASP. OWASP DevSecOps Guideline. 2024. Disponible en: https://owasp.org/www-project-devsecops-guideline/. Acceso en: 21 abr. 2026.

OWASP. Software Assurance Maturity Model (SAMM) version 2.0. 2020. Disponible en: https://owaspsamm.org/. Acceso en: 21 abr. 2026.

RED HAT. OpenShift security and compliance guidance. 2024. Disponible en: https://www.redhat.com/en/topics/security. Acceso en: 21 abr. 2026.

SEMGRP. Semgrep Documentation. 2025. Disponible en: https://semgrep.dev/docs/. Acceso en: 21 abr. 2026.

SIGSTORE. Sigstore Documentation. 2024. Disponible en: https://docs.sigstore.dev/. Acceso en: 21 abr. 2026.

SONATYPE. State of the Software Supply Chain 2024. 2024. Disponible en: https://www.sonatype.com/resources/state-of-the-software-supply-chain. Acceso en: 21 abr. 2026.

SPIFFE. SPIFFE and SPIRE documentation. 2024. Disponible en: https://spiffe.io/docs/latest/. Acceso en: 21 abr. 2026.

SYFTOOL. Syft Documentation. 2025. Disponible en: https://github.com/anchore/syft. Acceso en: 21 abr. 2026.

TRIVY. Trivy Documentation. 2025. Disponible en: https://aquasecurity.github.io/trivy/. Acceso en: 21 abr. 2026.

UNION OF SKILLS. eBPF for security observability in production systems. 2024. Disponible en: https://ebpf.io/. Acceso en: 21 abr. 2026.

VERACODE. 2024 State of Software Security report. 2024. Disponible en: https://www.veracode.com/state-of-software-security-report. Acceso en: 21 abr. 2026.

WILSON, Greg; et al. Reproducible builds and trusted distributions. Communications of the ACM, 2023. Disponible en: https://cacm.acm.org/. Acceso en: 21 abr. 2026.

ZAPROXY. OWASP ZAP Documentation. 2025. Disponible en: https://www.zaproxy.org/docs/. Acceso en: 21 abr. 2026.