Adopción de imperativos de planeamiento de desarrollo seguro

En este artículo se definen los imperativos clave para integrar la seguridad en las prácticas de desarrollo como parte de la materia de seguridad de desarrollo.

Las organizaciones modernas dependen del desarrollo rápido de software para ofrecer innovación, satisfacer los requisitos empresariales, mantener una ventaja competitiva y responder a las necesidades empresariales cambiantes. Aunque DevOps permite esta agilidad, también presenta nuevos riesgos de seguridad a medida que los procesos de código, infraestructura e implementación evolucionan más rápidamente.

Para adoptar de forma segura las prácticas de DevOps, las organizaciones deben integrar la seguridad en los procesos de estrategia de desarrollo, flujos de trabajo y entrega, y adoptar prácticas de DevSecOps que protejan la entrega de aplicaciones en todo el ciclo de vida.

Resultados

La adopción de los imperativos de planificación en este artículo permite a las organizaciones:

• Reduzca la incorporación de vulnerabilidades de seguridad en las cargas de trabajo en producción.
• Mejore la coherencia de las decisiones de preparación de producción.
• Reduzca la fricción entre el desarrollo, la seguridad y las operaciones.
• Mejorar la resistencia de las aplicaciones y la infraestructura de entrega.
• Mantener la velocidad de innovación al administrar la seguridad y el riesgo operativo.

Reconocimiento del ámbito de la seguridad de desarrollo

La seguridad de desarrollo se aplica a más que el código de aplicación. Las organizaciones deben definir los requisitos de seguridad y las actividades en todos los componentes implicados en el diseño, la creación, la implementación y las cargas de trabajo operativas.

Las organizaciones deben tener en cuenta los riesgos de seguridad en:

• Lógica de aplicaciones y servicios
• Implementaciones de automatización de la infraestructura o infraestructura como código (IaC)
• Canalizaciones de compilación y versión
• Configuraciones de despliegue y secuencias de comandos de operaciones
• Entornos de desarrollador e identidades de servicio
• Dependencias de terceros y componentes de la cadena de suministro

Reconocer este ámbito completo ayuda a las organizaciones a definir los requisitos de seguridad que reflejan cómo se entregan las cargas de trabajo modernas, en lugar de limitar la seguridad a la revisión del código de la aplicación al final del ciclo de vida.

Tener en cuenta los riesgos clave

Las organizaciones deben incluir explícitamente los siguientes riesgos al definir los requisitos:

Estos riesgos informan directamente a los imperativos de planificación definidos en este artículo y deben abordarse mediante decisiones de diseño, proceso y gobernanza.

Estos riesgos afectan tanto a las cargas de trabajo de la aplicación como a la infraestructura que se usa para compilarlas y operarlas.

Integración de la seguridad en la estrategia y el ciclo de vida

La seguridad debe incorporarse a la estrategia de desarrollo, no aplicarse como control posterior a la versión.

Las organizaciones deben definir los requisitos de seguridad junto con los requisitos funcionales y alinearlos con:

• Estrategia de desarrollo
• Planificación de la arquitectura
• Flujos de trabajo de entrega
• Modelos de soporte técnico operativo

Los resultados de seguridad son responsabilidades compartidas que recaen en las funciones de ingeniería y operaciones, con el apoyo de especialistas en seguridad.

La seguridad impulsa la innovación; no es un control que se aplica tras la entrega.

Las organizaciones deben adoptar un enfoque de ciclo de vida de desarrollo seguro (SDL) continuo que incluya:

• Definir los requisitos de seguridad al principio del diseño.
• Alineación de los requisitos de seguridad con la arquitectura y la implementación.
• Integración de la seguridad con la automatización de la infraestructura.
• Realización de la validación continua de seguridad.
• Seguimiento de los resultados de seguridad.
• Priorización de la corrección.
• Aplicar los hallazgos de seguridad a las decisiones sobre la idoneidad para la publicación, de modo que los problemas de seguridad se traten como motivos de bloqueo para producción cuando sea necesario.

