Descripción general de DevSecOps
Escrito por
0 minutos de lectura
¿Qué es DevSecOps?
DevSecOps hace referencia a la integración de prácticas de seguridad en un modelo de entrega de software de DevOps. Este enfoque se establece sobre la base de una cultura donde el desarrollo y las operaciones se realizan mediante procesos y herramientas que permiten compartir las responsabilidades para entregar software seguro.
A grandes rasgos en cuanto al funcionamiento, un modelo de DevSecOps integra los objetivos de seguridad tan pronto como sea posible en el ciclo de vida del desarrollo de software. Aunque la seguridad es “responsabilidad de todos”, los equipos de DevOps se ubican en la intersección entre el desarrollo y las operaciones, con la tarea de aplicar seguridad de forma detallada y variada.
¿Cuál es la diferencia entre DevOps y DevSecOps?
En términos simples, lo que diferencia a los modelos de DevOps y DevSecOps es la cultura de responsabilidad compartida. Hace más de una década que se habla y escribe sobre DevOps, lo que permitió la proliferación de definiciones. En esencia, DevOps es un paradigma de organización que alinea las prácticas de desarrollo y operaciones como una responsabilidad compartida.
Diferencias entre DevOps y DevSecOps
Lo que comenzó como una colección dispersa de prácticas comunes para los equipos de ingeniería de software eficaces se transformó en una declaración moderna de ingeniería sobre cultura y procesos: DevOps. Las organizaciones que tienen una responsabilidad compartida sobre el desarrollo y las operaciones pueden iterar procesos con mayor rapidez, de modo que se vuelven más exitosas. Un modelo de DevSecOps expande esa filosofía: los objetivos de seguridad se codifican como parte de la estructura de intenciones generales. El enfoque de DevSecOps debería considerarse como una evolución natural de DevOps, y no como un concepto independiente. Los equipos que tienen éxito utilizando prácticas de DevOps deberían considerar DevSecOps como el paso siguiente, en lugar de como una medida revolucionaria.
Muchas personas dirían que el objetivo es idear un entorno donde se pueda obtener valor comercial migrando desde el código a producción mediante un flujo sostenible e ininterrumpido. Este nuevo modelo trajo consigo herramientas y metodologías que aumentaron el ritmo y crearon cuellos de botella, en los que las prácticas de seguridad tradicionales con ciclos de comentarios lentos inhibían las prácticas de DevOps de ritmo acelerado. Como resultado, las prácticas de seguridad solo se completaban una vez en producción o mediante la participación de equipos externos en el proceso, lo que ralentizaba los procesos.
Para aclarar más la diferencia entre DevOps y DevSecOps, DevSecOps expande la cultura de DevOps sobre una responsabilidad compartida para incluir también las prácticas de seguridad. Las actividades creadas para identificar y resolver problemas de seguridad se inyectan en un momento temprano del ciclo de vida del desarrollo de aplicaciones, y no después del lanzamiento del producto. Para lograrlo, los equipos de desarrollo realizan muchas de las tareas de seguridad de forma independiente dentro del SDLC (ciclo de vida de desarrollo de software).
Este enfoque permite reducir al mínimo las vulnerabilidades que llegan al entorno de producción, lo que, a su vez, reduce el costo asociado con las correcciones de fallas de seguridad. Además, ofrece escalabilidad y una cultura de colaboración que acerca la seguridad a los objetivos de DevOps. El modelo de DevSecOps tiene como objetivos agregar seguridad en cada etapa del proceso de entrega, desde la etapa de establecimiento de requisitos en adelante, y crear un plan para automatizar la seguridad.
La importancia de DevSecOps
¿Por qué las prácticas de DevSecOps son importantes?
La transformación digital es un requisito existencial para casi todas las empresas. Dicha transformación incluye tres movimientos importantes: más software, tecnologías de nube y metodologías de DevOps.
Más software significa que habrá más riesgo corporativo digital, lo que aumentará la deuda técnica y, por lo tanto, la seguridad para las aplicaciones, y dificultará la protección de recursos digitales.
El uso de la nube implica emplear tecnologías nuevas que presentan riesgos diferentes, cambian más rápidamente y son más públicas que antes, lo que elimina o redefine el concepto de “perímetro seguro”. También significa que muchos riesgos de infraestructura y TI se trasladan a la nube, y otros están determinados únicamente por el software utilizado; de esta forma, se reducen muchos riesgos, pero se resalta la importancia de la gestión de accesos y permisos.
Finalmente, DevOps implica cambiar cómo se desarrolla y entrega software, lo que acelera todo el ciclo, desde la escritura de código, pasando por la entrega de valor a los clientes, hasta el aprendizaje del mercado y la adaptación. Los equipos de desarrollo modernos entregan software de forma continua y más rápido que nunca, de modo que las decisiones tecnológicas y de implementación se vuelven autónomas y no requieren intermediarios. Los tradicionales y lentos ciclos de comentarios que retrasan el desarrollo no se toleran, dado que los equipos priorizan cada vez más la autosuficiencia: tú lo escribes, tú lo ejecutas.
A medida que evoluciona el resto de la organización, los equipos de seguridad se deben enfrentar a mayores exigencias y suelen convertirse en cuellos de botella. Las prácticas y herramientas de seguridad para aplicaciones heredadas, diseñadas en la era previa al uso de la nube para un ritmo más pausado, les exigen a los equipos de seguridad ofrecer aplicaciones de alta calidad. Estos equipos, sin el personal suficiente debido a la grave falta de talento en seguridad, se convierten en un cuello de botella y no pueden seguir este ritmo acelerado. Como resultado, los equipos de desarrollo entregan aplicaciones poco seguras, los equipos de seguridad están agotados y la seguridad se convierte en el enemigo, lo que impide la aceleración que busca conseguir la empresa.
Para lidiar con estos desafíos, se comenzaron a modificar las prácticas, lo que dio origen a DevSecOps. Una cultura de DevSecOps inyecta seguridad en DevOps, lo que permite a los equipos de desarrollo proteger lo que escriben a su ritmo, mientras se fomenta una mayor colaboración entre quienes se dedican al desarrollo y a la seguridad. De esta forma, los equipos de seguridad se convierten en entes de apoyo: ofrecen conocimiento experto y herramientas para aumentar la autonomía de los desarrolladores mientras siguen brindando el nivel de atención que la empresa exige.
6 beneficios del modelo de DevSecOps
Entregas más rápidas. Se mejora la velocidad de entrega de software cuando se integra la seguridad en el pipeline. Los errores se identifican y corrigen antes de la implementación a producción; de esta forma, los desarrolladores se pueden dedicar a la entrega de funcionalidades.
Mejor postura de seguridad. La seguridad es una característica que aparece desde la fase de diseño en adelante. Un modelo de responsabilidad compartida garantiza que la seguridad esté firmemente integrada, desde la creación, pasando por la implementación, hasta la protección de las cargas de trabajo de producción.
Costos más bajos. Al identificar vulnerabilidades y errores antes de producción, se reducen de forma exponencial los costos operativos y por riesgos.
Mayor valor de DevOps. Al sumar prácticas de seguridad a DevOps, se mejora la postura de seguridad general como una cultura de responsabilidad compartida. De hecho, esto se evidencia en el Informe sobre DevSecOps de Snyk y Puppet de 2020 en lo que respecta a organizaciones maduras con DevSecOps.
Mejor ritmo e integración de la seguridad. Se reducen el tiempo y el costo de entregar software seguro, dado que ya no se deben mejorar los controles de seguridad luego de las implementaciones.
Mayor éxito comercial general. Una mayor confianza en la seguridad del software desarrollado y la adopción de nuevas tecnologías aumenta el crecimiento de las ganancias y expande las ofertas comerciales.
Adopción de DevSecOps: cómo integrar la seguridad en el pipeline CI/CD
La mayoría de las organizaciones de DevOps modernas dependerán de alguna combinación de sistemas de integración continua y entrega/implementación continua, que tomará la forma de un pipeline CI/CD. El pipeline ofrece una base excelente desde donde pueden realizarse diversas tareas de validación y pruebas de seguridad automatizadas, sin la necesidad del trabajo manual de operadores humanos.
Adopción de DevSecOps: cómo integrar la seguridad en el pipeline CI/CD
Para sumar los objetivos de seguridad al comienzo del desarrollo de una aplicación, se debe comenzar antes de escribir cualquier línea de código. La seguridad puede integrarse y comenzar el modelado eficaz de amenazas durante la conceptualización inicial del sistema, la aplicación o la historia de un usuario individual. Pueden ejecutarse análisis estáticos, linters y motores con políticas en todo momento en que un desarrollador agrega código, a fin de garantizar que cualquier cuestión sencilla se aborde antes de que llegue a un nivel superior.
El análisis de la composición de software puede aplicarse de forma holística para confirmar que toda dependencia de código abierto cuente con licencias compatibles y no tenga vulnerabilidades. Como consecuencia, los desarrolladores se sienten responsables de la seguridad de sus aplicaciones, y reciben comentarios inmediatos sobre la seguridad relativa del código que escribieron.
Luego de agregar el código y compilarlo, puedes comenzar a realizar pruebas sobre la integración de seguridad. Ejecutar código en un entorno de pruebas con contenedores aislados permite realizar pruebas automatizadas sobre llamadas de red, validación de entradas y autorizaciones, entre otras cosas. Estas pruebas generan comentarios inmediatos, que permiten la rápida iteración y clasificación de los problemas identificados, a fin de provocar la mínima interrupción sobre el flujo general. Por ejemplo, si ocurren llamadas de red injustificadas o entradas sin limpiar, las pruebas fallan y el pipeline genera comentarios prácticos que se envían como informes y notificaciones a los equipos pertinentes.
Luego de que el artefacto de implementación aprueba el primer conjunto de pruebas de integración, pasa a la siguiente etapa de pruebas. Ahora, se implementará en un entorno de pruebas más amplio: una copia limitada del futuro entorno de producción. En esta etapa, pueden realizarse más pruebas de integración de seguridad, aunque estas tengan otro objetivo.
En este momento, pueden hacerse pruebas sobre controles de accesos e inicios de sesión correctos. ¿La aplicación registra las métricas de rendimiento y seguridad relevantes de forma adecuada? ¿El acceso está limitado al grupo correcto de desarrolladores (o se impide por completo)? Si las pruebas fallan, nuevamente los equipos pertinentes recibirán instrucciones sobre cómo actuar.
Finalmente, la aplicación llega a producción. Sin embargo, el trabajo de DevSecOps no se para aquí. La gestión automatizada de parches y configuraciones garantiza que el entorno de producción siempre ejecute las versiones más recientes y seguras de las dependencias de software. En un mundo ideal, una infraestructura inmutable implica que todo el entorno se destruye y se vuelve a crear con frecuencia, dado que está constantemente sujeto al conjunto de pruebas durante todo el pipeline.
Al utilizar un pipeline CI/CD de DevSecOps, se suman los objetivos de seguridad en cada fase, sin la burocracia y los controles molestos, lo que permite que se siga ofreciendo valor comercial con rapidez.
Cómo potenciar una cultura de DevSecOps
Entonces, ¿cómo puede hacer una organización para dar el paso siguiente y pasar de DevOps a DevSecOps? No es tan sencillo como darle a un agotado equipo de DevOps una serie de KPI (indicadores clave de rendimiento) sobre seguridad y dar por terminado el asunto. Debe ser una tarea colaborativa y compartida de rápidas iteraciones.
Si el propósito es integrar objetivos de seguridad lo antes posible, hacerlo debe ser lo menos engorroso posible. La carga de sumar los objetivos y a los equipos de seguridad al flujo de valor no debería caer sobre los desarrolladores. Agregar pasos adicionales solo prolongará el tiempo que toma ofrecer funcionalidades nuevas a los clientes. La seguridad debe ser un aspecto ágil y la organización debe aplicar un enfoque pragmático para agregar seguridad con la mínima interrupción.
Durante el proceso de planificación, en especial en lo que refiere a la infraestructura, los equipos de seguridad deben formar parte de las conversaciones, deben sentirse empoderados para descartar decisiones incorrectas o inseguras, pero deben tener el conocimiento suficiente para ofrecer alternativas. Con frecuencia, los equipos de seguridad que están sobrecargados solo dicen “no” y les encomiendan la búsqueda de alternativas a los equipos de DevOps. Reiteramos: se trata de empoderar a los entes de seguridad con el nivel adecuado de recursos.
Si DevOps y los entes de seguridad colaboran de forma regular y desde temprano, los objetivos de seguridad se incluirán en toda la infraestructura. Las funcionalidades y las aplicaciones llevadas a producción serán el resultado de una colaboración integral y eficaz entre seguridad, desarrollo y operaciones. Los equipos de seguridad no tendrán la necesidad de solicitar funcionalidades adicionales ni auditorías por parte de los equipos de desarrollo luego; sabrán que estas funcionalidades estarán desde el primer día.
Si la organización donde trabajas dio el siguiente paso y aplica prácticas de DevSecOps, sabes que no solo iteras con rapidez y maravillas a los clientes con funciones nuevas y mejoradas, sino que ofreces una experiencia con un nivel de seguridad semejante.
Descubre cómo implementar DevSecOps en 4 pasos.