L'importance de la signature de code dans la chaîne d'approvisionnement Software

Comment savoir si votre code est fiable ?

Dans un monde où la confiance est difficile à obtenir, il est important de se poser la question. Comment savoir si les applications que nous exécutons, les conteneurs que nous déployons ou le code que nous livrons à nos clients sont authentiques ? Comment savoir s'il n'a pas été altéré ?

Tout se résume à la signature du code.

Dans ce blog, nous discuterons de l'importance de la signature de code, des défis à relever pour la mettre en œuvre correctement et de la façon dont Keyfactor Code Assure vous permet de centraliser et de sécuriser la signature de code sans perturber les flux de travail des développeurs (vous pouvez trouver le webinaire complet sur ce sujet en cliquant sur "Regarder maintenant" ci-dessous).

Aujourd'hui, software n'est pas seulement une vitrine. C'est le moteur opérationnel de chaque entreprise. Et pour que ce moteur fonctionne comme une machine bien huilée, nous devons savoir que tout ce que nous construisons et tout ce que nous déployons est fiable.

La signature de code est au cœur de la confiance dans la chaîne d'approvisionnement software . La signature de code prouve l'identité du vendeur de la source du code et vérifie que le code n'a pas été modifié depuis sa publication.

Nous nous dirigeons rapidement vers une réalité où tout doit être signé. Non seulement le site software que nous achetons à des fournisseurs tiers, mais aussi, et c'est tout aussi important, le site software que nous construisons et déployons au sein de nos propres organisations. Il s'agit de tout ce qui concerne les scripts PowerShell, les scripts Bash, les conteneurs, les bibliothèques, les fichiers et les exécutables (et j'en passe).

Mais la signature de code existe depuis des années. Qu'est-ce qui a changé ?

Les équipes chargées des applications et des opérations se déplacent plus rapidement que jamais, grâce à l'adoption de CI/CD et d'outils d'automatisation de la construction et des tests. Cela signifie qu'il y a moins d'yeux humains avec une ligne de vue directe sur ce qui se passe tout au long du pipeline.

Les mauvais acteurs, qu'il s'agisse de groupes de menaces persistantes avancées (APT) ou de pirates informatiques vivant dans des caves, recherchent des faiblesses ou des vulnérabilités dans ces environnements complexes qui évoluent rapidement. Pour rester discrets, les codes malveillants sont souvent injectés ou modifiés à n'importe quel point de la chaîne d'approvisionnement sans être détectés. Soit ils compromettent le processus de signature du code lui-même.

Un pirate peut injecter un code malveillant dans open-source software , dans votre dépôt de code source ou compromettre les serveurs de construction eux-mêmes. Dans le cas de SolarWinds, les attaquants n'ont injecté que quelques lignes de code d'apparence anodine dans un seul fichier DLL, ce qui a créé une menace profonde et généralisée sur l'ensemble de la chaîne d'approvisionnement.

Les adversaires peuvent également acquérir ou voler des clés de signature de code trouvées sur des systèmes vulnérables pour signer leurs outils malveillants. Nous avons vu cela se produire dans un certain nombre de scénarios différents, où les clés privées de signature de code sont compromises à partir d'un serveur de construction, d'un poste de travail de développeur, ou même exposées accidentellement dans un micrologiciel ou à l'adresse software elle-même.

Du point de vue de la sécurité, il ne suffit donc plus de signer le code. Désormais, il est tout aussi important de : (1) de s'assurer que ce que les développeurs construisent est bien ce qui est signé et livré à vos clients, et (2) que l'infrastructure et les clés privées utilisées pour signer le code sont étroitement contrôlées.

Les attaquants sont passés à gauche. Plutôt que de cibler directement les organisations, ils recherchent les maillons faibles de la chaîne d'approvisionnement software où ils peuvent voler des outils ou compromettre du code. L'APT 41, soutenu par un État, maîtrise cette technique depuis plus d'une décennie, ciblant indirectement un large éventail d'entreprises en compromettant leurs vendeurs ou fournisseurs software .

La signature de code est une cible naturelle pour les attaquants, car elle leur permet de s'infiltrer dans la chaîne d'approvisionnement et d'atteindre des cibles de l'intérieur. Voici comment cela peut se produire :

• Vol ou utilisation abusive de clés : Les adversaires volent des documents de signature de code via des systèmes non protégés ou des contrôles d'accès aux comptes mal configurés.
• Compromission du système : les attaquants peuvent également compromettre les serveurs centralisés de signature ou de mise à jour pour détourner une mise à jour software au cours du processus de livraison.
• Compromission du code: un code malveillant est injecté dans les bibliothèques open-source ou les dépôts de code source, et n'est pas détecté avant d'être signé et transmis aux utilisateurs finaux.
• Menaces internes : Les développeurs au sein de l'organisation peuvent signer intentionnellement un code malveillant ou même divulguer involontairement des clés de signature dans une mise à jour ou un répertoire software accessible au public.

Malgré ces menaces bien connues, la réalité est que la plupart des organisations avec lesquelles nous discutons aujourd'hui ne signent pas autant qu'elles le devraient, et plus important encore, elles n'ont généralement pas de processus de signature de code cohérent.

Une étude récente a révélé que les entreprises possèdent en moyenne 25 certificats de signature de code. Environ 51 % des personnes interrogées ont déclaré qu'elles stockaient les clés privées associées dans un module de sécurité hardware (HSM). Par ailleurs, près de deux tiers (60 %) des entreprises ne disposent pas de contrôles d'accès formels ni de processus d'approbation pour les clés de signature de code.

Le problème est que la signature du code est souvent couplée de manière lâche avec le développement software , plutôt que d'être étroitement intégrée. Les deux processus sont disjoints, ce qui crée des frictions et des retards dans la livraison de software , ou pire, permet à de mauvais acteurs d'en tirer profit. Voici quelques obstacles courants :

• Équipes à distance : Le développement décentralisé est la nouvelle norme, ce qui pose plusieurs problèmes. Le stockage des clés localement sur une machine n'est pas une option, mais le transfert de fichiers volumineux vers un système de signature centralisé entraîne des temps d'attente importants.
• Pas de processus : Les clés de signature de code sont bien protégées dans un HSM, mais il est toujours nécessaire de contrôler ce qui est signé, qui peut signer, etc.
• Processus manuel : Les garde-fous politiques sont essentiels, mais les processus qui dépendent fortement de la configuration de hardware et des processus d'approbation manuels ne peuvent pas évoluer.
• Pas d'intégration : L'absence de prise en charge des types de fichiers ou d'intégration avec les outils existants (par exemple SignTool, Authenticode, jarsigner) rend extrêmement difficile le maintien d'un contrôle centralisé tout en permettant aux développeurs de travailler de manière transparente.

La question est donc de savoir comment faciliter la signature du code par les développeurs et la rendre transparente, tout en conservant un contrôle centralisé sur ce qu'ils peuvent signer et sur la manière dont ils peuvent le faire. C'est une question que nous nous sommes posée, mais au lieu de chercher la réponse, nous l'avons construite.

Alors que nous évoluons vers des mises à jour plus fréquentes de software , des équipes de développement à distance et un plus grand nombre de produits, nous avons dépassé notre solution de signature existante qui reposait sur des processus hautement sécurisés, mais fortement manuels. C'est là que Keyfactor Code Assure entre en jeu.

Pour trouver le juste équilibre entre nos exigences (et celles de nos clients) en matière de transparence, de facilité d'utilisation et, bien sûr, de sécurité, nous avons élaboré une solution qui pouvait.. :

• Protéger les clés privées dans un HSM contrôlé de manière centralisée (physique ou dans le nuage)
• Permettre aux développeurs d'utiliser des outils natifs et des méthodes de signature sur leur machine locale, sans que les clés privées ne quittent jamais le HSM central.
• Contrôler l'accès et séparer les tâches des différentes équipes et des différents rôles
• Appliquer des règles de sécurité pour la signature en fonction de l'utilisateur/du groupe, de l'emplacement, de la méthode de signature et d'autres paramètres.
• Conserver une piste d'audit et un horodatage de toutes les activités de signature de code et de l'utilisation des clés.
• Intégrer les serveurs de construction et les outils CI/CD, notamment Jenkins, pour automatiser la signature du code.

Jetons un coup d'œil à son fonctionnement. Voici un aperçu rapide de la solution et de la manière dont elle permet la signature de code sécurisée pour Java et Windows (vous pouvez trouver la démo complète ici).