En los últimos años se han escrito muchas palabras sobre la SBOM – Lista de materiales del software. Con toda esta exposición, la gente siente que saben lo suficientemente bien lo que es explicar: es una lista de ingredientes del software, es importante para la transparencia y la seguridad, y ayuda a exponer las dependencias transitorias. Todo esto es verdad.
Aún así, el SBOM no es tan claro como parece. Por un lado, considere que para mantenerse actualizado, cada nueva versión o parche de la biblioteca requiere el lanzamiento de un nuevo SBOM. A menudo, solo cambias o parcheas una o dos bibliotecas a la vez para poder desglosar sus nuevos ingredientes, agregarlos al SBOM y dejar todo lo demás igual, ¿verdad?
¿Y qué pasa con el concepto de "lo conocido-desconocido"? Si los desarrolladores saben que les falta algo, pueden ingresarlo como "conocido-desconocido" y completar los espacios en blanco más tarde (o no completarlo).
También hay artefactos de software que son muy complejos e incluyen múltiples elementos entrelazados, cada uno de los cuales es un artefacto de software por derecho propio. Cada elemento a menudo tiene su propio SBOM separado, y toda la construcción puede tener un SBOM agregado mayor.
Todo esto demuestra que en lugar de un archivo SBOM simple y claro, podría terminar con una serie de elementos diferentes y en constante cambio que debe mantener constantemente lo más actualizados posible.
Todo esto está muy bien, pero ¿qué diferencia habría para alguien si un SBOM o parte de un SBOM no fuera tan preciso o actualizado como podría ser? ¿Qué podríamos hacer para mantener tanto la procedencia como la precisión del SBOM?
En este artículo, examinaremos el uso de SBOM en análisis de vulnerabilidades y divulgación de vulnerabilidades. Hablaremos sobre la firma criptográfica y veremos cómo firmar un SBOM, o partes de él, lo hace más útil como herramienta de seguridad y transparencia. También hablaremos sobre los metadatos y por qué son tan importantes en SBOM y otros tipos de producción de artefactos, especialmente cuando se firma criptográficamente en una atestación.
Comience aquí: ¿Qué es la firma criptográfica?
Las firmas criptográficas se utilizan para verificar la integridad y precisión de archivos o carpetas digitales. Un archivo firmado no se puede alterar sin invalidar la firma, por lo que se descubriría inmediatamente una vez que alguien intentara verificar el documento firmado.
Eso hace que las firmas digitales sean una herramienta invaluable en el arsenal de la seguridad de software industria y ya se han encontrado numerosos usos para el concepto simple de firma digital o criptográfica de activos digitales.
¿Como funciona? Las firmas digitales se basan en criptografía asimétrica en la que una entidad tiene dos claves: una clave privada y una clave pública. Las dos claves están vinculadas de tal manera que un documento firmado con la clave privada se puede verificar utilizando la pública. Una verificación significaría tanto que el documento no fue manipulado de ninguna manera (incluso el cambio de un solo bit haría que la firma no fuera verificable) como probar la identidad del firmante, o al menos la identidad de la clave utilizada.
¿Qué estás haciendo con ese SBOM?
Los SBOM no son sólo archivos largos y complicados que contienen información sobre componentes de software. Son su puerta de entrada para saber exactamente qué componentes componen su artefacto de software. Necesita conocer la lista completa de componentes, ya que aunque crea que sabe exactamente lo que incluyó, es probable que con cada biblioteca agregada que envíe se incluyan numerosas dependencias ocultas y transitorias, cada una de las cuales podría ser portadora de una vulnerabilidad o exploit que ahora está incluido en el software que envía a sus clientes.
Una vez que tenga un SBOM y esa lista completa de ingredientes, puede escanear esa lista con bases de datos de vulnerabilidades conocidas y ver qué vulnerabilidades están incluidas en su software. Pero eso es sólo el comienzo. Como sabe cualquiera que alguna vez haya realizado un análisis de vulnerabilidades, los resultados de incluso un simple análisis de artefactos pueden fácilmente ser cientos (o más) de vulnerabilidades.
Ahí es donde comienza el trabajo duro, mapeando cada vulnerabilidad, viendo si podría ser explotable en su composición de software específica, documentando esa información y tratando las vulnerabilidades explotables parcheándolas y remediandolas, preferiblemente en orden del peligro que representan (en vivo). Los exploits en la naturaleza son más peligrosos que un exploit teórico que nunca ha ocurrido todavía).
Todo este trabajo y la documentación y corrección de vulnerabilidades son importantes para usted como productor de software, pero también lo son para sus clientes, socios y auditores potenciales.
Quieren saber que usted es consciente de las vulnerabilidades potenciales y que está al tanto de ellas, parcheando y corrigiendo fallas, para que no los afecten a ELLOS como sus clientes o socios.
Dado que el momento en que realiza un escaneo es importante en este sentido debido al hecho de que constantemente salen a la luz nuevas vulnerabilidades, firmar su SBOM junto con los metadatos de CUÁNDO se creó es una excelente manera de demostrar que realmente está en la cima. de su lista de vulnerabilidades.
De esta manera, puede demostrar que conocía una vulnerabilidad de antemano y que no es relevante (usando un VEJAR aviso), que no está presente en una determinada versión, o que ni siquiera existía en el momento en que lanzó su última versión.
¿Dónde firmo?
Ahora reemplacemos ese simple archivo de lista de ingredientes con uno de los casos de uso más complejos descritos al comienzo del artículo. Una vez que haya combinado varios SBOM para formar una versión agregada más grande para describir su artefacto completo, firmar y verificar cada parte individual de esa versión agregada se vuelve aún más importante. Supongamos que está creando una nueva versión de un artefacto de software complejo. En esta nueva versión, lo único que cambió es la parte 1 de un artefacto de 3 partes. Las otras dos partes quedan exactamente iguales. ¿Por qué debería perder tiempo y recursos construyendo el SBOM completo de 3 partes, escaneando los 3 en busca de vulnerabilidades y mapeando los 3 en busca de exploits relevantes? Los únicos cambios se produjeron en la parte 1, por lo que es la única en la que debe trabajar. Si firmó los 3 SBOM y los análisis de vulnerabilidad la última vez que los creó, puede incluir la información de las otras dos partes sabiendo que no podría hacerlo. No han sido modificados. De este modo podrá demostrar en cualquier momento que los SBOM de las partes 2 y 3 son idénticos a las versiones originales. Por supuesto, puedes volver a realizar los análisis si te preocupan nuevas vulnerabilidades, pero eso depende completamente de ti y de tu software. análisis de riesgos.
Ser capaz de demostrar a sus clientes, socios y auditores cuándo y con qué frecuencia creó SBOM y los escaneó en busca de vulnerabilidades es útil por numerosas razones. Lo más importante es que podría usarse en los tribunales para demostrar que usted no es responsable del daño causado por un exploit, ya que hizo todo lo que debía para estar protegido, obteniendo así una Puerto seguro.
A dónde ir desde aquí
Como dijimos anteriormente, uno de los problemas con la firma digital de artefactos o archivos de software es la molestia de lidiar con sistemas de administración de claves. Una vez que eliminemos esa molestia usando algo como Sigstore para evitar el uso de una PKI tradicional y hacer que el flujo de firma y verificación sea automático, realmente habrá pocas razones para no utilizar esta herramienta de seguridad. Cuando considera que la identidad utilizada para firmar un archivo o artefacto también se puede utilizar en una política que verifica la seguridad de su canal de CI/CD, debería estar aún más motivado para comenzar a firmar casi todo lo que está a la vista.
Firmar archivos con sus metadatos puede ayudarle a verificar la hora y la ubicación de su origen, así como la persona y el sistema donde fueron creados, todos ellos datos relevantes cuando se consideran a través de la lente de un especialista en seguridad. Ser capaz de decir que la persona, el sistema y la hora coinciden con la empresa y el canal donde se creó el software es una buena idea cuando una simple sustitución puede presentar una falsificación firmada y convincente, hasta que se controle a la persona que canta.
Teniendo en cuenta que la herramienta que sugeriría para firmar y verificar pruebas es de uso gratuito, realmente no debería tener excusa. Consulta nuestro artículo completo sobre valent – nuestra herramienta de Integridad de Validación para ver qué más puede hacer con ella y comenzar a firmar sus SBOM y otras evidencias generadas hoy.
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
