Pase de DevOps a DevSecOps

A medida que crea o moderniza una materia de seguridad de desarrollo, en este artículo se describe cómo la integración de la seguridad en las prácticas de desarrollo permite el cambio de las operaciones de desarrollador (DevOps) a las operaciones de seguridad para desarrolladores (DevSecOps) y ayuda a proteger la entrega de aplicaciones.

Las organizaciones modernas dependen del desarrollo rápido de software para ofrecer innovación, responder a los requisitos empresariales cambiantes y mantener una ventaja competitiva. DevOps permite esta agilidad a través de la integración y entrega continuas. Sin embargo, la mayor velocidad también introduce nuevos riesgos de seguridad.

Los ciclos de versión continua reducen el tiempo entre las decisiones de diseño y la implementación de producción, lo que aumenta la probabilidad de que se introduzcan puntos débiles en entornos de producción, entre los que se incluyen:

• Puntos débiles del diseño de aplicaciones
• Dependencias vulnerables
• Errores de configuración
• Errores de automatización de la infraestructura
• Mala administración de secretos o higiene.

Riesgo de DevOps

Los entornos modernos de DevOps amplían la superficie expuesta a ataques en los sistemas de desarrollo, canalización y producción. Las herramientas de DevOps, como los repositorios de código fuente, las canalizaciones y los sistemas de automatización, son destinos de alto valor para los atacantes.

Si el código malintencionado se introduce al principio, puede pasar por las comprobaciones de seguridad existentes y llegar a los sistemas de producción.

Entre los objetivos de ataque comunes se incluyen:

• Insertar código malintencionado en artefactos de compilación.
• Poner en peligro las identidades de desarrollador o las cuentas de servicio.
• Acceso o filtración de datos de producción.

A menudo, los atacantes tienen como destino aplicaciones personalizadas y entornos de desarrollo para obtener acceso a:

• Datos confidenciales de la organización o del cliente.
• Lógica empresarial propietaria y propiedad intelectual.
• Infraestructura de producción a través de sistemas de desarrollo comprometidos.
• Clientes aguas abajo mediante la vulneración de la cadena de suministro de software.

Los posibles riesgos de seguridad se resumen en el diagrama siguiente:

Riesgo de aplicación y desarrollo

Las cargas de trabajo de las aplicaciones pueden verse comprometidas debido a vulnerabilidades introducidas durante el desarrollo o por el compromiso de la infraestructura utilizada para compilarlas y desplegarlas.

Riesgo	Target	Resultado potencial
Diseño o implementación de aplicaciones	Los problemas de seguridad introducidos durante el diseño o el desarrollo pueden exponer cargas de trabajo a técnicas de ataque como: - Validación de entrada incorrecta - Lógica de autenticación o autorización no segura - Criptografía débil o implementada incorrectamente - Exposición de datos confidenciales a través de la lógica de la aplicación	Estas debilidades podrían permitir a los atacantes: - Acceso o manipulación de datos de la aplicación - Ejecutar operaciones no autorizadas - Mantener el acceso persistente a través de defectos lógicos implantados.
Infraestructura de desarrollo/automatización	Los ataques pueden tener como destino: - Repositorios de código fuente - Canalizaciones de compilación - Automatización de la implementación - Plantillas de infraestructura como código (IaC) - Desarrollo de puntos de conexión o identidades de servicio	La vulneración podría permitir a los atacantes: - Insertar código malintencionado en artefactos de compilación - Modificar configuraciones de implementación - Mantener el acceso persistente a través de un fallo lógico implantado - Obtener credenciales o secretos usados en entornos de producción.
Cadena de suministro de software de desarrollo	Las aplicaciones se basan normalmente en: - Bibliotecas de terceros - Paquetes de código abierto - Imágenes de contenedor - Servicios de plataforma	Las vulnerabilidades o el código malintencionado introducido a través de estas dependencias pueden afectar a: - Cargas de trabajo de producción organizativas - Entornos de cliente o asociados

La integración de la seguridad en los procesos de desarrollo reduce la probabilidad de que estos riesgos se propaguen a la versión de producción.

Desplazamiento a la izquierda

Shift left es un enfoque de ingeniería de seguridad que integra la seguridad en una fase más temprana del ciclo de vida del desarrollo.

En lugar de validar la seguridad en tiempo de ejecución, las organizaciones la insertan en:

• Previendo
• Design
• Desarrollo
• Operations

Esto reduce el costo de corrección y la exposición al riesgo.

Para apoyar este enfoque, las organizaciones deberían"

