La fecha límite de 24 horas de CRA está cambiando la visibilidad de la cadena de suministro de software.

      TL;DR A partir del 11 de septiembre, la Ley de Ciberresiliencia de la UE requerirá que los fabricantes notifiquen a los reguladores dentro de las 24 horas de enterarse de que una vulnerabilidad en su producto está siendo explotada activamente. Para las empresas cuyos productos contienen software de múltiples proveedores, el cuello de botella no es tener un SBOM, sino saber si refleja con precisión el código subyacente. Aaron Branson de FossID argumenta que el análisis de código fuente proporciona la capa de verificación que convierte los documentos SBOM en inteligencia confiable de la cadena de suministro.

      Según un análisis publicado por The Hacker News, los fabricantes de productos con elementos digitales vendidos en la Unión Europea enfrentarán un plazo del 11 de septiembre bajo la Ley de Ciberresiliencia (CRA) para notificar a los reguladores dentro de las 24 horas después de enterarse de que una vulnerabilidad está siendo explotada activamente, con un informe más completo que debe presentarse dentro de las 72 horas. Para los ejecutivos de manufactura, la ventana de 24 horas puede atraer una mayor atención a la visibilidad de la cadena de suministro de software. Los productos complejos pueden contener software propietario, aplicaciones desarrolladas por proveedores, paquetes comerciales, software de microcontroladores y bibliotecas de código abierto, con dependencias que se extienden a través de varios niveles. Un fabricante puede mantener numerosas relaciones con proveedores mientras tiene una visión limitada del software incrustado en componentes individuales.

      Bajo la CRA, el producto relevante puede abarcar el producto terminado completo, creando la necesidad de conectar información de numerosos proveedores en un inventario de software coherente. Los fabricantes de automóviles, dispositivos médicos, aeroespacial y electrónica de consumo pueden enfrentar versiones particularmente intrincadas de este desafío.

      Los Listados de Materiales de Software, o SBOMs, proporcionan una base importante para organizar esa información. Según IBM, un SBOM proporciona un inventario legible por máquina de componentes de software, bibliotecas, módulos y dependencias, ayudando a las organizaciones a entender el software incluido en productos y sistemas. IBM también describe la adopción más amplia de las prácticas de SBOM en varios sectores a medida que los requisitos regulatorios y las preocupaciones sobre la cadena de suministro de software se han expandido. Sin embargo, para los grandes fabricantes, los archivos de proveedores pueden llegar en diferentes formatos y con diferentes niveles de detalle. Una colección de documentos puede, en consecuencia, volverse difícil de reconciliar a nivel de producto, particularmente cuando el software subyacente cambia después de que se ha producido un SBOM.

      Esa distinción puede volverse particularmente importante cuando la notificación de vulnerabilidades es sensible al tiempo. El análisis de The Hacker News sobre la CRA argumenta que las organizaciones pueden encontrar el requisito del 11 de septiembre más desafiante cuando no pueden establecer rápidamente qué software está presente en un producto particular o cuándo se conoció por primera vez una vulnerabilidad. Una hoja de cálculo o un archivo de correo electrónico puede documentar la composición del software en un momento particular, mientras que lanzamientos posteriores, parches, cambios de dependencia o componentes recién identificados pueden alterar la imagen.

      Crédito: Aaron Branson

      Este es el entorno en el que FossID, una empresa de análisis de composición de software centrada en la inteligencia de código fuente y la transparencia de la cadena de suministro de software, ha desarrollado su papel. El Director de Crecimiento Aaron Branson ve el problema subyacente a través de la fiabilidad de la información que llega a los fabricantes. “Un SBOM es tan útil como la confianza que una organización puede depositar en la información que contiene”, afirma. “Para las empresas que reciben software de numerosos proveedores, esa confianza requiere una capa adicional de examen en el punto donde la información del proveedor ingresa a la empresa”.

      El análisis de código fuente tiene como objetivo proporcionar esa capa al examinar el software en sí para identificar componentes, dependencias, licencias y vulnerabilidades. La tecnología de FossID puede escanear código e identificar componentes de código abierto y de terceros, incluidos fragmentos de código más pequeños y dependencias que pueden ser difíciles de establecer solo a partir de la información del paquete declarado. Según Branson, esto crea una distinción importante entre recibir un SBOM y examinar si el SBOM corresponde con el software subyacente.

      La relación con el proveedor puede agregar otra capa al desafío de visibilidad. Para los grandes fabricantes, la utilidad de un SBOM puede depender en parte de si la información de diferentes proveedores puede evaluarse de manera consistente y llevarse a un registro común. Esta es un área donde el análisis de composición de software puede desempeñar un papel más amplio. La información proporcionada por el proveedor puede examinarse en comparación con el software en sí, ayudando a distinguir un documento que ha sido presentado de información que ha sido suficientemente validada.

      Branson argumenta que esta distinción puede volverse cada vez más importante a medida que la responsabilidad regulatoria se extiende a través de cadenas complejas de dependencias de software. El trabajo de FossID se sitúa dentro de un esfuerzo más amplio para hacer que la información del software del proveedor sea más utilizable para los equipos de ingeniería, seguridad y cumplimiento responsables del producto terminado.

      La complejidad puede aumentar cuando el software de un proveedor contiene dependencias de otros vendedores y proyectos de código abierto. Un fabricante puede recibir información sobre un componente sin tener el mismo nivel de visibilidad sobre el software que lo subyace. Esto puede crear una pregunta más amplia sobre cómo los fabricantes pueden establecer confianza en la información del software que proviene de fuera de sus propios equipos de ingeniería.

      “Nuestro trabajo en análisis de código fuente es relevante para esa pregunta porque examina la composición del software a nivel de código, proporcionando otro medio para evaluar la información suministrada a través del ecosistema más amplio”, explica Branson. “Pero el problema más grande es que los fabricantes pueden necesitar procesos que permitan verificar la información del software a través de múltiples capas de responsabilidad”. Según Branson, FossID ha discutido este desafío más amplio con analistas de la industria a medida que las organizaciones pasan de simplemente generar SBOMs a incorporarlos en procesos continuos de la cadena de suministro de software.

      Katie Norton, Gerente de Investigación Senior en IDC, ve la flexibilidad como una parte importante de esa transición. “A medida que las empresas operacionalizan los SBOMs, necesitan procesos que puedan acomodar diferencias en proveedores, requisitos regulatorios y revisión interna”, afirma Norton. “El desafío es apoyar esas variaciones sin imponer el mismo flujo de trabajo a cada organización”.

      Branson ve esto como un cambio en el propósito de la gestión de SBOM en sí. “La pregunta está pasando de ‘¿Tenemos un SBOM?’ a ‘¿Podemos verificar continuamente la cadena de suministro de software que representa el SBOM?’”, afirma. Esa distinción coloca el análisis de composición de software dentro de un proceso operativo más amplio que involucra a equipos de ingeniería, seguridad, adquisiciones y regulaciones. Un SBOM puede servir como el registro, mientras que el análisis de código fuente puede proporcionar un medio para probar ese registro contra el software del cual se derivó.

      En última instancia, el requisito del 11 de septiembre puede representar un hito temprano en una evolución más amplia de la gobernanza del software. The Hacker News señala que las obligaciones de informes de la CRA llegan antes de los requisitos de ingeniería más amplios de la regulación, que están programados para aplicarse en diciembre de 2027. Esta secuencia puede dar a los fabricantes la oportunidad de examinar los sistemas que apoyan la identificación de vulnerabilidades, la información del proveedor y la visibilidad del software a nivel de producto.

      A medida que los productos conectados incorporan software de cadenas de suministro cada vez más complejas, la preparación regulatoria puede depender cada vez más de la calidad y actualidad de la información detrás del inventario de software de una organización. El desafío emergente puede ser más sobre mantener una comprensión confiable del software que permanece conectado a un producto a lo largo de su ciclo de vida.