La discusión sobre la seguridad de la Open Source está abierta.
Uno de los argumentos más recurrentes para defender el desarrollo Open Source (o de código abierto) en relación con la seguridad informática es que la visibilidad pública del código permite que los fallos de seguridad puedan ser detectados y depurados más fácilmente por porque hay más ojos mirando.
Pero, en sentido contrario, se comenta que al permitir el acceso al código fuente, también se estaría dando la oportunidad de buscar esos fallos a terceros con intenciones maliciosas, cuyo propósito no es poner en conocimiento estos fallos y corregirlos, sino utilizarlos para beneficio propio: explotarlos.
Y Google es de las empresas que opinan de esta última manera, de acuerdo a Xataka. Porque es relativamente habitual que se encuentren vulnerabilidades que permanecieron latentes en el código fuente durante años. Este es el caso, por ejemplo, de una vulnerabilidad del sistema operativo Unix en la funcionalidad sudo, que fue descubierta diez años después de que estuviera ahí.
La propuesta de Google
Teniendo en cuenta esta disyuntiva, el equipo de Google ha propuesto un nuevo marco estándar que redefine el enfoque del código abierto para evitar potenciales vulnerabilidades. La idea es que la industria llegue a un consenso sobre aquellas partes del software que son especialmente críticas. Por ello, a la hora de desarrollarlas es fundamental que se apliquen ciertas limitaciones o controles en el proceso para garantizar una mayor seguridad. Recordemos que fallos de este tipo pueden dar lugar a brechas de seguridad en la protección de datos.
Para esto propone cinco pilares fundamentales en los que se debe basar este nuevo estándar que propone. El primero es que los cambios unilaterales en el código, hechos por cualquier usuario, tendrán que ser aprobados y revisados por al menos dos personas independientes. Otro aspecto, es que se identifique a los propietarios y los que mantienen el proyecto, dejando de ser anónimos como hasta el momento.
En realidad, esta propuesta de Google no es tan nueva. Dado que ya existen proyectos de código abierto que aplican algunas de estas restricciones.
La amornización de las limitaciones en el Open Source
Sin embargo, lo que sí sería novedoso es llegar a un consenso sobre un estándar en cuanto a las limitaciones que se apliquen y uniformizarlas para lograr armonización. Lo cual puede suponer un hito importante para el desarrollo de Open Source. Cuya característica principal es tener muchas dependencias y dentro de ellas integran muchas partes del desarrollo de terceros. Entonces sí es una buena aproximación para aumentar el nivel de confianza en las cadenas de dependencias que integran el software.
Pero por el momento, se trata de una mera invitación a discutir para fortalecer el sector del desarrollo en código abierto. Porque no todo es blanco o negro. Sino, que un desarrollo en código abierto dependiendo las circunstancias de cada proyecto su finalidad, la cantidad de participantes involucrados y el nivel de respaldo de la comunidad, puede ser más o menos seguro.