La seguridad debe evaluarse y mejorarse continuamente a medida que evolucionan las arquitecturas de aplicaciones, los riesgos y los modelos de entrega.

Definición de criterios mínimos de viabilidad de producción

Las cargas de trabajo deben cumplir los criterios mínimos de viabilidad antes de su puesta en producción. Estos criterios definen si una carga de trabajo está segura, compatible y operativamente lista para su uso en producción en tres dimensiones:

• Desarrollo (dev): las partes interesadas del desarrollo definen los requisitos funcionales mínimos necesarios para satisfacer las necesidades empresariales y el valor para el cliente/usuario.
• Seguridad (sec): las partes interesadas en materia de seguridad definen los requisitos mínimos necesarios para cumplir las obligaciones normativas, mantener la postura de seguridad de la organización y respaldar la detección y la respuesta ante las amenazas activas.
• Operaciones (ops): Las partes interesadas del área de operaciones definen los requisitos mínimos de rendimiento, calidad y capacidad de soporte necesarios para que la carga de trabajo funcione de forma fiable en entornos de producción.

Criterios de viabilidad de producción:

• Asegúrese de que las cargas de trabajo son seguras para implementar y operar en entornos de producción.
• Servir como elementos de entrada para las decisiones de lanzamiento y deben aplicarse de forma coherente en todos los flujos de trabajo de desarrollo.

Los criterios de viabilidad de producción evolucionan en función de los cambios en:

• Modelos de entrega de aplicaciones.
• Condiciones de amenaza.
• Tolerancia al riesgo de la organización.
• Requisitos de cumplimiento.

Integración de la seguridad en flujos de trabajo de desarrollo

La seguridad debe insertarse directamente en los procesos de desarrollo y entrega. Las organizaciones deben:

• Defina los requisitos de seguridad dentro de los flujos de trabajo de desarrollo.
• Integre las actividades de seguridad en:
  • Procesos de diseño
  • Canalizaciones de compilación
  • Flujos de trabajo de implementación (CI/CD)
• Implemente mecanismos de validación de seguridad como:
  • Análisis de código
  • Validación de dependencias
  • Comprobaciones de configuración

Los resultados de seguridad deben tratarse iguales que los defectos de producción e incorporarse a las decisiones de liberación.

La validación de seguridad debe producirse continuamente a través de la entrega, no solo en los puntos de control de versión.

Equilibrio y armonización de los requisitos

Las organizaciones deben definir cómo se equilibran los requisitos operativos, de desarrollo, seguridad y entrega de software. Las cargas de trabajo de producción deben cumplir los requisitos en:

• Funcionalidad empresarial.
• Resistencia de seguridad.
• Velocidad de innovación.
• Confiabilidad y rendimiento operativos.

Las organizaciones deben definir objetivos de entrega compartidos y métricas de rendimiento que:

• Alinee con los objetivos de rendimiento y entrega compartidos en el desarrollo, la seguridad y las operaciones.
• Evite la dominación por un solo dominio.
• Priorice los resultados en función de:
  • Tolerancia al riesgo de la organización.
  • Obligaciones normativas.
  • Responsabilidad empresarial.

El equilibrio debe adaptarse a medida que evolucionan las condiciones de amenaza, cambian los modelos de entrega y cambian las prioridades organizativas.

Establecimiento de responsabilidad compartida

DevSecOps efectivo requiere la propiedad compartida entre los equipos de desarrollo, seguridad y operaciones con vistas a:

• Alinear la propiedad de los criterios de viabilidad de producción.
• Alinear los objetivos de entrega entre disciplinas.
• Reducir los silos y la fricción perjudicial que genera brechas de seguridad, retrasos en la entrega e inestabilidad operativa.

Aplicación de barreras de seguridad controladas por directivas

Las barreras de protección controladas por directivas deben aplicar controles sin introducir fricción excesiva. Las salvaguardas deben incluir:

• Requisitos de identidad y acceso.
• Estándares de configuración y cumplimiento.
• Controles de despliegue y lanzamiento.

Las barandillas de protección deben ser:

