DevSecOps: solución del dilema de seguridad del software adicional

 DevSecOps

La falta de prácticas estándar en las comunidades de DevOps está provocando una fricción creciente a medida que los equipos de seguridad se alinean contra los desarrolladores. Esta fricción interna deja al software que desarrollan y a las organizaciones que usan las aplicaciones vulnerables a ataques e infracciones.

Un informe publicado el 30 de septiembre por la empresa de administración de licencias y seguridad de código abierto WhiteSource explora varios factores que contribuyen al aislamiento cultura de desarrollo de software y qué pasos se necesitan para lograr prácticas de DevSecOps ágiles y maduras, lo que implica la integración de la seguridad de TI como una función compartida entre todos los equipos de DevOps.

El informe muestra sentimientos de mayor presión entre los equipos de desarrollo de software para pasar por alto las características de seguridad para cumplir con ciclos de vida de desarrollo cortos.

Ese hallazgo es especialmente significativo a la luz de las revelaciones de que más de la mitad de todos los desarrolladores encuestados en el informe dijeron que no tienen capacitación en codificación segura o solo tienen un evento anual. Agregue a esta falta de capacitación en seguridad entre los codificadores de software el hallazgo de que menos de un tercio de las organizaciones tienen un proceso de priorización de vulnerabilidades definido y acordado.

El enfrentamiento de DevSecOps

Quizás un dilema aún más alarmante es que, en promedio, solo la mitad de las organizaciones tienen un campeón de AppSec en sus equipos. Más evidencia de la división de seguridad entre los equipos es que incluso cuando los profesionales de la seguridad dicen que hay una, los desarrolladores no siempre están de acuerdo, según el informe titulado "WhiteSource DevSecOps Insights, Security vs. Developers: The DevSecOps Showdown".

"Si los desarrolladores sienten que están descuidando la seguridad para cumplir con el cronograma, algo en el proceso DevSecOps está roto ", advierten los redactores del informe.

WhiteSource encuestó a más de 560 profesionales de seguridad de aplicaciones y desarrolladores de software. Esos resultados muestran que, si bien la mayoría de los profesionales y desarrolladores de seguridad creen que sus organizaciones están en el proceso de adoptar DevSecOps, la mayoría de las organizaciones todavía tienen un camino por recorrer, según Rami Sass, CEO y cofundador de WhiteSource. La distancia recorrida es especialmente significativa cuando se trata de romper los silos que separan el desarrollo en los equipos de seguridad, señaló.

"La madurez total de DevSecOps requiere que las organizaciones implementen DevSecOps en todos los ámbitos. Los procesos, las herramientas y la cultura deben evolucionar en para romper los silos tradicionales y asegurar que todos los equipos compartan la propiedad tanto de la seguridad como de la agilidad ", dijo Sass.

Otros hallazgos clave

El informe de WhiteSource tenía como objetivo obtener una mejor comprensión del nivel de madurez de DevSecOps dentro de las organizaciones. Muchos de los resultados indican que el proceso de DevSecOps es hasta inmaduro e inseguro.

El informe encontró que para cumplir con ciclos cortos de implementación, el 73 por ciento de los profesionales y desarrolladores de seguridad se sienten obligados a comprometer la seguridad. Además, las empresas compraron herramientas AppSec para 'marcar la casilla', sin tener en cuenta las necesidades y los procesos de los desarrolladores. Esta práctica da como resultado la compra de herramientas, pero no su uso.


 Hallazgos de WhiteSource DevSecOpsreport

DevSecOps puede ser poco más que una palabra de moda para las organizaciones.


En muchos equipos de organizaciones existe un desafío significativo de "brechas de conocimiento y habilidades de AppSec". El informe encontró que las organizaciones ignoran en gran medida esta brecha de conocimiento.

El principal desafío de los profesionales de la seguridad es la priorización, al menos en teoría. Pero en la práctica, las organizaciones carecen de procesos estandarizados para agilizar la priorización de vulnerabilidades, según el informe.

Profundización en la cultura DevOps

TechNewsWorld analizó con David Habusha, vicepresidente de producto de WhiteSource, el estado de DevSecOps a la luz del informe.

TechNewsWorld: ¿En qué se diferencia la cultura aislada de otros programas? culturas?

David Habusha: El enfoque en silos es un legado que queda de la metodología en cascada. En la cultura en silos, los elementos críticos del ciclo de vida del desarrollo de software, como la seguridad, se tratan como un campo especializado, se colocan bajo la responsabilidad de un equipo dedicado y se abordan en una fase específica del desarrollo. En lo que respecta a la seguridad, se abordó hacia el final del ciclo de vida del desarrollo de software.

