La importancia de la firma de códigos en la cadena de suministro Software

¿Cómo sabe que su código es de confianza?

En un mundo en el que la confianza es difícil de conseguir, es importante que nos hagamos esta pregunta. ¿Cómo sabemos que las aplicaciones que ejecutamos, los contenedores que desplegamos o el código que entregamos a nuestros clientes son auténticos? ¿Cómo sabemos que no ha sido manipulado?

Todo se reduce a la firma del código.

En este blog, hablaremos de la importancia de la firma de código, de los retos que supone implementarla correctamente y de cómo Keyfactor Code Assure le permite centralizar y asegurar la firma de código sin interrumpir los flujos de trabajo de los desarrolladores (puede encontrar el seminario web completo sobre este tema haciendo clic en "Ver ahora" más abajo).

Hoy en día, software no es sólo el escaparate. Es el motor operativo de todas las empresas. Y para que ese motor funcione como una máquina bien engrasada, necesitamos saber que todo lo que construimos y todo lo que desplegamos es de confianza.

En el centro de la confianza en la cadena de suministro de software está la firma de código. La firma de código demuestra la identidad del proveedor del código fuente y verifica que el código no ha sido manipulado desde su publicación.

Nos acercamos rápidamente a una realidad en la que todo debe estar firmado. No sólo el software que compramos a proveedores externos, sino, lo que es igual de importante, el software que creamos e implantamos en nuestras propias organizaciones. Es decir, todo, desde secuencias de comandos PowerShell, secuencias de comandos Bash, contenedores, bibliotecas, archivos y ejecutables (de todo).

Pero la firma de código existe desde hace años. ¿Qué ha cambiado?

Los equipos de aplicaciones y operaciones se mueven más rápido que nunca, gracias a la adopción de CI/CD y herramientas de automatización de pruebas y creación. Esto significa menos ojos humanos con una línea de visión directa de lo que está sucediendo en todo el proceso.

Los malos actores, desde los grupos de amenazas persistentes avanzadas (APT) hasta los hackers que viven en sótanos, buscan puntos débiles o vulnerabilidades en estos entornos complejos y en rápida evolución. Para pasar desapercibidos, a menudo inyectan o modifican código malicioso en prácticamente cualquier punto de la cadena de suministro sin detectarlo. Eso o comprometen el propio proceso de firma de código.

Un atacante podría inyectar código malicioso en open-source software , en su repositorio de código fuente o comprometer los propios servidores de compilación. En el caso de SolarWinds, los atacantes inyectaron unas pocas líneas de código de apariencia benigna en un único archivo DLL que creó una amenaza profunda y generalizada en toda su cadena de suministro.

Los agresores también pueden adquirir o robar claves de firma de código encontradas en sistemas vulnerables para firmar sus herramientas de malware. Hemos visto que esto ocurre en varios escenarios diferentes, donde las claves privadas de firma de código se ven comprometidas desde un servidor de compilación, una estación de trabajo de desarrollador o incluso se exponen accidentalmente en el propio firmware o software .

Desde el punto de vista de la seguridad, ya no basta con firmar el código. Ahora es igual de importante: (1) asegurarse de que lo que crean los desarrolladores es lo que se firma y se entrega a los clientes, y (2) que la infraestructura y las claves privadas utilizadas para firmar el código están estrictamente controladas.

Los atacantes se han desplazado a la izquierda. En lugar de atacar directamente a las organizaciones, buscan eslabones débiles en la cadena de suministro de software , donde pueden robar herramientas o comprometer el código. La APT 41, respaldada por el Estado, ha dominado esta técnica durante más de una década, atacando indirectamente a un amplio abanico de empresas al comprometer a sus vendedores o proveedores de software .

La firma de códigos es un objetivo natural para los atacantes, ya que les permite introducirse en la cadena de suministro y violar objetivos desde dentro. He aquí cómo puede ocurrir:

