El 48% considera que la seguridad es un obstáculo importante para entregar software rápidamente
28 de enero de 2020
0 minutos de lecturaA medida que los equipos y las organizaciones se apresuran a integrar la seguridad en todo el ciclo de vida del desarrollo de software (SDLC), surgen desafíos de todo tipo. Para hacer frente al ritmo cada vez más rápido de entrega de software y a la escasez de recursos de seguridad disponibles, las organizaciones deben tomar decisiones sobre cultura, procesos y herramientas: desde definir la cultura interna hasta encontrar las herramientas adecuadas para integrar en los flujos de trabajo de ingeniería, que permitan y empoderen a los desarrolladores y minimicen el trabajo no planificado que interrumpe sus tareas.
Con cada filtración de datos que se hace pública, las organizaciones toman más conciencia de la necesidad de abordar la seguridad desde las primeras etapas y durante todo el SDLC, para proteger la privacidad y los activos de los clientes, garantizar la seguridad de las funciones y mantener la velocidad de entrega. Para hacerlo bien, DevSecOps debe estar impulsado por la seguridad y respaldado por los desarrolladores.
Una buena implementación de DevOps es clave para habilitar DevSecOps
Cuanto más avanzada esté una organización en la escala de evolución de DevOps, más probabilidades tendrá de adoptar prácticas de seguridad. Cuando las organizaciones adoptan ampliamente las herramientas y la cultura de DevOps, están bien posicionadas para incorporar más prácticas de seguridad y habilitar DevSecOps. En el mundo de DevSecOps, una organización se basa en la automatización y empodera a los ingenieros de toda la organización para colaborar entre departamentos y tomar medidas que mejoren la seguridad.
Recientemente realizamos un estudio sobre la adopción de DevOps y DevSecOps, cuya conclusión principal fue que el 48% de los encuestados considera que la seguridad es un obstáculo importante para entregar software rápidamente.
Descargar el PDF de DevSecOps Insights 2020
¿La seguridad es realmente una responsabilidad compartida?
Todos hablan de la seguridad como una responsabilidad compartida en toda la organización. Entonces, ¿por qué cuesta tanto llevar esta idea a la práctica? El informe Puppet State of DevOps ofrece una perspectiva cínica, pero no poco común: a menudo, se considera que las preocupaciones de seguridad sirven para evitar culpas, en lugar de mejorar de forma medible la postura de seguridad general de una organización.
Pasemos a otra pregunta crucial: ¿la seguridad de las aplicaciones es responsabilidad exclusiva del equipo de seguridad? En el informe Snyk State of Open Source Security 2019, descubrimos que el 81% de los encuestados cree que los desarrolladores deberían ser responsables de la seguridad, pero que no cuentan con las herramientas adecuadas para hacerlo.
Según esta encuesta, los desarrolladores son responsables de la seguridad de su código y sus aplicaciones.
¿Cómo podemos ayudarlos a tener más éxito? ¿Cómo podemos empoderar a estos promotores de seguridad para que integren mejor la seguridad en sus flujos de trabajo? Quizás una pregunta aún más polémica sería: ¿quién es responsable de aplicar las correcciones de seguridad y a quién le corresponde encontrarlas?
A medida que se adoptan cada vez más los procesos de DevSecOps, algunos se preguntan si la seguridad dificulta las iteraciones rápidas de desarrollo. A diferencia de DevOps, que se celebra por acelerar la entrega de software en equipos ágiles, se percibe que la seguridad la ralentiza. Los equipos deben lidiar con la presión constante de las partes interesadas del negocio, que exigen entregar funciones con urgencia y las priorizan por encima de la deuda técnica y los problemas de seguridad. Estos problemas suelen quedar sin resolver y representan un posible riesgo de ralentizar el desarrollo de software, además de un riesgo importante para el negocio.
De hecho, según el informe de Puppet, el 48% de los encuestados aún considera que la seguridad es un obstáculo importante para entregar software rápidamente.
Las prácticas de seguridad tradicionales se llevan a cabo en etapas tardías del SDLC; por ejemplo, cuando se envía una versión a control de calidad. Incluso en los equipos que practican la entrega ágil de software en sprints cortos, las revisiones de seguridad no son frecuentes —por ejemplo, pueden hacerse trimestralmente— ni están integradas en las etapas de desarrollo, compilación automatizada y pruebas.
Las herramientas integradas son clave
El software está «conquistando el mundo» y no se detiene. Cada vez vemos más tecnologías tradicionales que pasan al mundo del software: desde las redes definidas por software hasta los proveedores de nube, que abstraen la administración de servicios tradicionales en su totalidad mediante Infrastructure as Code (IaC).
A medida que el software controla cada vez más aspectos del mundo que nos rodea, los desarrolladores son clave para abordar eficazmente los problemas de seguridad, porque tienen un impacto directo en el código y su seguridad. Vemos que este cambio se afianza en los principales ecosistemas de desarrollo, por ejemplo, con integraciones de seguridad clave en el mayor servicio de alojamiento de repositorios de código, GitHub.
Para adaptarse a la agilidad que exige el mundo de DevOps, las herramientas deben incorporar la automatización desde la detección de riesgos hasta su corrección. Así, los ingenieros pueden abordar de forma proactiva los problemas de seguridad y reducir los riesgos rápidamente. Las herramientas eficaces también deben ofrecer contexto para que los desarrolladores puedan evaluar y priorizar los riesgos. En cualquier momento puede haber un volumen enorme de _riesgos potenciales_, lo que genera ruido para los equipos de desarrollo y seguridad. Saber dónde se encuentran los riesgos más altos es fundamental para reducirlos de manera eficiente en aplicaciones y servicios.
Esto no solo empodera a los ingenieros para abordar los problemas de seguridad, sino que también reduce el tiempo durante el cual las vulnerabilidades están expuestas. Así disminuye el riesgo general para la organización y sus activos.
El 79% de las organizaciones está a mitad de su recorrido hacia DevOps
El informe Puppet State of DevOps arroja luz sobre el estado de adopción y madurez de DevOps en distintas organizaciones, así como sobre el impacto de estos factores en la adopción de la seguridad.
Uno de los hallazgos del informe es que el 79% de las organizaciones se encuentra en un nivel intermedio de evolución de DevOps. Además, las organizaciones enfrentan desafíos para escalar las herramientas, la cultura y las prácticas con el fin de cumplir eficazmente las promesas y aprovechar el valor de DevOps.
Para facilitar la adopción de DevOps en las etapas intermedias, Puppet recomienda centrarse en medir los resultados de negocio y utilizar métricas basadas en DevOps. Este enfoque refleja la situación actual y permite identificar los próximos pasos para lograr una adopción más madura de DevOps.
Sigue leyendo nuestro estudio DevSecOps Insights 2020: