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
Ver 36 comentarios
36 comentarios
black_ice
Vaya titular más tendencioso.
Existen ciertos proyectos de código abierto que son bloques esenciales en el funcionamiento de una enorme cantidad de proyectos, incluidos navegadores , sistemas operativos, o sistemas de seguridad. Lo que propone Google me parece de entrada razonable, sobre todo para evitar los "chain supply attacks", que es básicamente que insertan una vulnerabilidad o backdoor en una dependencia por lo que decenas, centenares o miles de proyectos que dependen de dicho software terminan siendo vulnerables a ciertos ataques.
Básicamente Google está diciendo que los proyectos Open Source necesitan asegurar que las contribuciones son de calidad y sus creadores no pretenden introducir problemas a propósito en el proyecto, y a partir de ahí generan las reglas que se enumeran en este artículo que ya se podría discutir si son mejores o peores...
Eso sin mencionar que muchos de estos mecanismos ya se emplean en proyectos Open Source (y nadie ha dicho que ahora son "bastante Closed Source"), donde si quieres participar tu código es sometido a reviews, o existen mecanismos de testing automático para detectar riesgos de seguridad.
Geardaron
No se que pensar, creo que esto no es contrario a la filosofía open source per se (Otra cosa es que esos controles se usen para censurar y bloquear), es solo incluir una capa de verificación del Código siendo un "verified open source" pero no necesariamente mas closed.
Entiendo las críticas grandes corporaciones buscando controlar, pero en esencia me parece razonable para evitar que grupos malintencionados corrompan proyectos open source.
Otra cosa es si después empiezas a meter "certificaciones", usuarios vip y etc.... que eso se podría desmadrar y eso claramente no sería Open source
leonsk29
Pues yo estoy de acuerdo con Google. Es hora de acabar de una vez por todas con el mito de que "si X software es de código abierto, es seguro". Eso es una falacia que cada día gana más adeptos y que cuando se le mira de cerca, no se sostiene. Me explico, antes de que los fundamentalistas comiencen a bombardear con negativos:
El código abierto es cierto que es más seguro desde el punto de vista de que cualquiera lo puede auditar y ver qué es lo que hace exactamente, pero...
1. Auditar código fuente es un proceso extremadamente complicado y tedioso, y que requiere de gran experiencia técnica, por tanto, NO CUALQUIERA como se dice lo puede hacer, eso es una mentira.
2. Muchas personas dan por hecho de que como X software es de código abierto, es seguro y OTROS seguramente se ocupan de auditar dicho código, pero se cae en la situación de que los otros también piensan que otros lo han hecho, y así sucesivamente se crea un falso estado de opinión de que el software es seguro porque sí y al final nadie se ha asegurado realmente de ello.
3. El hecho de que todo el mundo tenga acceso al código fuente no significa absolutamente nada, ya que el 99% de los usuarios por lo general descarga la versión pre-compilada, la cual puede contener modificaciones que no aparezcan en el código fuente público.
4. La única manera 100% segura de saber que un código abierto es seguro, valga la redundancia, es hacer una auditoría independiente del código y luego a partir de dicho código compilar uno mismo el software y usar el resultado final. Pero casi nadie tiene la capacidad técnica, ni el tiempo ni los recursos para hacer esto, excepto las grandes empresas y gobiernos.
sapito_uy
Que un código sea eficiente y eficaz o no, seguro o inseguro, es independiente de si se trata de un proyecto de código abierto o cerrado. Hay sistemas cerrados que están de "toda una vida" y no han encontrado (o encontrado casi) vulnerabilidades y de código abierto que tienen agujeros de seguridad importantes (en el proyecto principal o en alguna de las decenas o cientos de librerías de terceros que utilizan).
enriquefernandez
No veo el problema ni el debate en que hagan un estándar diferente al open source actual. Hacer (o intentar hacer) un estándar con unas normas diferentes a otro estándar establecido es simplemente poner una nueva etiqueta a proyectos hechos con unas determinadas reglas diferenciadas. No supone la destrucción del open source tal como lo conocemos ahora y me parece bien que cada uno haga lo que le dé la gana (también con sus productos) siempre que no pretenda obligar a otros a que hagan lo mismo. Esta última frase no la aplicaría tan tajantemente a productos de primera necesidad pero sí en general para la mayoría de cosas.
Dimas
Vaya, que quieren controlar lo que se hace y ser "censores", como ya han hecho con la W3C. El software open source ya tiene varias de esas medidas, no cualquiera puede modificar el código de un proyecto open source y hacerlo público, que no se escuden en esto porque es muy mala la excusa...
deidian
Esto que dices ya existe por lo menos en el código fuente de .NET. Es open source con limitaciones: cualquiera puede proponer una característica o API nueva tanto simplemente desde la perspectiva de funcionalidad como sugiriendo código.
Al final del día el equipo de .NET(personal de Microsoft) decide si y cuando se implementa. Puedes proponer tu código o que se haga en conjunto o te asesoren como hacerlo. Pero en cualquier caso Microsoft tiene la última palabra. Si todo sale adelante aun así está de tu mano encargarte de las pruebas unitarias y de rendimiento usando por supuesto las automatizaciones para ello que ya están establecidas en el repositorio de código fuente.
Básicamente, Open Source con vistas a una empresa seria. Cualquiera puede ver el código fuente y contribuir, pero es decisión de la empresa que al final le va a poner el nombre y la cara al producto la dirección de desarrollo que sigue el producto.
Me parece lo más normal de mundo, no anti código libre. El kernel Linux también funciona así por muy abierto que sea.
Usuario desactivado
Basura de titular sensacionalista... el clickbait no sirve. Sí, os dará clicks y comentarios pero no son gratis. Estáis comprando visitas con vuestra reputación y esa reputación ni es infinita ni fácil de recuperar.
Pero si a eso aspira Xataka, buena suerte, es un sector con mucha competencia.
Ya desapareció genbeta:dev, hace muchos meses que abandoné genbeta y al paso que vamos calculo que a Xataka no le quedará más de un año en mi feedly.
Usuario desactivado
¿Ya se dieron cuenta de que los demás estaban usando sus propias armas en su contra? vaya vaya... :o -_- en serio, ni que fuera gran cosa.
danielmarin2
El título me parece un clickbait en toda regla... Y la gente está poniendo a partir a Google, cuando su posición me parece hasta lógica. Seguramente han leído el título y ya vienen corriendo a llorar.
Que la persona que quiera contribuir se tenga que autenticar de forma segura, y requieran revisión de su código antes de incluirlo me parece de lo más lógico, porque si nadie revisa el código que yo subo, mañana puedo colocar un troyano en toda regla, y ale, hasta que alguien lo detecte. No están diciendo que sea closed source...