En Google proponen hacer que ciertos proyectos Open Source sean bastante Closed Source
Quienes defienden el modelo Open Source afirman que la calidad del código generado es superior a la que se genera en proyectos propietarios. Tiene cierto sentido: cualquiera puede revisar y mejorar ese código, y millones de ojos teóricamente verán más fallos y probables mejoras que unos pocos.
Esa idea entra en conflicto con otra que parece preocupar en Google. Cuando el código es Open Source cualquiera puede modificarlo, lo que quizás haga necesaria una solución intermedia. Una especie de Open Source un poco más “Closed Source” que pueda ser aplicados a proyectos críticos en los que es necesario establecer límites claros a lo que se puede y no se puede hacer con ese código.
Cuando el Open Source es menos Open
Los responsables de la división de seguridad en Google argumentan que los últimos problemas de seguridad y el caso de Solar Winds quizás deberían hacernos cambiar el enfoque del Open Source, al menos para según qué cosas.
En su opinión la industria debería acceder a “definir colectivamente el conjunto de paquetes software críticos” que estuviesen bajo esos estándares especiales.
Cinco serían los pilares de ese tipo de código Open Source especial:
- Prohibidos los cambios unilaterales: si alguien quiere cambiar algo, necesitará que sus cambios sean revisados y aprobados por dos personas independientes.
- Autenticar a los participantes: los propietarios y mantenedores del proyecto no pueden ser anónimos, y los que contribuyen estarían obligados a usar sistemas de autenticación fuertes como la verificación en dos pasos.
- Notificaciones: debería avisarse de qué cambios pueden plantear riesgos de seguridad en ese proyecto software.
- Transparencia: si se sospecha de que el software puede generar conflictos, debe avisarse también.
- Generar métodos para garantizar la confianza en este proceso de desarrollo.
Para estos desarrolladores las medidas son lógicamente molestas e incómodas para la comunidad de desarrolladores, “pero creemos que las limitaciones adicionales son fundamentales para la seguridad“. Con ello, explican, se podrían detectar, prevenir y corregir o eliminar potenciales vulnerabilidades.
Uno de los argumentos más conocidos de la defensa del modelo Open Source en el ámbito de la ciberseguridad es que se evita la peligrosa “seguridad a través de la oscuridad” que el opaco código propietario tiene. “El software Open Source debería tener menos riesgos en el ámbito de la seguridad ya que tanto el código como las dependencias están abiertas y libres para que cualquiera las inspeccione y verifique”, explicababan, “pero aunque eso es generalmente cierto, también se asume que la gente realmente inspecciona ese código“.
En el código Open Source además se suele hacer uso de muchas más dependencias que en el código propietario, lo que obliga a que la confianza en todas esas entidades en las que se basan esas dependencias deba ser muy alta. Será interesante ver si esta propuesta de Google acaba definiendo algún tipo de medida colectiva en el mundo Open Source.
Vía | ZDNet
–
La noticia
En Google proponen hacer que ciertos proyectos Open Source sean bastante Closed Source
fue publicada originalmente en
Xataka
por
Javier Pastor
.
