Intégration de la signature de code sécurisée dans le pipeline CI/CD

Dans notre monde de plus en plus numérique, la confiance est essentielle.

Les utilisateurs finaux doivent faire confiance au site software avec lequel ils interagissent, les développeurs et les ingénieurs doivent être en mesure de créer cette confiance, et les équipes de sécurité doivent mettre en place les contrôles appropriés pour activer l'ensemble du cycle.

Bien sûr, comme nous le savons tous aujourd'hui, il n'est pas toujours facile d'établir et de maintenir la confiance numérique.

L'un des meilleurs moyens d'établir la confiance numérique est l'utilisation d'identités et, plus précisément, de signatures de code, signature de codequi permet de vérifier l'authenticité des nouvelles versions. Mais comment la signature de code est-elle utilisée dans les organisations aujourd'hui ? Quels sont les principaux défis auxquels les équipes sont confrontées lors de la mise en œuvre de la signature de code, et que se passe-t-il lorsque ces processus ne sont pas sécurisés ? Peut-être plus important encore, comment pouvez-vous garantir la sécurité de la signature de code dans votre pipeline CI/CD ?

Nous avons récemment répondu à ces questions et à d'autres lors de notre webinaire Intégrer la signature de code sécurisée dans le pipeline CI/CD. Lisez la suite pour connaître les points forts de cette discussion, ou cliquez ici pour visionner l'enregistrement complet.

Avant toute chose, il convient de parler de l'établissement de la confiance numérique. En ce qui concerne la signature de code, chaque organisation doit créer un environnement de confiance où les équipes de sécurité se sentent à l'aise avec les contrôles en place et où les développeurs et les ingénieurs peuvent travailler comme ils l'entendent et où ils le veulent sans créer de risques inutiles.

Il n'est pas facile de trouver cet équilibre, en particulier pour les équipes DevOps. Entre les développeurs qui travaillent à distance, les charges de travail qui s'exécutent dans plusieurs environnements et les chaînes d'outils DevOps qui deviennent de plus en plus complexes, il devient de plus en plus difficile de savoir ce qui est fiable et ce qui ne l'est pas. 

C'est là que l'identité prend toute son importance surtout pour les machines. Tout simplement, chaque machine, chaque appareil et chaque charge de travail a besoin d'une identité, et chacune de ces identités doit être protégée et gérée.

Les certificats de signature de code ne sont pas différents : ils sont l'identité derrière votre software puisqu'ils sont utilisés pour tout authentifier, des builds et artefacts software aux images de conteneurs et même au firmware et aux paramètres IoT . Par conséquent, si cette identité de signature de code est compromise, la confiance est ébranlée.

Au cours des dernières années, le rôle de la signature de code dans l'établissement de la confiance numérique est devenu de plus en plus critique. Les utilisateurs finaux qui téléchargent software à partir d'Internet s'attendent à ce que software soit signé. 

Cette réalité, combinée à la montée en puissance des environnements de confiance zéro, signifie que pratiquement tous les actifs produits par une entreprise doivent être signés - tout ce qui peut être déployé (scripts, code d'infrastructure, images de conteneurs, applications, fichiers WAR, fichiers EAR, DLL, exécutables, macros, et j'en passe) doit être signé, car une activité malveillante peut se produire n'importe où.

Dans cette optique, les cas d'utilisation les plus courants de la signature de code sont les suivants :

• Protéger l'infrastructure : Empêcher les téléchargements non autorisés et les ransomwares en n'autorisant que les applications de confiance à fonctionner sur votre infrastructure.

• Sécurisation des appareils et des microprogrammes : Empêcher l'accès non autorisé aux appareils en sécurisant les microprogrammes et leurs mises à jour à l'aide de signatures numériques et de vérifications.

• Sauvegarde de software: Veiller à ce que le site software publié et distribué soit signé et que les clés soient protégées.

• Confiance dans les conteneurs : Établir des images de base fiables et signées numériquement pour les conteneurs et les machines virtuelles déployés dans votre environnement.

