La seguridad del software de código abierto ha atraído la atención de la industria, pero las soluciones requieren consenso sobre los desafíos y cooperación en la ejecución.

El problema es complejo y hay muchas facetas por cubrir, desde la cadena de suministro, gestión de dependencias, identidad, entre otras cosas más. Para ello Google dio a conocer hace poco un marco («Conocer, prevenir, reparar») en el que explica cómo la industria puede pensar en las vulnerabilidades en el código abierto y en áreas concretas que deben abordarse primero.

Google explica sus motivos:

“Debido a eventos recientes, el mundo del software ha adquirido una comprensión más profunda del riesgo real de ataques a la cadena de suministro. El software de código abierto debería ser menos riesgoso desde una perspectiva de seguridad, ya que todo el código y las dependencias están abiertos y disponibles para inspección y verificación. Y si bien esto es generalmente cierto, se supone que las personas realmente están haciendo este trabajo de inspección. Con tantas dependencias, es imposible monitorearlas todas y muchos paquetes de código abierto no están bien mantenidos.

“Es común que un programa dependa, directa o indirectamente, de miles de paquetes y bibliotecas. Por ejemplo, Kubernetes ahora depende de alrededor de 1000 paquetes. El código abierto probablemente usa dependencias más que software propietario y proviene de una gama más amplia de proveedores; el número de entidades independientes en las que se puede confiar puede ser muy elevado. Esto hace que sea extremadamente difícil comprender cómo se usa el código abierto en los productos y qué vulnerabilidades pueden ser relevantes. Tampoco hay garantía de que lo que se construye coincida con el código fuente.

Dentro del marco propuesto por Google se sugiere dividir esta dificultad en tres áreas problemáticas en gran medida independientes, cada una con objetivos concretos:

Conocer las vulnerabilidades de su software

Conocer las vulnerabilidades de su software es más difícil de lo que se podría esperar por muchas razones. Si bien existen mecanismos para informar vulnerabilidades, no está claro si realmente afectan las versiones específicas del software que está utilizando:

• Objetivo: datos de vulnerabilidad precisos: En primer lugar, es fundamental capturar metadatos de vulnerabilidad precisos de todas las fuentes de datos disponibles. Por ejemplo, saber qué versión introdujo una vulnerabilidad ayuda a determinar si el software está afectado, y saber cuándo se ha parcheado da como resultado correcciones precisas y oportunas (y una ventana reducida para una posible explotación). Idealmente, este flujo de trabajo de clasificación debería automatizarse.
• En segundo lugar, la mayoría de las vulnerabilidades se encuentran en sus dependencias, más que en el código que escribe o controla directamente. Entonces, incluso cuando su código no cambia, el panorama de vulnerabilidades que afectan a su software puede cambiar constantemente: algunas se corrigen y otras se agregan.
• Propósito: Esquema estándar para bases de datos de vulnerabilidad La infraestructura y los estándares de la industria son necesarios para rastrear y mantener las vulnerabilidades de código abierto, comprender sus consecuencias y administrar sus mitigaciones. Un esquema de vulnerabilidad estándar permitiría que las herramientas comunes se ejecutaran en múltiples bases de datos de vulnerabilidades y simplificaría la tarea de seguimiento, especialmente cuando las vulnerabilidades cruzan múltiples lenguajes o subsistemas.

Evitar la adición de nuevas vulnerabilidades

Sería ideal evitar la creación de vulnerabilidades y, si bien las herramientas de prueba y análisis pueden ayudar, la prevención siempre será un tema difícil.

Aquí, Google propone centrarse en dos aspectos específicos:

• Comprender los riesgos al elegir una nueva adicción.
  Mejora de los procesos de desarrollo de software crítico

Reparar o eliminar vulnerabilidades

Google reconoce que el problema general de la reparación está más allá de su alcance, pero el editor cree que los actores pueden hacer mucho más para abordar el problema específico de administrar las vulnerabilidades en las dependencias.

Además menciona: 

“Hoy en día hay poca ayuda en este frente, pero a medida que mejoramos la precisión, vale la pena invertir en nuevos procesos y herramientas.

“Una opción, por supuesto, es parchear la vulnerabilidad directamente. Si puede hacer esto de una manera compatible con versiones anteriores, la solución está disponible para todos. Pero el desafío es que es poco probable que tenga experiencia en el problema o la capacidad directa para realizar cambios. La reparación de una vulnerabilidad también supone que los responsables del mantenimiento del software son conscientes del problema y tienen el conocimiento y los recursos para revelar la vulnerabilidad.

Fuente: https://security.googleblog.com