• Use procedimientos recomendados estructurados, como el ciclo de vida de desarrollo de seguridad (SDL) al principio del proceso, en lugar de tarde cuando los problemas sean costosos y difíciles de corregir.
• Para mantener este enfoque, integre la gobernanza, el riesgo y el cumplimiento (GRC) en la estrategia de desarrollo.

¿Qué es DevSecOps?

DevSecOps ofrece el enfoque de desplazamiento a la izquierda al extender DevOps e insertar la seguridad en cada fase del ciclo de vida de desarrollo de software, desde el inicio de la idea hasta el diseño, el desarrollo y las operaciones.

• En los enfoques de desarrollo tradicionales, la validación de seguridad a menudo se realizó como una puerta de calidad final antes de la versión. Esto ha creado retrasos, un mayor costo de corrección y permite que las vulnerabilidades persistan hasta finales del ciclo de vida.

• DevSecOps integra la seguridad desde fases más tempranas y la incorpora de forma continua en los procesos de desarrollo y operaciones.

• DevSecOps reduce la fricción entre los equipos de desarrollo, operaciones y seguridad, alineándolos en torno a objetivos compartidos de velocidad de innovación, confiabilidad y resistencia de seguridad, y permite a los equipos abordar los problemas más importantes de forma temprana y continua.

• DevSecOps integra la seguridad en:

  • Diseño arquitectónico
  • Implementación de la aplicación
  • Automatización de la infraestructura
  • Implementación y procesos operativos

Benefits

DevSecOps permite a los equipos de desarrollo, seguridad y operaciones:

• Identifique y corrija problemas anteriormente en el ciclo de vida.
• Reduzca la exposición en producción.
• Mantener la velocidad de entrega al administrar el riesgo.

La seguridad se convierte en parte de cómo se compila y entrega software, en lugar de un control aplicado después de la entrega.

Ciclo de vida de innovación segura

Normalmente, la innovación avanza a través de dos fases de ciclo de vida:

Fase	Detalles
Incubación de ideas	Una funcionalidad está diseñada, implementada y validada para el uso inicial de producción. Comienza con una nueva idea
Versión inicial	Una primera versión de producción cumple los criterios mínimos de producto para uso seguro del producto. - Desarrollo: la funcionalidad cumple los requisitos empresariales mínimos. - Seguridad: las funcionalidades cumplen los requisitos de cumplimiento normativo, seguridad y seguridad para su uso en producción. - Operaciones: La funcionalidad cumple los requisitos mínimos de calidad, rendimiento y compatibilidad para ser un sistema de producción.

Después de la versión inicial, el desarrollo se convierte en iterativo a medida que las cargas de trabajo evolucionan con:

• Cambio de la tolerancia al riesgo
• Requisitos y madurez de la aplicación
• Obligaciones normativas
• Condiciones de amenaza

Integración de la seguridad en el desarrollo

Los enfoques de desarrollo tradicionales validan la seguridad en una fase tardía del ciclo de vida, como control final antes del lanzamiento, una vez completados el diseño y la implementación. En entornos de desarrollo modernos, el retraso de la validación aumenta:

• Complejidad de la vulnerabilidad
• Costo de corrección
• Retrasos operativos e interrupciones
• Mayor exposición de riesgos a la explotación activa

DevSecOps integra la seguridad continuamente a lo largo del desarrollo y las operaciones, para solucionar problemas anteriores, reducir el riesgo y mejorar la coherencia.

Procedimientos clave

La seguridad debe insertarse en los procesos de desarrollo existentes para ser eficaces, escalables y sostenibles. Debe integrarse directamente en cómo se diseñan, compilan, implementan y operan las aplicaciones, no se implementan en un flujo de trabajo independiente o paralelo. Es recomendable que:

• Mapeo de flujos de trabajo de extremo a extremo, desde la idea hasta el desarrollo, la implementación y las operaciones continuas.
• Definir roles, herramientas y responsabilidades claros para la seguridad en cada fase del ciclo de vida.
• Establecimiento de rutas de corrección coherentes para vulnerabilidades, defectos y problemas de diseño.

Adapte las prácticas de seguridad en función del riesgo de la carga de trabajo. Las aplicaciones críticas para la empresa requieren un mayor rigor, mientras que los escenarios de menor riesgo pueden seguir enfoques simplificados.

Como mínimo, asegúrese de que:

• Identifique las fases, las personas y las tecnologías implicadas en el ciclo de vida de desarrollo.
• Defina cómo se integran las actividades de seguridad en cada fase, en lugar de tratarlas como puntos de control independientes.
• Establezca procesos para controlar los cambios principales y las correcciones rutinarias a lo largo del ciclo de vida.

