Dependencias seguras

  • 5 minutos

Un porcentaje elevado del código presente en las aplicaciones modernas se compone de las bibliotecas y las dependencias elegidas por el desarrollador. Esto es una práctica común que ahorra tiempo y dinero. Pero la desventaja es que ahora es el responsable de este código, aunque otros lo han escrito, ya que lo utiliza en el proyecto. Si un investigador (o peor, un hacker) detecta una vulnerabilidad en una de estas bibliotecas de terceros, el mismo error probablemente también estará presente en su aplicación.

El uso de componentes con vulnerabilidades conocidas es un gran problema en nuestro sector. Es tan problemático que está incluido en la lista de las 10 principales de OWASP con las peores vulnerabilidades en aplicaciones web, donde se mantiene en el número 9 desde hace varios años.

Seguimiento de vulnerabilidades de seguridad conocidas

El problema que tenemos es saber cuándo se detecta un problema. Mantener las bibliotecas y dependencias actualizadas será de ayuda (número 4 en nuestra lista), pero es una buena idea realizar un seguimiento de las vulnerabilidades identificadas que podrían afectar a la aplicación.

Importante

Cuando un sistema tiene una vulnerabilidad conocida, es mucho más probable que también tenga vulnerabilidades de seguridad disponibles, es decir, código que se puede usar para atacar dichos sistemas. Si se ha hecho pública una vulnerabilidad de seguridad, es fundamental que los sistemas afectados se actualicen inmediatamente.

Mitre es una organización sin ánimo de lucro que mantiene la lista de vulnerabilidades y exposiciones comunes. Esta lista es un conjunto de vulnerabilidades de ciberseguridad conocidas en aplicaciones, bibliotecas y marcos de trabajo que se puede consultar públicamente. Si encuentra una biblioteca o componente en la base de datos de CVE, tiene vulnerabilidades conocidas.

La comunidad de seguridad envía los problemas cuando se encuentra un error de seguridad en un producto o un componente. Se asigna un identificador a cada problema publicado que contiene la fecha en la que se detectó, una descripción de la vulnerabilidad y referencias a soluciones publicadas o instrucciones del proveedor sobre el problema.

Procedimiento para comprobar si tiene vulnerabilidades conocidas en los componentes de terceros

Podría poner una tarea diaria en su teléfono para comprobar esta lista pero, afortunadamente para nosotros, existen muchas herramientas que nos permiten comprobar si las dependencias son vulnerables. Puede ejecutar estas herramientas en el código base o, mejor aún, agregarlas a la canalización de CI/CD para buscar problemas automáticamente como parte del proceso de desarrollo.

También se pueden usar algunas herramientas creadas específicamente para análisis de código estático.

Para más información sobre los riesgos que implica el uso de componentes vulnerables, visite la página de OWASP dedicada a este tema.

Resumen

Cuando usa bibliotecas u otros componentes de terceros como parte de la aplicación, también acepta los riesgos que pueden tener. La mejor manera de reducir este riesgo es asegurarse de usar únicamente componentes que no tienen vulnerabilidades conocidas asociadas.