El Manual de buen gobierno de OSS está diseñado como una guía para las empresas que promueve el uso adecuado del software de código abierto y protege a las empresas de amenazas técnicas, legales y de propiedad intelectual.
El manual es una creación de la alianza Open Source Program Office (OSPO) recién formada, una coalición de organizaciones europeas líderes sin fines de lucro de código abierto que incluyen OW2, Eclipse Foundation, OpenForum Europe y Foundation for Public Code, con la misión de crear conciencia abierta fuente de software y promover su gestión estructurada y profesional por parte de empresas y administraciones.
Hay dos perspectivas sobre la ejecución de un proyecto de software de código abierto; uno es el del gerente / técnico de mantenimiento / colaborador y el otro el de la empresa que lo cuenta. Cubrí el primer aspecto en «Las guías de código abierto para la gestión de proyectos de software de código abierto», que examina otro manual, una serie de guías de Github que detallan los detalles del lanzamiento, la gestión, el mantenimiento y la contribución a proyectos abiertos.
La otra cara de la moneda es sacar el software de las manos de los fabricantes y usarlo en un entorno empresarial, que a menudo requiere integración con otro software, especialmente bibliotecas. Por supuesto, una empresa también puede desempeñar el papel de contribuyente, retribuyendo al proyecto y a la comunidad en general.
Todos sabemos lo omnipresente que es el software de oss en cualquier entorno, ya sea en el hogar, en el trabajo o en el entorno empresarial. Es tan omnipresente que se ha infiltrado tanto en la mentalidad colectiva que la Comisión Europea acaba de anunciar que adoptará nuevas reglas que permitirán que sus soluciones de software sean de código abierto y accesibles al público siempre que existan beneficios potenciales para los ciudadanos, las empresas. .u otros servicios públicos. Y con razón, ya que un estudio demostró que:
La inversión en código abierto genera, de media, una rentabilidad cuatro veces superior para la economía de la UE.
El amor de la Comisión Europea por el código abierto se remonta más atrás que la reciente iniciativa, cuando inició una recompensa de errores patrocinada por el estado que muestra que entre los burócratas hay personas conocedoras de la tecnología que comprenden el verdadero valor del software. OSS para la sociedad y, como tal, el impacto cuando su seguridad falla.
Esta recompensa por errores es parte del proyecto Free and Open Source Software Audit (FOSSA), gracias a la eurodiputada Julia Reda del Partido Pirata de la UE, quien comenzó el proyecto pensando que era suficiente después de que se descubrieron graves vulnerabilidades en componentes clave de la infraestructura, como OpenSSL. Esto la llevó a involucrar a la Comisión Europea en la contribución a la seguridad de Internet. Más información sobre «EU Bug Bounty – La seguridad del software como ley civil».
Entonces, habiendo establecido cuán beneficioso es el OSS para la sociedad, veámoslo desde un entorno corporativo. Una empresa debe implementar una gestión profesional y hacer malabares con mucho equipaje al adoptar software de código abierto, especialmente al compilar código que tiene una combinación de dependencias. El Manual de buen gobierno de OSS ha clasificado estas actividades en:
Negocio de confianza
Gestionar el cumplimiento legal
Gestionar vulnerabilidades de software
Gestionar dependencias de software
Gestionar indicadores clave
Realizar revisiones de código
Actividades culturales
Promover las mejores prácticas de desarrollo de código abierto
Contribuir a proyectos de código abierto
Pertenece a la comunidad de código abierto
Perspectiva de recursos humanos
Río arriba primero
Actividades de participación
Interactuar con proyectos de código abierto
Apoya a las comunidades de código abierto
Interactuar con proveedores de código abierto
Afirmar públicamente el uso de código abierto
Política de adquisiciones de código abierto
Actividades estratégicas
Establecer una estrategia de gobierno corporativo de código abierto
Conciencia de nivel C
Código abierto y soberanía digital
El código abierto permite la innovación
Código abierto que permite la transformación digital
teniendo en cuenta los siguientes requisitos:
Se cubre cualquier tipo de organización: desde pymes hasta grandes empresas y organizaciones sin fines de lucro, desde autoridades locales (por ejemplo, ayuntamientos) hasta grandes instituciones (por ejemplo, instituciones europeas o gubernamentales). La estructura proporciona bloques de construcción para una estrategia y sugerencias para su implementación, pero la forma en que se realizan las actividades depende completamente del contexto del programa y depende del administrador del programa.
No se hacen suposiciones sobre el nivel de conocimiento técnico dentro de la organización o el dominio empresarial. Por ejemplo, algunas organizaciones necesitarán establecer un plan de estudios de capacitación integral, mientras que otras pueden simplemente proponer material ad hoc a los equipos.
Cada talón de actividad se divide en las siguientes secciones:
Descripción Evaluación de oportunidades Herramientas de evaluación del progreso Recomendaciones Recursos
Como ejemplo práctico de lo que incluye cada stub, proporcionamos un pequeño ejemplo de la actividad Gestionar vulnerabilidades de software.
Descripción
Su código es tan seguro como su parte menos segura. Casos recientes (por ejemplo, heartbleed1, equifax2) han demostrado la importancia de verificar las vulnerabilidades en partes del código que no son desarrolladas directamente por la entidad. Las consecuencias de las exposiciones van desde fugas de datos (con un gran impacto en la reputación) hasta ataques de ransomware y la falta de disponibilidad de servicios que amenazan la empresa.
Evaluación de la oportunidad
Cualquier empresa que utilice software debe comprobar sus vulnerabilidades en:
su infraestructura (p. ej., infraestructura en la nube, infraestructura de red, almacén de datos), sus aplicaciones comerciales (recursos humanos, herramientas CRM, gestión de datos internos y de clientes), su código interno: p. ej. sitio web de la empresa, proyectos de desarrollo interno, etc., y todas las dependencias directas e indirectas de software y servicios.
El ROI de las vulnerabilidades no se comprende bien hasta que sucede algo malo. Las consecuencias de una importante filtración de datos o la falta de disponibilidad de servicios deben tenerse en cuenta para estimar el costo real de las vulnerabilidades.
Evaluación de progreso
Debe haber una persona o equipo dedicado para monitorear las vulnerabilidades y los procesos fáciles de usar en los que los desarrolladores puedan confiar. La evaluación de vulnerabilidades es una parte estándar del proceso de integración continua y las personas pueden monitorear el estado de riesgo actual en un tablero dedicado.
Los siguientes puntos de verificación demuestran el progreso en esta actividad:
La actividad se cubre cuando todo el software y los servicios internos se evalúan y monitorean para detectar vulnerabilidades conocidas. La actividad se cubre cuando se implementa una herramienta y un proceso dedicados en la cadena de producción de software para evitar la introducción de problemas en las rutinas de desarrollo diarias. Una persona o equipo es responsable de evaluar el riesgo / vulnerabilidad de CVE con respecto a la exposición. Una persona o equipo es responsable de enviar CVE / vulnerabilidades a las personas afectadas (SysOps, DevOps, desarrolladores, etc.).
Instrumentos
Herramientas de GitHub
GitHub proporciona pautas y herramientas para proteger el código alojado en la plataforma. Para obtener más información, consulte los documentos de GitHub.
GitHub proporciona Dependabot para identificar automáticamente vulnerabilidades en dependencias. Eclipse Steady es una herramienta gratuita y de código abierto que analiza los proyectos de Java y Python en busca de vulnerabilidades y ayuda a los desarrolladores a mitigarlas. Comprobador de dependencias de OWASP: un escáner de vulnerabilidades de código abierto. Kit de herramientas de revisión de OSS: un orquestador de código abierto capaz de recopilar alertas de seguridad para las dependencias utilizadas por los servicios de datos de vulnerabilidad configurados.
En la sección Herramientas agregaría Semgrep o Qodana.
Obviamente, otro problema espinoso es la gestión de la dependencia del software. La seguridad de la cadena de suministro está de moda en este momento. Analizamos las implicaciones y las modalidades de mitigación en «¿Sigstore realmente protege la cadena de suministro?» La respuesta de la Fundación Linux a los ataques a la cadena de suministro:
Para construir software útil no reinventamos la rueda, sino que confiamos en el trabajo ya realizado que viene empaquetado en forma de bibliotecas. El problema es que incluso un proyecto de código abierto mediocre puede tener muchas de esas dependencias que a su vez dependen de otras, formando una cadena larga. Eso no es un problema en sí mismo, a menos que un código malicioso o una vulnerabilidad de seguridad encuentre su camino en algún lugar de esta cadena.
El manual contiene una buena lista de herramientas, recursos y pautas. A primera vista recomienda:
Realice verificaciones periódicas sobre las dependencias y los requisitos de IP para mitigar los riesgos legales. Idealmente, integre la gestión de dependencias en el proceso de integración continua para que los problemas (nueva dependencia, incompatibilidad de licencias) se identifiquen y resuelvan lo antes posible. Realice un seguimiento de las vulnerabilidades de dependencia, mantenga informados a los usuarios y desarrolladores. Eduque a las personas sobre los riesgos asociados con una licencia incorrecta. Proponga una solución simple para que los proyectos configuren el control de licencias en su código base. Comunique su importancia y ayude a los proyectos a agregarla a sus sistemas de CI. Establezca un KPI visible para los riesgos de adicción.
La primera versión del Manual GGI se publicó en octubre de 2021. Se planean otras iteraciones para mejorar el contenido y articular mejor la metodología de implementación.
