Resumen

Completado

En este módulo, ha explorado cómo el desarrollo de software moderno depende de los componentes de código abierto y las estrategias aprendidas para implementar software de código abierto al tiempo que administra los riesgos operativos, legales y de seguridad asociados. Comprender estos conceptos le permite aprovechar las ventajas de código abierto a la vez que protege a su organización frente a posibles pasivos.

Cómo se crea el software moderno

Ha aprendido que las aplicaciones contemporáneas se ensamblan desde componentes en lugar de compilarse completamente desde cero:

  • Composición de componentes: Las aplicaciones modernas constan de aproximadamente 80% componentes existentes mantenidos fuera del proyecto, con solo 20% siendo código de lógica de negocios original.
  • Código abierto frente al código cerrado: Los componentes de código abierto proporcionan código fuente disponible públicamente que cualquier usuario pueda inspeccionar, modificar y distribuir, mientras que los componentes de código cerrado solo distribuyen archivos binarios sin acceso de origen.
  • Ecosistemas de paquetes: Los componentes se distribuyen a través de administradores de paquetes como npm, PyPI, NuGet y Maven Central, que automatizan la administración de dependencias.
  • Ventajas del desarrollo basado en componentes: La reutilización de componentes probados acelera el desarrollo, mejora la calidad a través de la investigación comunitaria, reduce los costos evitando las tarifas de licencia y proporciona acceso a innovaciones de vanguardia.
  • Velocidad de desarrollo: El uso de componentes de código abierto reduce drásticamente el tiempo de comercialización al permitir que los equipos se centren en un valor empresarial único en lugar de volver a generar una infraestructura común.

Preocupaciones corporativas sobre el software de código abierto

Ha examinado los riesgos significativos a los que se enfrentan las organizaciones al adoptar componentes de código abierto:

Problemas de seguridad:

  • Vulnerabilidades conocidas: Miles de vulnerabilidades de seguridad se detectan anualmente en componentes de código abierto, lo que requiere supervisión continua y aplicación de revisiones rápidas.
  • Ataques de cadena de suministro: Los atacantes ponen en peligro las cuentas del mantenedor de paquetes, usan errores tipográficos o aprovechan la confusión de dependencias para insertar código malintencionado.
  • Proyectos no detenidos: Muchos proyectos de código abierto carecen de mantenimiento activo, dejando las vulnerabilidades no actualizadas cuando los mantenedores abandonan proyectos.

Problemas de calidad y confiabilidad:

  • Calidad variable: Los componentes de código abierto abarcan desde proyectos mantenidos profesionalmente hasta código de hobby poco probado.
  • Cambios importantes: Los componentes no siempre priorizan la compatibilidad con versiones anteriores, lo que requiere cambios de código al actualizar.
  • Brechas en la documentación: la documentación inadecuada aumenta los errores de integración y el uso incorrecto.

Problemas legales y de licencias:

  • Obligaciones de cumplimiento de licencias: Cada licencia de código abierto impone requisitos que van desde la atribución simple hasta el aprovisionamiento abierto obligatorio de obras derivadas.
  • Propagación de copyleft: las licencias de copyleft fuertes, como la GPL, pueden requerir la liberación del código fuente de toda la aplicación si no se gestionan adecuadamente.
  • Proliferación de licencias: Las aplicaciones pueden depender de cientos de paquetes con docenas de licencias diferentes, lo que supone una carga de cumplimiento compleja.

Preocupaciones operativas:

  • Dependencia de infraestructura externa: Las aplicaciones se basan en registros de paquetes públicos que pueden experimentar interrupciones o eliminación de paquetes.
  • Carga de administración de actualizaciones: Mantener las dependencias actuales requiere esfuerzo continuo, pruebas e implementación.

¿Qué es el software de código abierto?

Ha aprendido las características fundamentales del software de código abierto:

  • Definición: Software cuyo código fuente está disponible públicamente para inspección, modificación y distribución, sujeto a una licencia de código abierto.
  • Desarrollo colaborativo: Los proyectos de código abierto implican colaboradores distribuidos en todo el mundo que participan voluntariamente, con el desarrollo que se produce de forma transparente en repositorios públicos.
  • Adopción generalizada: Más de 90% de empresas usan software de código abierto en producción y tecnologías de código abierto potencian la infraestructura de Internet, las plataformas en la nube y los dispositivos móviles.
  • Transformación de Microsoft: Microsoft cambió de ver el código abierto como una amenaza para adoptarlo de forma completa, open-sourcing .NET, contribuir a Linux y Kubernetes, y crear herramientas populares de código abierto como Visual Studio Code y TypeScript.
  • Justificación estratégica: Las organizaciones eligen código abierto para ahorrar costos, flexibilidad y control, transparencia y seguridad a través de la inspección de código, evitando el bloqueo del proveedor, el soporte técnico de la comunidad y el acceso anticipado a las innovaciones.

