La principal amenaza de la seguridad de código abierto y qué hacer …



Con los desarrolladores de código abierto produciendo regularmente nuevas herramientas, el panorama del riesgo se ha vuelto demasiado fragmentado para monitorearlo adecuadamente.

El noventa y nueve por ciento de las bases de código empresariales contienen componentes de código abierto, según un reciente estudiar. Pero en medio de esa adopción abrumadora, ha surgido un peligro: las organizaciones han perdido visibilidad de la gran cantidad de componentes de código abierto que se utilizan en sus aplicaciones e infraestructura, lo que dificulta la identificación de posibles vulnerabilidades de seguridad.

Lo mismo que hace que el código abierto sea tan poderoso: una comunidad mundial de millones de desarrolladores que constantemente producen nuevas herramientas para fomentar la eficiencia y la innovación, también presenta su mayor prueba de seguridad. Con tantos subcomponentes que se utilizan en cada aplicación, el panorama del riesgo se ha vuelto demasiado fragmentado para que los equipos de seguridad monitoreen adecuadamente los agujeros que los ciberatacantes pueden explotar.

El cincuenta y siete por ciento de los encuestados de Gartner encuesta calificó las vulnerabilidades de seguridad como un desafío importante cuando se trabaja con código abierto, lo que demuestra que los beneficios de costos, la flexibilidad y la conveniencia del código abierto conllevan ciertos riesgos que deben abordarse.

Era más fácil para las organizaciones comprender y controlar su uso del program de código abierto hace 10 o 20 años, cuando un grupo más pequeño de proveedores comerciales de código abierto licenciaba su application a los clientes, entendía todo sobre el código y manejaba los parches de seguridad.

Ahora, sin embargo, los desarrolladores se basan en una gran variedad de proyectos más pequeños que encuentran en GitHub o comparten entre ellos. Después de todo, eso es lo hermoso del código abierto: los desarrolladores ya no tienen que luchar con malas herramientas o reinventar las ruedas de computer software cuando pueden beneficiarse fácilmente de las contribuciones de la comunidad disponibles gratuitamente para abordar casi cualquier necesidad de desarrollo.

Sin embargo, cuando lo hacen, rara vez examinan lo que hay debajo del capó: el código fuente y sus dependencias (los otros componentes con los que se ensambló la herramienta y deben usarse para ejecutarse).

¿Pueden realmente confiar en el código? ¿La parte que lo creó está lista para identificar y revelar fallas de seguridad? ¿Hay alguien con quien contactar? Una sola aplicación puede tener 10 tiempos de ejecución y otros 100 paquetes. ¿Cómo puede estar seguro de que todos están actualizados desde una perspectiva de seguridad?

Esta fragmentación es la amenaza de seguridad de código abierto número uno para las empresas, y puede ayudar a explicar por qué las vulnerabilidades y exposiciones comunes (CVE) en el software program de código abierto se duplicaron con creces entre 2018 y 2019, de 421 a 968, según un reporte por la empresa de seguridad de la información RiskSense.

Dado que COVID-19 trae una variedad de cambios que afectan la infraestructura de TI y genera nuevas preocupaciones de ciberseguridad, se ha vuelto más importante que nunca para las organizaciones reconocer la necesidad de mejores prácticas de seguridad en sus empresas.

Aquí hay tres pasos esenciales que toda empresa debe seguir.

Paso 1: Realice un seguimiento de los componentes de código abierto que se están utilizando
En la fabricación, una lista de materiales es un inventario completo y centralizado de todos los materiales y piezas necesarios para fabricar un producto. Si se encuentra que uno está defectuoso, el fabricante puede señalar el impacto de inmediato.

Al adoptar un enfoque similar, las empresas pueden obtener una nueva visibilidad del desorden de componentes de código abierto que utilizan sus desarrolladores. Como resultado, pueden tomar el regulate de garantizar que sus componentes de código abierto sean seguros en lugar de depender de la información de la comunidad que a menudo es escasa o difícil de encontrar. Este inventario, que incluye todas las dependencias utilizadas por diferentes aplicaciones, se puede compilar manualmente o con una herramienta de descubrimiento automatizada.

Paso 2: deje de enfatizar la agilidad sobre la seguridad
Para seguir siendo competitivas, todas las empresas hoy en día sienten la presión de implementar nuevas aplicaciones rápidamente. Pero eso nunca debería tener un costo de seguridad. Esta es la razón por la que todas las organizaciones deben adoptar DevSecOps, que aplica una mejor higiene a la entrega de aplicaciones al introducir la seguridad en una etapa más temprana del ciclo de vida de la aplicación y requerir pruebas de seguridad y verificación en cada paso.

Paso 3: opte por servidores proxy de confianza siempre que sea posible
Los editores de Linux, como Canonical para Ubuntu, tienen un programa integral para revisar, priorizar y corregir sus paquetes de software en busca de vulnerabilidades. Aunque no todas las aplicaciones de código abierto pueden estar cubiertas de forma predeterminada, vale la pena comprobar qué paquetes y versiones de código abierto pueden beneficiarse de los parches de seguridad. Los editores de SO mantienen su propia base de datos para rastrear la remediación de las últimas vulnerabilidades públicas de varias fuentes, incluyendo INGLETE, NIST NVD, y otros. Estos son los tipos de cualidades que hacen que un proveedor de código abierto sea confiable, y las empresas deberían considerarlas como parte de sus decisiones de código abierto.

Siguiendo estos tres pasos, las empresas pueden asegurarse de que la fragmentación en su application de código abierto no tiene por qué significar una seguridad comprometida.

Lech es responsable de los productos de seguridad y nube pública en Canonical, el editor de Ubuntu. Tiene más de 10 años de experiencia en funciones de liderazgo de productos en las industrias de desarrollo de program, consultoría y telecomunicaciones. Tiene un MBA ejecutivo de LBS. Ver biografía completa

Lectura recomendada:

Más información





Enlace a la noticia primary