Escucha en estas plataformas
Breve resumen
Most organizations today recognize the critical importance of security today. But at the same time, development teams are pushed to move faster, deliver quicker and more frequently, and to behave autonomously. It can be tough to meet these twin demands.
Transcripción de podcast
Rebecca Parsons:
Hola a toda la gente. Bienvenidas al podcast de Thoughtworks. Mi nombre es Rebecca Parsons. Soy la Chief technology officer de Thoughtworks.
Mike Mason:
Y mi nombre es Mike Mason. Soy el jhead of technology de Thoughtworks y trabajo estrechamente con Rebecca en su oficina del CTO, y juntos somos copresentadores del Podcast de Thoughtworks. Hoy nos acompañan dos de nuestros expertos en seguridad, Cade y Ken, para hablar de DevSecOps. Cade, ¿te gustaría presentarte?
Cade Cairns:
Claro, soy Cade Cairns. Soy un principal technologist aquí en Thoughtworks. Tengo una carrera bastante larga en TI, que abarca muchas funciones de desarrollo y también una buena mezcla de seguridad. En la actualidad, estoy más centrado en la intersección de ambas.
Mike Mason:
Y Ken, ¿podrías saludar y presentarte?
Ken Mugrage:
Claro. Soy Ken Mugrage. Soy un defensor de la tecnología de los productos de Thoughtworks. He estado trabajando con la entrega continua durante un buen número de años, nueve o diez años. También soy un organizador global de una serie de conferencias llamadas DevOpsDays, que es de donde surgió el término DevOps.
Rebecca Parsons:
Gracias, Cade. Gracias, Ken. Me gustaría empezar a hablar un poco sobre DevOps en general y algunas de estas nociones que están flotando alrededor, DevSecOps, algunos de los otros. Parece que Dev seguido del fregadero de la cocina seguido de Ops es uno de esos memes que circulan. Pero Ken, ¿puedes hablarnos un poco de DevOps y de cómo ves la seguridad y los aspectos de seguridad y DevOps?
Ken Mugrage:
Claro, encantado. En primer lugar, creo que me gusta pensar en DevOps como un portmanteau de dos verbos en lugar de sustantivos. Así que no se trata de desarrolladores y operadores, sino de desarrollar y operar software. Tengo la impresión o la opinión de que cuando se piensa así, es más inclusivo. Piensas en todo lo que implica el desarrollo y el funcionamiento del software. No soy partidario de añadir más palabras al asunto, sólo porque creo que la intención de hacerlo más inclusivo tiene en realidad el efecto contrario.
Ken Mugrage:
Así que, por ejemplo, con DevSecOps, si decimos que, "Bueno, la seguridad no es parte de DevOps, por lo que necesitamos DevSecOps", entonces estamos implicando que la experiencia del usuario o el cumplimiento o algún otro departamento tampoco es parte de DevOps. Y hay una persona, Nathan Harvey, que dice que si tomas azúcar, bicarbonato de sodio, chocolate, huevos, no tienes sugbakechocegg, tienes pastel. Así que quiero decir que es mi cosa, es que creo que DevOps ya es inclusivo. Y cuando decimos que este equipo está practicando DevOps, pero este equipo está practicando DevSecOps, en cierto modo deja al primer equipo fuera del gancho para hacer la seguridad.
Cade Cairns:
Creo que es un buen punto, Ken. Pero al mismo tiempo, parece que la seguridad ha estado ausente de la mesa, supongo que en muchas organizaciones diferentes con las que he trabajado. Y en consecuencia, parece que estamos escuchando mucho más sobre DevSecOps y la construcción de la seguridad en e incluso conseguir la seguridad más involucrados en la entrega de estos días. Porque para muchas organizaciones, hay mucha gente, y se siente como un gran logro. Creo que también estamos en un lugar donde colectivamente nuestra industria está empezando a entender que tenemos que hacer más para mantener la información de nuestros clientes a salvo, y mantener nuestro estado de TI a salvo, y buscar maneras de hacerlo.
Mike Mason:
Me sorprende, Cade, escuchar que el progreso ha sido tan lento, teniendo en cuenta el tipo de infracciones de alto perfil y mucho, al menos, hablar de la importancia de la seguridad y de mantener los datos de las personas en privado. ¿Es simplemente tan difícil de hacer que las organizaciones no están haciendo progresos? ¿O hay otras razones por las que no ha ocurrido a pesar de la [inaudible 00:04:15]?
Cade Cairns:
Creo que hay muchas organizaciones en las que están haciendo un gran trabajo en este sentido, o al menos en las que la seguridad participa más activamente. Pero al mismo tiempo, el lado del desarrollo o la gente que hace DevOps se mueve continuamente más rápido, y quieren una mayor autonomía y se están moviendo a las plataformas, y sólo siguen haciendo las cosas más y más y más rápido. Y realmente, para la mayoría de las organizaciones, hay un número limitado de personas de seguridad que pueden ayudar o tratar de mantenerse al día con todos los diferentes esfuerzos que están sucediendo. Como consecuencia de esto, y probablemente del hecho de que la seguridad ha sido durante mucho tiempo una función bastante aislada, no ha estado generalmente tan cerca del desarrollo como probablemente podría estar.
Rebecca Parsons:
A raíz de esto, has hablado del número finito de personal de seguridad, del número limitado de personal de seguridad. ¿En qué medida crees que lo que estamos hablando aquí está simplemente relacionado con la escala de la tecnología, la medida en que la tecnología se está utilizando cada vez más y se está convirtiendo en el centro de diferentes tipos de organizaciones? No sólo las empresas tecnológicas, o las empresas de productos tecnológicos puros, tienen que preocuparse por estas cosas, sino que todas las organizaciones tienen este problema. ¿En qué medida cree que se trata de una cuestión de escala, frente a la velocidad de avance de la tecnología?
Cade Cairns:
Creo que parte de los desafíos son sin duda la escala, pero quizás no se trata sólo de la escala, sino también de la forma en que se han realizado muchas tareas de seguridad en el pasado. Gran parte de las pruebas de seguridad han sido tradicionalmente bastante manuales, y aunque la gente confía en un montón de grandes herramientas automatizadas, no creo que muchas de ellas hayan sido realmente optimizadas de la misma manera para el uso repetitivo en un entorno de tipo CICD como lo haríamos en el desarrollo.
Cade Cairns:
Y entre eso y el número limitado de personas, es un reto bastante grande para escalar y tener el mismo impacto que digamos que hacemos con las pruebas que hacemos como parte de nuestras prácticas de entrega de software.
Mike Mason:
Algo que vi en un par de años de este informe sobre el estado de DevOps también, fue que al principio, las organizaciones de TI de alto rendimiento eran las que estaban desplegando con frecuencia. Y sabemos que la capacidad de desplegar software con frecuencia es útil para mejorar la capacidad de respuesta y, por lo general, mejorar la calidad. Pero algunas de las organizaciones más rezagadas seguían esto como una especie de culto a la carga, donde empezaban a desplegar con más frecuencia y no tenían todos los procesos y buenos niveles de automatización y pruebas en su lugar. Y así, a pesar de que estaban desplegando con más frecuencia, estaban viendo una especie de tasa de fracaso más alta, un tiempo más largo para la recuperación y todo ese tipo de cosas.
Mike Mason:
Lo que creo que es interesante es que muchas organizaciones vieron todo esto de la entrega continua y el despliegue continuo y trataron de emularlo. Y, presumiblemente, cuantas más compilaciones intentas lanzar a la producción, más estrés estás poniendo en algo como un proceso de seguridad tradicional.
Ken Mugrage:
Sí. Y para ser honesto contigo, esa es una de las razones por las que personalmente no soy un gran fan de eso, de los despliegues por día o por período de tiempo, como una métrica. Quiero decir que si eso es algo importante para tu negocio y necesitas permitirlo, si eres una empresa de comercio, que se mueve rápidamente, etc., entonces eso es algo muy importante. Pero el patrón que mencionaste es exactamente, es correcto, es que la gente comenzó a desplegar más rápido, pero peor. Así que no era sólo la seguridad era otro tipo de pruebas también, donde eso se convirtió en la métrica. Y creo que todos sabemos que las métricas impulsan comportamientos. Así que son, "Oh, no quiero hacer pruebas de seguridad en mi tubería, porque eso va a tomar minutos u horas. Y no quiero consumir eso y tener que esperar y demás". Y algo de eso tiene que ver con el diseño de la tubería, que podemos ir si queremos más tarde. Pero no, creo que ese es el peligro de las métricas. Tenemos que averiguar cuál es la frecuencia de lanzamiento correcta para nuestro negocio.
Cade Cairns:
Y eso es ciertamente importante. Pero en mi experiencia trabajando con muchas organizaciones, la mayoría de las veces no vemos los requisitos de seguridad en nuestros backlogs, que nos obligarían a escribir pruebas para estas cosas. Y ciertamente, lo que has dicho es preocupante para casi cualquier equipo con el que he trabajado, ya que se refiere a algunas de las herramientas de pruebas de seguridad más grandes y complicadas que existen y que pueden tardar bastante en ejecutarse. También hay muchas oportunidades, o debería haber muchas oportunidades, si tuviéramos los requisitos de seguridad adecuados para escribir una prueba de voz, o encontrar otras maneras de asegurarse de que no hemos introducido defectos de seguridad o hemos aplicado correctamente los controles de seguridad. Y creo que muchas de esas veces se está perdiendo la oportunidad, porque no estamos teniendo esas conversaciones. Y eso probablemente se relaciona con el hecho de que, bueno, la seguridad no se ha incluido tanto.
Ken Mugrage:
Creo que gran parte es el intercambio de información, y Cade lo ha insinuado un par de veces. Es increíblemente importante para mí que estas cosas se hagan, pero voy a ser honesto, no puedo decir exactamente qué herramientas utilizar o qué pruebas ejecutar. Así que estoy ahí. Uno de los patrones que he visto que funciona mucho. Funciona bien, especialmente en nosotros, si tenemos equipos que son equipos de larga duración, por lo que el conjunto de los productos no proyectos cosa es para incrustar la gente en ese equipo, al menos al principio.
Ken Mugrage:
Sé que lo hemos hecho en algunos proyectos con auditores y otros tipos de cosas en los que compartimos: "Bien, estas son las cosas que vamos a hacer desde una perspectiva tecnológica. Esta es la pila de tecnología que hemos elegido. Este es el tipo de información que vamos a pedir a nuestros usuarios. Estos son los sistemas con los que nos vamos a conectar, etc."
Ken Mugrage:
La persona encargada de la seguridad puede decir: "Bien, en ese caso, estas son las cosas que tenemos que probar. Aquí es donde está tu superficie de ataque, esta es la plataforma que podrías querer usar. Esto es lo que sea". Y entonces, juntos, elaboran el plan, por así decirlo. Las cosas que van a necesitar estar en la tubería, frente a las cosas que van a necesitar ser manual. Porque, no vamos a pasar por alto, todo esto no puede ser automatizado. Soy un fanático de la entrega continua y tengo un buen amigo Jason, que se sienta en un cuarto oscuro y hace pruebas de pluma y quiero a Jason.
Ken Mugrage:
Y así, no es un sustituto de ese tipo de cosas. Pero si podemos aportar ese conocimiento a esos equipos, incluso si es la buena y vieja organización matricial o un gremio o llámalo como quieras, donde ayudas a establecer ese proyecto, ayudas a establecer lo que las pruebas deben ser y luego te vas y te conviertes más en un papel de asesor.
Cade Cairns:
Estoy totalmente de acuerdo. Quiero decir que hay algunos retos con la escala, de nuevo, sólo hay un número determinado de personas que pueden dedicar de forma realista esa cantidad de su tiempo a trabajar con un equipo. Pero también señalaría que la seguridad es algo que tiene que existir durante todo el ciclo de vida de un proyecto. Así que hay un montón de actividades iniciales realmente valiosas que deberíamos hacer. Y casi considero que son tipos de actividades de la lista de control. Quiero decir, varían un poco de un proyecto a otro, dependiendo de sus circunstancias y su pila de tecnología y ese tipo de cosas.
Cade Cairns:
Pero donde creo que un especialista en seguridad o un experto en la materia de seguridad ofrece el mayor valor, es en la forma en que faculta a los equipos de ingeniería, los equipos de desarrollo para hacer estas cosas más por sí mismos. Y hay muchas cosas que probablemente nunca consideraría responsabilidad de un equipo de desarrollo, a menos que tengas la suerte de contar con gente realmente apasionada por la seguridad. Pero hay muchas cosas que creo que deberíamos esperar que hicieran. El problema es que, en muchos casos, nunca les hemos pedido que lo hagan, y volviendo a lo que comentabas hace un momento, creo que muchas veces no sabemos por dónde empezar o qué es lo que hay que hacer. Y el hecho de que alguien con experiencia en este campo nos dé su opinión, que entienda cómo es la seguridad y cómo incorporar al desarrollo, es un buen punto de partida. Sin embargo-
Mike Mason:
¿Puede darnos...?
Cade Cairns:
Claro que sí.
Mike Mason:
¿Puedes dar un ... Quiero decir, Ken acaba de hablar de su amigo Jason, que se sienta en un cuarto oscuro haciendo pen testing, y obviamente ese es un papel bastante especializado. Creo que está claro que mantenerse al día con lo último en pentesting es algo muy, muy especializado.
Cade Cairns:
Sí.
Mike Mason:
Pero, ¿qué cosas deberían hacer los equipos? ¿Existen algunas cosas del tipo "low hanging fruit" que todos los equipos de desarrollo deberían incorporar en sus ... Sólo danos una idea. Tal vez, quiero decir que esto no va a ser una lista exhaustiva, sino sólo para dar a los oyentes una idea del tipo de cosas que creemos que la mayoría de los equipos deben estar haciendo.
Cade Cairns:
Bueno, desde el punto de vista de la automatización, hay una gran cantidad de herramientas automatizadas que existen para, digamos, tratar de identificar los defectos comunes de seguridad de las aplicaciones en el software que estamos construyendo. O digamos que estamos desplegando a la infraestructura de la nube o un sistema de orquestación de contenedores o cosas de esa naturaleza. Hay listas de comprobación que nos indican cómo hacer estas cosas de forma segura y cómo configurarlas bien. Hay herramientas automatizadas que podemos ejecutar sobre ellas y que nos dirán si hemos dejado agujeros evidentes en nuestras configuraciones o hemos cometido errores.
Cade Cairns:
Todas las organizaciones deberían tener una herramienta que, por ejemplo, les dijera si han dejado abiertos sus cubos S3 de Amazon AWS, porque solo eso ha sido el origen de muchas violaciones o revelaciones de datos, debería decir. Hay muchas cosas realmente básicas como esa, que son ganancias rápidas que creo que están muy dentro del ámbito de la capacidad y la responsabilidad que los equipos de entrega podrían asumir, y simplemente poner en marcha desde el primer día. Incluso si no son necesariamente los que están detrás de toda la información que genera y tal vez eso va al equipo de seguridad o tal vez eso va a otra persona. Es un material útil para tener.
Cade Cairns:
Dimos una charla en el evento XCONF de Thoughtworks sobre la seguridad desde el primer día, y cubrimos un montón de estas preocupaciones y es realmente básico, cosas de tipo de ganancia rápida que los equipos pueden hacer. No siempre está claro por dónde podemos empezar, pero hay una lista bastante corta de cosas que realmente pueden ser bastante impactantes, al menos para que las cosas vayan en una dirección positiva.
Ken Mugrage:
Si pudiera. Creo que otra victoria rápida es dejar de usar los repositorios públicos. Veo un montón de eventos que se construyen en, siempre elegimos en imágenes de contenedores, pero eso es uno. O podría ser [inaudible 00:15:48], podría ser RPM, podría ser lo que tiene. Es eso, ¿en quién confías? Y si estás construyendo sobre algo que es público y no sabes realmente lo que hay en él, entonces no sabes realmente lo que hay en él.
Cade Cairns:
Sí, y eso es ciertamente aterrador. Creo que el punto sobre la persona en una habitación oscura es interesante. Vuelve a uno de los desafíos que tenemos. Hay tantos tipos diferentes de especialistas en seguridad, en primer lugar. Así que yo no esperaría necesariamente que la persona que es increíblemente fuerte en las pruebas de penetración para venir y ayudar a planificar una entrega segura con un equipo de desarrollo. Pero creo que la cosa del cuarto oscuro es bastante interesante para pensar, porque muchas veces vemos los equipos de seguridad que tradicionalmente han sido bastante aislados en el tipo de organizaciones. Casi todos los clientes con los que he trabajado, todas las organizaciones con las que he trabajado, tienen una variedad relativamente pequeña de personas. Y esas personas tienen un gran número de tareas tratando de mantener la organización segura, tratando de lidiar con todas las estaciones de trabajo, tratando de lidiar con todo el software que compran, tratando de lidiar con sus operaciones en la nube.
Cade Cairns:
Luego tenemos equipos de alto rendimiento, que practican DevOps y tratan de ir cada vez más rápido, y decimos: "Sí, mantente al día con eso también". Y es mucho para mantenerse al día. Y por desgracia, si estás en esa sala y no estás acostumbrado a estar sobre el terreno trabajando con la gente que está trabajando en software a medida, o que ha pedido tener una relativa autonomía en la infraestructura que controla, no se van a beneficiar de tus conocimientos especializados y de tu punto de vista sobre los riesgos para tu organización. Y, por supuesto, ni siquiera vas a saber realmente lo que están haciendo.
Cade Cairns:
En realidad, no culpo de ello a ningún grupo de personas en ningún papel concreto, porque ha sido así durante mucho tiempo y ambas partes tienen intereses casi diferentes. La seguridad está muy centrada en asegurarse de que... o se centran en el interior de una organización y en asegurarse de que nos mantenemos seguros y protegidos. Y los equipos que están entregando valor se centran en el exterior y tratan de empujar las cosas tanto y tan rápido como pueden.
Rebecca Parsons:
Espera, lo que nos lleva de nuevo al papel de la automatización. Porque cuanto más podemos automatizar estas comprobaciones de seguridad, estás usando tu experiencia en seguridad una vez para decidir qué debe estar ahí y hasta qué punto puede ser automatizado. Y entonces eso puede escalar a través de cualquier equipo, cualquier despliegue, y elimina el cuello de botella. ¿Cuál es tu opinión sobre cómo lo estamos haciendo, en términos de avanzar en la automatización de más y más de estas tareas? Quiero decir que esto es algo que ha sido parte de la entrega continua, el despliegue continuo, es automatizar todas las cosas. Y hemos escuchado durante mucho tiempo, "Oh no, no se puede automatizar eso. No se puede automatizar eso", y hemos estado avanzando. ¿Qué opinas de la postura de la comunidad de seguridad? ¿Y si esas cosas, si las miramos de otra manera, serían más fáciles de automatizar?
Cade Cairns:
Creo que hay muchas, muchas oportunidades para automatizar cosas que se identifican como riesgos potenciales de seguridad o controles de seguridad que se nos ha pedido que incorporamos a nuestro software o a nuestros sistemas. Pero parte del reto es que no siempre existen como requisitos formales. Porque no siempre tenemos un especialista en seguridad o alguien con ese conocimiento especializado, que sea capaz de darnos una idea de lo que tenemos que construir. Eso es de esperar.
Cade Cairns:
Por ejemplo, hace unos meses trabajamos con una organización que tenía unos 8.000 desarrolladores trabajando en todo momento. Y uno de nuestros otros consultores dentro de Thoughtworks me dijo: "Bueno, no podemos esperar que el equipo de seguridad proporcione un alto toque para todo el mundo. Simplemente hay demasiada gente que mantener para escalar a eso".
Cade Cairns:
Volviendo a la lista de control de la que hablábamos antes, todo el mundo debería tener al menos una línea de base de automatización que aplicamos a todos nuestros proyectos. Y para aquellos que son de mayor riesgo, de mayor importancia, dependiendo de su valor relativo para el negocio o el riesgo relativo, creo que realmente tenemos que pensar en maneras de traer a esos especialistas un poco más, para que nuestros requisitos puedan reflejar lo que necesita ser incorporado. A partir de ahí, obtendremos mejores pruebas. Pero es bastante difícil ver que eso ocurra mucho hasta que... Y vuelve a lo que decía antes. Si no tenemos gente en el equipo con conocimientos especializados sobre seguridad, que creo que muchas veces no tenemos, la gente no sabe lo que no sabe, y es bastante difícil incorporarlo.
Ken Mugrage:
Creo que esta es una de las áreas donde la automatización realmente puede ayudar dependiendo de cómo se aplica. Por lo tanto, uno de los más grandes, supongo anti-patrones, pero que veo mucho en las tuberías de entrega continua, es la gente tratando de hacer todo de una manera súper lineal. Así que primero ejecuto las pruebas unitarias, y luego ejecuto las pruebas funcionales, y luego hago esto y aquello y lo otro. Y en algún lugar de allí es la seguridad y en algún lugar de allí es el cumplimiento, que tiene un par de efectos secundarios.
Ken Mugrage:
En primer lugar, si la tubería no llega tan lejos, entonces esas pruebas no se ejecutan. Y así, si tienen cosas que están fallando en algún lugar antes, entonces es sólo esa vuelta, no se ejecutan con la suficiente frecuencia. En el momento en que se encuentran, es como, "Oh, ahora es la deuda técnica, y ahora tenemos que negociar con un propietario del producto", o lo que tiene y etc.
Ken Mugrage:
Eso es algo que creo que las plataformas pueden aportar. Y entiendo que es un problema de personal. Creo que es un problema masivo de personal y de aprendizaje; sabemos que necesitamos más gente con este conocimiento. Pero con la entrega continua moderna en contraposición a la integración continua, no podemos hacer cosas que digan: "Si estás haciendo una pila de tecnología Java y construyes un tarro, entonces voy a configurar mi propia tubería. Y cada vez que tu tarro está hecho, voy a absorberlo en mi tubería. Que soy parte del equipo de seguridad y voy a ejecutar un montón de cosas en él, y te voy a decir acerca de muchos de ellos y no voy a decir acerca de otros, porque quiero deshacerse de los prejuicios inconscientes.
Ken Mugrage:
Mientras tanto, tus pruebas unitarias y funcionales siguen funcionando. Pero voy a chupar ese frasco en el mío cada vez. Te voy a dar un panel de control, te voy a dar visibilidad, etcétera, y te voy a ayudar cuando algo vaya mal, no sé, cuando. Pero no voy a alargar tu pipeline haciéndolo o no voy a hacer que no puedas hacer la aceptación del usuario porque mis pruebas siguen ejecutándose, porque podrían ejecutarse durante más tiempo, etcétera".
Ken Mugrage:
Disculpen. Vemos que la gente utiliza Parallel todo el tiempo para hacer como Chrome y Firefox. Pero usted puede hacer Paralelo para más de las pruebas del mismo tipo. Y usted puede hacer, por lo que son diferentes bases de código. Así que la gente que tiene esa experiencia puede decir: "Bueno, si va a crear una imagen Docker, entonces estoy obligado a configurar como", la herramienta que más uso, lo llamamos un material. "Pero si voy a tener una imagen Docker, entonces cada vez que creas una nueva imagen, voy a tirar de ella y ejecutar este material en ella". Creo que eso podría ayudar en algún lugar. Y es algo que no veo muy a menudo.
Mike Mason:
Y creo que eso se remonta a algunas de las cosas que mencionas antes sobre no confiar necesariamente en los repositorios en Internet. Porque la gente hizo esto con sólo, no sé, archivos de biblioteca durante mucho tiempo. Y ahora lo estamos haciendo con imágenes enteras, Docker, que es descargar el material de otra persona de Internet y ejecutarlo efectivamente. Quiero decir, ¿es cierto que la postura de seguridad en una pieza de software tal vez se mueve un poco más lentamente que el nivel de las líneas individuales de código? Por ejemplo, si se tarda en escanear una imagen, tal vez eso esté bien, porque no estás creando imágenes cada vez que te registras o no estás rehaciendo completamente las cosas cada vez que te registras. Así que porque eso es un análisis de dependencia uniforme, ¿verdad? Quiero decir, eso es un objetivo más lento, así que está bien si tienes un poco de tiempo de procesamiento?
Ken Mugrage:
Y creo que eso es lo que estoy diciendo, es que si lo haces, piensa en ello como una dependencia de diamante. Así que si construimos el frasco y se inició la exploración de seguridad y también se inició la prueba de la unidad, la etapa de prueba de la unidad de mi tubería podría ejecutar 10 veces por cada uno que la seguridad hace. Pero puedo configurarlos como un bloqueador usando la dependencia de diamante fan in, fan out, lo llamamos, ese tipo de cosas. Y decir, las pruebas de ese tipo podría ejecutar cada 10 veces por cada uno de los míos. Así que sólo la décima cosa puede llegar a la producción, porque es un bloqueador a la producción. Pero todavía vamos a dar al equipo de desarrollo una retroalimentación rápida.
Ken Mugrage:
Y entonces, quiero decir, probablemente se salga un poco del ámbito. Pero puedo poner cosas de cortocircuito. Así que si tengo una emergencia cuando el frasco está hecho, puedo saltar las cosas y desplegarlo. Dejando que esta cosa todavía se ejecute después del hecho, la cola en lugar de hacia adelante, es todo tipo de cosas que puedes hacer, pero y eso es todo, supongo, la ventaja de ejecutar tuberías enteras en paralelo, es que no terminan al mismo tiempo. No tengo que esperar a que la prueba de seguridad se haga antes de que pueda pasar al siguiente paso.
Cade Cairns:
Iba a decir que esos son puntos realmente grandes Ken, y me encantaría ver a más gente hablando de cómo conseguir que todas estas cosas funcionen en Paralelo de una manera exitosa, y hacer que sea lo más fácil y sin fricción posible para el equipo para conseguir estas cosas en su lugar. Esas herramientas a las que te refieres pertenecen a la categoría del tipo del que hablaba antes. Cosas que todos los equipos deberían tener como parte de lo que hacen, porque nos permitirán encontrar defectos bastante comunes o nos dirán cuándo nuestras dependencias están desactualizadas, o cuándo nuestro software está desactualizado, y realmente reducirán el tiempo del ciclo para que el equipo pueda hacer eso, que es en última instancia a donde queremos llegar.
Cade Cairns:
Pero hay muchos problemas de seguridad en los que queremos pensar más allá de eso, como los defectos que escribimos en nuestro software. O tal vez las cosas que hacemos involuntariamente cuando estamos modificando nuestra infraestructura o traer nuevos contenedores o cosas por el estilo. Lo ideal es que tengamos un conjunto de objetivos de seguridad que alguien nos haya ayudado a determinar o que hayamos hecho nosotros mismos, y que tengamos que escribir pruebas automatizadas para asegurarnos de que lo que hemos hecho sigue siendo de alta calidad y no está introduciendo nuevos riesgos para la organización. Y ahí es donde creo que queremos un poco más de ayuda de los especialistas cuando tiene sentido hacerlo.
Cade Cairns:
La otra cosa que no habíamos hablado, que Ken mencionó hace un segundo, es la visibilidad y los bucles de retroalimentación y cosas por el estilo, que no me importaría tocar si podemos tratar de encajar en muy rápidamente. Porque creo que es probablemente la cosa más importante que está ausente hoy en día para muchos equipos por ahí. Es realmente difícil de obtener información sobre si usted está haciendo lo correcto o lo incorrecto para la seguridad. Y hasta que no mejoremos eso a través de los informes de las herramientas, de la retroalimentación de la gente que hace pruebas más a menudo, o de las cosas que realmente están sucediendo en nuestro entorno de producción, es bastante difícil esperar que los equipos mejoren en estas cosas.
Rebecca Parsons:
Así que nos estamos acercando al final. Me gustaría pedirles que cada uno de ustedes identifique lo que cree que es lo más importante para que un equipo se inicie en esto.
Cade Cairns:
He hablado del hecho de que muchas veces el equipo de seguridad está aislado o quizás es un poco más difícil de conseguir, y tal vez no han estado tradicionalmente tan involucrados o comprometidos con la entrega personalizada que estamos haciendo. Creo que es muy importante tratar de establecer mejores relaciones. De hecho, creo que es muy importante que ambas partes establezcan mejores relaciones y traten de comprender mejor lo que hace la otra parte, lo que le permite hacer su trabajo con éxito. Y lo ideal sería no sólo ganar empatía, compartir nuestros conocimientos, sino también creo que al colaborar con los equipos de desarrollo, los equipos de seguridad aprenderán mucho sobre cómo automatizar mejor las herramientas, cómo mejorar el estado general de las muchas tareas que tienen que hacer, y espero encontrar maneras de automatizar algunas de esas cosas. Y los equipos de desarrollo se beneficiarán mucho simplemente por tener un mayor contacto con personas que tienen un poco más de conocimiento especializado para hacer las cosas mejor.
Ken Mugrage:
Voy a hacer trampa, porque sé que has dicho una cosa. Voy a decir visibilidad, pero parte de ella es la visibilidad de esa información. Así que esa es la trampa, es cómo podemos compartir esa información y si se trata de podcasts o lo que tienen, incluso los internos, estas son las cosas que vamos a hacer. Pero entonces también, la visibilidad desde un punto de vista técnico de los cuadros de mando y lo que sea. "Aquí está la prueba que estamos ejecutando, aquí están las que no estamos ejecutando, aquí está cómo estamos puntuando, etcétera". Incluso las cosas más simples, hay herramientas que dicen qué porcentaje de tu aplicación está usando artefactos externos, y tienen esas pruebas pasadas, etc. Hay algunas estadísticas bastante aterradoras por ahí en cosas como los repositorios de Maven y así sucesivamente.
Ken Mugrage:
Y así, tal vez si tenemos tableros por el bien de los tableros, las luces bonitas no hacen nada. Pero si realmente podemos mostrar a la gente, "Aquí están las cosas que usted podría estar probando y aquí es lo que están probando", incluso si es desde esa perspectiva, una especie de auditoría de la tubería, si eso tiene algún sentido. "Aquí están las herramientas de prueba que estás ejecutando. Usted no está ejecutando estos siete que están disponibles para nosotros. Vamos a hablar de eso".
Rebecca Parsons:
Bueno, gracias Ken. Gracias Cade por esta fascinante discusión sobre la seguridad. Y no salí demasiado aterrorizado, así que eso es probablemente algo bueno.