El ritmo al que se revelan nuevas vulnerabilidades aumenta constantemente. Actualmente se sitúa en una media de 15,000 CVE al año. 2022 se destaca con más de 26,000 nuevos CVE reportados. Obviamente, no todas las vulnerabilidades son relevantes para su software. Para determinar si una vulnerabilidad en particular es un problema, primero debe determinar si está utilizando la biblioteca o el producto que contiene la vulnerabilidad y luego si está utilizando la versión y el módulo problemáticos de esa biblioteca. Finalmente, debe consultar con su equipo de desarrollo para ver si esa vulnerabilidad es relevante para su producto en particular y la forma en que ha utilizado esa biblioteca o producto vulnerable.
El proceso de resolver todo esto no es sencillo y puede llevar bastante tiempo. Tom Alrich, un conocido experto en ciberseguridad, estima que Alrededor del 95% de todos los CVE presentes en un producto de software en particular no son explotables.. Pero, si usted es un usuario final o una empresa que está a punto de integrar software de terceros en su sistema, ¿cómo puede identificar el 5% problemático para poder solicitar la solución o el parche adecuado?
Aquí es donde surge la idea de Llega el intercambio de vulnerabilidad y explotación (VEX). El propósito de VEX, tal como lo define guía de la Administración Nacional de Información y Telecomunicaciones de EE. UU. (NTIA) en 2021, es “proporcionar a los usuarios (por ejemplo, operadores, desarrolladores y proveedores de servicios) información adicional sobre si un producto se ve afectado por una vulnerabilidad específica en un componente incluido y, si se ve afectado , si existen acciones recomendadas para remediar”.
En este momento probablemente esté pensando: ¿cómo puedo obtener estos documentos VEX y comenzar a verificar mis componentes? Bueno, la realidad del uso de VEX es, como siempre, complicada.
Descubra el propósito de VEX
En pocas palabras, se supone que VEX responde rápida y fácilmente a la pregunta "¿mi versión de este software es explotable para este ¿vulnerabilidad?'.
Se supone que la respuesta a esa pregunta es una de cuatro opciones principales:
- No afectado: No se requiere ninguna solución con respecto a esta vulnerabilidad.
- Afectado: Se recomiendan acciones para remediar o abordar esta vulnerabilidad.
- Fijo: Estas versiones de productos contienen una solución para la vulnerabilidad.
- Bajo investigación: Aún no se sabe si estas versiones del producto se ven afectadas por la vulnerabilidad. Se proporcionará una actualización en una versión posterior.
Dado que se supone que VEX es legible y generado por máquina, la idea es tener una base de datos con capacidad de búsqueda de estos documentos en algún lugar para que cualquier parte interesada pueda consultarla y obtener la respuesta necesaria.
Dado que se supone que el 95% de las vulnerabilidades no son explotables en ningún producto de software determinado, este sistema está destinado a reducir las listas masivas de vulnerabilidades encontradas para cada producto a solo aquellas que el usuario debe vigilar o solicitar reparación o parches. para.
Hay una serie de datos interesantes sobre la historia de VEX.
En 2020, la NTIA (la Administración Nacional de Información y Telecomunicaciones de EE. UU.) comenzó a discutir la idea de VEX como herramienta de acompañamiento al SBOM (Lista de materiales del software). En septiembre de 2021, la NTIA publicó una introducción de una página y una explicación de lo que se supone que debe hacer VEX.
Posteriormente, el esfuerzo por perfeccionar los requisitos del nuevo formato de asesoramiento se realizó bajo el auspicio de CISA, la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU., que publicó su propio documento a principios de 2022, entraremos en más detalles y en algunos casos de uso en los que se suponía que ayudaría el documento VEX. El documento, un borrador, definía los campos mínimos requeridos del documento VEX de la misma manera que la NTIA definió los campos mínimos requeridos del SBOM.
Desde entonces, hubo dos intentos importantes de crear un formato de documentación VEX legible por máquina:
- El Marco Consultivo de Seguridad Común (CSAF) fue el primer formato disponible. Este formato fue lanzado a finales de 2022 por OASIS Open, una organización internacional sin fines de lucro dedicada a producir estándares de código abierto para ciberseguridad, blockchain, IoT y otras áreas.
- ciclón DX, un formato estandarizado para SBOM lanzado por OWASP (Open Web Application Security Project), que fue adaptado para crear también documentos VEX.
CSAF es un formato completo, pero para usarlo con éxito es necesario incluir múltiples campos y mucha metainformación, lo que hace poco probable una adopción real. La iniciativa CyclonDX VEX es mucho más delgada, por lo que al considerar qué estándar VEX usar, la mayoría probablemente optaría por con el formato CyclonDX.
Por qué VEX se ha topado con un obstáculo: Descubriendo los problemas que sabotean su éxito
VEX es una buena idea y podría proporcionar la valiosa capacidad de comprobar rápidamente si una vulnerabilidad particular es realmente explotable en un producto de software en particular.
Sin embargo, hay varios problemas que hasta ahora están obstaculizando su implementación:
- Responsabilidad de presentación: ¿quién debería estar a cargo de presentar los documentos VEX requeridos? ¿Son los productores de software? ¿Empresas de seguridad de terceros u organizaciones sin fines de lucro? ¿Una agencia gubernamental? ¿Qué pasaría si varias fuentes presentaran información contradictoria?
- Base de datos VEX: ¿quién o qué debería guardar y categorizar la información VEX? Suponiendo que algunos de los documentos describan problemas explotables en el software, ¿no existe el peligro de que la información caiga en manos equivocadas (maliciosas)?
- Los formatos actuales no cubren adecuadamente la cuestión de las versiones y menos aún el problema de las versiones combinadas.
Las versiones combinadas de software/paquete se refieren a la práctica de agrupar múltiples paquetes o componentes de software en una única versión o paquete de instalación.
Cuando se trata de parchear vulnerabilidades, las versiones combinadas de software/paquetes pueden ayudar o dificultar el proceso. Por un lado, tener un único paquete de instalación que incluya todos los componentes necesarios puede simplificar el proceso de identificación y parcheo de vulnerabilidades. En lugar de tener que identificar y parchear manualmente cada componente individual, simplemente puede aplicar el parche a todo el paquete.
Sin embargo, la otra cara de la moneda es que si un componente del paquete es vulnerable, todo el software es vulnerable. Esto significa que incluso si algunos de los componentes del paquete han sido parcheados, el paquete en general aún puede estar en riesgo si hay un solo componente sin parches presente.
Digamos que la versión 1 de la biblioteca A de su software tiene una vulnerabilidad. Ese problema sólo se manifiesta cuando la biblioteca A está presente con la versión 2 de la biblioteca B. Hay un parche de seguridad, pero no todos lo habrían instalado. Eso significa que el documento VEX para esa vulnerabilidad en su software debe cubrir todas las combinaciones posibles del producto, sus versiones, las bibliotecas contenidas, sus versiones y los posibles parches lanzados. Se trata de una gran cantidad de información compleja que no es fácil de expresar de forma sencilla.
- ¿Cómo cubriría VEX el software integrado en el hardware con todas las versiones y parches posibles disponibles allí? ¿De quién sería la responsabilidad de parchear este software considerando que usted mismo no puede abrir fácilmente el hardware y parchear las cosas?
Estos son sólo algunos de los problemas que cualquier herramienta automática para lidiar con VEX debería comprender y tener en cuenta.
¿No sería más fácil si pudieras solicitar y obtener información de cualquier versión?
La suposición de que la mejor manera de compartir esta importante información es mediante un documento es posiblemente errónea. Producir suficientes documentos VEX para cubrir cada combinación de versión, parche y vulnerabilidad es una tarea trascendental que, comprensiblemente, nadie quiere emprender.
Escriba ha creado una plataforma para rastrear y compartir información relacionada con la seguridad para cada compilación de un proyecto o producto de software en particular. Como parte de eso, cada compilación genera un SBOM preciso y una lista de vulnerabilidades descubiertas en el producto.
Scribe permite al productor de software agregar avisos en formato VEX a cada una de estas vulnerabilidades para observar si no son explotables, están bajo investigación, etc. Una vez que se publica una versión, toda la información de seguridad sobre esa versión se puede compartir con terceros interesados, usuarios. , reguladores, etc. Incluir la lista de vulnerabilidades así como la lista de asesoramiento VEX significa que el destinatario debería poder ver sólo aquellas vulnerabilidades que son un problema potencial en este producto en particular. Le quita gran parte de la carga tanto al productor de software, que puede incluir su producto en la lista blanca, como al consumidor de software, que comprende exactamente qué nivel de riesgo implica un producto de software específico.
Como el productor de software es el único que puede decir definitivamente si una vulnerabilidad particular es, de hecho, relevante para una versión particular del producto, son los únicos que pueden agregar y modificar avisos en sus propios productos. La opinión del productor de software a este respecto es definitiva e indiscutible. La decisión sobre con quién compartir esta información es también prerrogativa del productor de software.
Dado que Scribe guarda el historial completo de las compilaciones del producto, los SBOM y la información de seguridad, los usuarios pueden solicitar y obtener fácilmente esta información para cualquier versión que puedan estar utilizando durante todo el ciclo de vida del software.
Conclusión
Recuerde que cualquier análisis decente hoy en día de un producto de software produciría cientos, si no miles, de posibles vulnerabilidades. La mayoría de la gente no puede lidiar con semejante número. Aparece la fatiga de alerta y la cantidad de vulnerabilidades se convierte en solo eso: un número.
La posibilidad de reducir el número de problemas detectados a una cantidad manejable sería una gran ayuda para los productores y usuarios de software. El objetivo es centrarse únicamente en los problemas reales para que el productor de software pueda parchearlos y remediarlos lo antes posible.
Herramientas automatizadas, como Escriba ofrece una manera fácil de ver solo las vulnerabilidades relevantes para cada uno de sus proyectos y compilaciones, información que puede compartir fácilmente, lo que hace que la montaña de vulnerabilidades sea significativamente más pequeña y mucho más manejable.
Sin embargo, una advertencia importante es que este futuro, en el que solo podremos ver y responder fácilmente a las vulnerabilidades relevantes, no sería posible sin la participación activa de la comunidad de código abierto. Hoy en día, la mayor parte del código se compone de cantidades significativas de software de código abierto, por lo que necesitamos que los mantenedores y desarrolladores de dichas bibliotecas participen en el descubrimiento y la corrección de las vulnerabilidades explotables que plagan su código.
El problema de las vulnerabilidades relevantes y explotables no va a desaparecer, por lo que nos corresponde a todos encontrar la manera más eficiente y rentable de obtener la respuesta a la pregunta: "¿mi versión de este software es explotable para este vulnerabilidad'.
Este contenido es presentado por Scribe Security, un proveedor líder de soluciones de seguridad de la cadena de suministro de software de extremo a extremo, que ofrece seguridad de última generación para artefactos de código y procesos de desarrollo y entrega de código en todas las cadenas de suministro de software. Más información.
Artículos relacionados con
