1. Introducción a la Seguridad de la Cadena de Suministro
Hola, soy Bradley Farias. Trabajo en Socket en Seguridad de la Cadena de Suministro. La cadena de suministro se refiere a la red de personas, herramientas y dependencias que se unen para construir software. Los proveedores de seguridad a menudo exageran los riesgos e intentan que entres en pánico. Es importante hacer preguntas y evaluar el impacto real de las amenazas. Al considerar la seguridad, enfócate en tu aplicación, sus dependencias y los consumidores. En Socket, priorizamos defendernos contra las dependencias y los riesgos que introducen. Comprender lo que ofrece el proveedor de seguridad y adaptarlo a tus necesidades es crucial.
Trabajo en Socket en Seguridad de la Cadena de Suministro, y quiero hablarles un poco sobre mi experiencia en hacerlo y cómo no sentirse abrumado por todas estas personas de seguridad que intentan hablar contigo sobre sus maravillosos productos y todo el caos que tenemos.
Entonces, la cadena de suministro simplemente significa una red de diferentes personas, diferentes herramientas, diferentes dependencias, que se unen para crear tu aplicación de software. La gente quiere exagerar esto, oh, esta red se está expandiendo cada vez más y cosas así. Y es grande, especialmente en JavaScript. La dependencia promedio puede tener alrededor de 80 dependencias, eso es lo que estamos viendo en el trabajo hoy en día. Así que cada vez que agregas una dependencia en tu package.json para node, en realidad estás agregando alrededor de 81 en promedio. Porque cada dependencia puede tener otra dependencia. Lo cual es un poco aterrador de pensar, pero es la realidad de la naturaleza de construir software en estos días. Todos estamos trabajando juntos. Y eso significa que nuestra cadena de suministro es muy grande.
Esto hace que las personas de seguridad y los proveedores de seguridad quieran que entres en pánico. Quieren que pienses que todo tipo de cosas son vulnerables. Cualquier tipo de ataque, en cualquier lugar, incluso el tipo más mínimo de ataque, es algo contra lo que debes estar alerta. Debes gastar miles y miles de tu dinero solo para defenderte de algo cuando en realidad si haces algunas preguntas. ¿Quién puede realizar realmente el ataque? ¿Qué puede hacer el ataque? ¿Dónde puede realizarse realmente el ataque? Y esas cosas. Puedes darte cuenta de que, vale, podemos invertir en estas cosas que el proveedor de seguridad ha dicho que son las cosas más importantes, pero el impacto de ellas es muy pequeño. Y así puede ser el caso de que todas estas amenazas de seguridad que se están identificando, que se están mostrando por estos proveedores de seguridad, sean imprácticas o simplemente no hagan nada a lo que tienes.
Entonces, cuando pienses en esto, debes pensar en tu aplicación, en las dependencias de tu aplicación y en los consumidores de tu aplicación. ¿Y para quién está haciendo algo realmente el proveedor de seguridad? ¿Están evitando que los consumidores hagan algo malo en tu aplicación? ¿Están evitando que las dependencias expongan peligros para tu aplicación? En nuestro trabajo en Socket, nos enfocamos principalmente en tus dependencias. Tenemos un alto nivel de confianza en tu aplicación. Y eso no quiere decir que sea lo único contra lo que nos defendemos, pero muchas veces, cuando trabajas con dependencias, no lees su código fuente. No sabes qué sucede cuando actualizas tus dependencias. Podrían agregar una nueva dependencia, y cuando esa dependencia se actualice, agregar una nueva dependencia podría introducir una puerta trasera. Podría introducir un script problemático que se ejecute en tu máquina de desarrollo, en tu servidor de compilación y cosas así. Gran parte de esto se trata de tratar de entender qué está proporcionando el proveedor de seguridad para ti. Para qué está tratando de adaptar su experiencia. Podrían ser informativos. Están tratando de decirte que esta cosa que instalaste tiene 80 dependencias dentro de ella. No estás instalando solo una cuando la agregas a tu package JSON.
2. Haciendo las Preguntas Correctas a los Proveedores de Seguridad
Debes hacer preguntas prácticas a los proveedores de seguridad sobre vulnerabilidades, escenarios e impactos. No te sientas abrumado por la cantidad de dependencias; enfócate en la relación calidad-señal y ruido. Asegúrate de que los proveedores tengan respuestas para incidentes y medidas preventivas. Mantén conversaciones continuas con los proveedores para abordar inquietudes. El tiempo de demostración es limitado, pero mantente informado y toma decisiones informadas.
Pueden ser proactivos. Podrían intentar evitar que instales algo. Oh, esta instalación hará que tengas un script de instalación. El script de instalación parece un poco aterrador. Retrocedamos.
Así que podrían ser proactivos en cuanto a la security, o podrían ser reactivos. Oh, vimos que ocurrió esta vulnerabilidad. Estos son los pasos que podrías seguir para identificar qué sucedió. ¿Qué fue vulnerable y qué data se vio afectada por ello? Debes hacer estas preguntas cuando hables con los proveedores de security. Y preguntar sobre escenarios, escenarios prácticos.
Figure.js, Event Stream, Lettpad, todos estos son muy famosos. Tengo muchas esperanzas de que cada proveedor de security con el que hables tenga al menos alguna respuesta básica sobre lo que ocurriría al usar su herramienta, si su herramienta incluso afecta esos escenarios. Sobre estos eventos se han escrito artículos académicos, están en artículos de Wikipedia y cosas así. O cualquier escenario teórico que se te ocurra.
Pero muchos de estos se reducen a un famoso xkcd. Una persona aleatoria está oculta dentro de tus dependencias. No sabes quién es esta persona aleatoria. Está tan profundamente enterrada allí, su dependencia está tan profundamente enterrada allí que cuando tienen un problema, cuando introducen scripts maliciosos en tu código, es posible que no puedas verlo. Y estas herramientas intentan exponer eso. Y parece abrumador.
A menudo, cuando tienes cientos y cientos de dependencias, es posible que solo tengas algunas que sean riesgosas. Así que no te sientas abrumado por los números. Obtén relaciones calidad-señal y ruido para poder tomar una decisión informada. Y el impacto. Cuando hables con estos proveedores, es posible que te muestren una gran demostración, pero definitivamente necesitan tener respuestas sobre qué sucede si hay un incidente. ¿Va a afectar tu máquina de producción? ¿Va a causar problemas para tu negocio? ¿Y cuánto esfuerzo requerirá para que un desarrollador, mientras espera una solución, mantenga las máquinas de producción funcionando? ¿Qué puedes hacer después? Lo has solucionado, pero ¿hay algo que la herramienta pueda hacer para prevenir el próximo incidente? Y necesitas tener esa conversación repetidamente. Y esperemos que los proveedores tengan una respuesta para ti. Eso es todo. No te sientas abrumado. Todos están tratando de mostrar el valor de su producto lo más rápido posible porque tenemos un tiempo muy corto cuando estamos demostrando cosas. Sí, todo estará bien. De acuerdo.