״Los proveedores de software deben ser considerados responsables cuando no cumplen con el deber de diligencia que deben a los consumidores, las empresas o los proveedores de infraestructura crítica ״ (la Casa Blanca).
Hoy en día, se espera que cualquier proveedor de software asuma una mayor responsabilidad para garantizar la integridad y seguridad del software a través de acuerdos contractuales, lanzamientos y actualizaciones de software, notificaciones y mitigación de vulnerabilidades. Recientemente, el ESF (Enduring Security Framework), un grupo de trabajo intersectorial, publicó una guía que incluye mejores prácticas y estándares recomendados para ayudar a los clientes a implementar medidas de seguridad dentro de la cadena de suministro de software. En este artículo, profundizaré en la recomendación práctica de utilizar la puntuación de riesgos basada en SBOM como un mecanismo eficaz para la clasificación y priorización.
Persisten los métodos comunes para comprometer las cadenas de suministro de software, incluida la explotación de fallas de diseño del software, la incorporación de componentes vulnerables de terceros en un producto de software, la infiltración de código malicioso en la red del proveedor antes de la entrega final del producto de software y la inyección de software malicioso en el software implementado. en el entorno del cliente.
Una lista de materiales de software (SBOM) se ha convertido en un elemento crucial en la seguridad del software y la gestión de riesgos de la cadena de suministro de software. Un SBOM sirve como un inventario anidado y proporciona una lista de ingredientes que constituyen los componentes de software.
La puesta en funcionamiento de SBOM a escala requiere automatización y estandarización de herramientas en las implementaciones de sistemas, el desarrollo de productos y el intercambio de datos entre proveedores y consumidores de software.
Hay algunos importantes legibles por máquina. Formatos estándar SBOM apoyado por la industria. CycloneDX y SPDX definen la forma en que se crean, analizan y comparten los SBOM. VEX es una forma complementaria de aviso de seguridad que indica si un producto o productos se ven afectados por una vulnerabilidad o vulnerabilidades conocidas. Por lo tanto, ofrece el beneficio de mostrar que un producto no se ve afectado por una vulnerabilidad específica, incluso si esta vulnerabilidad existe en su SBOM.
La correlación del contenido de SBOM entre los productos de software implementados dentro de la empresa puede proporcionar información valiosa para la seguridad de las aplicaciones, los equipos forenses y de respuesta a incidentes, la gestión de riesgos y las adquisiciones. Se espera que las organizaciones generen y administren una gran cantidad de datos SBOM para productos internos, así como también consuman datos externos que deben administrarse de manera efectiva. Por lo tanto, es necesario apoyar automatización de SBOM-gestión de riesgos impulsada a escala.
Uso de SBOM y puntuación de riesgo
La puntuación de riesgos puede servir como un medio para generar una descripción general condensada derivada del contenido de los SBOM, lo que permite comparaciones rápidas con fuentes de datos externas y facilita la toma rápida de decisiones basadas en los SBOM recibidos y la priorización.
- El SBOM mejora la transparencia, mejorando así la gestión de activos de software, la gestión de parches, la identificación de brechas de deuda técnica y la gestión de vulnerabilidades para las organizaciones de clientes. También tiene el potencial de extraer la procedencia de componentes para validar la integridad y la confianza.
- El análisis de la alineación del contenido de SBOM en los productos de software implementados en la empresa genera información valiosa para los equipos de respuesta a incidentes, la gestión de riesgos y la validación de procesos de adquisiciones.
Convertir la SBOM en información sobre riesgos a escala: justificación de la puntuación de riesgos
Un desafío clave para todos los profesionales de AppSec y CISO es gestionar la fatiga de alertas en sus productos y servicios. Incluyendo la evaluación de riesgos externos provenientes de componentes de software de terceros.
Las barreras clave para la implementación son el soporte contractual o basado en licencias desactualizado que puede afectar la disponibilidad de parches posteriores y actualizaciones de productos y el crecimiento exponencial en la complejidad de las dependencias dentro de los productos de software, ya sean de código abierto o de código cerrado.
A puntuación de riesgo es una métrica utilizada para predecir aspectos del software y el riesgo actual y futuro de sus componentes que pueden respaldar eficazmente la priorización a escala.
Puntuación de riesgo = probabilidad x impacto
La puntuación de riesgo permite a las organizaciones comprender el riesgo de su cadena de suministro de software en función de factores de riesgo definidos y anticipar el riesgo futuro potencial de un producto de software determinado en la empresa.
Una puntuación de riesgo eficaz podría estar en una escala del 1 al 10 (como CVSS y Scorecard), de modo que podamos alinear cada componente de riesgo con la escala del 1 al 10 para facilitar la referencia.
Una puntuación de riesgo agregada: En muchos sistemas complejos y sistemas de sistemas, puede haber múltiples SBOM como parte de la solución colectiva y, por lo tanto, una colección de puntuaciones de riesgo.
Componentes de calificación de riesgo:
1.Vulnerabilidades: Mapeo de vulnerabilidades conocidas mediante enumeración CVE y Puntuación CVSS de fuentes disponibles como NVD, OSV y Github Advisories.
2. Contexto de los proveedores: VEX y contexto de asesoramiento de proveedores que pueden cambiar la decisión de puntuación de vulnerabilidad en el contexto de uso. Vincular los SBOM a las vulnerabilidades habilita señales de riesgo, mientras que los documentos VEX permiten al consumidor priorizar las vulnerabilidades.
3. EPSS 3.0: Métrica de explotabilidad de FIRST, que predice la probabilidad (entre 0 y 1.0) de explotación en los próximos 30 días. Este es un efectivo capa de probabilidad adicional a la puntuación CVSS que puede ayudar a priorizar los CVE más importantes para manejar primero.
4. KEV: CISA también creó una fuente de inteligencia sobre amenazas disponible públicamente que se conoce hoy como Catálogo CISA KEV (vulnerabilidades explotables conocidas). Este catálogo contiene aproximadamente el 5% de todos los CVE identificados que CISA confirma que han sido explotados o explotados activamente. Por lo tanto, este es un buen punto de partida para priorizar las vulnerabilidades de alto impacto a abordar. Además, esto es parte de la lista de verificación que validará antes de la aprobación final del lanzamiento de la nueva versión.
5. Inteligencia sobre amenazas – Agregar adicional fuentes de amenazas y vulnerabilidades alimentan paquetes maliciosos conocidos (Ejemplos: feeds privados de Snyk, Sonatype, Graynoise, etc.)
6. Reputación de OSS: la El cuadro de mando open SSF evalúa de forma independiente las métricas de medidas de rendimiento que afectan a diferentes partes de la cadena de suministro de software, incluido el código fuente, la compilación, las dependencias, las pruebas y la reputación del mantenimiento de proyectos de código abierto (calificación de 1 a 10).
7. Desempeño a lo largo del tiempo: Las vulnerabilidades críticas MTTR (tiempo medio de reparación) de una versión de producto/paquete podrían proporcionar una métrica relevante del rendimiento del riesgo de seguridad.
8. Impacto y contexto. En este aspecto, la priorización basada en el contexto empresarial del producto de software ayudaría a priorizar y clasificar el bosque de vulnerabilidad.
Algunos ejemplos son
- Criticidad del módulo/producto: ¿Es esto de misión crítica (sensibilidad o criticidad)?
- ¿En cuántos productos tengo la vulnerabilidad específica?
- Exposición a la externalidad de un servicio/componente
9. Exposición de cumplimiento – Licencias: Tanto las licencias de software propietario como las de código abierto son importantes para validar el cumplimiento de la política legal de la organización.
Concepto de capas de puntuación de riesgo: agregar métricas de riesgo a los SBOM:
- Inicio con enumeración CVE y puntuación CVSS basada en los datos de SBOM.
- Consumir y agregar contexto VEX para volver a priorizar la criticidad
- Evaluar CVE con una puntuación EPSS alta (es decir, 0.6-1.0)
- Priorizar lista KEV – para dirección primero.
- Evalúe según la puntuación de reputación de OpenSSF (1-10): identifique dependencias riesgosas.
- Analizar exposición a la red externa (usando el vector CVSS)
- Evaluar acumula riesgo por el cantidad de producto por vulnerabilidad.
- Evaluar por el Etiqueta de la criticidad de un SBOM de contenedor específico para el negocio.
- Identificar violación de cumplimiento riesgos al utilizar el análisis de dependencias de SBOM de acuerdo con la política de licencia de la empresa.
- Comparte y administrar los datos as atestaciones en una plataforma colaborativa con flujos de trabajo hacia otros sistemas como Jira y otros mediante API y legible por máquina.
Aprovechar los SBOM con puntuación de riesgo para casos de uso prácticos:
- Clasificación continua de vulnerabilidades para productos mediante el uso de métricas de riesgo para priorizar un plan de trabajo de parcheo en todos los productos.
- Compare productos uno al lado del otro según métricas de riesgo.
- Compare y apruebe las actualizaciones de nuevas versiones antes de la implementación/lanzamiento.
- Realice un seguimiento de la brecha de deuda técnica utilizando los umbrales de puntuación de riesgo para las versiones del producto.
- Cree un informe rápido de los 50 riesgos principales de mis productos más críticos.
- Análisis de impacto para acelerar la respuesta a un incidente, en caso de que se encuentre una vulnerabilidad explotada activamente en la naturaleza. En este caso, el tiempo importa para identificar rápidamente cómo me veo afectado y cuál sería el radio de explosión del mapa de calor de esta exposición.
Cómo utilizar la plataforma Scribe Hub para una gestión de riesgos eficaz:
- Plataforma de gestión SBOM centralizada – Crear, gestionar y compartir SBOM junto con sus aspectos de seguridad: vulnerabilidades, avisos VEX, licencias, reputación, explotabilidad, cuadros de mando, etc.
- Cree e implemente software seguro – Detecte manipulaciones firmando y verificando continuamente el código fuente, las imágenes de contenedores y los artefactos en cada etapa de sus canalizaciones de CI/CD.
- Automatice y simplifique la seguridad SDLC: Controlar el riesgo en su fábrica de software y garantice la confiabilidad del código traduciendo la seguridad y la lógica empresarial en políticas automatizadas, aplicadas mediante barreras de seguridad.
- Habilitar la transparencia. Mejorar la velocidad de entrega – Dotar a los equipos de seguridad de las capacidades para ejercer su responsabilidad, simplificando el control de seguridad sin impedir los resultados del equipo de desarrollo.
- Hacer cumplir las políticas. Demostrar cumplimiento – Supervise y aplique las políticas y la gobernanza de SDLC para mejorar la postura de riesgo del software y demostrar el cumplimiento necesario para su negocio.
Dos ejemplos de Centro de escribas Se presentan capacidades de análisis de riesgos:
Vulnerabilidades mapeadas por SBOM, calificación de riesgo mediante datos CVSS, VEX, EPSS y KEV.
Serie temporal del rendimiento de la versión SBOM a lo largo del tiempo que indica el MTTR, el tiempo medio para reparar las vulnerabilidades críticas identificadas.
Resum
La puntuación de riesgos basada en SBOM permite a las organizaciones evaluar el riesgo de la cadena de suministro mediante la evaluación de factores de riesgo predefinidos y la previsión de posibles riesgos futuros asociados con un producto de software específico dentro de la empresa. La puntuación de riesgo sirve como medida cuantitativa para anticipar los riesgos actuales y potenciales relacionados con el software y sus componentes.
Esta métrica de puntuación se deriva de indicadores obtenidos de SBOM, VEX, entre otros feeds, y se alinea con el contenido que respalda la Gestión de riesgos de la cadena de suministro (SCRM). Al aplicar o evaluar una puntuación de riesgo, se deben tener en cuenta factores como el contexto de uso del software, cómo se accede a él o se aísla, y los procesos y sistemas que admite.
Scribe Hub sirve como una plataforma colaborativa diseñada para la extracción, gestión, recopilación de certificaciones y análisis de puntuación de riesgos de SBOM a escala. Esta plataforma procesa de manera eficiente múltiples fuentes de datos externos para manejar las complejidades de sistemas y productos de software complejos.
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