• Permettre DevSecOps : Établir la confiance dans le pipeline CI/CD, de la signature numérique du code source vérifié dans les dépôts à la signature des paquets après la construction.
• Prévention des macros malveillantes : Empêcher les macros non autorisées ou malveillantes sur les appareils internes en veillant à ce que seules les macros signées soient autorisées à s'exécuter.

Compte tenu de l'importance de la signature de code pour établir la confiance numérique et de la grande variété des cas d'utilisation de la signature de code, les organisations doivent prêter une attention particulière à leurs pratiques de signature de code. C'est là que l'idée d'un modèle de maturité de la signature de code entre en jeu. Ce modèle se présente comme suit :

• Ne pas signer les produits livrables sur software
• Vulnérable à l'accès non autorisé au code
• Pas d'auditabilité ni d'intégrité derrière le software

• Signer les produits livrables sur le site software , mais avec des outils fragmentés
• Les développeurs gèrent leurs propres clés privées sans contrôle centralisé.
• Les clés de signature sont vulnérables en cas d'abus ou de compromission

• Utilisation d'une plate-forme centralisée pour la politique de signature de code, le flux de travail et l'auditabilité
• Protection des clés de signature sensibles dans un HSM sécurisé
• Pas d'intégration avec les processus ou flux de travail CI/CD et tous les cas d'utilisation ne sont pas couverts

• Signature de tous les conteneurs, artefacts et produits livrables software
• Intégration avec des outils de signature et des flux de travail natifs
• Auditabilité et gouvernance totales de tous les processus de signature

Malheureusement, de nombreuses organisations se situent aujourd'hui quelque part entre le niveau 0 et le niveau 1 de ce modèle de maturité. Le problème n'est pas que les équipes ne reconnaissent pas l'importance de la signature du code, mais plutôt qu'elles ne savent pas comment signer ou qu'elles ne sont pas au fait des meilleures pratiques en la matière.

Par exemple, nous voyons souvent des clés circuler sur des clés USB, ce qui crée des risques d'exposition. Ou bien nous voyons différentes équipes utiliser différentes solutions ponctuelles, ce qui signifie que les processus sont fragmentés et ne se traduisent pas bien dans l'ensemble de l'organisation. 

Cela est dû au fait que la signature de code sécurisée est un défi : Il faut rendre les clés accessibles aux équipes qui en ont besoin, où qu'elles soient, mais les rendre inaccessibles à ceux qui ne devraient pas signer avec ces clés. Cela peut ressembler à un cercle vicieux.

Alors, comment parvenir à la centralisation et au-delà sur le modèle de maturité de la signature du code ? Les équipes doivent généralement relever trois défis principaux. Heureusement, Keyfactor Signum offre des solutions à ces défis grâce à des fonctionnalités telles que la protection des clés, le contrôle des politiques, les journaux d'événements, les interfaces natives, l'authentification et l'attestation. 

Le défi : Pour commencer, où sont stockées vos clés de signature de code ? Trop souvent, elles sont stockées sur des lecteurs flash, des serveurs de construction ou des postes de travail - autant d'endroits vulnérables à l'accès non autorisé de tiers.

La solution : Keyfactor Signum protège ces clés sensibles en les générant et en les stockant dans un HSM. Notamment, Keyfactor empêche ces clés de quitter le HSM une fois qu'elles ont été générées.

Pourquoi c'est important : À l'avenir, cette attestation de clé (ou la capacité de fournir à votre autorité de certification publique la preuve que les clés sont générées sur un HSM) sera très importante, car le forum CAB imposera bientôt aux autorités de certification publiques de disposer de cette preuve pour signer tout certificat.

Le défi : Ensuite, qui a accès à la signature du code, et existe-t-il une piste d'audit permettant de savoir qui a signé quoi, quand il a signé et avec quoi il a signé ? Il ne suffit pas de stocker et de générer des clés dans un endroit sécurisé, car il faut aussi contrôler qui y a accès.

La solution : Keyfactor Signum Le système de gestion des clés établit cette vérifiabilité en appliquant des règles et des politiques concernant les personnes qui ont accès aux clés, celles qui peuvent les utiliser et l'usage qu'elles peuvent en faire. Elle fournit également une piste d'audit complète pour une meilleure visibilité de tout ce qui se passe dans l'environnement.

