Los equipos de software están bajo presión para lanzar más rápido, corregir problemas antes y proteger las aplicaciones frente a amenazas de seguridad cada vez más complejas. Por eso DevOps seguro se ha convertido en una prioridad práctica para los equipos de ingeniería modernos.
Antes, los desarrolladores se centraban principalmente en construir funcionalidades. Los equipos de seguridad revisaban los riesgos más tarde, a menudo cerca del final del ciclo de vida del desarrollo de software. Ese enfoque ya no funciona bien. Las aplicaciones actuales dependen de servicios en la nube, APIs, paquetes de código abierto, pipelines de CI/CD, herramientas de codificación con IA, integraciones de terceros y equipos distribuidos. Un único punto débil puede pasar rápidamente del desarrollo a producción.
La brecha de habilidades en DevOps no se refiere solo a la falta de especialistas en ciberseguridad. También se trata de si los desarrolladores, ingenieros DevOps, equipos de QA y equipos de producto entienden cómo integrar la seguridad en la entrega diaria de software. NIST explica que las prácticas DevSecOps están diseñadas para abordar la seguridad de forma continua en todas las fases del ciclo de vida del desarrollo de software, lo que significa que la seguridad ya no puede quedar fuera del proceso de desarrollo.
Por qué importa la brecha de habilidades en DevOps seguro
La brecha de habilidades en DevOps seguro importa porque la seguridad del software está ahora directamente vinculada al riesgo empresarial. Cuando los desarrolladores no tienen suficiente conocimiento de seguridad, las vulnerabilidades pueden introducirse durante la codificación, pasarse por alto en las pruebas o desplegarse a través de pipelines automatizados antes de que los equipos de seguridad puedan reaccionar.
El Informe sobre el coste de una brecha de datos de IBM de 2025 reveló que el coste medio global de una brecha de datos fue de 4,44 millones de USD. Esa cifra explica por qué el desarrollo de software seguro ya no puede tratarse como una preocupación técnica opcional.
La seguridad es ahora una responsabilidad compartida
En el modelo tradicional, la responsabilidad de seguridad solía estar separada del desarrollo. Los desarrolladores escribían código, los equipos de operaciones lo desplegaban y los equipos de seguridad lo revisaban después.
Sin embargo, la entrega de software moderna es demasiado rápida para ese modelo de traspaso. Los pipelines de CI/CD, la infraestructura como código, los despliegues automatizados y las arquitecturas cloud-native permiten a los equipos publicar cambios con frecuencia. Si las verificaciones de seguridad se retrasan, los riesgos pueden avanzar rápidamente por el pipeline.
Un modelo más sólido de DevOps seguro asigna a cada rol una responsabilidad de seguridad clara. Los desarrolladores necesitan habilidades de codificación segura. Los ingenieros DevOps necesitan conocimiento de seguridad de pipeline e infraestructura. Los equipos de QA necesitan entender las pruebas de seguridad. Los product owners necesitan definir criterios de aceptación relacionados con la seguridad.
Los equipos de ciberseguridad no pueden cubrirlo todo solos
La brecha de seguridad de los desarrolladores se vuelve más grave cuando las organizaciones ya tienen escasez de talento en ciberseguridad. El informe State of Cybersecurity 2025 de ISACA reveló que el 55 % de los equipos de ciberseguridad están infradotados y el 65 % tiene puestos de ciberseguridad sin cubrir. El mismo informe también señaló que el 70 % de los encuestados espera que aumente la demanda de contribuyentes técnicos en ciberseguridad.
Esto significa que las empresas no pueden depender solo de los equipos centrales de seguridad para detectar todos los problemas. Los equipos de desarrollo necesitan suficiente conciencia de seguridad para prevenir los riesgos comunes antes.
Qué causa la brecha de habilidades
La brecha de habilidades en DevOps seguro rara vez ocurre porque los desarrolladores sean descuidados. Más a menudo, ocurre porque el conocimiento de seguridad, la velocidad de entrega, la presión empresarial y las herramientas no evolucionan al mismo ritmo.
La formación académica suele omitir el trabajo práctico de seguridad
Muchos desarrolladores se gradúan con un sólido conocimiento de programación, pero con una experiencia práctica limitada en codificación segura. Pueden entender algoritmos, bases de datos y diseño de software, pero no lo suficiente sobre modelado de amenazas, control de acceso, riesgos de dependencias, diseño seguro de APIs, gestión de secretos o seguridad en la nube.
Esto crea una brecha entre lo que los desarrolladores aprenden y lo que las empresas esperan de ellos. En entornos de producción, los desarrolladores necesitan entender no solo cómo hacer que el software funcione, sino también cómo puede fallar, ser abusado o exponer datos sensibles.
La Linux Foundation y OpenSSF abordaron esta problemática más amplia en 2025 al publicar un marco de habilidades de ciberseguridad que ofrece orientación para roles que incluyen desarrolladores web y de software, ingenieros DevOps, gestores de proyectos de TI y arquitectos de plataformas. Es una dirección útil porque las habilidades de seguridad deben ser específicas para cada rol, no limitarse a los especialistas en seguridad.
Las herramientas de seguridad se añaden sin diseñar el flujo de trabajo
Muchas empresas compran herramientas de seguridad antes de rediseñar sus flujos de trabajo. Como resultado, los desarrolladores pueden recibir informes de vulnerabilidades interminables, alertas ruidosas o consejos de remediación poco claros. Esto puede generar frustración en lugar de mejorar la seguridad.
En un entorno maduro de DevOps seguro, las herramientas deberían ayudar a los desarrolladores a actuar antes y más rápido. Las pruebas de seguridad estática de aplicaciones, el análisis de composición de software, la detección de secretos, el escaneo de contenedores, el escaneo de infraestructura como código y las pruebas dinámicas deberían integrarse en el pipeline de desarrollo con una responsabilidad clara.
El objetivo no es bloquear a los desarrolladores con más herramientas. El objetivo es darles retroalimentación accionable en el momento adecuado.
La responsabilidad suele estar mal definida
Otro problema habitual es la responsabilidad poco clara. Los desarrolladores pueden asumir que los equipos de seguridad son responsables de la seguridad de las aplicaciones. Los equipos de seguridad pueden asumir que los desarrolladores corregirán los problemas una vez reportados. Los equipos de producto pueden no incluir los requisitos de seguridad en las historias de usuario.
Esto genera retrasos y una responsabilidad débil.
Un modelo de responsabilidad mejor es sencillo:
- Los desarrolladores son responsables de la codificación segura y la remediación.
- Los ingenieros DevOps son responsables de los controles de pipeline, despliegue e infraestructura.
- Los equipos de seguridad son responsables de los estándares, la orientación sobre riesgos y el análisis complejo de amenazas.
- Los equipos de QA ayudan a validar el comportamiento relacionado con la seguridad.
- Los equipos de producto definen los riesgos empresariales y de impacto en el usuario.
Cuando la responsabilidad es compartida pero poco clara, la seguridad se convierte en preocupación de todos, pero prioridad de nadie. Cuando la responsabilidad es compartida y claramente definida, la seguridad pasa a formar parte de la entrega normal.
Desarrollar habilidades de seguridad en todo el equipo
Cerrar la brecha de habilidades en DevOps seguro requiere más que una formación puntual. Necesita aprendizaje continuo, herramientas prácticas, apoyo entre pares y una cultura en la que la seguridad se trate como parte de la calidad del software.
Empezar por los fundamentos de la codificación segura
Los desarrolladores deberían entender primero las debilidades de seguridad más comunes que aparecen en las aplicaciones modernas. Estas incluyen el control de acceso roto, la inyección, la autenticación insegura, la exposición de datos sensibles, el diseño inseguro, las dependencias vulnerables, la mala configuración y el registro débil.
OWASP publicó la versión ASVS 5.0.0 en mayo de 2025, ofreciendo a los equipos un estándar actualizado de verificación de seguridad de aplicaciones para aplicaciones y servicios web.
Para los desarrolladores, la formación en codificación segura debería cubrir:
- Validación de entradas
- Autenticación y autorización
- Gestión de sesiones
- Seguridad de APIs
- Gestión segura de errores
- Cifrado de datos
- Gestión de dependencias
- Gestión de secretos
- Registro y monitorización
- Principios de diseño seguro
Estas habilidades hacen que DevOps seguro sea más realista porque los desarrolladores pueden prevenir problemas básicos antes de que lleguen a las pruebas o a producción.
Enseñar seguridad a través de escenarios reales del proyecto
La formación genérica en seguridad suele ser demasiado abstracta. Los desarrolladores aprenden mejor cuando la formación se conecta con los sistemas que realmente construyen.
Por ejemplo, un equipo que construye una aplicación fintech debería practicar flujos de pago seguros, control de acceso basado en roles, registros de auditoría y privacidad de datos. Un equipo que construye una plataforma de salud debería centrarse en datos de salud sensibles, consentimiento, cumplimiento normativo, límites de acceso e integraciones seguras.
El aprendizaje basado en escenarios ayuda a los desarrolladores a entender el impacto de las decisiones de seguridad. También hace que la formación sea más fácil de recordar porque conecta los conceptos de seguridad con código familiar, flujos de usuario y riesgos empresariales.
Hacer que la seguridad forme parte de la revisión de código
La revisión de código no debería centrarse solo en el estilo, el rendimiento o la lógica. También debería verificar si el código introduce riesgos de seguridad.
Los revisores pueden buscar problemas como:
- Verificaciones de autorización ausentes
- Exposición insegura de datos
- Validación de entradas débil
- Secretos codificados directamente
- Respuestas de API inseguras
- Permisos demasiado amplios
- Uso inseguro de dependencias
- Gestión de errores deficiente
- Falta de registro para acciones sensibles
Esto ayuda a que DevOps seguro se convierta en un hábito de ingeniería normal en lugar de una actividad aparte.
Cómo cerrar la brecha
Las empresas necesitan un plan práctico para desarrollar la capacidad de seguridad en los equipos de desarrollo. El objetivo no es convertir a cada desarrollador en un experto en seguridad a tiempo completo. El objetivo es que el conocimiento de seguridad esté disponible, sea repetible y fácil de aplicar durante la entrega diaria.
1. Crear formación en seguridad específica por roles
Un desarrollador backend, un desarrollador frontend, un ingeniero DevOps, un ingeniero de QA y un product owner no necesitan exactamente la misma formación en seguridad. Cada rol necesita el conocimiento de seguridad que se ajuste a sus responsabilidades.
Por ejemplo:
- Los desarrolladores backend necesitan seguridad de APIs, control de acceso, validación de datos y seguridad de dependencias.
- Los desarrolladores frontend necesitan prevención de XSS, gestión segura de sesiones y prácticas seguras de exposición de datos.
- Los ingenieros DevOps necesitan gestión de secretos, seguridad de CI/CD, seguridad de infraestructura y permisos en la nube.
- Los ingenieros de QA necesitan casos de prueba de seguridad, casos de abuso y validación de regresión.
- Los product owners necesitan conciencia de riesgos y criterios de aceptación de seguridad.
La formación por roles hace que DevOps seguro sea más fácil de adoptar porque evita sobrecargar a cada miembro del equipo con material irrelevante.
2. Integrar el escaneo de seguridad en los pipelines de CI/CD
Las verificaciones de seguridad deberían estar integradas en el flujo de trabajo de desarrollo. Si las herramientas de seguridad solo se ejecutan al final del proyecto, los equipos pueden descubrir los problemas demasiado tarde y enfrentarse a un retrabajo costoso. Una hoja de ruta de implementación DevOps bien estructurada debería tratar el escaneo de seguridad como un hito clave, no como una ocurrencia tardía.
En un pipeline moderno, el escaneo de seguridad puede incluir:
- Pruebas de seguridad estática de aplicaciones
- Escaneo de vulnerabilidades en dependencias
- Detección de secretos
- Escaneo de imágenes de contenedores
- Escaneo de infraestructura como código
- Pruebas de seguridad de APIs
- Pruebas dinámicas de seguridad de aplicaciones
- Verificaciones de cumplimiento de licencias
Cuando los flujos de entrega automatizados envían cambios a producción sin verificaciones de seguridad tempranas, incluso los problemas más pequeños pueden propagarse rápidamente. Por eso la automatización de seguridad debe formar parte del pipeline de entrega, no un paso final aparte.
Sin embargo, la seguridad del pipeline debería diseñarse con cuidado. No todos los hallazgos deberían bloquear todos los lanzamientos. Los equipos deberían definir niveles de severidad, reglas de excepción, plazos de remediación y rutas de escalado.
3. Crear un programa de campeones de seguridad
Un programa de campeones de seguridad da a cada equipo de desarrollo una o más personas que actúan como puente entre ingeniería y seguridad.
Los campeones de seguridad no reemplazan al equipo de seguridad. En su lugar, ayudan a llevar el conocimiento práctico de seguridad a la planificación de sprints, la revisión de código, las discusiones de amenazas y la preparación de lanzamientos.
Un buen campeón de seguridad puede ayudar con:
- Revisar historias sensibles desde el punto de vista de seguridad
- Explicar los estándares de codificación segura
- Ayudar a los desarrolladores a entender los resultados de los escáneres
- Apoyar las sesiones de modelado de amenazas
- Compartir lecciones aprendidas de incidentes
- Coordinar con especialistas de seguridad
- Fomentar mejores hábitos de seguridad dentro del equipo
Este modelo funciona bien para DevOps seguro porque acerca la seguridad al equipo sin ralentizar la entrega a través de un cuello de botella centralizado.
4. Añadir el modelado de amenazas antes en el SDLC
El modelado de amenazas ayuda a los equipos a pensar en cómo podría atacarse un sistema antes de construirlo. Es especialmente útil para nuevas funcionalidades, APIs, flujos de autenticación, sistemas de pago, funciones de IA e integraciones con servicios de terceros.
El modelado de amenazas no necesita ser pesado. Incluso una breve discusión puede ayudar a los equipos a identificar riesgos como:
- ¿Quién puede acceder a esta funcionalidad?
- ¿Qué datos quedan expuestos?
- ¿Qué podría abusar un atacante?
- ¿Qué ocurre si se llama a una API demasiadas veces?
- ¿Qué secretos o credenciales están involucrados?
- ¿Qué registros se necesitan para la investigación?
- ¿Qué controles deberían añadirse antes del lanzamiento?
Esto hace que DevOps sea más proactivo. En lugar de encontrar todos los problemas después de codificar, los equipos pueden reducir el riesgo durante el diseño.
5. Usar la IA con cuidado en el desarrollo y la seguridad
Las herramientas de codificación con IA están transformando el desarrollo de software, pero también crean nuevas preocupaciones de seguridad. Los desarrolladores pueden usar la IA para generar código, escribir pruebas, explicar vulnerabilidades, revisar pull requests o resumir hallazgos de seguridad. Sin embargo, el resultado generado por IA sigue necesitando revisión humana.
La encuesta Stack Overflow 2025 Developer Survey reveló que el 84 % de los encuestados están usando o planean usar herramientas de IA en su proceso de desarrollo, y el 51 % de los desarrolladores profesionales usa herramientas de IA a diario.
Esto importa porque la IA puede mejorar la velocidad, pero también puede aumentar el riesgo de código generado inseguro, exposición de datos y gobernanza débil. Los desarrolladores necesitan orientación sobre qué código puede compartirse con herramientas de IA, cómo debe revisarse el código generado y cómo deben asegurarse las funciones de IA antes del lanzamiento. Para un análisis más profundo de los riesgos de seguridad relacionados con la IA, consulte nuestra guía sobre seguridad LLM para IA agéntica.
Para DevOps seguro, la IA debería tratarse como un asistente, no como una autoridad.
Cómo se ve DevOps seguro en la práctica
Un proceso DevOps maduro no se define por una sola herramienta o un solo curso de formación. Se define por la consistencia con la que la seguridad se integra en la entrega diaria.
Antes del desarrollo
Antes de que comience la codificación, los equipos deberían aclarar los requisitos de seguridad, los permisos de usuario, la sensibilidad de los datos, las necesidades regulatorias y los posibles casos de abuso. La seguridad debería aparecer en las historias de usuario y en los criterios de aceptación cuando sea relevante.
Esta discusión temprana ayuda a los equipos a evitar requisitos vagos como “hacerlo seguro”. En su lugar, pueden definir comportamientos específicos, como quién puede acceder a una funcionalidad, qué datos deberían enmascararse y qué acciones deberían registrarse.
Durante el desarrollo
Durante el desarrollo, los equipos deberían seguir estándares de codificación segura, usar verificaciones de dependencias, proteger los secretos, revisar el código cuidadosamente y ejecutar pruebas automatizadas. Los desarrolladores deberían recibir retroalimentación mientras aún trabajan en la funcionalidad, no semanas después.
Aquí es donde la brecha de habilidades en DevOps seguro suele hacerse visible. Si los desarrolladores no entienden los resultados de los escáneres, ignoran las alertas o no tienen tiempo para corregir los problemas, las herramientas por sí solas no mejorarán la seguridad.
Antes del lanzamiento
Antes del lanzamiento, los equipos deberían revisar los cambios de alto riesgo, verificar los controles de seguridad críticos, comprobar los resultados del pipeline, validar el control de acceso y confirmar que la monitorización está lista. Los problemas de alta severidad deberían tener reglas de remediación claras.
Las puertas de seguridad deberían ser lo suficientemente estrictas para reducir el riesgo, pero lo suficientemente prácticas para respaldar la entrega. Un proceso de lanzamiento útil debería distinguir entre vulnerabilidades críticas, problemas de riesgo medio, riesgos aceptados y elementos que pueden corregirse después del lanzamiento.
Después del lanzamiento
Después del lanzamiento, los equipos deberían monitorizar los registros, responder a incidentes, parchear dependencias, revisar vulnerabilidades y aprender de los problemas en producción. La seguridad no se completa cuando la aplicación se publica.
El aprendizaje posterior al lanzamiento ayuda a los equipos a mejorar la formación, actualizar los estándares de codificación segura, ajustar las herramientas de seguridad y prevenir problemas similares en futuros ciclos de desarrollo.
Cómo deberían medir el progreso las empresas
Para mejorar la brecha de habilidades en DevOps seguro, las organizaciones deberían medir tanto el progreso técnico como el cultural. Las métricas ayudan a los equipos a entender si la seguridad se está integrando en el flujo de trabajo o sigue siendo una actividad de cumplimiento aparte.
Métricas técnicas
Las métricas técnicas útiles incluyen:
- Número de vulnerabilidades de alta severidad detectadas antes de producción
- Tiempo medio de remediación de vulnerabilidades
- Porcentaje de repositorios con detección de secretos activada
- Porcentaje de dependencias críticas parcheadas a tiempo
- Porcentaje de lanzamientos con las verificaciones de seguridad requeridas
- Número de incidentes de producción vinculados a problemas de codificación o configuración
- Tasa de falsos positivos de los escáneres de seguridad
- Porcentaje de aplicaciones cubiertas por pruebas de seguridad
Estas métricas muestran si los equipos están reduciendo el riesgo de seguridad antes en el ciclo de vida del desarrollo.
Métricas de equipo y proceso
La brecha de habilidades en DevOps seguro también es un problema de personas y procesos, por lo que las empresas deberían medir también la preparación del equipo.
Las métricas de proceso útiles incluyen:
- Número de equipos con campeones de seguridad formados
- Finalización de la formación en seguridad por rol
- Satisfacción de los desarrolladores con las herramientas de seguridad
- Número de sesiones de modelado de amenazas completadas
- Porcentaje de problemas de seguridad corregidos dentro del SLA
- Porcentaje de historias de usuario con criterios de aceptación de seguridad cuando corresponde
- Tiempo necesario para aclarar la responsabilidad de seguridad
- Frecuencia de sesiones de intercambio de conocimiento sobre seguridad
Estas métricas ayudan a los líderes a ver si el conocimiento de seguridad se está extendiendo por toda la organización.
Errores comunes que mantienen abierta la brecha de habilidades
Muchas empresas intentan mejorar la seguridad de las aplicaciones pero siguen teniendo dificultades porque sus acciones no abordan las causas reales de la brecha de habilidades en DevOps seguro.
Tratar la seguridad como una revisión final
Si las verificaciones de seguridad ocurren solo antes del lanzamiento, los equipos descubrirán los problemas demasiado tarde. Esto genera presión, conflictos y retrabajo. La seguridad necesita adelantarse a la planificación, la codificación, las pruebas y el despliegue.
Sobrecargar a los desarrolladores con alertas de herramientas
Demasiadas alertas pueden hacer que los desarrolladores ignoren las herramientas de seguridad. Los equipos deberían ajustar los escáneres, priorizar los hallazgos de alto riesgo y proporcionar una guía de remediación clara.
Dar la misma formación a todos
La formación genérica es fácil de organizar, pero a menudo menos efectiva. Los desarrolladores, ingenieros de QA, ingenieros DevOps y product owners necesitan una formación que se ajuste a sus responsabilidades reales.
Ignorar la seguridad de la nube y del pipeline
El riesgo moderno de las aplicaciones no está solo dentro del código de la aplicación. También puede provenir de una infraestructura mal configurada, secretos expuestos, permisos débiles del pipeline, contenedores vulnerables y un control de acceso deficiente.
Usar la IA sin gobernanza
Las herramientas de IA pueden ayudar a los equipos de desarrollo, pero no deberían usarse sin reglas. Los equipos necesitan políticas para el intercambio de datos, la revisión del código generado, la validación de seguridad y los flujos de trabajo de desarrollo asistidos por IA.
Reflexión final
La brecha de habilidades en DevOps seguro ya no es un problema meramente de formación. Es un desafío empresarial, de ingeniería y de seguridad. Los equipos de software modernos necesitan moverse rápido, pero también necesitan construir sistemas que sean seguros, fiables y resilientes.
Cerrar esta brecha requiere formación práctica, un mejor diseño del flujo de trabajo, verificaciones de seguridad automatizadas, campeones de seguridad, modelado de amenazas y un uso responsable de la IA. Y lo más importante, requiere una cultura en la que la seguridad se trate como parte de la calidad del software.
HDWEBSOFT ofrece servicios de DevOps y servicios de ciberseguridad para empresas que quieren construir procesos de entrega de software seguros, escalables y fiables. Como empresa certificada ISO 27001, aplicamos los mismos estándares de seguridad a nuestra propia entrega que los que recomendamos a nuestros clientes. Con la estrategia adecuada, la seguridad DevOps puede ayudar a los equipos a reducir el riesgo sin ralentizar la innovación.
Preguntas frecuentes sobre DevOps seguro
¿Qué es DevOps seguro?
DevOps seguro es un enfoque que integra la seguridad en las prácticas de DevOps. Ayuda a los equipos a construir, probar, desplegar y operar software con controles de seguridad incluidos a lo largo de todo el ciclo de vida del desarrollo de software.
¿Qué es la brecha de habilidades en DevOps seguro?
La brecha de habilidades en DevOps seguro se refiere a la diferencia entre el conocimiento de seguridad que los equipos de desarrollo necesitan y el que actualmente tienen. Suele incluir carencias en codificación segura, seguridad en CI/CD, seguridad en la nube, gestión de dependencias y modelado de amenazas.
¿Por qué los desarrolladores necesitan habilidades de seguridad DevOps?
Los desarrolladores necesitan habilidades de seguridad porque muchas vulnerabilidades se introducen durante la codificación, la configuración, la gestión de dependencias o el diseño de APIs. Los equipos de seguridad no pueden detectar todos los problemas una vez finalizado el desarrollo.
¿Qué causa la brecha de habilidades en DevOps seguro?
La brecha de habilidades en DevOps seguro suele estar causada por una formación limitada en codificación segura, una responsabilidad mal definida, la presión por entregar rápido, un diseño deficiente del flujo de trabajo, herramientas de seguridad ruidosas y la falta de formación específica por roles.
¿Cómo pueden las empresas formar a los desarrolladores en DevOps seguro?
Las empresas pueden formar a los desarrolladores mediante cursos de codificación segura, talleres basados en proyectos, sesiones de modelado de amenazas, orientación en revisiones de código, programas de campeones de seguridad y práctica práctica de remediación.
¿Qué herramientas respaldan la seguridad DevOps?
Las herramientas habituales incluyen pruebas de seguridad estática de aplicaciones, análisis de composición de software, detección de secretos, escaneo de contenedores, escaneo de infraestructura como código, pruebas dinámicas, pruebas de seguridad de APIs y puertas de calidad en CI/CD.
¿Es DevOps seguro lo mismo que DevSecOps?
Están estrechamente relacionados. DevSecOps es el término habitual en la industria para integrar la seguridad en el desarrollo y las operaciones. DevOps seguro se usa a menudo para describir el mismo objetivo de forma más legible: hacer que las prácticas de DevOps sean seguras por diseño.
¿Cómo afecta la IA a DevOps seguro?
La IA puede ayudar a los desarrolladores a escribir código, generar pruebas, revisar problemas y resumir hallazgos de seguridad. Sin embargo, la IA también introduce riesgos como código generado inseguro, exposición de datos y gobernanza débil. La revisión humana sigue siendo esencial.
¿Cuál es el mejor primer paso para mejorar la seguridad DevOps?
El mejor primer paso es identificar dónde entran actualmente los problemas de seguridad en el ciclo de vida del software. Después, los equipos pueden priorizar la formación por roles, las verificaciones de seguridad en CI/CD y la responsabilidad de seguridad para las áreas de mayor riesgo.
