SecDevOps vs DevSecOps: el camino hacia la transformación

¿Cómo podemos cambiar la forma en que abordamos la seguridad del software y limitar las vulnerabilidades? Hacer de la seguridad una parte integral de nuestro desarrollo de software desde el inicio de nuestros proyectos es una buena forma de empezar. Descubra cómo SecDevOps y DevSecOps se interrelacionan para respaldar la seguridad del software.

¿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 y DevSecOps comparan dos cosas radicalmente diferentes. ¿Por qué? Porque el orden de las palabras es importante. En la mayoría de los casos, la seguridad 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:

Dado que el conocimiento en seguridad suele ser escaso y limitado a unas pocas personas en una organización, estas suelen agruparse en un equipo de seguridad centralizado. El equipo de seguridad se encarga de probar el producto utilizando su ingenio para encontrar vulnerabilidades en la versión candidata antes de su implementación. Cuando, inevitablemente, el equipo encuentra una vulnerabilidad, comunica la mala noticia al equipo de desarrollo. Sin embargo, dado que el equipo de desarrollo carece de la formación en seguridad ni de los conocimientos necesarios para usar las herramientas que utiliza el equipo de seguridad, este suele ser visto como un "malo" porque está retrasando la versión 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 implementar correcciones de seguridad, controles y estándares de codificación importantes en un proyecto que el equipo de desarrollo considera "terminado y resuelto". ¿Y qué ocurre? El producto sale al mercado con vulnerabilidades de seguridad conocidas y desconocidas, con la posible promesa de "solucionarlas o cambiarlas en la próxima versión". Esto es lo que se obtiene al priorizar la seguridad después del desarrollo: "Desarrollo", "Seguridad" y "Operaciones". Si bien esta no es la intención, es la realidad en muchas organizaciones. Considere un enfoque más adecuado, como 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 logra incluyendo la seguridad desde el principio: "Seguridad", luego "Desarrollo" y luego "Operaciones". El equipo de seguridad (o quizás un arquitecto o desarrollador sénior especializado en seguridad) define las políticas necesarias con antelación.

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 "¿El proyecto está mejorando o empeorando?" o "¿Qué áreas del código están causando la mayor cantidad de 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.