
Las preocupaciones sobre la seguridad de la cadena de suministro de software han dominado los titulares negativos últimamente. Es probable que esto prepare el escenario para lo que se espera del próximo informe State of Open Source.
La colaboración entre OpenLogic de Perforce y la Iniciativa de código abierto (OSI) proporcionará a la industria una instantánea de los beneficios y desafíos para las organizaciones que utilizan software de código abierto. La encuesta, que se extiende hasta este mes, mide el uso diario y la gestión del software de fuente abierta.
Tal vez como preludio del informe, una investigación reciente sugiere pesimismo sobre las vulnerabilidades aparentemente irresolubles en el software de código abierto. Un hilo común recientemente descubierto se refiere al éxito o fracaso potencial de las implementaciones de listas de materiales de software (SBOM) en toda la industria.
Nueva herramienta SBOM para una mejor reparación de OSS
Empresa de gestión de terminales titanio Disponible el 1 de noviembre titanio Una lista de materiales de software (SBOM) ayuda a las organizaciones a proteger los activos digitales de las amenazas externas de las vulnerabilidades del software de código abierto, incluido OpenSSL v3.
La solución brinda a los equipos de TI y seguridad visibilidad granular y paquetes de remediación en tiempo real para cada aplicación en cada punto final en tiempo de ejecución. Tanium SBOM es particularmente beneficioso para las organizaciones del sector público que enfrentan nuevos requisitos regulatorios para la integridad y seguridad del software en los EE. UU. y el Reino Unido.
Aunque el software de código abierto impulsa la economía digital moderna, el proyecto de desarrollo de aplicaciones promedio contiene casi 50 vulnerabilidades que involucran 80 dependencias directas. Según Tanium, aunque las dependencias indirectas son más difíciles de encontrar, el 40 % o más de las vulnerabilidades están ocultas allí.
«Las vulnerabilidades de la cadena de suministro de software han estado en el centro de algunos de los incidentes cibernéticos más devastadores que hemos visto», dijo Nic Surpatanu, director de productos de Tanium.
«SBOM de Tanium enfrenta este desafío de frente, utilizando datos de punto final para desglosar componentes de software y eliminar debilidades, como las vulnerabilidades recientemente anunciadas en OpenSSL versión 3», continuó. «Esta claridad podría significar la diferencia entre problemas operativos menores o una interrupción global completa con efectos duraderos».
SBOM es un enfoque completamente nuevo para abordar las vulnerabilidades de la cadena de suministro. Se centra en el software que reside en activos individuales para detectar bibliotecas y paquetes con vulnerabilidades conocidas. El proceso de Tanium va más allá de las herramientas básicas de escaneo para examinar el contenido de archivos individuales ubicados en cualquier lugar del entorno de TI.
Este enfoque permite que Tanium tome medidas rápidas y apropiadas, como parches de aplicaciones y actualizaciones de software, incluida la finalización de procesos específicos o la desinstalación de aplicaciones afectadas. Tanium puede encontrar y corregir las vulnerabilidades actuales, como OpenSSL v3, así como las nuevas vulnerabilidades de la cadena de suministro del mañana.
«La vulnerabilidad Log4j arroja luz sobre los peligros del software de código abierto vulnerable», dijo Jason Bloomberg, presidente de la firma de analistas Intellyx.
«La capacidad de aprovechar los datos de punto final para el análisis de diagnóstico de entornos de software es fundamental, ya que las empresas confían cada vez más en muchas aplicaciones diferentes. Los datos SBOM de Tanium permiten a los equipos de seguridad administrar una amplia variedad de aplicaciones con la confianza de que pueden identificar y resolver las vulnerabilidades antes de que los clientes afectado adversamente”, explicó.
OpenSSL corrige dos vulnerabilidades de alta gravedad
El proyecto OpenSSL lanzó parches el 1 de noviembre para dos vulnerabilidades de seguridad de alta gravedad en su biblioteca criptográfica de código abierto, que se utiliza para cifrar los canales de comunicación y las conexiones HTTPS. Estas vulnerabilidades (CVE-2022-3602 y CVE-2022-3786) afectan a las versiones 3.0.0 y posteriores de OpenSSL.
El primero es un desbordamiento de búfer de pila arbitrario de 4 bytes que podría desencadenar un bloqueo o provocar una ejecución remota de código (RCE). Un atacante puede usar el segundo a través de un desbordamiento de búfer para iniciar una condición de denegación de servicio. El equipo de OpenSSL considera que estos problemas son vulnerabilidades graves, pero no ha encontrado ningún exploit válido que pueda conducir a la ejecución remota de código.
La advertencia inicial instó a los administradores del sistema a tomar medidas inmediatas para mitigar la vulnerabilidad. CVE-2022-3602 se calificó inicialmente como crítico, pero ahora se ha degradado a gravedad alta. Según los funcionarios del proyecto, a diferencia de las versiones anteriores de la biblioteca OpenSSL, estas versiones lanzadas recientemente aún no se han implementado en gran medida en el software utilizado en producción.
El CEO y cofundador de Chainguard, Dan Lorenc, señaló que esta grave vulnerabilidad es solo la segunda vulnerabilidad de OpenSSL en la última década. Esto refuerza la noción de que el código de fuente abierta es al menos tan seguro como el código de fuente cerrada patentado, dijo.
«Los principales proveedores bien financiados tienen muchas más posibilidades de encontrar este tipo de errores. En lugar de discutir sobre los méritos del código abierto, deberíamos centrarnos en crear un software seguro que tenga las herramientas necesarias al enraizarlo en una configuración predeterminada segura para remediar más rápido y sin problemas», agregó.
Si bien los SBOM han dominado la discusión desde la violación de SolarWinds, ninguna solución ha ayudado a las organizaciones a remediar estos problemas de manera efectiva, dijo Lorenc.
«Se necesita un nuevo enfoque para hacer que los SBOM sean válidos, confiables y completos. Para hacer esto, necesitamos generar SBOM en el momento de la compilación en lugar de después del hecho. La realidad es que las cadenas de suministro de software, no solo de código abierto, tienen muchos problemas hoy en día que no se puede resolver con una bala de plata o soluciones de un solo punto», dijo a LinuxInsider.
«Las soluciones de cadena de suministro fijas basadas en SCA de hoy en día han fallado y seguirán fallando en la seguridad de la cadena de suministro de software de nuestra industria. Si queremos eliminar este vector de amenazas, debemos incorporar la seguridad de manera predeterminada».
La vulnerabilidad de GitHub amenaza la cadena de suministro de software
La vulnerabilidad de GitHub podría afectar a todos los nombres de usuario renombrados en GitHub y permitir que los delincuentes tomen el control de los repositorios de GitHub, infectando todas las aplicaciones y otros códigos. Checkmarx Equipo SCS (Seguridad de la cadena de suministro). Los atacantes pueden haber apuntado a millones de usuarios a través de la cadena de suministro de código abierto.
Los investigadores informaron la vulnerabilidad a GitHub, que la clasifica como de «gravedad alta», y recientemente se aplicó una solución. A principios de este año, un atacante usó una vulnerabilidad similar para secuestrar y envenenar un popular paquete PHP con millones de descargas. Solo los lenguajes Go, PHP y Swift tienen más de 10.000 paquetes vulnerables a este vector de ataque.
Las implicaciones prácticas son que miles de paquetes de software pueden ser secuestrados a la vez y entregar código malicioso a millones de usuarios y muchas aplicaciones.
“No es tan diferente de otros problemas de la cadena de suministro que hemos visto en el pasado. Se está convirtiendo en un vector de ataque común que requerirá que las empresas que aprovechan los repositorios de software de código abierto tengan especial cuidado para asegurarse de que no solo entienden lo que están implementando, Y lo han inventariado en la Lista de materiales de software (SBOM cuando se encuentran cargas maliciosas o sospechosas en repositorios públicos, dijo a LinuxInsider Jim Kelly, vicepresidente regional de Tanium Endpoint Security) que les permitirá identificar y reparar más fácilmente.
Se crea una nueva ayuda para la cadena de suministro
Google anunció a fines de octubre la creación del proyecto de código abierto GUAC para mejorar la seguridad de la cadena de suministro de software. Graph for Understanding Artifact Composition (GUAC) se encuentra en sus primeras etapas, pero promete cambiar la forma en que la industria entiende las cadenas de suministro de software, según el blog de seguridad de Google. Este trabajo hará que los metadatos de seguridad del software sean más accesibles para los desarrolladores y otras partes interesadas.
Scott Gerlach, cofundador y CSO de API Security Testing Company, dice que GUAC es un buen comienzo para resolver problemas reales pila de águilaEs útil para proporcionar a los desarrolladores y equipos de seguridad una gran cantidad de información sobre la seguridad de las bibliotecas y los paquetes de código abierto.
«El truco aquí es involucrar a los desarrolladores de código abierto en tales iniciativas. ¿Cuáles son sus motivaciones? La mayoría de las veces, estas personas trabajan en proyectos por pasión por la resolución de problemas y un fuerte sentido de curiosidad. Motivar a los desarrolladores de OSS La participación será clave para el éxito de GUAC», dijo a LinuxInsider.
No existe una panacea para la seguridad de las aplicaciones. No solo debe trabajar en la seguridad de la cadena de suministro, sugiere, sino que también debe probar el código que escribe en busca de vulnerabilidades de AppSec. La construcción de un programa de seguridad fuerte incluye el monitoreo práctico y de producción.