Pourquoi c'est important : Le volume des cas d'utilisation nécessitant la signature de code ne cessant de croître, ce niveau de visibilité permettant de vérifier et de valider les activités de signature sera essentiel pour évoluer en toute sécurité.

Le défi : Enfin, les développeurs veulent un outil facile à utiliser et qui ne modifie pas leur processus. Si vous stockez les clés dans un endroit sécurisé et que vous en contrôlez étroitement l'accès, comment faire pour que ces clés soient facilement accessibles aux équipes qui en ont besoin pour signer le code ?

La solution : Keyfactor Signum Rendre ces protections opérationnelles en les intégrant aux outils de signature natifs et en les insérant dans les processus de construction et de livraison existants ; ainsi, les développeurs n'ont pas à modifier leurs flux de travail.

Pourquoi c'est important ? En permettant à vos développeurs de continuer à travailler comme ils le font déjà en introduisant des intégrations natives à leurs outils existants, il est facile pour eux d'obtenir des clés selon leurs besoins (évitant ainsi les ralentissements et/ou les solutions de contournement) tout en maintenant la sécurité en s'authentifiant par l'intermédiaire d'un fournisseur d'identité.

Savoir ce qu'est Keyfactor Signum est une chose, comprendre comment cela fonctionne exactement et à quoi cela ressemble en pratique en est une autre. Dans cette optique, voici un aperçu d'un flux de travail typique avec Keyfactor Signum :

Une fois que le code est validé, d'où qu'il vienne et quel qu'il soit, il doit être signé. Keyfactor Signum propose des intégrations à des outils de signature courants (par exemple, SignTool, jarsigner, Cosign, etc.) pour y parvenir. Comme Keyfactor est hébergé dans le nuage, il permet aux utilisateurs de signer de n'importe où et en toute sécurité.

Keyfactor Signum offre également différents modèles d'authentification par le biais d'un agent SAML/OAuth et d'une console d'administration. Grâce à la console, les administrateurs ont le contrôle et la visibilité sur les politiques de signature et peuvent accorder des approbations pour savoir qui peut faire quoi, et ont accès aux pistes d'audit pour voir l'activité réelle.

Dans l'ensemble, cette architecture offre une solution puissante qui facilite le processus de signature de code pour les développeurs tout en donnant aux administrateurs tout le contrôle dont ils ont besoin pour centraliser la gestion et s'assurer que les clés sont protégées de manière appropriée.

Enfin, comment tout cela s'intègre-t-il dans le pipeline CI/CD ? Avec une solution comme Keyfactor Signum , il est possible de faire en sorte que tout binaire qui entre dans votre dépôt soit signé, point final. Voici à quoi ressemble le processus :

Une fois qu'un développeur a livré du code dans le pipeline CI/CD, il va dans le dépôt de sources et votre serveur CI (qu'il s'agisse de Jenkins, d'Azure DevOps ou d'autre chose) exécute des tests unitaires. Ensuite, le code est signé à l'aide du client Keyfactor Signum , puis il est stocké dans le référentiel.

À l'avenir, chaque fois que quelqu'un tirera du code de la base de données, ce code sera vérifié. Des outils comme SignTool, jarsigner et Cosign intègrent tous un composant de vérification qui vérifie que le code est signé par un certificat vérifié basé sur la bonne racine de confiance. Cela signifie que même si quelqu'un devait créer son propre certificat de signature, il serait en dehors de la racine de confiance désignée, de sorte que tout code signé avec ce certificat échouerait lors de l'étape de vérification.

Une fois que le code a passé l'étape de la vérification, les tests d'intégration et de charge peuvent commencer, et finalement, ce code peut passer en production. L'élément clé de tout cela est que, quel que soit le moment où quelqu'un puise dans le répertoire, il y a toujours une étape de vérification avant que quoi que ce soit d'autre ne se produise.

Vous voulez en savoir plus sur l'intégration de la signature de code sécurisée dans votre pipeline CI/CD et sur la façon dont Keyfactor Signum peut vous aider ? Cliquez ici pour regarder le webinaire complety compris une démonstration en direct de Keyfactor Signum .