SecDevOps vs DevSecOps: el camino hacia la transformación

¿Qué es SecDevOps?

SecDevOps frente a DevSecOps. Puede parecer semántico, pero el orden de las palabras tiene todo el peso. ¿Cómo cambiamos culturalmente la forma en que abordamos la seguridad? Empezamos por tratarlo con la gravedad que se merece y comenzamos a incorporarlo desde el principio.

No hay duda de que DevOps y la seguridad son una prioridad para las organizaciones de TI empresariales y de software, y el resultado de la integración de la seguridad en DevOps ha sido la introducción de los términos SecDevOps y DevSecOps. El resultado de integrar la seguridad en DevOps se ha acuñado como SecDevOps y DevSecOps.

Aunque se usan indistintamente, SecDevOps vs DevSecOps compara dos cosas radicalmente diferentes. ¿Por qué? Porque el orden de las palabras es importante. En la mayoría de los casos, la seguridad todavía se “añade” al final del proceso de implementación.

En esta publicación, discutiré por qué la distinción entre DevSecOps vs SecDevOps es crucial para la seguridad de sus aplicaciones. También abordaré cómo es más fácil entregar software seguro cuando la seguridad es una parte integral del desarrollo, desde el inicio del proceso de desarrollo de software y no como una puerta al final del proceso de entrega.

Cómo se ve la seguridad en DevSecOps

A pesar del mayor enfoque en la seguridad, es un desafío para los equipos de software incorporar la seguridad en un proceso y canalización. La presión para completar los proyectos a tiempo y dentro de los presupuestos a menudo anula otras consideraciones. Como resultado, la integración de seguridad tiende a verse como el último paso de activación para un candidato de lanzamiento, como se ilustra a continuación:

Como los conocimientos sobre seguridad suelen ser escasos y limitados a unas pocas personas de una organización, estas personas suelen agruparse en un equipo de seguridad centralizado. El equipo de seguridad tiene la tarea de probar el producto utilizando su "caja mágica de trucos" para encontrar vulnerabilidades en la versión candidata antes de su implementación. Cuando el equipo, inevitablemente, encuentra una vulnerabilidad, le transmiten las "malas noticias" al equipo de desarrollo. Sin embargo, debido a que el equipo de desarrollo no tiene la capacitación en seguridad ni el conocimiento sobre cómo usar las herramientas que el equipo de seguridad está usando, el equipo de seguridad a menudo es visto como "malos" porque ahora están retrasando el lanzamiento debido a " algunas vulnerabilidades de seguridad”. Entonces, ¿cuál es la reacción típica del equipo?

El enfoque tradicional provoca retrasos en el lanzamiento y/o vulnerabilidades de seguridad en producción.

Seamos realistas, es difícil incorporar importantes correcciones de seguridad, controles y estándares de codificación en un proyecto que está "hecho y desempolvado" en lo que respecta al equipo de desarrollo. ¿Así que lo que ocurre? El producto sale por la puerta con vulnerabilidades de seguridad conocidas y desconocidas con posiblemente alguna promesa de "arreglarlas o cambiarlas en la próxima versión". Esto es lo que obtienes cuando pones seguridad después del desarrollo: "Desarrollo", luego "Sec" y luego "Operaciones". Si bien esta no es la intención, esta es la realidad en muchas organizaciones. Considere un mejor enfoque que se describe a continuación.

Qué aspecto tiene la seguridad con SecDevOps

Los controles de seguridad, las directrices, los estándares de codificación y las mejores prácticas deben integrarse completamente en el proceso de desarrollo de software. Esto se hace incluyendo la seguridad desde el principio: "Sec", luego "Dev" y luego "Ops". El equipo de seguridad (o quizás un arquitecto o desarrollador senior especializado en seguridad) define las políticas necesarias por adelantado para el equipo.

Estas políticas pueden consistir en estándares de codificación segura, reglas para evitar API inseguras y cifrado deficiente, instrucciones de uso análisis estático y dinámicoy pautas de prueba. El objetivo es que los desarrolladores trabajen para lograr un software más seguro como parte de su rutina diaria y la automatización ayuda a que esto sea una realidad.

