Saltar al contenido
← Volver al blog
políticascumplimientolicenciashomebrewempresarial

El Riesgo de Licencias que se Esconde en tus Instalaciones de Homebrew

Licencias de código abierto como GPL y AGPL suponen un riesgo legal real para el software comercial — y se cuelan a través de dependencias que nadie ha revisado. Así se cierra esa brecha sin frenar a los desarrolladores.

EnterpriseBrew Team··3 min lectura

Casi todas las conversaciones de seguridad sobre Homebrew terminan hablando de CVEs y herramientas peligrosas. Casi ninguna llega a las licencias — hasta que legal encuentra una librería con licencia copyleft dentro de un producto comercial, normalmente durante una auditoría o, peor aún, durante la due diligence de una adquisición.

Es un mal momento para descubrirlo. También es algo totalmente evitable.

El riesgo que nadie vigila

Cuando un desarrollador instala un paquete, está aceptando la licencia con la que se distribuye, se dé cuenta o no. La mayoría de las veces no hay problema: MIT, Apache, BSD. A veces sí lo hay. Una dependencia con licencia GPL o AGPL conlleva obligaciones legales reales sobre cómo puedes distribuir el software que la usa — y esas obligaciones no piden permiso antes de colarse en tu código.

Lo que pilla desprevenidas a la mayoría de las empresas: casi nunca es el paquete que el desarrollador instaló directamente. Es algo de lo que ese paquete depende en silencio. Nadie lo eligió, nadie lo revisó, y cuando aparece en una auditoría ya lleva tiempo integrado en un producto.

Los controles a nivel de paquete no detectan esto porque responden a la pregunta equivocada. Bloquear nmap por ser una herramienta de escaneo de red es una decisión de seguridad sobre una herramienta concreta. Ese modelo no vigila una cláusula de licencia enterrada tres dependencias más abajo.

Por qué sale caro

El riesgo de licencias no aparece como un incidente. Aparece como una adquisición que se para, un hallazgo de cumplimiento sin solución fácil, o una orden a ingeniería de arrancar y sustituir una dependencia después de que el producto ya se haya lanzado. Todo eso es mucho más caro y más difícil que impedir la instalación desde el principio. Y no es algo que TI pueda decidir por sí sola: qué licencias son aceptables lo decide legal.

Ahí está la brecha real: legal define la política, pero no tiene forma de aplicarla en el único momento en que realmente importa — el de la instalación.

Cómo se cierra esa brecha

EnterpriseBrew convierte una política de licencias en algo que realmente se aplica, no en un documento que nadie consulta. El equipo legal decide qué condiciones de licencia son inaceptables — GPL, AGPL, lo que diga la política — y cada instalación en toda la empresa se comprueba automáticamente contra esa regla, incluyendo todo lo que ese paquete arrastre en silencio detrás. Si prefieres trabajar al revés, también puedes hacerlo: defines las licencias aprobadas y todo lo que no esté en esa lista se bloquea por defecto.

Elijas el modelo que elijas, es una regla que aplica a toda la empresa, no un ajuste de equipo del que alguien pueda salirse. Una excepción de seguridad para un ingeniero tiene sentido. Una excepción legal para un solo portátil no lo tiene — la obligación nace en el momento en que se usa el código, no en el momento en que alguien se da cuenta.

El resultado

En lugar de descubrir un problema de licencias después de haber lanzado el producto, ese paquete nunca llega a instalarse. Legal define la política una vez. TI no tiene que vigilarla a mano, y los desarrolladores no necesitan convertirse en expertos en licencias para cumplir — la comprobación ocurre automáticamente, antes de que nada llegue a una máquina.

La próxima auditoría deja de ser una carrera para averiguar qué hay instalado y a qué te expone. La respuesta ya está aplicada de antemano.

Artículos relacionados