Por qué su empresa necesita una lista de materiales de software

La vulnerabilidad más reciente, Log4j, ha revelado problemas sistémicos con las pruebas de su software por parte de las empresas y toda la comunidad.

Los primeros indicios muestran que la vulnerabilidad Log4j fue utilizada y explotada como arma Días antes de que se conociera la noticia de su existencia. Las empresas tenían que tomar medidas inmediatas para encontrar todas las instancias de la vulnerabilidad en las bibliotecas vinculadas, pero la mayoría no tenía una visión clara de dónde se encontraban dichas instancias en sus sistemas. La propia investigación de Google ha demostrado que más del 8% de todos los paquetes en Maven Central tienen una versión vulnerable de Log4j en sus dependencias, pero solo una quinta parte de ese grupo lo ha declarado directamente. Esto significa que alrededor de 28 000 paquetes en Maven Central se ven afectados por estos errores, mientras que Log4j nunca se declara ni se usa directamente.

Encontrar todas las instancias de dependencias vulnerables y confirmar los niveles de parches puede ser una tarea abrumadora, incluso para el software que usted mismo controla y desarrolla por completo. Identificarse con sus proveedores puede ser aún más difícil. A menudo, estos proveedores tienen una noción igualmente sombría de sus propias dependencias.

Al igual que con todos los demás activos de TI, como servidores, computadoras portátiles o aplicaciones instaladas, un inventario preciso de su software y dependencias (tanto directas como transitivas) es un control de seguridad esencial y posiblemente el más básico que puede aplicar. Las empresas no pueden asegurar lo que no conocen. ¿Cómo comienzan las empresas a hacer frente a la creciente complejidad de las dependencias? Al examinar y automatizar los gráficos de dependencia, comenzando con las dependencias directas hasta las transitivas, a menudo denominadas listas de materiales de software (SBOM).

Aunque la discusión sobre lo que debe ser y contener un SBOM tiene matices, a los fines de este artículo simplemente nos referimos a un SBOM de manera informal como el manifiesto de todos los componentes y bibliotecas que se empaquetan con una aplicación junto con sus licencias. Esto incluye herramientas y bibliotecas vinculadas. Cuando proporciona una imagen de Docker, también debe contener la lista de todos los paquetes instalados.

Tómese en serio su cadena de suministro de software

Desafortunadamente, el ecosistema para generar estos mapas de dependencia a menudo carece de herramientas adecuadas. Si bien las herramientas disponibles para analizar las dependencias de vulnerabilidad están evolucionando y mejorando rápidamente, el dominio aún está en pañales. Snyk, Anchore y otras herramientas brindan una visión sorprendente de las dependencias de su aplicación, pero pocos idiomas ofrecen herramientas nativas para generar mapas visuales enriquecidos. Como ejemplo, considere un lenguaje más antiguo (Java) y un lenguaje más nuevo (Go) que usaron el tiempo y la experiencia para desarrollar un ecosistema de paquete moderno.

En Java, los desarrolladores pueden usar herramientas como jdeps (introducido en JDK 8) o Maven Dependency Analyzer, mientras que Golang, a pesar de su modernidad, tuvo problemas desde el principio para resolver su propio historial de administración de dependencias y, en cambio, permitió herramientas como Dep (obsoleto y archivado) para llenar los vacíos antes de comprometerse finalmente con su propio sistema modular. En cualquier caso, las dependencias directas suelen ser fáciles de enumerar, pero puede ser difícil crear una lista completa y completa de dependencias directas y transitivas sin herramientas adicionales.

Para los mantenedores de código abierto, Google ha iniciado un proyecto muy útil llamado Open Source Insights para revisar proyectos alojados en NPM, PyPI o Github o ubicaciones similares. Ya se está haciendo mucho trabajo e investigación en esta área, pero está claro que se necesita hacer más.

Si bien es importante que las aplicaciones mismas sean revisadas en busca de dependencias y vulnerabilidades, ese es solo el comienzo de la historia. Así como un informe de inventario o vulnerabilidad solo puede decirle lo que existe, un SBOM es solo un manifiesto de paquetes y dependencias. Estas dependencias deben ser revisadas en su estado relativo, más allá de los posibles puntos débiles. Por ejemplo, es posible que una dependencia no cumpla con los requisitos para informar al Instituto Nacional de Estándares y Tecnología (NIST), y no se puede asignar una exposición de vulnerabilidades comunes (CVE) por algún motivo, ya sea un problema con abandonware o un problema completamente interno. producto que es relativamente no probado. Otras razones por las que es posible que no se informe son la propiedad o el mantenimiento de la biblioteca que se ha transferido a un mal actor, los malhechores modifican deliberadamente las publicaciones, los paquetes obsoletos y vulnerables en el contenedor Docker en el que se ejecuta la aplicación y/o los hosts que usan núcleos antiguos. con conocido, crítico. ejecutar CVE.

Los oficiales de seguridad de la organización tienen la responsabilidad de estudiar y pensar detenidamente sobre cualquier problema de la cadena de suministro de software que pueda afectar sus productos o negocios. Todo esto comienza con un inventario preciso de las dependencias en el SBOM.

Generar un SBOM

Generar un SBOM puede ser un desafío técnico en sí mismo, pero recuerde que las organizaciones están compuestas por personas y procesos. Comprender y evangelizar la necesidad de tal trabajo es vital para obtener la aprobación. Como se mencionó anteriormente, los oficiales de seguridad corporativa deben comenzar por hacer un inventario de todo su software interno, contenedores y paquetes o aplicaciones de terceros. Una vez que se completa el primer nivel de inventario, el siguiente paso es determinar las dependencias directas y, en última instancia, las dependencias transitivas. Este proceso debe usarse para todos los demás procesos de reconocimiento, p. Como el registro de eventos o el inventario.

Al evangelizar una SBOM en su organización, considere los siguientes beneficios:

1. Un inventario completo, actualizado y preciso de las dependencias de su software reduce drásticamente el tiempo de reparación cuando se descubren vulnerabilidades en paquetes como Log4j.

2. Un manifiesto generado durante el proceso de CI/CD también proporciona comentarios instantáneos sobre nuevas dependencias y puede evitar que se agreguen componentes nuevos y vulnerables a su software al hacer cumplir las pautas en el momento de la compilación.

3. Suele decirse que lo que se mide mejora. Vigilar sus adicciones promoverá la higiene al eliminar las adicciones innecesarias y eliminar las viejas.

4. Promueve la coherencia en el control de versiones del software y ahorra tiempo y dinero a los equipos de ingeniería y seguridad.

5. Pronto se convertirá en un requisito de cumplimiento para muchas empresas, según la Casa Blanca.

A medida que la complejidad de nuestras pilas de software continúa creciendo y las cadenas de suministro se vuelven objetivos cada vez más tentadores y útiles para los atacantes, las técnicas y herramientas como la gestión de dependencias y los SBOM deben convertirse en partes integrales de nuestra estrategia de seguridad general. Y los oficiales de seguridad tienen la responsabilidad de brindar estos beneficios de estas herramientas a sus organizaciones.

Bren Briggs es el Director de DevOps y Ciberseguridad en Hypergiant.