Con la automatización, puede cambiar a la izquierda su enfoque de seguridad para adoptar una estrategia SecDevOps similar a esta:

Como la seguridad ahora está incorporada al inicio del desarrollo, el equipo naturalmente se volverá más competente en seguridad y se encontrarán menos vulnerabilidades de seguridad al final del proceso.

Las vulnerabilidades que lo logran se pueden investigar y los resultados del análisis de la causa raíz se pueden usar para mejorar las políticas y pautas de seguridad, esencialmente mejorando el resultado a medida que avanza cada ciclo.

Impulsar mejoras iterativas en la política da como resultado escaladas de último ciclo menos disruptivas, y se ve así:

Cuando compara SecDevOps vs DevSecOps, el enfoque incremental e integrado del primero funciona mucho mejor que intentar abordar una auditoría de seguridad al final del proyecto.

¿Cómo transformar DevSecOps en SecDevOps?

No hay forma de evitar el hecho de que la seguridad agrega un requisito adicional para los desarrolladores, pero la forma en que administra el impacto de este trabajo es lo que marca la diferencia entre un puntual, seguro producto, y un tarde, inseguro uno. Un requisito fundamental es integrar la seguridad en el proceso de desarrollo existente, lo que puede hacer integrando el conjunto de herramientas de prueba compatibles con CWE de Parasoft para que la seguridad forme parte de la calidad y del flujo de trabajo general de las operaciones.

Haga que la seguridad sea parte de la calidad con un flujo de trabajo centrado en la seguridad

El flujo de trabajo comienza con la política de codificación segura. El arquitecto o líder crea una configuración (posiblemente basada en pautas de codificación como CERT, CWE, OWASP, UL-2900 o PCI DSS) para que el resto del equipo la aproveche directamente dentro de su IDE. Esto le da al desarrollador la capacidad de verificar el código localmente en su máquina antes de comprometerse con el control de fuente, detectando y corrigiendo violaciones de seguridad donde y cuando sea más barato y más fácil hacerlo.

Luego, el análisis ejecutado como parte del proceso de compilación aprovecha la misma configuración. Este análisis integral va más allá del alcance del código modificado localmente por el desarrollador y proporciona una red de seguridad para bloquear el proceso de entrega y garantizar que el código inseguro no se promueva a etapas posteriores.

Por último, los resultados del análisis se envían de vuelta al IDE del desarrollador a través del panel centralizado de informes y análisis, donde se puede realizar un seguimiento del progreso, realizar correcciones en el rumbo y generar informes de auditoría en tiempo real.

El flujo de trabajo completo de SecDevOps se ve así:

Los gerentes y líderes de seguridad ahora pueden evaluar proyectos basándose en estándares de seguridad como CWE, en el tablero central como se muestra a continuación:

Estos paneles permiten un monitoreo integral y pueden mostrar información de tendencias para ayudar a responder preguntas, como "¿Está mejorando o empeorando el proyecto?" o "¿Qué áreas del código están causando más problemas?"

Ser capaz de responder estas y otras preguntas y tomar medidas transforma al equipo de desarrollo de DevSecOps a SecDevOps.

DevSecOps vs SecDevOps: priorizar la seguridad en el desarrollo

A pesar del uso intercambiable de DevSecOps y SecDevOps, el orden de las palabras es tan importante como las implicaciones de las herramientas, técnicas y procesos que implica la palabra. La seguridad a menudo se deja como un complemento o un proceso de activación antes de lanzar un producto, pero es difícil solucionar los problemas de seguridad cuando un producto está a medio camino de salir al mercado.

Desplazar la seguridad hacia la izquierda, como en SecDevOps, es la clave del éxito. La seguridad debe ser parte del flujo de trabajo diario de cada desarrollador e integrarse en el proceso de software. Los controles y políticas de seguridad automatizados de Parasoft incorporan seguridad en la tubería al tiempo que reducen el impacto y el riesgo de SecDevOps o DevSecOps.