Territorio Móvil
Linux
Por qué debería usar SPDX para la seguridad

Por qué debería usar SPDX para la seguridad

Por Phil Odence

Software Package Data Exchange® (SPDX®) es un formato estándar para describir una lista de materiales de software que admite una serie de casos de uso, sobre todo SBOM para gestionar vulnerabilidades. SPDX ha sido un proyecto abierto bajo los auspicios de la Fundación Linux durante más de una década, siempre con el propósito de describir contenido de software. SPDX se convirtió recientemente en un estándar ISO. (https://www.iso.org/standard/81870.html) SPDX se adelantó a su tiempo y se desarrolló originalmente teniendo en cuenta el cumplimiento de la licencia, pero también se ha convertido en un estándar para admitir casos de uso de seguridad, como la ciberseguridad. y reconocida Agencia para la Seguridad de la Infraestructura (CISA). Probablemente, el caso de uso más complejo es la inclusión de información de licencia y derechos de autor en los paquetes de software. Esto se debe a que la propiedad legal puede ser del paquete, los archivos que contiene e incluso una pequeña colección de líneas de código. Para admitir completamente dicho uso, este estándar debe ser capaz de manejar la granularidad que también requieren algunos casos de uso de seguridad. Además, el análisis legal requiere una lista estándar e inmutable de licencias, su texto y formas de expresar situaciones de licencia complejas. Entonces, SPDX contiene una colección de licencias (también heredadas de otros proyectos) y un lenguaje de expresión de licencias. Al comienzo del proyecto, hubo interés en una versión más liviana que fuera menos complicada y permitiera a las empresas proporcionar información sobre licencias de paquetes en un formato estándar. El estándar se desarrolló para especificar un conjunto básico de campos obligatorios y un superconjunto de campos opcionales. Este concepto sentó las bases para los «perfiles», que actualmente se están definiendo, varios conjuntos de campos obligatorios y opcionales requeridos para un caso de uso específico. Otra dimensión importante del desarrollo de SPDX fue la adición de relaciones y referencias a documentos externos. Esto se desarrolló originalmente con la idea de vincular diferentes documentos SPDX, por ejemplo, para permitir que la estructura de una descripción SPDX refleje la estructura del software que describe. Sin embargo, la funcionalidad central permite la vinculación a otros tipos de documentos y es fundamental para respaldar la vinculación y SBOM con la información de seguridad asociada. El reciente aumento de interés en los SBOM se ha centrado en el caso de uso de la seguridad, impulsado por el clima general de riesgo de ciberseguridad y específicamente por la intención del gobierno de los EE. UU. de exigir SBOM a los proveedores. SPDX se ha estado moviendo en esta dirección durante algún tiempo y la especificación incluye la funcionalidad para respaldarlo. En la versión 2016, se lanzó la versión 2.1 de SPDX, que incluía campos de referencia externos específicos para los casos de uso de seguridad. La versión 2.3 actual estaba dirigida específicamente a aumentar el soporte de seguridad, y un perfil clave planificado para la versión 3.0 está dirigido a este caso de uso. SPDX aprovecha la capacidad de referencia externa de SPDX y agrega nuevas categorías de referencia para ayudar a vincular documentos de seguridad. Apéndice K de la especificación: Cómo usar SPDX en diferentes escenarios https://spdx.github.io/spdx-spec/v2.3/how-to-use/ entra en detalles y proporciona ejemplos de cómo vincular a diferentes vulnerabilidades . recursos relacionados, incluidos CPE, CVE, información VEX, incluida información de seguridad en formato CSAF, correcciones de código y otra información. También hay una sección que asigna los elementos mínimos de la NTIA a los campos correspondientes en SPDX. SPDX 3.0, actualmente en desarrollo activo, amplía el concepto de perfil introducido en 2.2 y presenta un perfil diseñado específicamente para la seguridad. Con 3.0, los documentos SPDX incorporarán más contexto para los datos de seguridad asociados, lo que permitirá la eficiencia de la herramienta. Los perfiles son conjuntos de campos obligatorios y opcionales para un caso de uso específico. Si un documento se ajusta a la especificación depende del caso de uso. Por ejemplo, un SBOM centrado en la seguridad puede no tener las características requeridas para cumplir con el perfil regulatorio, pero de lo contrario podría tener todos los campos requeridos para cumplir con ambos. Un perfil principal contiene un conjunto mínimo de elementos para describir un paquete de software aproximadamente equivalente a lo que antes se conocía como SPDX Lite. Además, habrá múltiples perfiles, incluidos los de seguridad, legales y otros, p. B. uno para aplicaciones de IA o uno que contiene información de compilación. Una referencia externa clave será la documentación de CISA Vulnerability Exploitability Exchange, una evaluación planificada, legible por máquina y proporcionada por el proveedor, de las vulnerabilidades en su software. VEX sigue siendo un objetivo en movimiento y varios «sabores» parecen estar emergiendo sin que se establezca un estándar. En cualquier caso, SPDX 3.0 lo admitirá. Además, en base a las contribuciones de varios proyectos de código abierto, el grupo está considerando incluir un conjunto simple de elementos mínimos de seguridad como campos SPDX opcionales en el perfil de seguridad. Esta no sería una nueva alternativa a CSAF o VEX, sino más bien una manera fácil para que los proyectos que no están diseñados para profundizar proporcionen la información básica de seguridad común a todos los formatos de descripción de vulnerabilidades. Un desafío para cualquiera que intercambie SBOM (en cualquier formato) sigue siendo la referencia clara de los elementos de software. «Log4j» de un SBOM es «Apache Log4j» de otro. Es un problema similar al que resolvió SPDX para las referencias de licencia. Una vaga analogía: si las aerolíneas compartieran horarios de vuelo sin ponerse de acuerdo sobre cómo referirse a Londres Heathrow, serían inútiles. Esto no se puede resolver localmente en SPDX, ya que se requiere para otros formatos y aplicaciones. El grupo cree que existe una solución al combinar Package URL (PURL) para componentes asociados con administradores de paquetes y CPE y SWID para componentes de software comercial. También se agregó soporte para GITBOM a SPDX 2.3, otra posible solución para identificar de manera única los componentes de software. SPDX ha demostrado una base sólida y la capacidad de evolucionar para satisfacer las necesidades cambiantes de los usuarios. La introducción de perfiles permite una gran flexibilidad. Un grupo creó recientemente un perfil de Seguridad Funcional (FuSa). También se discutió el tema del hardware y la especificación algún día podría llamarse System Package Data Exchange…SPDX.

Contenidos

mitos SPDX

SPDX no puede soportar la seguridad.

INCORRECTO. SPDX actualmente admite la vinculación a la inteligencia de seguridad, y esta capacidad se ampliará para cubrir una gama más amplia de casos de uso en el futuro.

SPDX es antiguo y complicado.

Parcialmente verdad. El equipo diría «bien establecido». «Complejo» es quizás una mejor palabra que «complicado», y también lo es la variedad de problemas que aborda. Y con campos opcionales, SPDX Lite y perfiles, puede ser tan simple como debe ser y aun así resolver el problema. Los arquitectos de SPDX han hecho todo lo posible para crear la flexibilidad necesaria para hacer frente a un futuro incierto.

SPDX no es legible por humanos

Parcialmente verdad. SPDX admite varios formatos, incluida una tabla muy fácil de leer para ejemplos sencillos. Se vuelve más desafiante con XML y JSON, que depende de los humanos. Pero la realidad es que para describir software de cualquier tamaño y hacer cualquier cosa útil con la información, las máquinas deben estar involucradas y los ojos humanos solo ralentizarían el proceso.

SPDX no es compatible con VEX.

Mayormente mal. Hoy en día, los documentos SPDX pueden hacer referencia a documentos VEX y VDR de forma externa. Estamos en el campo de las personas que creen que esta es la mejor manera de apoyar a VEX. Dado que los SBOM y el conocimiento sobre las vulnerabilidades en los componentes incluidos evolucionan de manera muy diferente, no creemos que sea razonable esperar que la información se incluya siempre en el documento SBOM.