• Robo o uso indebido de claves: Los adversarios roban material de firma de código a través de sistemas desprotegidos o controles de acceso a cuentas mal configurados.
• Compromiso del sistema: Los atacantes también pueden comprometer servidores centralizados de firma o actualización para secuestrar una actualización de software en el proceso de entrega.
• Código comprometido: se inyecta código malicioso en las bibliotecas o repositorios de código fuente de open-source y no se detecta antes de que se firme y se distribuya a los usuarios finales.
• Amenazas internas: Los desarrolladores dentro de la organización pueden firmar intencionadamente código malicioso o incluso revelar involuntariamente claves de firma en una actualización o repo de software de acceso público.

A pesar de estas amenazas bien conocidas, la realidad es que la mayoría de las organizaciones con las que hablamos hoy en día no están firmando tanto como deberían y, lo que es más importante, no suelen tener un proceso de firma de código coherente.

En un estudio reciente, descubrimos que las empresas tienen una media de 25 certificados de firma de código. Alrededor del 51% de los encuestados afirmaron que almacenan las claves privadas asociadas en un módulo de seguridad hardware (HSM). Por otro lado, muchos afirmaron que las claves privadas también se encuentran en los servidores de compilación (33%) y en las estaciones de trabajo de los desarrolladores (19%), y casi dos tercios (60%) de las empresas no tienen controles de acceso formales ni procesos de aprobación para las claves de firma de código.

El problema es que la firma de código suele estar poco vinculada al desarrollo de software , en lugar de estrechamente integrada. Los dos procesos están desarticulados, lo que crea fricciones y retrasos en la entrega de software , o peor aún, abre la posibilidad de que se aprovechen los malos actores. He aquí algunos obstáculos habituales:

• Equipos remotos: El desarrollo descentralizado es la nueva norma, lo que plantea varios retos. Almacenar claves localmente en una máquina no es una opción, pero transferir archivos grandes a un sistema de firma centralizado conlleva tiempos de espera considerables.
• Sin proceso: Las claves de firma de código están bien protegidas en un HSM, pero sigue siendo necesario controlar qué se firma, quién puede firmar, etc.
• Proceso manual: Los guardarraíles de políticas son esenciales, pero los procesos que dependen en gran medida de la configuración de hardware y los procesos de aprobación manual no pueden ampliarse.
• No hay integración: La falta de compatibilidad con tipos de archivos o de integraciones con herramientas existentes (por ejemplo, SignTool, Authenticode, jarsigner) dificulta enormemente el mantenimiento de un control centralizado al tiempo que permite a los desarrolladores trabajar de forma transparente.

Así que la pregunta es: ¿cómo facilitar y hacer transparente a los desarrolladores la firma de código manteniendo un control centralizado sobre qué y cómo pueden firmar? Es una pregunta que nos hicimos, pero en lugar de buscar la respuesta, la construimos.

A medida que avanzamos hacia actualizaciones más frecuentes de software , equipos de desarrollo remotos y más productos, se nos quedó pequeña nuestra solución de firma existente, que se basaba en procesos muy seguros pero muy manuales. Ahí es donde entra en juego Keyfactor Code Assure.

Para encontrar el equilibrio adecuado entre nuestros requisitos (y los de nuestros clientes) de transparencia, facilidad de uso y, por supuesto, seguridad, creamos una solución que pudiera:

• Proteger las claves privadas en un HSM controlado centralmente (físico o en la nube)
• Permitir a los desarrolladores utilizar herramientas y métodos de firma nativos en su equipo local, sin que las claves privadas salgan nunca del HSM central.
• Controle el acceso y separe las funciones de los distintos equipos y funciones.
• Aplique políticas de protección para la firma en función del usuario/grupo, la ubicación, el método de firma y otros parámetros.
• Mantener un registro de auditoría y una marca de tiempo de todas las actividades de firma de código y uso de claves.
• Integración con servidores de creación y herramientas CI/CD, especialmente Jenkins, para automatizar la firma de código.

Veamos cómo funciona. He aquí un rápido avance de la solución y de cómo permite la firma segura de código para Java y Windows (puede encontrar la demostración completa aquí).