Aspectos básicos de la licencia de código abierto

Ha explorado cómo las licencias de código abierto rigen el uso de software:

Propósito de licencia:

  • Definir permisos: Las licencias conceden derechos para usar, modificar y distribuir software que la ley de derechos de autor prohibiría de otro modo.
  • Imponer obligaciones: Las licencias requieren atribución, divulgación de código fuente, preservación de la licencia y, a veces, cumplimiento de copyleft.
  • Renuncia a responsabilidad: Los autores no son responsables de los daños y el software se proporciona "tal cual" sin garantías.

Criterios de definición de código abierto:

  • Redistribución gratuita: No hay restricciones en la venta o entrega de software.
  • Disponibilidad del código fuente: Debe incluir el origen en forma preferida para las modificaciones.
  • Trabajos derivados permitidos: Debe permitir modificaciones y obras derivadas.
  • Sin discriminación: No se puede discriminar contra personas, grupos o campos de esfuerzo.
  • Tecnología neutra: No se pueden requerir tecnologías o interfaces específicas.

Categorías de licencia:

  • Licencias permisivas: Permitir la incorporación de código en software propietario con restricciones mínimas (MIT, Apache 2.0, BSD).
  • Licencias de Copyleft: Requerir trabajos derivados para usar la misma licencia, asegurándose de que el software sigue siendo de código abierto (GPL, AGPL).
  • Licencias de copyleft débiles: requerir modificaciones de aprovisionamiento abierto en el componente, pero permitir el uso propietario (LGPL, MPL).

Licencias comunes de código abierto

Ha examinado las licencias populares y sus características clave:

Licencias permisivas:

  • Licencia MIT: Licencia permisiva más sencilla que requiere solo atribución, maximizando la adopción y el uso comercial.
  • Licencia de Apache 2.0: Licencia permisiva con concesiones explícitas de patentes y terminación defensiva, proporcionando claridad en la patente.
  • Licencias de BSD: De forma similar a MIT, con BSD de cláusula 3, agregando restricciones de uso de nombres para la protección de marcas comerciales.

Licencias de copyleft seguras:

  • GPL v2 y v3: Requerir que las obras derivadas sean con licencia GPL y distribuyan código fuente con archivos binarios; GPL v3 agrega mejoras de compatibilidad internacional y protección de patentes.
  • AGPL: Amplía GPL v3 con una cláusula de uso a través de la red que requiere divulgación del código fuente para las ofertas de SaaS.

Licencias de copyleft débiles:

  • LGPL: Permite vincular a bibliotecas de aplicaciones propietarias, al tiempo que requiere modificaciones en la propia biblioteca para ser de código abierto.
  • MPL 2.0: Proporciona copyleft de nivel de archivo, que solo requiere divulgación de código fuente para archivos con licencia MPL, no código propietario en la misma aplicación.

Compatibilidad de licencias:

  • Combinaciones compatibles: MIT + Apache 2.0, MIT + GPL v3, Apache 2.0 + GPL v3, LGPL + GPL.
  • Combinaciones incompatibles: GPL v2 + Apache 2.0, GPL + Propietario, diferentes licencias de copyleft combinadas.

Implicaciones de licencia y clasificaciones de riesgo

Ha aprendido a evaluar los riesgos de licencia e implementar el cumplimiento:

Marco de riesgo de licencia:

  • Bajo riesgo (verde): Las licencias permisivas como MIT, BSD, Apache 2.0 son seguras para cualquier uso comercial.
  • Riesgo medio (amarillo): licencias de copyleft débiles como LGPL, MPL permiten el uso propietario con restricciones en las modificaciones.
  • Alto riesgo (Rojo): Las licencias de copyleft fuertes como GPL, AGPL no son compatibles con la distribución de software propietario.
  • Riesgo desconocido (Naranja): Las licencias personalizadas o poco claras requieren revisión legal antes de su uso.

Implicaciones de software comercial:

  • Licencias permisivas: Habilite la distribución propietaria solo con requisitos de atribución.
  • Copyleft débil: permitir el uso de bibliotecas en aplicaciones propietarias, pero requerir modificaciones de aprovisionamiento abierto en las bibliotecas.
  • Copia fuerte: requerir trabajos derivados de aprovisionamiento abierto, por lo que son incompatibles con el software propietario.

Consideraciones sobre la propiedad intelectual:

  • Protección de IP propietaria: Las licencias permisivas conservan el código propietario; las licencias copyleft requieren divulgación.
  • Disposiciones sobre patentes: Apache 2.0 y GPL v3 incluyen concesiones explícitas de patentes; MIT/BSD carece de claridad de patentes.
  • Pérdida de secretos comerciales: La divulgación de código fuente elimina la protección de secretos comerciales.

