Vulnerabilidades de código abierto y seguridad con Jeff McAffer de Microsoft
Hayley Denbraver
20 de noviembre de 2019
0 minutos de lecturaAhora que 2019 llega a su fin, vamos a recordar algunos de los grandes episodios de nuestro podcast The Secure Developer. Lee la primera publicación aquí.
El podcast The Secure Developer forma parte de MyDevSecOps, nuestra comunidad de educación en seguridad independiente de proveedores. La comunidad, que antes también se conocía como The Secure Developer, se reúne de forma virtual a través de nuestro grupo de Slack y en eventos virtuales, además de hacerlo en persona en eventos de DevSecCon en todo el mundo.
Sobre nuestro invitado
Jeff McAffer es director de la oficina de programas de código abierto de Microsoft. En ese puesto, dirige la oficina y ayuda a impulsar políticas, procesos, herramientas y cambios culturales en toda la empresa, en un momento en que Microsoft está cambiando su visión sobre el código abierto. Hace poco nos acompañó en el podcast The Secure Developer para hablar sobre lo siguiente:
Cómo agilizar los procesos de seguridad
Gestión de vulnerabilidades
Administración del código abierto y más
Hoy queremos compartir los puntos destacados de nuestra conversación con Jeff.
Cómo agilizar el proceso
Los doce integrantes del equipo de Jeff han trabajado para agilizar el proceso de código abierto en Microsoft con el lema «eliminar, automatizar, delegar». Esto es lo que significa:
Eliminar: Si es posible, el equipo elimina las políticas, preguntas o fricciones que se puedan identificar y resolver.
Automatizar: El equipo redacta políticas que se automatizan ampliamente, pueden incorporar datos y contexto y generar una respuesta.
Delegar: Si el equipo identifica un riesgo que requiere la opinión de alguien externo, delega la tarea a un tercero con la experiencia pertinente, como un abogado o un integrante del equipo con más conocimientos de negocios.
Según Jeff, al aplicar este flujo de trabajo, dejar atrás un modelo de solicitud y aprobación y adoptar uno de registro y revisión, «Hemos llegado al punto en que, gracias a las integraciones con nuestros sistemas de compilación, estas políticas automatizadas y buenos datos, alrededor del 99 % de nuestros usos de código abierto se detectan automáticamente y pasan por nuestros motores de políticas sin intervención humana».
A pesar del esfuerzo por automatizar los sistemas al máximo, las herramientas no son perfectas porque, como dice Jeff, los humanos son humanos y las herramientas son herramientas. Por eso es importante tener listo un plan de seguridad para abordar las vulnerabilidades que puedan surgir.
Cómo gestionar las vulnerabilidades
En cuanto al enfoque de seguridad de Microsoft, hay dos niveles distintos:
Desarrollo activo: El primer conjunto de componentes de seguridad se centra en el desarrollo activo. Si se agrega un componente que tiene algún problema de seguridad o licencia, se marca, se notifica al equipo y este puede tomar medidas.
Respuesta a incidentes: Si se divulga una vulnerabilidad de gravedad alta, se envía al equipo de respuesta a incidentes de seguridad, que toma una decisión según la información disponible. La decisión de dar la alarma depende de la definición del SLA.
Estos niveles cubren la mayoría de los casos de uso. Sin embargo, según Jeff, sigue siendo interesante preguntarse: «¿Qué información de evaluación más precisa podemos tener? ¿Cómo puede saber un usuario si es vulnerable?». En Snyk coincidimos con esta línea de pensamiento (y nuestras herramientas permiten identificar vulnerabilidades en tus dependencias en todo momento). Este enfoque permite a las empresas ser totalmente transparentes al gestionar sus vulnerabilidades y declarar que han tenido éxito.
Informar de forma proactiva sobre tus vulnerabilidades, ya sea a través de los CDE estándar o por otros medios, es una práctica responsable y respetuosa con la comunidad de código abierto en general. Esto forma parte de asumir la responsabilidad como mantenedor de código abierto. Si decides usar componentes de código abierto, Jeff recomienda hacerte responsable de ellos: realiza un seguimiento de las vulnerabilidades relacionadas e infórmalas a medida que distribuyas ese código.
Una mejor administración del código abierto
En la misma línea, así como las empresas trabajan para encontrar formas de identificar vulnerabilidades, Microsoft lanzó ClearlyDefined.io para ayudar a recopilar datos de licencias de forma colaborativa. En esta comunidad, las personas pueden agregar anotaciones sobre licencias y titulares de derechos de autor difíciles de rastrear, y garantizar que la información esté lo más actualizada posible.
ClearlyDefined se revisa como cualquier otra contribución de código abierto y luego se integra en las definiciones de los componentes de código abierto. Lo ideal es que los cambios se incorporen a los componentes originales para que las versiones futuras estén «mejor definidas».
Como explicó Jeff: «Mucha gente todavía piensa: “Es código abierto. Simplemente lo tomaré, lo usaré y listo”. Pero en realidad tienes que tratarlo como si fuera tu código. Aunque no vayas a escribir código, aunque no conozcas el lenguaje, tienes que tratarlo como parte de tu sistema y preocuparte por su seguridad. También tienes que colaborar con los equipos que lo producen, los equipos del proyecto, y decir: “¿Cómo podemos crear esto juntos? ¿Cómo podemos hacer que este proyecto sea seguro para que todos podamos usarlo de forma segura?”». Estamos totalmente de acuerdo con esta visión de la administración del código abierto.
MyDevSecOps se dedica a traer excelentes ponentes como Jeff McAffer a nuestras sesiones virtuales y a nuestro podcast, The Secure Developer. Si te interesa aprender más sobre todos los aspectos de la seguridad, considera unirte a la comunidad.



