Descripción general de DevSecOps
Escrito por
0 minutos de lectura
¿Qué es DevSecOps?
DevSecOps consiste en integrar prácticas de seguridad en un modelo de entrega de software DevOps. Su fundamento es una cultura que, mediante procesos y herramientas, permite que los equipos de desarrollo y operaciones compartan la responsabilidad de entregar software seguro.
En un nivel de alto funcionamiento, el modelo DevSecOps consiste en integrar los objetivos de seguridad lo antes posible en el ciclo de vida del desarrollo de software. Aunque la seguridad es «responsabilidad de todos», los equipos de DevOps ocupan una posición única en la intersección entre desarrollo y operaciones, y están capacitados para aplicar la seguridad con amplitud y profundidad.
¿Cuál es la diferencia entre DevOps y DevSecOps?
En pocas palabras, la diferencia entre DevOps y DevSecOps está en la cultura de responsabilidad compartida. DevOps es un concepto del que se habla y se escribe desde hace más de una década, y han surgido muchas definiciones. En esencia, DevOps es un paradigma organizacional que alinea las prácticas de desarrollo y operaciones como una responsabilidad compartida.
Comparación entre DevOps y DevSecOps
Lo que comenzó como un conjunto informal de prácticas comunes compartidas por equipos de ingeniería de software de alto desempeño se convirtió en una declaración moderna de cultura y procesos de ingeniería: DevOps. Las organizaciones que comparten la responsabilidad del desarrollo y las operaciones pueden iterar más rápido y, como resultado, tener más éxito. DevSecOps amplía esa filosofía e incorpora los objetivos de seguridad a las metas generales. DevSecOps debe entenderse como la continuación natural de DevOps, no como una idea o un concepto independiente. Los equipos que aplican con éxito las prácticas de DevOps deben considerar DevSecOps un paso evolutivo, no revolucionario.
Muchos estarían de acuerdo en que el objetivo era crear un entorno donde se genere valor para el negocio al pasar del código a producción mediante un flujo fluido y sostenible. Este nuevo modelo trajo herramientas y metodologías que aceleraron el proceso y generaron un cuello de botella: las prácticas de seguridad tradicionales, con ciclos de retroalimentación lentos, obstaculizaban el ritmo acelerado de DevOps. Como resultado, muchas veces las prácticas de seguridad solo se llevaban a cabo después de la puesta en producción o las aplicaban equipos externos que se incorporaban al proceso, lo que lo hacía más lento.
Para dejar más clara la diferencia entre DevOps y DevSecOps, DevSecOps amplía la cultura de responsabilidad compartida de DevOps para incluir también las prácticas de seguridad. Las actividades diseñadas para identificar y, de ser posible, resolver problemas de seguridad se incorporan al principio del ciclo de vida del desarrollo de aplicaciones, en lugar de hacerlo después del lanzamiento de un producto. Esto se logra al permitir que los equipos de desarrollo realicen muchas de las tareas de seguridad de forma independiente dentro del ciclo de vida del desarrollo de software (SDLC).
Este enfoque ayuda a minimizar las vulnerabilidades que llegan a producción y, por lo tanto, reduce el costo de corregir fallas de seguridad. Permite escalar y, al mismo tiempo, fomenta una cultura colaborativa que acerca la seguridad a los objetivos de DevOps. DevSecOps busca integrar la seguridad en cada etapa del proceso de entrega, desde la etapa de requisitos, y establecer un plan para automatizarla.
La importancia de DevSecOps
¿Por qué son importantes las prácticas de DevSecOps?
La transformación digital se ha convertido en una necesidad fundamental para casi todas las empresas. Esta transformación incluye tres grandes cambios: más software, tecnologías en la nube y metodologías DevOps.
Más software significa que una mayor parte del riesgo de la organización se vuelve digital, lo que aumenta la deuda técnica y los desafíos de seguridad de las aplicaciones, y hace cada vez más difícil proteger los activos digitales.
La nube implica usar tecnologías más recientes que introducen distintos riesgos, cambian más rápido y son más accesibles al público, lo que elimina o redefine el concepto de perímetro seguro. También significa que muchos riesgos de TI e infraestructura se trasladan a la nube, mientras que otros pasan a definirse exclusivamente por software. Esto reduce muchos riesgos, pero resalta la importancia de administrar permisos y accesos.
Por último, DevOps implica un cambio en la forma de desarrollar y entregar software: acelera el ciclo que va desde escribir código hasta ofrecer valor a los clientes, aprender del mercado y adaptarse. Los equipos de desarrollo capacitados entregan software de forma continua y más rápido que nunca, y toman decisiones autónomas sobre tecnología e implementación, sin intermediarios. Los ciclos de retroalimentación tradicionales y lentos que frenan el desarrollo ya no son aceptables, porque los equipos priorizan cada vez más la autosuficiencia: tú lo escribes, tú lo ejecutas.
A medida que el resto de la organización evoluciona, los equipos de seguridad enfrentan mayores exigencias y, a menudo, se convierten en un cuello de botella. Las herramientas y prácticas heredadas de seguridad de aplicaciones, diseñadas para la era previa a la nube, de ritmo más lento, colocan a los equipos de seguridad en el camino crítico para entregar aplicaciones de alta calidad. Como estos equipos tienen poco personal debido a la grave escasez de talento en seguridad, se convierten en un cuello de botella y no logran seguir el ritmo. Como resultado, los equipos de desarrollo entregan aplicaciones inseguras, los equipos de seguridad se agotan y la seguridad termina diciendo que no, lo que anula la aceleración que busca el negocio.
Para enfrentar estos desafíos, se empezaron a cambiar las prácticas y así nació DevSecOps. Una cultura DevSecOps incorpora la seguridad en DevOps, lo que permite a los equipos de desarrollo proteger lo que crean a su propio ritmo y fomenta una mayor colaboración entre quienes trabajan en desarrollo y seguridad. También permite que los equipos de seguridad sean un área de apoyo que ofrece experiencia y herramientas para aumentar la autonomía de los desarrolladores y, a la vez, proporcionar el nivel de supervisión que exige el negocio.
6 beneficios del modelo DevSecOps
Entrega más rápida: La integración de la seguridad en el pipeline mejora la velocidad de entrega del software. Los errores se identifican y corrigen antes de la implementación, lo que permite a los desarrolladores enfocarse en entregar funcionalidades.
Mejor postura de seguridad: La seguridad es una característica desde la fase de diseño. Un modelo de responsabilidad compartida garantiza que la seguridad esté estrechamente integrada en todo el proceso: desde la creación y la implementación hasta la protección de las cargas de trabajo en producción.
Menores costos: Identificar vulnerabilidades y errores antes de la implementación reduce exponencialmente el riesgo y los costos operativos.
Mayor valor de DevOps: Integrar prácticas de seguridad en DevOps mejora la postura de seguridad general y crea una cultura de responsabilidad compartida. El Informe de perspectivas de DevSecOps de Snyk/Puppet de 2020 confirmó esta tendencia en las organizaciones con DevSecOps maduro.
Mejor integración de la seguridad y mayor velocidad: Se reducen el costo y el tiempo de entrega de software seguro al eliminar la necesidad de adaptar los controles de seguridad después del desarrollo.
Mayor éxito general del negocio: Confiar más en la seguridad del software desarrollado y adoptar nuevas tecnologías permite aumentar los ingresos y ampliar la oferta del negocio.
Adopción de DevSecOps: integración de la seguridad en el pipeline de CI/CD
La mayoría de las organizaciones modernas de DevOps dependen de alguna combinación de sistemas de integración continua y de implementación o entrega continua, en forma de un pipeline de CI/CD. El pipeline es una excelente base para realizar distintas pruebas y validaciones de seguridad automatizadas, sin depender del trabajo manual de una persona.
Adopción de DevSecOps: integración de la seguridad en el pipeline de CI/CD
Para integrar los objetivos de seguridad al principio del desarrollo de una aplicación, empieza antes de escribir la primera línea de código. La seguridad puede integrarse y comenzar a aplicar un modelado de amenazas eficaz desde la concepción inicial del sistema, la aplicación o una historia de usuario individual. El análisis estático, los linters y los motores de políticas pueden ejecutarse cada vez que un desarrollador registra código, para asegurar que los problemas más fáciles de resolver se atiendan antes de que los cambios avancen.
El análisis de composición de software puede aplicarse de forma integral para confirmar que las dependencias de código abierto tengan licencias compatibles y estén libres de vulnerabilidades. Además, esto hace que los desarrolladores sientan que son responsables de la seguridad de sus aplicaciones, ya que reciben comentarios inmediatos sobre la seguridad relativa del código que escribieron.
Una vez que el código se registra y compila, puedes empezar a usar pruebas de integración de seguridad. Ejecutar el código en un entorno aislado dentro de un contenedor permite automatizar pruebas de llamadas de red, validación de entradas y autorización, entre otras. Estas pruebas generan comentarios rápidos, permiten iterar y clasificar los problemas detectados con agilidad y causan una interrupción mínima en el flujo general. Si se producen llamadas de red inexplicables o se usan entradas sin sanitizar, las pruebas fallan y el pipeline genera comentarios prácticos mediante informes y notificaciones a los equipos correspondientes.
Una vez que el artefacto de implementación supera la primera serie de pruebas de integración, pasa a la siguiente etapa. En esta fase, se implementa en un entorno de pruebas más amplio, una copia limitada del entorno de producción previsto. Aquí se pueden realizar más pruebas de integración de seguridad, aunque con un objetivo distinto.
Ahora se pueden probar aspectos como el registro correcto de eventos y los controles de acceso. ¿La aplicación registra correctamente las métricas de seguridad y rendimiento pertinentes? ¿El acceso está limitado al grupo correcto de personas o completamente bloqueado? Si las pruebas vuelven a fallar, se asignan tareas a los equipos correspondientes.
Por último, la aplicación llega a producción. Sin embargo, el trabajo de DevSecOps continúa con más fuerza que nunca. La aplicación automática de parches y la administración de la configuración garantizan que el entorno de producción siempre ejecute las versiones más recientes y seguras de las dependencias de software. Lo ideal es contar con una infraestructura inmutable: todo el entorno se desmantela y reconstruye con frecuencia, y se somete constantemente a la serie de pruebas a lo largo de todo el pipeline.
Usar un pipeline de CI/CD de DevSecOps ayuda a integrar objetivos de seguridad en cada fase sin agregar burocracia ni controles excesivos, y permite mantener la entrega rápida de valor para el negocio.
Fomentar una cultura DevSecOps
Entonces, ¿cómo puede una organización dar el paso evolutivo de «DevOps» a «DevSecOps»? No basta con entregarle a un equipo DevOps ya ocupado un conjunto de KPI de seguridad y dar el tema por resuelto. Se necesita una cultura colaborativa y compartida que permita iterar rápidamente.
Si el objetivo es integrar los objetivos de seguridad desde el principio, hacerlo debe ser lo más sencillo posible. La responsabilidad de integrar a los equipos y objetivos de seguridad en el flujo de valor no debe recaer en los desarrolladores. Agregar pasos solo alargará el tiempo que toma entregar funcionalidades a los clientes. El área de seguridad debe ser ágil y adoptar un enfoque práctico para aplicar la seguridad con la menor interrupción posible.
Durante la planificación, especialmente en lo relacionado con la infraestructura, los ingenieros de seguridad deben participar en las conversaciones y tener la capacidad de cuestionar las decisiones deficientes o inseguras, pero también los conocimientos para ofrecer alternativas. Muchas veces, los equipos de seguridad sobrecargados simplemente dicen «no» y dejan que los equipos de DevOps encuentren alternativas. Una vez más, esto demuestra la importancia de que las áreas de seguridad cuenten con los recursos adecuados.
Cuando los equipos de seguridad y DevOps colaboran desde el principio y con frecuencia, los objetivos de seguridad quedan profundamente integrados en la infraestructura. Las funcionalidades y aplicaciones que se implementan en producción son el resultado de una colaboración integral y eficaz entre seguridad, desarrollo y operaciones. El equipo de seguridad no tendrá que pedir funcionalidades adicionales ni auditorías a los equipos de desarrollo después del hecho; sabrá que todo esto se integró desde el primer día.
Si tu organización ha evolucionado para adoptar DevSecOps, sabes que no solo iteras rápidamente y deleitas a tus clientes con nuevas funcionalidades y mejoras, sino que también les ofreces una experiencia con un nivel de seguridad a la altura.