El término "metodología en cascada" se aplica a menudo al proceso de desarrollo de software. Sigue un enfoque de gestión de proyectos lineal en el que los requisitos de las partes interesadas y los clientes se recopilan al comienzo del proyecto. Luego, el equipo de desarrollo aplica un plan de proyecto secuencial para adaptarse a esos requisitos.

La mayoría de las organizaciones de hoy comprenden que la seguridad debe tratarse en todo el proceso de DevOps, comenzando desde las primeras etapas de desarrollo. Para hacer esto, los silos deben romperse y la responsabilidad de la seguridad de las aplicaciones debe compartirse entre los equipos. De esa manera, los problemas de seguridad no se abordan solo en las últimas etapas del desarrollo, cuando son más costosos de arreglar y a menudo retrasan la publicación.

TNW: ¿Qué factores contribuyen a una cultura aislada?

Habusha: La cultura en silos es un enfoque heredado heredado persistente. Si bien la mayoría de las organizaciones comprenden que es necesario derribar los muros entre el desarrollo y la seguridad, muchas luchan por poner ese entendimiento en práctica.

Hay muchos factores que contribuyen a la dificultad de las organizaciones para abandonar completamente la cultura aislada. Para que las organizaciones cambien con éxito la seguridad hacia la izquierda y ayuden a los equipos de desarrollo a compartir la propiedad de la seguridad, deben abordar la cultura organizacional, actualizar sus procesos e implementar herramientas automatizadas.

Actualmente, los desarrolladores aún carecen de los conocimientos y las habilidades de AppSec que necesitan para abordar la seguridad. También necesitan herramientas de seguridad que se integren en sus procesos y entornos de desarrollo, de modo que puedan detectar, priorizar y solucionar fácilmente los problemas de seguridad sin ralentizar el desarrollo.

La falta de comunicación entre los equipos también es una gran barrera para los equipos de seguridad y desarrollo. trabajando juntos, compartiendo la responsabilidad y la propiedad sobre la seguridad de las aplicaciones en todo el proceso de DevOps.

TNW: ¿Qué pasos se necesitan para lograr prácticas de DevSecOps ágiles y maduras?

Habusha: Allí no es un cambio mágico para lograr la madurez de DevSecOps. Requiere muchos cambios y ajustes a los enfoques tradicionales del ciclo de vida del desarrollo de software. Esto incluye actualizar nuestras actitudes, conjuntos de habilidades, procesos, las herramientas que usamos, la forma en que nos comunicamos, la estructura de nuestros equipos y más. La madurez de DevSecOps es un maratón, no una carrera.

Uno de los pasos principales que ayudan a lograr la madurez de DevSecOps es cerrar la brecha de conocimiento de seguridad de las aplicaciones proporcionando a los desarrolladores capacitación continua de AppSec, incluida la codificación segura. Esta es una excelente manera de abordar AppSec desde el principio, enseñando a los desarrolladores cómo evitar problemas de seguridad de las aplicaciones desde las primeras etapas de la codificación.

Colocar campeones de AppSec en equipos de desarrollo es otra estrategia inteligente y efectiva para cerrar la brecha entre los equipos de seguridad y desarrollo. Esto aumenta el conocimiento y las habilidades de AppSec de los desarrolladores y abre líneas de comunicación entre equipos.

Un tercer paso importante es integrar las herramientas de seguridad de AppSec en todo el proceso de DevOps. Al elegir estas herramientas, es fundamental que los responsables de la toma de decisiones compren herramientas que se integren perfectamente en los entornos de los desarrolladores y que sean fáciles de adoptar para los desarrolladores.

TNW: ¿Cómo crea esto un sentido de propiedad compartida entre los competidores? factores entre equipos?

Habusha: Para cultivar una cultura de propiedad compartida sobre la seguridad, es importante que las organizaciones creen una política de seguridad de aplicaciones integral que se mantenga entre todos los equipos. Eso ayuda a todos los equipos a compartir el sentido de responsabilidad por la seguridad de las aplicaciones.

TNW: ¿Cómo afecta esto al desarrollo de DevOps?

Habusha: Cuando las organizaciones invierten en tomar medidas para La madurez de DevSecOps, la seguridad está integrada en la canalización de DevOps desde las primeras etapas de desarrollo. Eso significa que los equipos de seguridad y desarrollo trabajan juntos para abordar los problemas de seguridad desde el principio.

Integrar la seguridad en el desarrollo de DevOps significa brindar a los desarrolladores todo el soporte que necesitan para abordar las tareas de seguridad de las aplicaciones sin ralentizar el desarrollo. Eso incluye herramientas de seguridad automatizadas que ayudan a los desarrolladores a abordar la seguridad durante todo el desarrollo, tener una política de seguridad de aplicaciones compartida entre los equipos y permitir y fomentar la comunicación abierta entre los equipos de seguridad y desarrollo.

TNW: ¿Cuáles son las conclusiones más importantes del ¿El último informe de WhiteSource DevSecOps Insights?

