El software es el núcleo de todas las empresas modernas y es crucial en todos los aspectos de las operaciones. Casi todas las empresas utilizarán software de código abierto, a sabiendas o no, ya que incluso el software propietario depende de bibliotecas de código abierto. de OpenUK El informe "State of Open" de 2022 encontró que el 89% de las empresas confiaban en el software de código abierto, pero no todas tienen claros los detalles del software en el que confían.
Las empresas exigen cada vez más información sobre su software de operación crítica. Las empresas responsables están tomando un interés detallado en su cadena de suministro de software y creando una lista de materiales de software (SBOM) para cada aplicación. Este nivel de información es crucial para que cuando se identifiquen fallas de seguridad en su software, puedan estar seguros de inmediato qué software y versiones están en uso y qué sistemas están afectados. ¡El conocimiento es poder en estas situaciones!
Dependencia de los voluntarios
A fines de 2021, una vulnerabilidad de seguridad llamada Log4Shell se identificó en un marco de registro de Java ampliamente utilizado, Log4j. Dado que se trata de una biblioteca de código abierto ampliamente utilizada, la vulnerabilidad fue bien publicitada y se esperaban correcciones. sin embargo, el los mantenedores del proyecto eran voluntarios. Tenían trabajos diurnos y no estaban de guardia para arreglos de seguridad urgentes, incluso si una gran cantidad de sistemas se vieron afectados. Se estimó que esta vulnerabilidad por sí sola afectó al 93 % de los entornos de nube empresarial.
En ese momento, había cierta prensa negativa sobre el código abierto, pero la verdad es que si se tratara de un componente de código cerrado, es posible que la vulnerabilidad nunca se hubiera conocido públicamente, dejando a las organizaciones expuestas a ataques. La naturaleza de código abierto de la biblioteca significaba que podía ser inspeccionada, los problemas encontrados y los consejos ofrecidos por otros. Entonces, sí, los mantenedores no estaban de guardia por problemas de seguridad en su proyecto de voluntariado. Entonces, la gran pregunta es: ¿Cómo llegamos a una situación en la que las principales empresas dependían de un software que era responsabilidad de alguien que hace otra cosa para pagar sus facturas?
El descuido de las dependencias del software es un negocio riesgoso cualquiera que sea la licencia del software, pero cuando es de código abierto y se usa mucho, se vuelve especialmente peligroso. Siguiendo con la historia de una vulnerabilidad; el problema había existido en el código base durante años, pero no se detectó. De hecho, la herramienta que se usaba tan ampliamente no tenía tanto apoyo, y lo que paso despues es historia.
Esta historia se repite una y otra vez en tantos negocios que tienen dependencias críticas pero que no toman medidas para respaldar a los mantenedores o los proyectos mismos. Tener un SBOM para el software utilizado por una empresa significa que tienen la información a mano. Para las organizaciones que suministran software a otras, la expectativa de suministrar el SBOM junto con el código es cada vez más la norma.
Conozca las dependencias para evaluar el riesgo
Aportar el conocimiento de las dependencias facilita la evaluación del riesgo asociado a cada una. Estos proyectos de código abierto son los más simples de evaluar: ¿se responde a los problemas y ha habido algún lanzamiento recientemente? Poder ver los mantenedores y la actividad del proyecto para cada proyecto brinda una buena perspectiva de la salud del proyecto.
Las empresas pueden desempeñar su papel para reducir los riesgos apoyando los proyectos de los que dependen. Algunos proyectos aceptan el patrocinio directamente a través del esquema de Patrocinadores de GitHub, mientras que otros pueden apreciar las ofertas de alojamiento o una auditoría de seguridad. Todo proyecto de código abierto agradece las contribuciones. Si su empresa hubiera creado esta biblioteca por sí misma, los ingenieros de la empresa tendrían que corregir todos los errores por sí mismos.
El código abierto es más como un esquema de propiedad compartida. No todos tenemos que construir lo mismo repetidamente, sino que podemos contribuir, lo que implica menos esfuerzo y, como resultado, conduce a una mejor calidad. Una de las cosas más impactantes que pueden hacer las empresas es usar un poco de sus recursos de ingeniería y contribuir a la corrección de errores o características de los proyectos que son tan fundamentales para el negocio.
Mantener a sus propios ingenieros involucrados en un proyecto tiene muchos beneficios. Llegan a conocerlo y pueden estar atentos a las nuevas funciones o cuando hay una nueva versión disponible. De manera crucial, el negocio tiene una idea de la salud y el estado del proyecto dependiente y es parte de lo que lo mantiene saludable, reduciendo el riesgo para el negocio de un problema con una dependencia. Varias organizaciones, incluida Aiven, tienen una OSPO (oficina de programas de código abierto), con personal dedicado a contribuir o incluso mantener los proyectos utilizados por la organización. Estos departamentos a menudo contribuyen a la presencia general de la empresa en el ecosistema de código abierto y permiten que otros empleados se comprometan con el código abierto.
Otro enfoque es apoyar a las organizaciones que existen para apoyar el código abierto. El OpenSSF (Fundación de seguridad de código abierto) trabaja para mejorar la seguridad de los proyectos de código abierto y está financiado por las organizaciones que dependen de esos proyectos. También publica excelentes recursos de aprendizaje para que las empresas puedan informarse sobre los riesgos del software que utilizan. Otra organización similar es Tidelift, que se asocia con mantenedores para garantizar que se cumplan ciertos requisitos básicos, nuevamente financiado por las organizaciones. Tidelift también proporciona herramientas y educación para ayudar a las empresas a administrar su cadena de suministro de software y adoptar las mejores prácticas en esta área.
Asegurar un futuro de software más seguro
Las empresas dependen del software, y esto incluye el software de código abierto, que se usa ampliamente y, por lo general, es más seguro que las alternativas propietarias.
Este es un movimiento inteligente, pero un movimiento aún más inteligente es tener un conocimiento claro de la cadena de suministro de software y sus dependencias. Cuando surge un problema, depender de proyectos saludables y tener los detalles de su software disponibles ayuda a todas las organizaciones. Si todas las organizaciones hicieran esto, se reduciría el riesgo de tener eventos como la vulnerabilidad Log4Shell.