• Integrado en bases de plataformas (por ejemplo, zonas de aterrizaje).
• Incrustado en flujos de trabajo de desarrollo e implementación.
• Se aplica automáticamente cuando sea posible.

Este enfoque garantiza que los requisitos de seguridad se apliquen de forma coherente al tiempo que se mantiene la velocidad de entrega.

Para un enfoque equilibrado entre la seguridad y la velocidad de la innovación, evalúe la adopción mediante límites de protección basados en directivas.

Mantener y mejorar

La seguridad no sigue siendo eficaz como un conjunto estático de controles y debe evolucionar con el tiempo.

Las organizaciones deben evaluar y actualizar continuamente las prácticas de seguridad de desarrollo en respuesta a los cambios en:

• Condiciones de amenaza y comportamiento del atacante.
• Arquitecturas de aplicaciones y modelos de entrega.
• Obligaciones normativas.
• Tolerancia al riesgo de la organización.
• Criterios de viabilidad de producción.
• Procesos de entrega del desarrollo.
• Prácticas de gobernanza de seguridad.

Las prácticas de seguridad deben evolucionar junto con los sistemas que protegen.

Técnicas de alineación

Los equipos deben alinearse con lo siguiente:

• Definir objetivos comunes: los líderes de desarrollo, seguridad y operaciones deben definir de forma colaborativa los objetivos de entrega y las métricas de rendimiento para la entrega de cargas de trabajo, con el fin de admitir un planeamiento de versiones coherente.
• Evitar la dominación de decisión de dominio único: las decisiones de entrega deben tener en cuenta los requisitos operativos, de seguridad y desarrollo para evitar desequilibrios que podrían afectar negativamente a la confiabilidad, el cumplimiento o la funcionalidad empresarial de las cargas de trabajo.
• Priorice la mejora continua sobre los criterios de versión estáticos: las prácticas de seguridad de desarrollo deben refinarse de forma iterativa a lo largo del tiempo a medida que evolucionan los modelos de entrega de aplicaciones, las condiciones de amenaza y las prioridades organizativas.
• Establecer el contexto de entrega compartido entre los roles de las partes interesadas: los equipos de desarrollo, seguridad y operaciones deben mantener una comprensión compartida de:
  • Urgencia empresarial y plazos de entrega
  • Condiciones de amenazas relevantes y exposición a riesgos
  • Requisitos de disponibilidad operativa y compatibilidad
• Supervisar la fricción de entrega introducida por los requisitos de seguridad: los requisitos de seguridad pueden introducir fricción de entrega. Los líderes deben evaluar si esta fricción contribuye a la reducción de riesgos (por ejemplo, habilitando la identificación anterior de vulnerabilidades) o retrasa innecesariamente la entrega de cargas de trabajo sin mejorar materialmente la resistencia de producción.
• Incorporar la seguridad de desarrollo en la planeación y asignación de recursos: los requisitos de seguridad para las cargas de trabajo de aplicaciones deben incorporarse al planeamiento del desarrollo y la asignación de recursos junto con los requisitos de compatibilidad operativa y funcionalidad.
• Definir objetivos de rendimiento de entrega compartida: las métricas de rendimiento y éxito de las cargas de trabajo de aplicaciones deben reflejar los resultados de desarrollo, seguridad y entrega operativa.

Alineación de flujos de trabajo con requisitos de seguridad

La seguridad debe estar operativa a través de flujos de trabajo de desarrollo. Las organizaciones deben definir y alinear flujos de trabajo para:

• Actividades de diseño arquitectónico.
• Procesos de compilación e implementación.
• Flujos de trabajo de seguimiento y corrección de problemas.

Los hallazgos de seguridad deben ser:

• Priorizado y rastreado.
• Gestionado junto con los defectos de producción.
• Se incorpora a las decisiones de preparación de la versión.

La alineación del flujo de trabajo garantiza que los requisitos de seguridad se aplican de forma coherente a lo largo de la entrega.

Pasos siguientes

Más información sobre el desarrollo basado en los principios de Confianza cero