Las empresas que utilizan código fuente abierto (incrustado en la mayoría del software empresarial) deben realizar un inventario completo de su existencia. Esto falta en muchos registros corporativos de TI.
Las empresas no pueden monitorear las políticas, licencias, vulnerabilidades y versiones del software sin estadísticas detalladas sobre el código fuente abierto que se ejecuta en el software. Esto significa que los departamentos de TI no tienen idea del estado general de los componentes de código abierto que utilizan.
El problema es que muchas empresas están convencidas de que no usan código abierto, por lo que no tienen que preocuparse por mantener actualizados los parches de seguridad y las actualizaciones de código. Este malentendido a menudo conduce a violaciones de la red que conducen a ataques de malware y ransomware.
2022 Sinopsis El informe Open Source Security and Risk Analysis (OSSRA) publicado el mes pasado reveló que la cantidad de código fuente abierto que se ejecuta en el software está en su punto más alto. Los problemas con el uso de código abierto continúan creciendo año tras año.
El código fuente abierto es omnipresente en paquetes de software que van desde aplicaciones comerciales hasta redes y procesos de servidor. Incluso las vulnerabilidades conocidas pasarán desapercibidas a menos que las empresas hagan un esfuerzo concertado para catalogar y monitorear cómo sus organizaciones usan piezas de código fuente abierto.
Tim Mackey, estratega jefe de seguridad de Synopsys SIG, dijo que abordar los problemas destacados en el informe implica problemas de propiedad.
Los resultados sugieren un reconocimiento tácito de que el software que impulsa una empresa puede no estar bajo el control de sus gerentes. También muestra que el código fuente abierto en los productos comerciales puede no cumplir con los estándares de los que hacen responsables a sus propios equipos.
«Dado que los datos de origen de OSSRA provienen de los esfuerzos de diligencia debida técnica relacionados con la actividad de fusiones y adquisiciones, en lugar de encuestas, el informe de OSSRA refleja el estado actual del uso del software en lugar de una vista de su condición probable», dijo Mackey a LinuxInsider.
brutal verdad revelada
El informe OSSRA de 2022 revisó los hallazgos anónimos de más de 2400 bases de códigos comerciales en 17 industrias. Los resultados resumidos en este gráfico deberían ser una llamada de atención para los reguladores de TI empresariales.
Fuente: Informe de análisis de riesgo y seguridad de código abierto de 2022 (Fuente: Synopsys)
El informe es una advertencia de crisis, especialmente dado el impacto continuo del brote. Vulnerabilidades Log4J apareció a finales del año pasado.
De los 2400 repositorios de códigos comerciales en 17 industrias, 2097 incluyeron evaluaciones de seguridad y riesgos operativos. El número de bases de código auditadas por Synopsys aumentó un 64 % con respecto al año pasado. Gran parte de este crecimiento provendrá de fusiones y adquisiciones en 2021.
Mackey señaló la amenaza a la seguridad que plantea Log4j como una de las principales razones por las que el presidente Biden impulsó su orden ejecutiva de seguridad cibernética a fines del año pasado.
También es fundamental que el informe OSSRA motive a los CISO empresariales, los vicepresidentes de ingeniería y los CTO a analizar su uso de software de código abierto y comprender qué tan bien se asignan los datos de OSSRA a sus propios procesos y gobierno.
«El informe OSSRA enfatiza constantemente que el problema con el código abierto no es el código fuente abierto en sí mismo, sino cómo la gente lo usa», agregó. «El código descargable gratuito es excelente para una billetera, pero eso no significa que pueda administrarse utilizando los mismos procesos que el software comercial».
SBOM sin arreglos genéricos
Un principio clave del informe OSSRA es que pueden surgir riesgos del uso no regulado de código abierto. El informe concluye que existe una gran diferencia entre la falta de gobernanza de código abierto y el hecho de que el código abierto en sí mismo no es un problema.
El código abierto es ahora la base del software comercial, señalan los investigadores. Está presente en el 97% del software comercial. A pesar de la ubicuidad del código abierto, todavía existe la idea errónea de que el código abierto es inherentemente peligroso.
anunciar
McKee observó que, a diferencia de los productos de Microsoft y Apple, en los que los proveedores de software pueden enviar actualizaciones y parches de manera proactiva a los usuarios conocidos, el código abierto no tiene proveedores que se ocupen de la gestión de riesgos.
«Las soluciones de administración de parches existentes a menudo están orientadas hacia un modelo de actualización», agregó. «El software descargable gratuito significa que los productores de software no saben quiénes son sus clientes, ni siquiera si están usando el software que descargan.
El proceso de parcheo y sus suposiciones se pierden cuando uno se enfoca en los siguientes temas Lista de materiales del software (SBOM) es la panacea para la gestión de código abierto, según Mackey. Resolver este problema requiere ir más allá del SBOM.
SBOM, dijo, es simplemente una herramienta de mejora de procesos diseñada para diferentes tipos de consumo de software. Además, la industria debe centrarse en identificar y monitorear los componentes de código abierto en el software comercial que utilizan. Eso es lo que se debe hacer para corregir los problemas identificados en el informe OSSRA, dijo McKee.
Arreglar lo que se puede arreglar
El uso de componentes de código abierto obsoletos requiere que las empresas cuenten con un proceso para monitorear cuándo sus componentes se vuelven obsoletos. Pero no se trata solo de declarar explícitamente dependencias o elegir un proveedor aprobado. McKee cree que la raíz del problema se encuentra en la cadena de suministro.
«La experiencia de Log4Shell es un ejemplo perfecto de un componente subyacente que pocas personas conocen. Pero una vez que Log4j pasó a ser el centro de atención debido al impacto de la vulnerabilidad de Log4Shell, [it] Obliga al equipo a luchar para encontrar la mejor manera de manejarlo», señaló.
Esta es una solución imprescindible para los usuarios empresariales de software empresarial. Inventariar la existencia de componentes de código abierto. Luego configure y ejecute el monitoreo, así como parches y actualizaciones.
«Cualquiera que sea el proceso que utilicen estos equipos para administrar con éxito su experiencia Log4j a escala, debe aplicarse a los otros componentes. En otras palabras, use la experiencia Log4j para crear una solución más escalable para su organización», insta Mackey.
