En diciembre de 2020, SolarWinds revel\u00f3 que su producto Orion hab\u00eda sido objeto de un ataque a gran escala que, a su vez, concedi\u00f3 al atacante acceso a la infraestructura de muchos clientes de SolarWinds, entre los que se encontraban, sobre todo, varios organismos gubernamentales. El alcance de esta infracci\u00f3n hizo que se preste mucha atenci\u00f3n a las vulnerabilidades de la cadena de suministro y al papel de las dependencias de terceros en la seguridad de un sistema de software. Si bien ninguna de estas amenazas es nueva, el escrutinio adicional llevado a esta \u00e1rea por los eventos actuales dej\u00f3 a las organizaciones con un fuerte deseo de mejorar su postura de seguridad con la esperanza de no ser el pr\u00f3ximo objetivo. Como equipo de ingenier\u00eda de software, su interacci\u00f3n m\u00e1s habitual con la cadena de suministro es la elecci\u00f3n de las bibliotecas externas que se incorporan a sus aplicaciones.<\/p>\n
Una biblioteca externa bien mantenida puede ser una gran ayuda para los esfuerzos de desarrollo, ya que ahorra innumerables horas de tiempo de ingenier\u00eda al permitirle concentrarse en los diferenciadores centrales de su propio producto en lugar de tener que volver a implementar una funcionalidad com\u00fan. Por el contrario, las bibliotecas mal implementadas pueden ser dif\u00edciles de usar, introducir vulnerabilidades de seguridad que crean riesgos para su organizaci\u00f3n y sus clientes o, en casos extremos, incluso interferir con el funcionamiento de partes no relacionadas de su servicio o socavar toda su arquitectura. A continuaci\u00f3n, resumir\u00e9 muchas de las consideraciones que he utilizado para evaluar las bibliotecas en cuanto a la solidez de sus pr\u00e1cticas de ingenier\u00eda y sus posibles consecuencias de seguridad. Ofrezco estos enfoques como un punto de partida, no como una receta. Encuentre un enfoque que satisfaga sus propias necesidades. Si bien no hay soluciones m\u00e1gicas en este espacio, asegurarse de que su proyecto se base solo en dependencias de alta calidad puede reducir sustancialmente su superficie de ataque y hacer que su producto sea m\u00e1s f\u00e1cil de expandir y mantener.<\/p>\n
Esta consideraci\u00f3n inicial es clave porque determina hasta qu\u00e9 punto es necesaria o adecuada una evaluaci\u00f3n. \u00bfQu\u00e9 nivel de funcionalidad ofrece la biblioteca? \u00bfQu\u00e9 importancia tiene esta funcionalidad para el funcionamiento de su producto? Una biblioteca simple con una superficie peque\u00f1a requiere mucho menos escrutinio que un marco grande que se integrar\u00e1 estrechamente en su propio c\u00f3digo. Adem\u00e1s, algunos indicadores que ser\u00edan se\u00f1ales de alarma importantes para la funcionalidad clave (por ejemplo, las actualizaciones poco frecuentes) pueden ser normales o esperables para las bibliotecas m\u00e1s peque\u00f1as que solo intentan cumplir una tarea extremadamente limitada.<\/p>\n
Una pregunta relacionada es c\u00f3mo piensa utilizar la biblioteca. Las dependencias de desarrollo (por ejemplo, una herramienta de an\u00e1lisis est\u00e1tico o un componente de un marco de pruebas unitarias) presentan mucho menos riesgo que las dependencias de tiempo de ejecuci\u00f3n. Aunque los fallos en el proceso de compilaci\u00f3n pueden retrasar una versi\u00f3n o causar otros problemas a corto plazo para los desarrolladores, no afectan directamente al usuario y, por lo general, no suponen un riesgo para la seguridad de la propia aplicaci\u00f3n.<\/p>\n
La forma m\u00e1s r\u00e1pida de hacerse una idea del estado general de un proyecto es mirar su historial de control de fuentes. \u00bfCu\u00e1ndo fue la \u00faltima versi\u00f3n? \u00bfCon qu\u00e9 frecuencia se publican las versiones y cu\u00e1l es el \u00edndice de confirmaciones en el repositorio de c\u00f3digo fuente? Me gusta ver proyectos que se actualizan con frecuencia porque eso me da m\u00e1s confianza en que la biblioteca seguir\u00e1 manteni\u00e9ndose en el futuro. Por el contrario, un proyecto que ha permanecido inactivo durante mucho tiempo puede contener errores no resueltos o puede introducir problemas de compatibilidad con las nuevas versiones de las dependencias comunes o incluso con el propio tiempo de ejecuci\u00f3n del lenguaje.<\/p>\n
Tambi\u00e9n es sumamente valioso consultar el registro de cambios de una biblioteca. A veces, los cambios introducidos por cada versi\u00f3n se describen en la p\u00e1gina de versiones. Otras veces, el registro de cambios es un archivo en el nivel superior del repositorio de c\u00f3digo fuente. Si esta informaci\u00f3n no est\u00e1 f\u00e1cilmente disponible, es una se\u00f1al de alarma importante. Busco descripciones claras de lo que ha cambiado de una versi\u00f3n a otra y que cualquier incompatibilidad con versiones anteriores est\u00e9 claramente documentada. Sin embargo, una alta frecuencia de cambios incompatibles con versiones anteriores o correcciones de errores en la funcionalidad central es en s\u00ed mismo motivo de preocupaci\u00f3n, ya que esto sugiere que el desarrollador no hace un buen trabajo de planificaci\u00f3n y depuraci\u00f3n de los cambios antes del lanzamiento.<\/p>\n
Una evaluaci\u00f3n m\u00e1s exhaustiva podr\u00eda consistir en examinar el registro de problemas de un proyecto y otros canales de comunicaci\u00f3n p\u00fablica. \u00bfC\u00f3mo responden los encargados de mantenimiento a los usuarios? \u00bfSon amables y receptivos a los comentarios, o suelen adoptar un tono m\u00e1s combativo? \u00bfCu\u00e1l es la proporci\u00f3n de problemas abiertos y cerrados? \u00bfLos encargados de mantenimiento abordan activamente las preocupaciones de los usuarios o los informes de errores permanecen inactivos durante largos per\u00edodos? \u00bfCu\u00e1n exhaustiva es la documentaci\u00f3n y en qu\u00e9 medida orienta al usuario hacia las mejores pr\u00e1cticas de implementaci\u00f3n? \u00bfHay indicios de una comunidad vibrante en torno a este proyecto? Por ejemplo, \u00bfla carga de la asistencia a los usuarios recae enteramente en el encargado de mantenimiento principal, o hay otros miembros de la comunidad dispuestos a asumir parte de la carga y capaces de hacerlo? Un proyecto que mantiene una relaci\u00f3n positiva con su comunidad tiene muchas m\u00e1s posibilidades de satisfacer las necesidades espec\u00edficas de los usuarios y de adaptarse r\u00e1pidamente a un entorno cambiante.<\/p>\n
Esta evaluaci\u00f3n requiere un poco m\u00e1s de esfuerzo que el simple recuento de la frecuencia de las versiones, pero proporciona informaci\u00f3n valiosa. Lo primero que quiero entender es en cu\u00e1ntas dependencias adicionales se basa una biblioteca, en particular, si incorpora dependencias innecesariamente. Las dependencias que proporcionan una funcionalidad clave para una biblioteca son mucho menos preocupantes que la incorporaci\u00f3n de muchas bibliotecas adicionales para tareas no relacionadas. Cada dependencia adicional supone una complejidad a\u00f1adida y un riesgo adicional para la cadena de suministro. En caso de duda, una sencilla herramienta de evaluaci\u00f3n es instalar la biblioteca en un contenedor de Docker y observar cu\u00e1ntas bibliotecas adicionales se a\u00f1aden en el proceso.<\/p>\n
La mayor preocupaci\u00f3n en esta categor\u00eda es la facilidad con la que podemos actualizar las dependencias a medida que se descubren nuevas vulnerabilidades. Por esta raz\u00f3n, una parte importante de la evaluaci\u00f3n es se\u00f1alar si una dependencia es restrictiva (solo se puede satisfacer con una versi\u00f3n espec\u00edfica de una biblioteca) o permisiva (se puede satisfacer con un rango de versiones). Las dependencias restrictivas son una preocupaci\u00f3n importante porque pueden dificultar los esfuerzos de colocaci\u00f3n de parches o incluso forzar que las bibliotecas de las que dependemos para otras funcionalidades vuelvan a una versi\u00f3n anterior. Tambi\u00e9n es relevante la vigencia de estas dependencias transitivas. Una dependencia versionada que especifica una versi\u00f3n de hace dos meses es mucho menos preocupante que una dependencia de una versi\u00f3n de hace dos a\u00f1os. Del mismo modo, un signo de un proyecto bien gestionado es un historial de actualizaciones frecuentes que mantienen sus dependencias al d\u00eda.<\/p>\n
Tenga especial cuidado con los paquetes escritos en un lenguaje con dependencias adicionales en un lenguaje diferente (por ejemplo, bibliotecas de Python con extensiones C compiladas). Si las dependencias secundarias implican un lenguaje o un entorno de programaci\u00f3n con el que est\u00e1 menos familiarizado, ser\u00e1 m\u00e1s dif\u00edcil evaluar su calidad general. Adem\u00e1s, los diferentes lenguajes suelen tener distintas convenciones de empaquetado, y los encargados de mantenimiento de los proyectos de lenguajes mixtos no suelen conocer las mejores pr\u00e1cticas de todos los lenguajes de programaci\u00f3n con los que trabajan, lo que dificulta a\u00fan m\u00e1s la aplicaci\u00f3n de parches y las actualizaciones.<\/p>\n
Las bibliotecas criptogr\u00e1ficas merecen una consideraci\u00f3n especial debido a la complejidad algor\u00edtmica implicada y al alto impacto de las posibles vulnerabilidades en este espacio. Examine estas bibliotecas con especial cuidado y aseg\u00farese de solo confiar en bibliotecas revisadas a fondo y con un largo historial. Algunas opciones seguras son OpenSSL para C y C++, BouncyCastle para Java y la biblioteca de criptograf\u00eda de PyCA para Python. Sus opciones pueden estar restringidas por la pol\u00edtica de seguridad de su organizaci\u00f3n o los requisitos de cumplimiento. Sea consciente de las vulnerabilidades conocidas en las bibliotecas criptogr\u00e1ficas y mant\u00e9ngase informado de las nuevas versiones. De todas las dependencias de terceros, estas son las que tienen mayor impacto en la seguridad.<\/p>\n
Esta secci\u00f3n y la siguiente son evaluaciones de alto esfuerzo, pero este nivel de escrutinio, a veces, se justifica en casos de mayor riesgo. Cuando quiero hacerme una idea de la calidad general del c\u00f3digo de un proyecto, trato de buscar el c\u00f3digo fuente que utiliza una funcionalidad que ya comprendo profundamente y eval\u00fao lo bien que han escrito esa peque\u00f1a \u00e1rea de su c\u00f3digo base. A veces, examino la calidad de la documentaci\u00f3n del proyecto, y me centro en la claridad y la capacidad del redactor para comunicar eficazmente conceptos complejos. En cualquier caso, el objetivo es determinar si los encargados de mantenimiento muestran una gran atenci\u00f3n al detalle o, por el contrario, tienden a tomar atajos. La expectativa es que el grado de atenci\u00f3n mostrado en una parte del proyecto sea probablemente representativo del estado del conjunto.<\/p>\n
Como ejemplo concreto, si he elegido mirar el manejo de SSL de un proyecto de Python, podr\u00eda notar lo siguiente:<\/p>\n
En una evaluaci\u00f3n como esta, quiero ver principios de dise\u00f1o s\u00f3lidos, la reutilizaci\u00f3n de modismos est\u00e1ndar y que el autor pueda prever las posibles necesidades de los usuarios y proporcionar la extensibilidad adecuada para abordarlas.<\/p>\n
He enumerado esto \u00faltimo porque suele ser una impresi\u00f3n que construyo con el tiempo y puede ser menos \u00fatil para una evaluaci\u00f3n inicial. Tambi\u00e9n depende, en gran medida, de la amplitud del uso y de la importancia de la seguridad de una biblioteca concreta. Sin embargo, esto puede ser, sin duda, un factor a la hora de decidir si se sigue utilizando una biblioteca existente o se intenta migrar a una que la sustituya.<\/p>\n
En pocas palabras, trato de evaluar la capacidad de respuesta del encargado de mantenimiento del proyecto a la hora de colocar parches a las vulnerabilidades y lo f\u00e1cil que es obtener los beneficios de esos parches en nuestras propias implementaciones. Un proyecto que con frecuencia est\u00e1 sujeto a divulgaciones de vulnerabilidades es algo preocupante, pero podr\u00eda f\u00e1cilmente ser un factor de uso generalizado y relevancia para la seguridad m\u00e1s que la calidad general del c\u00f3digo y las pr\u00e1cticas de mantenimiento. Una mejor m\u00e9trica es lo que sucede despu\u00e9s de que se conoce una vulnerabilidad. \u00bfSe incorporan r\u00e1pidamente los parches a las nuevas versiones? \u00bfQu\u00e9 tan f\u00e1cil es hacer actualizaciones una vez que se lanzan las versiones con parches? Si el proyecto, a menudo, realiza cambios radicales, especialmente si rompen regularmente la compatibilidad con versiones anteriores, \u00bfhacen modificaciones a las versiones anteriores? Si la biblioteca forma parte de una distribuci\u00f3n de Linux, la responsabilidad de aplicar los parches suele recaer en los encargados de mantenimiento de la distribuci\u00f3n y no en el desarrollador original, pero las mismas preguntas pueden aplicarse a la forma en la que el empaquetador maneja la biblioteca (las distribuciones suelen distinguir entre los paquetes principales con mantenimiento activo y los paquetes m\u00e1s perif\u00e9ricos, que suelen realizar un seguimiento de las versiones anteriores con cambios m\u00ednimos aplicados).<\/p>\n
Cuando una biblioteca muestra un historial claro de manejo deficiente de las vulnerabilidades o funciona de un modo que dificulta el aprovechamiento de los parches de seguridad, suelo recomendar a mi equipo que migre a un sustituto.<\/p>\n
La evaluaci\u00f3n de la calidad global de un proyecto de software y de la comunidad que lo rodea es una habilidad fundamental que ser\u00e1 m\u00e1s relevante a medida que los proyectos de software sean m\u00e1s interdependientes. Tambi\u00e9n es una habilidad muy individual; a menudo, obtendr\u00e1 el mayor provecho de la investigaci\u00f3n de las decisiones que toman los encargados de mantenimiento de las bibliotecas dentro de sus \u00e1reas de experiencia. Dado que la validaci\u00f3n completa de cada detalle de un posible proveedor es una tarea a\u00fan m\u00e1s dif\u00edcil que la creaci\u00f3n de la funcionalidad por parte de uno mismo, el proceso de evaluaci\u00f3n consiste en establecer un grado de confianza y adoptar medidas para garantizar que esa confianza no se pierda. En \u00faltima instancia, aprender a examinar las dependencias de terceros es un componente importante de la creaci\u00f3n de una cultura de ingenier\u00eda que se hace cargo de la seguridad y la confiabilidad de su producto.<\/p>\n
Jacob Emmert-Aronson<\/a> es ingeniero s\u00e9nior del equipo de MindMeld, que forma parte de la organizaci\u00f3n Webex Intelligence. Es un l\u00edder del conocimiento en seguridad de la informaci\u00f3n, DevOps y mantenimiento de software, y su especialidad es entender c\u00f3mo se relacionan estos temas<\/p>\n \u00bfEst\u00e1 interesado en unirse al equipo de MindMeld? \u00a1Env\u00ede un correo a mindmeld-jobs@cisco.com!<\/span><\/p><\/blockquote>\n Reg\u00edstrese en Webex<\/a><\/p>\n Visite nuestra p\u00e1gina de inicio<\/a> o p\u00f3ngase en contacto con nosotros<\/a> directamente para obtener ayuda.<\/p>\n