Automatización de la seguridad en el desarrollo y la implementación

La automatización es esencial para aplicar la seguridad de forma coherente y a escala en el desarrollo y las operaciones.

• Integrar controles de seguridad y herramientas directamente en los canales de CI/CD.
• Automatice actividades clave, como el modelado de amenazas, el examen de código, la validación y la aplicación de directivas.
• Use infraestructura como código (IaC) para habilitar implementaciones repetibles y seguras.

Los fundamentos de la plataforma, como las zonas de aterrizaje de Azure, pueden respaldar este enfoque mediante

Las bases de la plataforma, como Azure zonas de aterrizaje pueden admitir este enfoque proporcionando patrones estandarizados para la seguridad, la gobernanza y la integración de DevOps.

Resultados esperados

Las organizaciones que cambian de DevOps a DevSecOps pueden:

• Reducir la probabilidad de que se introduzcan vulnerabilidades en cargas de trabajo de producción
• Limitar la capacidad de los atacantes de aprovechar la infraestructura de desarrollo o la automatización
• Mejora de la resistencia de las aplicaciones a técnicas de ataque en evolución
• Compatibilidad con los requisitos de cumplimiento normativo y organizativo
• Mantener la velocidad de innovación sin aumentar el riesgo operativo o de seguridad

Sugerencias para navegar por el recorrido

La adopción de DevSecOps requiere cambios organizativos y culturales.

Cambios en la educación y la cultura

Estos son los primeros pasos críticos. El equipo que tiene debe desarrollar nuevas aptitudes y adoptar nuevas perspectivas para comprender el modelo de DevSecOps.

El cambio en la educación y la cultura tarda tiempo, enfoque, patrocinio ejecutivo y seguimiento regular para ayudar a las personas a comprender completamente y ver el valor del cambio.

El cambio de culturas y habilidades a veces puede aprovechar drásticamente la identidad profesional de las personas, creando potencial para una fuerte resistencia. Es fundamental comprender y expresar el por qué, qué y cómo del cambio para cada individuo y su situación.

El cambio tarda tiempo

Solo puede avanzar tan rápido como su equipo pueda adaptarse a las implicaciones de hacer las cosas de nuevas formas. Los equipos deben realizar sus trabajos existentes mientras se transforman.

Es fundamental priorizar cuidadosamente lo que es más importante y administrar las expectativas de la rapidez con que puede producirse este cambio.

Centrarse en una estrategia gradual, en la que los elementos más importantes y fundamentales se abordan primero, resulta beneficioso para su organización.

El cambio introduce (temporal) fricción

Todas las nuevas tecnologías, metodologías y otros cambios introducen fricción y confusión. Es fundamental centrarse en una fricción correcta que impulsa el pensamiento crítico para reducir el riesgo, a la vez que evita la fricción incorrecta que ralentiza los procesos con beneficios limitados o reducción de riesgos.

Recursos limitados

Un desafío al que normalmente se enfrentan las organizaciones es encontrar talento y aptitudes en el desarrollo de aplicaciones y seguridad.

A medida que las organizaciones comienzan a colaborar de forma más eficaz, pueden descubrir talento oculto, como desarrolladores con una mentalidad orientada a la seguridad o profesionales de la seguridad con experiencia en desarrollo.

Turnos en curso

Las aplicaciones cambian rápidamente. Además de las nuevas características, la definición técnica y la composición de una aplicación está cambiando fundamentalmente con la introducción de tecnologías como la nube, sin servidor y la inteligencia artificial.

Este cambio está cambiando las prácticas de desarrollo, la seguridad de las aplicaciones e incluso permite a los no desarrolladores crear aplicaciones.

Considerar un modelo de SRE

Algunas implementaciones de DevSecOps combinan las operaciones y las responsabilidades de seguridad en un rol de ingeniero de confiabilidad de sitios (SRE).

Aunque este modelo puede funcionar, a menudo es un cambio extremo de las prácticas y la cultura empresarial existentes.

Si está considerando un modelo de SRE, le recomendamos que empiece por insertar la seguridad en DevOps con resultados rápidos prácticos y progreso incremental descrito en esta guía para asegurarse de obtener una buena rentabilidad de la inversión (ROI) y satisfacer las necesidades inmediatas.

Esto agrega incrementalmente responsabilidades de seguridad al personal de operaciones y desarrollo, lo que mueve a los equipos más cerca de un estado final de SRE.

Pasos siguientes

Obtenga información sobre los procedimientos recomendados de desarrollo seguro.