Tiempo de leer: 5 minutosNo 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 usa indistintamente, SecDevOps vs DevSecOps en realidad está comparando 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 está “agregando” al final del proceso de implementación.
En esta publicación, discutiré por qué la distinción entre DevSecOps y SecDevOps es crucial para la seguridad de sus aplicaciones. También hablaré sobre cómo la entrega de software seguro es más fácil de lograr cuando la seguridad es una parte integral del desarrollo, desde el inicio del proceso de desarrollo de software en lugar de como una puerta al final del proceso de entrega.
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 el conocimiento de seguridad suele ser escaso y se limita a unas pocas personas en una organización, estas personas a menudo se agrupan 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 el candidato de lanzamiento antes de la implementación. Cuando el equipo, inevitablemente, encuentra una vulnerabilidad, le pasa la "mala noticia" al equipo de desarrollo ... pero, porque el equipo de desarrollo no tiene la capacitación en seguridad o el conocimiento sobre cómo usar las herramientas que el equipo de seguridad está usando. , el equipo de seguridad a menudo se ve como "chicos 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 conduce a un lanzamiento retrasado y / o vulnerabilidades de seguridad en la 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.
Los controles de seguridad, las pautas, los estándares de codificación y las mejores prácticas deben integrarse completamente en el proceso de desarrollo de software. Esto se hace al incluir la seguridad desde el principio: "Sec", luego "Dev" y luego "Ops". El equipo de seguridad (o quizás una arquitectura o un 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 para usar análisis estáticos y dinámicos y pautas de prueba. El objetivo es que los desarrolladores trabajen hacia 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 una estrategia deSecDevOps que se parece a esto:
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 ciclo tardío menos disruptivas y tiene este aspecto:
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.
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.
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 arreglando violaciones de seguridad donde y cuando sea más barato y fácil hacerlo.
Luego, la misma configuración se aprovecha mediante el análisis ejecutado como parte del proceso de construcció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 controlar 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 del curso y generar informes de auditoría en tiempo real.
El flujo de trabajo completo de SecDevOps se ve así:
Los gerentes y los líderes de seguridad ahora pueden evaluar proyectos basados 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.
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 mitad de camino. Cambiar la seguridad hacia la izquierda, como en SecDevOps, es la clave del éxito. La seguridad debe formar parte del flujo de trabajo diario de cada desarrollador e integrarse en la canalización del software. Las políticas y los controles de seguridad automatizados de Parasoft integran la seguridad en el proceso al tiempo que reducen el impacto y el riesgo de SecDevOps o DevSecOps.
Mark, vicepresidente de productos de Parasoft, es responsable de garantizar que las soluciones de Parasoft brinden un valor real a las organizaciones que las adoptan. Mark ha estado con Parasoft desde 2004, trabajando con una amplia variedad de clientes de Global 2000, desde implementaciones de tecnología específicas hasta iniciativas de mejora de procesos SDLC más amplias.