Implementación de cumplimiento:

  • Inventario de dependencias: Mantener una lista completa de materiales de seguimiento de todos los componentes y versiones de código abierto.
  • Comprobación de compatibilidad de licencias: Use herramientas automatizadas para identificar incompatibilidades de licencias.
  • Cumplimiento de atribución: Genere archivos de agregación de licencias, inclúyalos en los diálogos Acerca de y manténgalos en la documentación.
  • Aprovisionamiento de código fuente: Para las licencias copyleft, proporcione código fuente completo con instrucciones de compilación.

Seguridad de la cadena de suministro de software:

  • Examen de vulnerabilidades: Examine continuamente las dependencias para detectar vulnerabilidades conocidas mediante herramientas como Snyk, Dependabot o WhiteSource.
  • Mitigación de ataques de cadena de suministro: Compruebe las firmas del paquete, prefiera orígenes de confianza, use registros privados y ancle versiones de dependencia.
  • Evaluación de la calidad: Evalúe el estado de mantenimiento, el tamaño de la comunidad, la calidad de la documentación y las prácticas de seguridad.

Directivas organizativas:

  • Flujos de trabajo de aprobación: Implemente la evaluación previa al uso para la seguridad, las licencias y la calidad antes de adoptar nuevas dependencias.
  • Listas de paquetes aprobadas: Mantener listas seleccionadas de componentes previamente examinados que los desarrolladores pueden usar inmediatamente.
  • Educación para desarrolladores: Entrene a los desarrolladores sobre implicaciones de licencia, prácticas de seguridad y procesos de cumplimiento.
  • Supervisión continua: Realice un seguimiento de las actualizaciones de dependencias, los cambios de licencia y las divulgaciones de vulnerabilidades.

Conclusiones clave

A medida que implemente software de código abierto en su organización, recuerde estos principios esenciales:

Adoptar el código abierto estratégicamente: El código abierto proporciona enormes ventajas, como la velocidad de desarrollo, la calidad, el ahorro de costos y el acceso a la innovación. En lugar de evitar el código abierto debido a riesgos, implemente procesos de gobernanza que permitan la adopción segura.

Conozca las dependencias: Mantenga inventarios completos de todos los componentes de código abierto, incluidas las dependencias transitivas. No puede administrar los riesgos que no conoce, lo que hace que la visibilidad de dependencias sea fundamental para una administración eficaz de código abierto.

Descripción de las implicaciones de la licencia: Las distintas licencias tienen implicaciones considerablemente diferentes para el software comercial. Las licencias permisivas como MIT son seguras para software propietario; las licencias copyleft como GPL requieren trabajos derivados de origen abierto. Haga coincidir la selección de licencias con el modelo de negocio.

Evaluación de la compatibilidad de licencias: Compruebe que las licencias de distintos componentes se pueden combinar legalmente. Las licencias incompatibles pueden crear problemas legales que requieren una corrección costosa, incluido el reemplazo de componentes o reescrituras de código.

Implementación del cumplimiento automatizado: El seguimiento manual de licencias no se escala a aplicaciones modernas con cientos de dependencias. Use herramientas automatizadas para el examen de dependencias, la detección de licencias y la supervisión de vulnerabilidades.

Priorizar la seguridad: Las vulnerabilidades de seguridad de las dependencias afectan a la aplicación independientemente de dónde se originen. Implemente el examen continuo de vulnerabilidades y establezca procesos de actualización rápidos para las revisiones de seguridad críticas.

Administrar los riesgos de la cadena de suministro: Más allá de las vulnerabilidades conocidas, proteja contra los ataques de la cadena de suministro a través de la comprobación de paquetes, la evaluación de la reputación de origen, los registros privados y el anclaje de dependencias.

Equilibrar el control con libertad: Los desarrolladores necesitan libertad para usar herramientas y marcos modernos. En lugar de bloquear la adopción de código abierto, implemente flujos de trabajo de aprobación y listas de paquetes aprobados que permitan el uso seguro.

Instruir a su equipo: El conocimiento del desarrollador de las licencias y los problemas de seguridad es esencial. Los programas de aprendizaje ayudan a los desarrolladores a tomar buenas decisiones sobre la selección de componentes y comprender las directivas de la organización.

Supervisión continua: La administración de código abierto no es una actividad única. Las nuevas vulnerabilidades se divulgan constantemente, las licencias a veces cambian y los proyectos se pueden abandonar. La supervisión continua garantiza el cumplimiento y la seguridad continuos.

Al aplicar estos principios e implementar prácticas sistemáticas de administración de código abierto, permite a su organización aprovechar las inmensas ventajas del software de código abierto a la vez que administra de forma eficaz los riesgos operativos, legales y de seguridad.

Más información