¿La mejor práctica para el código abierto también para las empresas que no utilizan "ninguno"?
Eso me sorprende, porque los expertos informan de que los componentes de código abierto se encuentran en cerca del 99% de las auditorías de software. Los motivos de estas auditorías son las negociaciones con revendedores como SAP, las absorciones de empresas, las rondas de financiación estratégica o los controles de conformidad y seguridad.
Por regla general, se encuentran cientos, a veces miles, de componentes de código abierto diferentes. Los expertos de los analistas llevan tiempo informando de que hoy en día normalmente un tercio del código de las aplicaciones está formado por componentes de código abierto.
Esto también se aplica a la comunidad SAP, donde Android, Apache, Git, Java, Linux, Maven, OpenStack, Spring y cientos de otros componentes más pequeños o más grandes desempeñan un papel cada vez más importante en TI.
Así que me pregunto cómo debo interpretar la declaración en respuesta a mi pregunta inicial. ¿Mi interlocutor no tiene una visión general del desarrollo interno de software, la empresa no es consciente o es indiferente a lo que hacen sus desarrolladores de software? ¿Realmente no se utiliza el código abierto y, por tanto, no se aprovecha el importante potencial de innovación y ahorro de costes?
¿Por qué es importante saber si se utiliza el código abierto y en qué medida? El dicho "lo que no sé no me hace daño" no protege ni a las empresas ni a los directivos en caso de problemas críticos. Mientras no se sepa si se está utilizando código abierto, dónde y qué, no puede haber una protección eficaz.
¿Por qué es necesario? Los componentes de código abierto pueden contener tipos de licencia poco claros o incluso virales, que en algunos casos ya han provocado costosas disputas legales con los desarrolladores de código abierto.
Mientras tanto, al igual que ocurre con las patentes, existen los llamados trolls que atacan a las empresas y "ganan" millones con ello. Dado que más de la mitad de las auditorías revelan tipos de licencia desconocidos para la dirección en cuestión o componentes con licencias GPL críticas, el riesgo potencial es muy alto.
También se conocen casos en los que adquisiciones de empresas, inversiones o acuerdos OEM han "reventado" o el valor de las empresas ha caído drásticamente. A diferencia de las aplicaciones móviles, los usuarios de código abierto no suelen ser informados automáticamente de las nuevas versiones.
Como consecuencia, las empresas suelen utilizar versiones obsoletas que contienen errores críticos y lagunas de seguridad conocidas desde hace tiempo. Los desarrolladores tienen que ser activos ellos mismos y averiguar laboriosamente las actualizaciones. Los piratas informáticos también lo hacen y utilizan la información de bases de datos como OWASP.org para realizar ataques selectivos a través de componentes inseguros.
Evite riesgos con las mejores prácticas
Es importante establecer primero el alcance del uso, aunque no se utilice "oficialmente" ningún código abierto. Las empresas deben definir un proceso en el que se regule el uso y, si es posible, se supervise automáticamente sin obstaculizar el desarrollo.
Empresas como SAP, Seeburger y Xing demuestran que esto es posible sin problemas asegurando la implantación mediante procesos ágiles y software de supervisión. Esto protege frente a riesgos comerciales, así como a la hora de cumplir requisitos legales como la Ley de Seguridad Informática.
Mientras tanto, existen algunas soluciones comerciales propietarias, sobre todo de EE.UU. e Israel, pero esto parece algo paradójico para la supervisión del software de código abierto.
Soluciones como VersionEye de Mannheim adoptan aquí un enfoque diferente, son ellas mismas 100 por cien de código abierto (licencia Apache) y también pueden utilizarse gratuitamente para una supervisión totalmente automática en lo que respecta a versiones, licencias y posibles riesgos de seguridad.
