Las bibliotecas de terceros son esenciales para acelerar el ciclo de vida del desarrollo de software. En lugar de programar desde cero, los desarrolladores suelen integrar bibliotecas de código abierto con diversos fines, ya sea por motivos de rentabilidad, por falta de recursos o para obtener una mayor flexibilidad. Repositorios como Maven Central y PyPI, junto con las herramientas de gestión de dependencias, simplifican este proceso y aumentan la productividad. Sin embargo, esta dependencia también conlleva posibles riesgos de seguridad.
La gestión de las dependencias de código abierto de un proyecto puede plantear retos, como las dependencias anidadas (una o más dependencias dentro de otra dependencia) y la falta de experiencia en la gestión de dependencias. La integración de bibliotecas externas amplía la superficie de ataque y aumenta los riesgos de seguridad. El descubrimiento de una vulnerabilidad en una biblioteca puede comprometer todo el software que dependa de ese componente. Por lo tanto, es fundamental utilizar herramientas de análisis de dependencias para identificar y corregir las vulnerabilidades conocidas que se originan en las dependencias de terceros.
Software y adopción de dependencias
A medida que los ecosistemas de distribución se vuelven más accesibles, los desarrolladores optan por reutilizar el software existente para agilizar el desarrollo de aplicaciones complejas. Sin embargo, esta comodidad puede generar problemas de seguridad inesperados si no se gestiona con cuidado. Estos programas de software existentes se distribuyen principalmente a través de Internet en forma de paquetes —archivos que contienen versiones de lanzamiento conocidas como bibliotecas, junto con metadatos que especifican la versión, el autor, la licencia, las referencias y otra información relevante—. La empaquetación de software agiliza los procesos de distribución y control de versiones.
Los desarrolladores suelen compartir su código públicamente bajo licencias de código abierto, lo que permite la revisión del código, la colaboración de la comunidad y una fácil integración. Cualquier desarrollador puede reutilizar, modificar o contribuir al código. Los proyectos varían mucho en cuanto a calidad, mantenimiento y asistencia técnica. Los autores publican estos paquetes para que sean más accesibles, pero la asistencia técnica y la responsabilidad dependen de la licencia.
Una vez que se hace referencia a un paquete en otro proyecto, este se convierte en una dependencia del proyecto, lo que supone una referencia a un paquete externo. Las dependencias crean relaciones unidireccionales entre paquetes de software, en las que uno depende de otro para funcionar correctamente. Los desarrolladores incluyen las dependencias en sus aplicaciones, las resuelven en el momento de la compilación y descargan las necesarias.
La cadena de suministro hace referencia a todos los proveedores externos que intervienen en el proceso, en particular aquellos que proporcionan los componentes de software necesarios. La gestión de la cadena de suministro ha cobrado importancia en el desarrollo de software en los últimos años, y las empresas han establecido políticas que abarcan los requisitos de los proveedores, los documentos legales y los contratos para garantizar el cumplimiento de las normas antes de aceptar a un proveedor.
Gestión de dependencias
La gestión de las dependencias puede resultar abrumadora en poco tiempo, lo que conduce a lo que se conoce como «el infierno de las dependencias». Las aplicaciones modernas pueden tener cientos o incluso miles de dependencias directas, lo que dificulta el seguimiento de las vulnerabilidades. A continuación se presentan algunos casos en los que la gestión de grandes volúmenes de dependencias se convierte en un reto.
- Falta de revisión del código: a pesar de la transparencia que ofrece el código abierto, en ocasiones los equipos pueden omitir la revisión del código, lo que genera una falsa sensación de seguridad.
- Confianza implícita: los desarrolladores suelen incluir dependencias sin comprobar a fondo quiénes son sus autores, basándose únicamente en su presencia en el repositorio.
- Uso excesivo de dependencias: los desarrolladores suelen recurrir en gran medida a los paquetes, aunque solo necesiten una parte de su funcionalidad, lo que da lugar a dependencias sobredimensionadas.
- Cambios que afectan a la compatibilidad: la actualización de paquetes puede resultar compleja y dar lugar a cambios que afecten a la compatibilidad, lo que provoca indecisión y que los paquetes queden obsoletos.
- Cuestiones relacionadas con la responsabilidad: los estándares de mantenimiento y asistencia técnica del software de código abierto no alcanzan el nivel exigido para el software comercial, lo que da lugar a disputas y a expectativas poco realistas por parte de los desarrolladores de los proyectos, lo que a su vez puede dar lugar a paquetes poco seguros.
El aumento de los ataques dirigidos a las dependencias de terceros ha suscitado preocupación en torno a la seguridad del software. Incidentes de gran repercusión, como la vulnerabilidad Log4Shell en 2021 o la puerta trasera de XZ Utils recientemente, en marzo de 2024, que afectó a miles de paquetes de Maven, pusieron de relieve el amplio impacto de este tipo de vulnerabilidades. Ese mismo año, el descubrimiento de malware en un popular paquete de NPM, ua-parser-js, puso de manifiesto los riesgos asociados al uso de bibliotecas de terceros en las pilas de aplicaciones.
Otro ataque digno de mención en enero de 2024 es el MavenGate, un nuevo método de ataque a la cadena de suministro de software que consiste en el secuestro de dependencias a través de bibliotecas abandonadas. La explotación exitosa de estas vulnerabilidades podría permitir a los atacantes encontrar artefactos vulnerables en las dependencias e inyectar código malicioso en la aplicación y, lo que es peor, comprometer el proceso de compilación mediante un complemento malicioso.
A medida que aumenta el uso de bibliotecas de código abierto, resulta fundamental comprender y mitigar estos riesgos. Esto impulsa una investigación más profunda sobre la prevalencia, los tipos y la persistencia de las vulnerabilidades en las bibliotecas de código abierto, así como su relación con los atributos de los proyectos y las confirmaciones.
Protección de las dependencias con OPSWAT
Como respuesta a los ataques a la cadena de suministro, los Estados Unidos de América aprobaron en mayo de 2021 la «Orden ejecutiva para mejorar la ciberseguridad nacional», que establece medidas para mejorar las políticas relativas a la cadena de suministro. Uno de los requisitos fundamentales es proporcionar una SBOM para cada producto.
OPSWAT Software Bill of Materials (SBOM) está en constante evolución para satisfacer las crecientes necesidades del desarrollo de software en un entorno seguro. Una de las características clave de OPSWAT es el análisis de dependencias. Esta función está diseñada para mejorar la visibilidad de su código base mediante la identificación de vulnerabilidades en las dependencias de las que dependen sus proyectos.
Análisis de dependencias de paquetes
OPSWAT detecta automáticamente las vulnerabilidades de seguridad en las dependencias de software durante las fases de desarrollo y pruebas. Por ejemplo, SBOM avisa a los equipos si la aplicación utiliza una biblioteca de código abierto que se sabe que es vulnerable. De este modo, los equipos pueden tomar medidas para proteger la aplicación.
Comprobar dependencias con Python
Análisis de Container
OPSWAT examina cada capa de una imagen de contenedor para identificar vulnerabilidades o amenazas, abarcando los paquetes del sistema operativo (SO) y las bibliotecas de software dependientes que utiliza la aplicación. Este enfoque proactivo permite detectar y resolver posibles incidencias antes de que se conviertan en problemas graves.
Comprobar las dependencias con Alpine
Los desarrolladores y los equipos de seguridad se benefician de conocer los tipos más comunes, la prevalencia y la persistencia de las vulnerabilidades de las dependencias, lo que les permite evaluar su gravedad y estudiar estrategias de corrección.
SBOM analiza las dependencias de tu proyecto en busca de vulnerabilidades conocidas. Cuando detecta alguna, SBOM proporciona información detallada, incluyendo los niveles de gravedad, las descripciones de las vulnerabilidades y las soluciones disponibles.
Se puede exportar un informe detallado para que los equipos puedan realizar un seguimiento de:
- Número total de dependencias analizadas
- Número total de vulnerabilidades detectadas en todas las dependencias
- Una serie de versiones escaneadas
- Vulnerabilidades CVE conocidas
- Número total de vulnerabilidades de gravedad crítica, alta, media y baja
OPSWAT recomienda a los equipos de seguridad que actualicen todos los paquetes vulnerables a las últimas versiones, que incluyen correcciones de vulnerabilidades. Esto permite a los equipos solucionar las vulnerabilidades detectadas por los responsables del mantenimiento de los paquetes o eliminar dichos paquetes del árbol de dependencias. Este enfoque proactivo permite a los equipos abordar los posibles riesgos de seguridad antes de que se conviertan en un problema, lo que mejora significativamente la seguridad y la integridad de sus proyectos de software. Además, OPSWAT ayuda a las organizaciones a mantener el cumplimiento normativo y la seguridad en la cadena de suministro de software. Se recomienda encarecidamente que los equipos:
Dependencias del mapa
Aprovecha las herramientas para identificar qué dependencias existen en el entorno y cuáles son sus relaciones.
Eliminar dependencias innecesarias
Elimina las dependencias innecesarias o no esenciales para reducir la superficie de ataque.
Utiliza repositorios consolidados
. Asegúrate de que las dependencias procedan de fuentes fiables.
Analizar todas las dependencias
Antes de utilizar dependencias en cualquier software, analízalas para detectar posibles problemas de seguridad o calidad.
Reflexiones finales
Al utilizar herramientas de análisis de dependencias como OPSWAT , podrá identificar y resolver de forma proactiva las vulnerabilidades presentes en las dependencias de su proyecto, mitigando así los posibles riesgos de seguridad antes de que puedan ser explotados. Aproveche el potencial del análisis de dependencias y las listas SBOM para crear aplicaciones de software seguras, conformes con la normativa y resilientes.