Habusha: La conclusión más importante de nuestro DevSecOps Insights Report es que, si bien la mayoría de las organizaciones sienten que están en el proceso de lograr la madurez de DevSecOps, todavía tienen un camino a seguir. Esto es evidente por el hecho de que la mayoría de los profesionales y desarrolladores de seguridad (el 73 por ciento de los 560 más los profesionales y desarrolladores de AppSec que encuestamos) se sienten obligados a comprometer la seguridad. Cuando miramos los datos del informe, es fácil ver las muchas barreras para la adopción de DevSecOps.

TNW: ¿Qué papel pueden desempeñar las herramientas de seguridad especializadas para superar las fricciones en los equipos relacionados con la construcción de una mejor seguridad?

Habusha: Descubrimos que los profesionales de la seguridad apenas consideran la adopción por parte de los desarrolladores al elegir las herramientas de AppSec. Esto explica otra realidad preocupante que descubrimos: muchas de las herramientas de AppSec adquiridas no son utilizadas por los desarrolladores. Cuando las herramientas DevSecOps se compran solo para "marcar la casilla" en lugar de fomentar la adopción por parte de los desarrolladores, la seguridad no se puede integrar con éxito durante todo el desarrollo.

TNW: ¿Pueden las herramientas automatizadas DevOps coexistir con más atención a la seguridad del software confiable?

Habusha: Las mejores herramientas automatizadas de DevOps ofrecen soluciones de seguridad para que los equipos puedan incorporar fácilmente la seguridad al desarrollo, desde las primeras etapas del proceso de DevOps. Éstas son la nueva generación de herramientas DevSecOps.

Las herramientas DevSecOps se pueden integrar sin problemas en los entornos de desarrollo para que puedan abordar la seguridad fácilmente durante todo el desarrollo. Las herramientas actuales de DevSecOps pueden ir mucho más allá de la detección de vulnerabilidades.

En lugar de simplemente presentar a los equipos de seguridad y desarrollo una lista abrumadora de vulnerabilidades de seguridad que deben abordar, las herramientas avanzadas de DevSecOps se integran en la canalización de DevOps y ofrecen a los desarrolladores y tecnologías de priorización de seguridad .

La priorización automatizada ayuda a los equipos a evitar fricciones y garantiza que aborden primero los problemas más críticos para que no pierdan un tiempo valioso debatiendo qué corregir primero o abordar problemas que no afectan sus proyectos.

Además Para la priorización automatizada, las herramientas avanzadas de DevSecOps también pueden ofrecer información de corrección procesable y actualizaciones de versiones automatizadas, lo que ayuda aún más a las organizaciones a garantizar que la seguridad no ralentice el desarrollo.

TNW: ¿Qué otras barreras tienen que superar los equipos de DevOps?

Habusha: Encontramos una barrera adicional para Dev SecOps fue que la mayoría de los desarrolladores no están recibiendo la capacitación de AppSec que necesitan, a pesar de que los profesionales de seguridad afirmaron que uno de los principales desafíos que enfrentan es la falta de personal calificado de AppSec.

TNW: ¿Por qué es importante para las organizaciones deben tener un proceso de priorización de vulnerabilidades definido y acordado?

Habusha: La priorización de vulnerabilidades es un desafío importante para los profesionales de la seguridad. La mayoría de los equipos de desarrollo y seguridad aún carecen de un proceso estandarizado. Los equipos a menudo se basan en prácticas ad-hoc o pautas separadas.

La falta de un proceso acordado para la priorización de vulnerabilidades retrasa la corrección de las vulnerabilidades de seguridad. También provoca más fricciones entre los equipos de seguridad y desarrollo.

TNW: ¿Por qué la seguridad del software todavía se considera secundaria a la velocidad de desarrollo?

Habusha: La mayoría de las organizaciones entienden la necesidad de invierta en seguridad de aplicaciones. Desafortunadamente, muchos todavía creen que la integración de la seguridad en la canalización de DevOps ralentizará el desarrollo.

Ese no tiene por qué ser el caso. Una de las principales razones de esta percepción errónea es la forma en que se abordaron las vulnerabilidades de seguridad según la metodología en cascada. Luego, después del desarrollo, el equipo de seguridad entraba, analizaba y probaba el proyecto y volvía al desarrollo con una larga lista de problemas de seguridad que debían abordarse antes de lanzar el producto.

Este proceso de detección tardía de vulnerabilidades de seguridad en el ciclo de vida del desarrollo de software fue muy costoso y ralentizó el desarrollo. El enfoque de DevSecOps ofrece una forma más rápida, económica, segura y más eficiente de abordar la seguridad durante todo el desarrollo mientras se ciñe a ciclos de lanzamiento cada vez más cortos.


Leave a Reply

Your email address will not be published. Required fields are marked *