Google propone establecer reglas a los desarrollos ‘open source’ que la industria considere “críticos”

05 Feb Google propone establecer reglas a los desarrollos ‘open source’ que la industria considere “críticos”

Google considera que la atención que recibe la seguridad del código abierto está justificada y asegurar la confianza de los usuarios requiere de un consenso sobre posibles soluciones como la que ellos proponen: en pocas palabras, que los desarrolladores se responsabilicen de sus desarrollos.

Ingenieros de Mountain View proponen un marco fundamentado en tres aspectos: conocer, prevenir, corregir. La idea básica es que los responsables de proyectos open source considerados críticos por la industria deben ser identificables, responsables y autentificados. No podrían actuar por libre.

Las reglas de Google para el código abierto más “crítico” según la industria

Desde Google consideran fundamental dos aspectos: alcanzar un consenso sobre metadatos y estándares de identidad y conseguir una mayor transparencia y revisión del mencionado software crítico. Este es el maro fundamental a partir del cual proponen desarrollar el resto de soluciones.

El primer aspecto lo consideran clave a la hora de permitir la automatización, reducir el esfuerzo requerido para actualizaciones y minimizar el impacto de vulnerabilidad. El segundo, explican, es necesario para asegurar una revisión suficiente de los proyectos críticos, evitar cambios unilaterales y obtener de forma transparente versiones oficiales verificables y bien definidas.

Eric Brewer, Rob Pike, Abhishek Arya, Anne Bertucio y Kim Lewandowski, los autores de la publicación de Google, sostienen que la intención es definir de forma colectiva el conjunto de paquetes de software “críticos” y aplicar las normas más estrictas de su propuesta de reglas para el código abierto solamente a ese conjunto de aplicaciones. Sería, hasta cierto punto, más closed source.

Concretamente, los objetivos generales para la gestión de vulnerabilidades en el código abierto son las siguientes:

• Conocer: datos de vulnerabilidad precisos, esquema estándar para bases de datos de vulnerabilidades y seguimiento preciso de dependencias.
• Prevenir: comprender los riesgos de nuevas dependencias.
• Corregir: comprender tus opciones para eliminar vulnerabilidades., notificaciones para acelerar las reparaciones y corrección de las versiones más utilizadas.

“Sin embargo, estos objetivos no son suficientes en presencia de adversarios o para prevenir ataques a la cadena de suministro”, dicen desde Google. Por eso, han planteado un segundo conjunto de objetivos específicos para el software crítico, como decíamos. “El segundo conjunto es más oneroso y, por lo tanto, encontrará cierta resistencia, pero creemos que las restricciones adicionales son fundamentales para la seguridad”.

Los objetivos específicos del código abierto crítico serían los siguientes:

• Sin cambios unilaterales: las modificaciones estarían sujetas a la previa aprobación de dos partes independientes y dichos cambios requerirían la revisión del código
• Participantes autenticados: los propietarios y/o encargados del mantenimiento no podrían ser anónimos, debería existir una autentificación fuerte de los contribuidores y debería desarrollarse un modelo federado de identidades.
• Notificación de cambios en el riesgo.
• Habilitar la transparencia para los artefactos de software.
• Cree formas de confiar en el proceso de desarrollo.

“El software de código abierto debería ser más seguro que el de código cerrado”, explicita Google, pero en su opinión requiere de una implicación adicional como la que quieren dejar patente mediante las reglas planteadas.

El objetivo último y fundamental dicen que es reforzar esa seguridad que siempre se ha defendido por parte de la comunidad que abraza el modelo. Quieren asegurar su fiabilidad porque el open source, pese a todo, no está a salvo de vulnerabilidades. Y eso, consideran, solo puede lograrse enfocándose en esta especie de disciplina que promulgan. El software probablemente hace un uso superior de dependencias si lo comparamos con el código cerrado, sostienen, y por tanto debería tratar de atajar la mayoría de vulnerabilidades.

“No somos más que una voz en un espacio en el que el consenso y las soluciones sostenibles son lo más importante”, dicen desde Google. Aunque no dejan de ser una de las grandes tecnológicas. “Esperamos que este debate promueva las mejores ideas y, en última instancia, soluciones que refuercen y agilicen la seguridad del código abierto del que todos dependemos”.

[genbeta.com]