A grandes rasgos, DevSecOps es una metodología que incorpora la seguridad a los procesos de desarrollo (Dev) y operaciones (Ops). En términos sencillos, esto significa que la seguridad de la tecnología se evalúa durante su desarrollo, pero también que la seguridad es responsabilidad de todos.
Posiblemente te has dado cuenta que la metodología DevSecOps se está adoptando cada vez más. En 2021, por ejemplo, en un estudio sobre DevSecOps a nivel mundial realizado por GitLab, cerca del 36% de los encuestados afirmó que sus equipos desarrollan software utilizando DevOps o DevSecOps. Por tanto, seguramente querrás saber qué significa este término. En este blog post, te daremos todos los conceptos básicos sobre esta metodología.
¿Qué es DevSecOps?
DevSecOps es la práctica de convertir la seguridad en una propiedad compartida y continua de la entrega de software, en lugar de una barrera al final. Los equipos de desarrollo, operaciones y seguridad trabajan sobre el mismo backlog, el mismo pipeline y la misma evidencia. El objetivo no es frenar la entrega sino eliminar el paso que solía detenerla: la revisión de seguridad que llega cuando el código ya está escrito.
Vale la pena aclarar tres malentendidos sobre DevSecOps, porque determinan cómo los equipos presupuestan el trabajo.
No es una categoría de herramientas. Comprar un escáner no convierte a un equipo en DevSecOps, igual que comprar un servidor de CI no lo convierte en DevOps. El proyecto DevSecOps del NIST NCCoE ubica los requisitos de seguridad, el diseño seguro, el modelado de amenazas y la definición de roles en la fase de plan, antes de que exista una sola línea de código. Las herramientas llegan después y sirven a esas decisiones.
No es solo shift-left. Mover las pruebas hacia el inicio es una mitad. La otra es lo que el NIST llama retroalimentación continua: un ciclo que agrega señales de éxito, falla y anomalía de todo el ciclo de vida de desarrollo de software (SDLC) y las devuelve a los equipos en el punto más temprano de detección. Sin el camino de vuelta, mover las pruebas a la izquierda solo desplaza un cuello de botella.
No es una fase que se termina. El mismo modelo de referencia trata las mejoras, la seguridad y el monitoreo como componentes presentes en todas las fases, no como una etapa propia. Un equipo que ejecuta análisis estático en los commits y nada más ha automatizado una fase de DevSecOps de siete.
DevOps y DevSecOps no son lo mismo
DevOps unió desarrollo y operaciones para entregar más rápido. DevSecOps conserva esa velocidad y suma la seguridad como tercera parte del mismo acuerdo, con autoridad para detener una liberación. La diferencia práctica no es el número de equipos involucrados. Es lo que ocurre cuando una verificación falla.
Dimensión | DevOps | DevSecOps |
Objetivo principal | Liberaciones más rápidas, frecuentes y confiables | Las mismas liberaciones, con el riesgo conocido resuelto antes de salir |
Dónde se ubica la seguridad | Una revisión antes de liberar, a menudo externa al equipo | Dentro de cada fase, de los requisitos al tiempo de ejecución |
Quién responde por ella | Un equipo de seguridad, consultado | Desarrollo, operaciones y seguridad, con responsabilidad conjunta |
Qué hace una verificación fallida | Genera un tiquete | Rompe el build y bloquea la fusión hasta cumplir la política |
Evidencia que produce | Registros de pruebas y despliegue | Esos, más hallazgos, severidad, explotabilidad e historial de remediación por cambio |
Estándares a los que mapea | Métricas de entrega | Un marco de desarrollo seguro de software como NIST SSDF, con controles trazados a requisitos |
Si quieres primero la mitad de entrega por separado, la práctica sobre la que DevSecOps se construye, tenemos una página aparte sobre DevOps.
DevSecOps en Fluid Attacks
Aplicamos DevSecOps a nuestro propio software y lo ejecutamos dentro de los pipelines de nuestros clientes. De esa doble posición salen las cifras de esta página: los datos de remediación de vulnerabilidades de nuestros clientes y un benchmark controlado en el que nuestro escáner y uno de nuestros pentesters probaron la misma aplicación que 36 herramientas de terceros.
Qué evaluamos y bajo qué reglas
Probamos los sistemas que el cliente inscribe, mientras estén inscritos, bajo un alcance definido y acordado antes de iniciar. La evaluación cubre código fuente, aplicaciones en ejecución, aplicaciones móviles, infraestructura como código, configuración de nube y dependencias de terceros. Los hallazgos se reportan con su severidad y la evidencia que los respalda, y una corrección no se da por cerrada hasta que un reattack reevalúa el código, porque una corrección puede introducir nuevas vulnerabilidades o no resolver la original.
Nada en nuestro modelo DevSecOps depende de que el cliente pause la entrega. Las pruebas corren mientras la aplicación cambia, que es la única manera de que los resultados sigan vigentes en una base de código que se despliega varias veces al día.
Cómo se ve DevSecOps en un pipeline
En un pipeline DevSecOps, cada fase tiene un control y cada control produce evidencia sobre la que la siguiente fase puede actuar. Así se ve el mapeo cuando está implementado y no solo descrito.
Fase | Qué se ejecuta | Evidencia que produce |
Plan | Requisitos de seguridad seleccionados por industria y regulación; modelado de amenazas | Un conjunto de requisitos contra el que después se mide el sistema |
Desarrollo | Static Application Security Testing (SAST), AI SAST y Escaneo de Secretos, en el IDE y en cada commit | Hallazgos en la línea de código, antes del pull request |
Construcción | Software Composition Analysis (SCA), generación de SBOM, verificación de contenedores e IaC | Un inventario de dependencias con vulnerabilidades conocidas y alcanzabilidad |
Pruebas | Dynamic Application Security Testing (DAST), MAST, Revisión de Código Seguro manual y Pentesting as a Service (PTaaS) | Hallazgos explotados con prueba, no solo firmas |
Liberación | CI Gate evaluado contra la política de severidad del cliente | Un paso aprobado o un build roto, con la razón adjunta |
Despliegue | CSPM y revisión de configuración | Configuraciones erróneas atadas al entorno desplegado |
Operación | Reattacks a solicitud, reescaneo continuo mientras el sistema cambia | Cierre verificado, o un hallazgo reabierto con evidencia |
Ciclo DevSecOps. Los nombres de las fases siguen el modelo de referencia del NIST NCCoE; los controles y la evidencia que se muestran son los que Fluid Attacks ejecuta en cada fase.
Cualquiera de nuestros escáneres puede integrarse a un pipeline de CI/CD mediante contenedores Docker, GitHub Actions o binarios distribuidos, y la plataforma se conecta con las herramientas que los equipos ya usan, desde IDE y asistentes de IA hasta gestores de incidencias.
Qué cambia de verdad romper el build
"Romper el build" es la única práctica de DevSecOps con un resultado medible en nuestros propios datos de clientes, así que vale la pena separar el eslogan del resultado. El CI Gate bloquea un despliegue mientras siga habiendo vulnerabilidades abiertas y sin aceptar que violan la política del cliente.
CI Gate ejecutado con un umbral de severidad de 7.0: el build falla cuando hay una vulnerabilidad de severidad alta.
Medida de remediación de vulnerabilidades (1 ene – 31 dic de 2025) | Clientes con CI Gate | Clientes sin él |
Proporción de vulnerabilidades reportadas que se remediaron | 72 % | 58 % |
Tiempo mediano de remediación | 22 días | 30 días |
Eso es una mejora del 26,7 % en la mediana, sobre una base de 1.119.396 vulnerabilidades reportadas en sistemas de clientes en 2025. La puerta no encuentra nada que los escáneres no hubieran encontrado ya. Lo que cambia es quién tiene que hacerse cargo del hallazgo, y cuándo.
Dónde se detiene la automatización
Esta es la cifra que complica el discurso habitual de los proveedores. En los mismos datos de 2025, las herramientas automatizadas encontraron el 88,4 % de todas las vulnerabilidades reportadas y las pruebas manuales el 11,6 %. Leído aisladamente, parece un argumento para automatizar y seguir adelante.
La vista ponderada por riesgo lo invierte. Esas mismas herramientas representaron el 55,8 % de la exposición total al riesgo, medida en CVSSF, frente al 44,2 % de las pruebas manuales. La vulnerabilidad promedio que encontró una herramienta cargaba 15,5 unidades CVSSF de exposición; la que encontró un pentester, 93,2, cerca de seis veces más. De las vulnerabilidades de severidad crítica reportadas ese año, el 87 % salió de pruebas manuales.
Las herramientas pasaron del 29,5 % al 55,8 % de la exposición al riesgo detectada; los pentesters siguen encontrando el 87 % de las vulnerabilidades de severidad crítica. Fuente: Fluid Attacks, State of Attacks 2026.
Fuente de detección (1 ene – 31 dic de 2025) | Proporción de vulnerabilidades halladas | Proporción de exposición al riesgo hallada | Exposición media por hallazgo (CVSSF) |
Herramientas automatizadas | 88,4 % | 55,8 % | 15,5 |
Pruebas manuales | 11,6 % | 44,2 % | 93,2 |
Una prueba controlada apunta en la misma dirección. En el benchmark de Fluid Attacks de 36 herramientas AppSec de terceros contra una aplicación sembrada con 1.201 vulnerabilidades, 743 de ellas —el 61,9 %— las detectó exclusivamente el pentester en pruebas manuales. Sobre el alcance que ese pentester revisó, que excluía las secciones ya cubiertas por nuestro propio escáner, alcanzó un 89,6 % de recall con 100 % de precisión.
El mejor resultado automatizado fue de 22,7 % de recall, y salió de nuestro propio escáner; las herramientas de terceros más fuertes quedaron entre 21,0 % y 21,6 %, y el promedio de las otras 34 fue de 1,7 %. La automatización es lo que hace asequibles las pruebas DevSecOps continuas a la frecuencia de los commits. No es lo que encuentra la vulnerabilidad que termina en un informe de incidente.
La práctica que decide todo lo demás
Si adoptas una sola práctica de DevSecOps de esta página, que sea la política detrás de la puerta, no la puerta en sí. Una puerta configurada por cantidad de vulnerabilidades castiga a los equipos por ruido de severidad baja y los entrena para pedir excepciones. Una puerta configurada por severidad y explotabilidad bloquea el puñado de hallazgos que concentra el riesgo y deja pasar el resto al backlog.
Los datos de 2025 respaldan la asimetría: las vulnerabilidades de severidad alta y crítica fueron el 4,5 % de los hallazgos pero el 79,9 % de la exposición total al riesgo. Pon el umbral donde está esa concentración y la puerta deja de ser un obstáculo que los equipos rodean.
Para profundizar: nuestra guía sobre cómo implementar DevSecOps recorre la selección de requisitos, y nuestro artículo de buenas prácticas de DevSecOps cubre los hábitos operativos en detalle.
Cómo funciona el ciclo DevSecOps
Funciona asignando una actividad de seguridad y una puerta de control a cada fase, y devolviendo a las fases anteriores lo que cada una aprende. El NIST describe las puertas de control como controles técnicos u organizacionales aplicados antes de permitir que un cambio de software avance a la siguiente etapa. El pipeline las hace cumplir; el ciclo de retroalimentación es lo que hace que valga la pena hacerlas cumplir.
Plan
La fase de plan fija los requisitos de seguridad contra los que se medirá el software, define una arquitectura que sigue principios de diseño seguro y ejecuta modelado de amenazas para decidir qué vale la pena defender. Los requisitos suelen venir de la regulación que la empresa ya debe cumplir, como PCI DSS, HIPAA o GDPR, más un marco de desarrollo seguro de software. NIST SP 800-218, el Secure Software Development Framework, es la línea base común; mapeamos sus prácticas a requisitos verificables en nuestra base de datos pública.
Saltarse esta fase es lo que produce la categoría de hallazgo más costosa: la debilidad creada por diseño, que ningún escáner reconoce porque el código hace exactamente lo que se especificó.
Desarrollo, construcción y pruebas
Estas tres fases concentran la mayor parte del trabajo automatizado de DevSecOps. El análisis estático y el escaneo de secretos corren mientras el desarrollador escribe y de nuevo en cada commit; el análisis de composición y la generación de SBOM corren en la construcción contra el árbol de dependencias; las pruebas dinámicas y móviles corren contra el artefacto desplegado. La revisión manual y el pentesting corren en paralelo, con una cadencia que depende de qué tan rápido cambia la aplicación.
Ubicarlas aquí es una cuestión de costo. Un hallazgo detectado en el IDE es una corrección. El mismo hallazgo detectado después de liberar es un incidente, un parche, un ciclo de liberación y una conversación con un cliente.
Liberación, despliegue y operación
En liberación, decide la puerta. En despliegue, las verificaciones de nube y configuración atrapan los errores de configuración que nunca aparecen en el código fuente. En operación, el sistema se reescanea a medida que cambia y las correcciones se verifican en lugar de asumirse, que es el paso que los equipos más saltan: un tiquete cerrado no es una vulnerabilidad cerrada hasta que algo la vuelva a probar.
Retroalimentación continua
El NIST define este ciclo como uno que agrega criterios de decisión —señales de éxito, falla y anomalía— de todo el SDLC y los entrega a los equipos en el punto más temprano de detección, para que se devuelvan a las fases anteriores. En la práctica esto significa que una debilidad recurrente en producción debería cambiar el conjunto de requisitos, el modelo de amenazas y la política de la puerta, no solo la línea de código que la causó.
Los equipos que tratan los hallazgos como tiquetes corrigen instancias. Los equipos que tratan los hallazgos como retroalimentación dejan de producir la clase entera.
¿Por qué necesitamos DevSecOps?
DevSecOps existe porque la alternativa dejó de funcionar. El software se despliega de forma continua, depende de código que nadie en el equipo escribió y corre sobre infraestructura definida por más código. Una revisión de seguridad trimestral no puede describir un sistema que cambió cuatrocientas veces desde la anterior.
La exposición crece, no se reduce
En 2025, el 70 % de los sistemas que evaluamos tenía al menos una vulnerabilidad de severidad alta o crítica, frente al 53,3 % en 2024. La mediana de exposición al riesgo por sistema subió 33,5 % año contra año. Son sistemas bajo pruebas continuas, lo que significa que la tasa de hallazgos refleja lo que hay, no lo que se alcanzó a mirar.
Tus dependencias son parte de tu superficie de ataque
La mayor parte del código de una aplicación moderna lo escribió otra persona, y los atacantes lo saben. En marzo de 2024, CISA y la comunidad de código abierto reportaron código malicioso incrustado en XZ Utils versiones 5.6.0 y 5.6.1, registrado como CVE-2024-3094, en una biblioteca de compresión que puede estar presente en distribuciones de Linux. Nada estaba mal en las aplicaciones que dependían de ella. El compromiso entró por la construcción.
Por eso la seguridad de la cadena de suministro de software va dentro del pipeline y no en un cuestionario anual a proveedores. Nuestro propio requisito al respecto es directo: los sistemas deben usar versiones estables, probadas y actualizadas de componentes de terceros. Nuestro análisis del OWASP Top 10 2025 cubre cómo la categoría ganó protagonismo, y profundizamos en el tema en nuestra página sobre software supply chain security.
La seguridad es asunto de todos
Un equipo de seguridad de diez personas no puede revisar la producción de trescientos desarrolladores, y nunca se esperó que lo hiciera. DevSecOps reparte el trabajo: los desarrolladores responden por los hallazgos en su código, operaciones por la configuración, y el equipo de seguridad por los requisitos, el modelo de amenazas y las decisiones de criterio. El rol que une esas piezas tiene nombre y descripción de cargo, y lo cubrimos en nuestro artículo sobre qué hace un ingeniero DevSecOps.
Shift-left, y lo que deja por fuera
La seguridad shift-left consiste en mover las pruebas hacia el inicio del SDLC, donde los defectos son más baratos de corregir. Es la mitad más citada de DevSecOps y es el comportamiento correcto por defecto. Por sí sola, también es una descripción incompleta de lo que el modelo exige.
Lo que deja por fuera es el lado derecho. Las vulnerabilidades llegan a producción de todos modos: por dependencias actualizadas después de liberar, por deriva de configuración, por clases de falla que ninguna prueba previa atrapa. Mover a la izquierda angosta esa ventana; el monitoreo, el reescaneo y los reattacks la cierran para lo que se cuela. El encuadre útil no es izquierda contra derecha sino cobertura DevSecOps a lo largo de toda la línea, con la retroalimentación del lado derecho redefiniendo qué se prueba en el izquierdo.
Automatización de DevSecOps junto con técnicas manuales
La automatización y las pruebas manuales resuelven mitades distintas del problema de DevSecOps: la automatización da cobertura a la velocidad a la que cambia el código, las pruebas manuales dan los hallazgos que cargan la severidad. Depender solo de la automatización implica aceptar tanto falsos positivos, que cuestan tiempo de revisión, como falsos negativos, que cuestan más.
En la práctica, los escáneres corren en cada commit y los pentesters trabajan de forma continua sobre los mismos sistemas, con ambos conjuntos de resultados en la misma plataforma y el mismo backlog. Los escáneres angostan la superficie; los pentesters encadenan lo que queda en algo que un atacante podría usar, incluidas fallas de lógica de negocio que ninguna firma describe. Nuestro artículo sobre DevSecOps en la nube aplica la misma división a pipelines nativos de nube, donde los archivos de IaC y las imágenes de contenedores necesitan pruebas continuas propias.
Cómo evolucionar de DevOps a DevSecOps
La madurez DevSecOps es un camino, no un interruptor. Un equipo no "hace DevSecOps" o no: tiene un nivel por práctica, y la pregunta útil es qué práctica subir a continuación. Modelos como OWASP SAMM existen precisamente para hacer eso evaluable, con prácticas puntuadas en gobierno, diseño, implementación, verificación y operaciones.
Un orden que funciona, cuando no hay una evaluación de partida:
Define los requisitos primero: elige el marco y las regulaciones que apliquen, para que los hallazgos posteriores tengan contra qué medirse.
Instrumenta las fases que ya automatizas: el análisis estático y el de composición van donde tu CI ya corre.
Agrega la puerta, por severidad: una política sobre severidad alta y crítica, no sobre cantidades.
Agrega pentesting donde se concentra la severidad: los hallazgos críticos son los que la automatización pierde.
Cierra el ciclo: usa reattacks para verificar las correcciones y deja que las debilidades recurrentes cambien los requisitos, no solo el código.
Vuelve a evaluar: puntúa las prácticas otra vez y sube la más baja.
Buenas prácticas de DevSecOps
Las prácticas que separan un programa DevSecOps que funciona de uno que solo tiene herramientas son sobre todo organizacionales. La colaboración va primero: los equipos de desarrollo y seguridad que revisan el producto juntos encuentran problemas que ninguno encontraría solo, porque entender por qué el código hace algo es la ruta más rápida a saber cómo se rompe.
Más allá de eso: probar de forma continua y no por ciclos de auditoría; priorizar por explotabilidad y severidad y no por cantidad de hallazgos; verificar cada corrección con un reattack en vez de confiar en un tiquete cerrado; y mantener el ciclo de retroalimentación del desarrollador dentro de su propio entorno, porque un hallazgo que exige entrar a otro portal se atiende tarde.
¿Cómo se relaciona DevSecOps con los red teams?
El red teaming complementa a DevSecOps probando a la organización y no a la base de código. Un red team emula adversarios reales —sus recursos, tácticas y procedimientos— en el plano tecnológico y el humano, incluida la ingeniería social, para medir qué tan bien funcionan la prevención, la detección y la respuesta. DevSecOps asegura lo que construyes; el red teaming verifica qué pasa cuando alguien va tras ello.
Los dos se encuentran en el ciclo de retroalimentación. Lo que un ejercicio de red team descubre pertenece al conjunto de requisitos y al modelo de amenazas, que es de donde sale la política de la puerta de la siguiente liberación.
¿SecDevOps?
SecDevOps, DevSecOps y DevOpsSec nombran lo mismo. El reordenamiento se usa a veces para argumentar que la seguridad debería ir primero y no en la mitad, pero ningún organismo de estándares los distingue, y el NIST usa DevSecOps. El término que elijas importa mucho menos que si una verificación de seguridad fallida puede detener una liberación.
Conclusiones
DevSecOps no es la automatización de las pruebas de seguridad, ni la práctica de mover la seguridad a la izquierda. Es un modelo de ciclo de vida en el que los requisitos, los controles, las pruebas, la retroalimentación, el monitoreo y la remediación operan de forma continua en planeación, desarrollo, construcción, pruebas, liberación, despliegue y operaciones, con puertas de control decidiendo qué avanza.
La evidencia de DevSecOps es específica, no filosófica. Los equipos que rompieron el build ante violaciones de política en 2025 alcanzaron una tasa de remediación de vulnerabilidades del 72 % frente al 58 % sin ese control, y lo hicieron ocho días más rápido en la mediana. Las herramientas automatizadas encontraron el 88,4 % de las vulnerabilidades pero solo el 55,8 % de la exposición al riesgo, y el 87 % de los hallazgos de severidad crítica salió de pruebas manuales. La seguridad shift-left y la retroalimentación continua son ambas estructurales, y un programa que financie solo una de las dos lo va a notar en la severidad de lo que se le escapa.
Preguntas frecuentes
¿DevSecOps es solo agregar herramientas de seguridad al pipeline de CI/CD?
No. Las herramientas en el pipeline son una fase de siete. El modelo de referencia del NIST NCCoE ubica trabajo de seguridad en plan, desarrollo, construcción, pruebas, liberación, despliegue y operación, con mejoras, seguridad y monitoreo presentes en todas ellas, más un ciclo de retroalimentación que devuelve los hallazgos a las fases anteriores. Un equipo que escanea en cada commit y nada más ha automatizado una fracción del modelo.
¿DevSecOps reemplaza al pentesting?
No, y los datos explican por qué. Sobre 1.119.396 vulnerabilidades reportadas en sistemas de clientes entre enero y diciembre de 2025, las herramientas automatizadas encontraron el 88,4 % de las vulnerabilidades pero el 55,8 % de la exposición al riesgo, mientras que el 87 % de las vulnerabilidades de severidad crítica salió de pruebas manuales. La automatización entrega cobertura a la velocidad a la que cambia el código; el pentesting entrega los hallazgos que cargan la severidad. Un programa DevSecOps necesita ambos.
¿Qué es una puerta de seguridad y qué significa romper el build?
Una puerta de seguridad es un control aplicado antes de permitir que un cambio pase a la siguiente etapa del ciclo. Romper el build significa que esa puerta detiene el despliegue mientras haya vulnerabilidades abiertas y sin aceptar que violan la política definida, lo que obliga a una corrección en lugar de a un tiquete. En 2025, los clientes que la usaban remediaron el 72 % de sus vulnerabilidades frente al 58 % de quienes no.
¿Cómo se mide la madurez DevSecOps?
Con un modelo puntuado, no con una respuesta de sí o no. Marcos como OWASP SAMM evalúan prácticas en gobierno, diseño, implementación, verificación y operaciones, de modo que un equipo puede ver cuál práctica está más débil y subir esa. Tratar la adopción como binaria esconde la diferencia entre un equipo que escanea en cada commit y uno que además fija requisitos, aplica puertas por severidad y verifica las correcciones.
¿Fluid Attacks soporta DevSecOps en pipelines de CI/CD?
Sí. Nuestros escáneres se integran a CI/CD mediante contenedores Docker, GitHub Actions o binarios distribuidos, y nuestro CI Gate evalúa cada build contra tu política de severidad y bloquea las fusiones cuando hay vulnerabilidades que violan la política. La plataforma se conecta con los IDE, los asistentes de IA y los gestores de incidencias que tu equipo ya usa, y nuestros pentesters prueban los mismos sistemas de forma continua en el plan Advanced.
Entrega rápido sin vulnerabilidades
Nuestros escáneres, nuestra IA y nuestros pentesters llevan las pruebas DevSecOps a tus aplicaciones a medida que cambian, y nuestro CI Gate detiene los builds que llevarían una vulnerabilidad crítica a producción. Start free trial · Contáctanos
