Keyfactor Days 2027 – Participez à la conférence « Trust Security » à San Diego Inscrivez-vous dès maintenant !

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

Eric Mizell Eric Mizell VP, Field Engineering
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.

One of the best ways to establish digital trust is through the use of identities and, more specifically, code signing, which verifies the authenticity of new releases. But how exactly is code signing used in organizations today? What are some of the top challenges teams face in implementing code signing, and what happens when those processes aren’t secure? Perhaps most importantly, how can you ensure secure code signing in your CI/CD pipeline?

We recently answered these questions and more during our webinar Integrating Secure Code Signing in the CI/CD Pipeline. Read on for the highlights of this discussion, or click here to watch the full recording.

Établir la confiance numérique : Chaque machine a besoin d'une identité, et chaque identité doit être gérée

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. 

This is where identity becomes so important – especially for machines. Quite simply, every machine, every device, and every workload needs an identity, and every one of those identities must be protected and managed.

Code signing certificates are no different: They are the identity behind your software since they’re used to authenticate everything from software builds and artifacts to container images and even firmware and IoT settings. As a result, if that code signing identity is compromised, it undermines trust.

Comprendre les cas d'utilisation de la signature de code : La composante intégrale de la confiance numérique

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 :

  • Protecting infrastructure: Preventing unauthorized downloads and ransomware by allowing only trusted applications to run on your infrastructure.
  • Securing devices and firmware: Preventing unauthorized device access by securing firmware and firmware updates with digital signatures and verification.
  • Safeguarding software: Ensuring published and distributed software is signed and that keys are protected.
  • Trusting containers: Establishing trusted and digitally signed base images for containers and virtual machines deployed in your environment.
  • Enabling DevSecOps: Establishing trust in the CI/CD pipeline, from digitally signing source code checked into repositories to signing packages post-build.
  • Preventing malicious macros: Preventing unauthorized or malicious macros on internal devices by ensuring that only signed macros are allowed to run.

Instaurer la confiance et réduire les risques : Le modèle de maturité de la signature du code

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 :

Niveau 0 : Pas de signature

  • 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

Niveau 1 : Fragmenté

  • 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

Niveau 2 : Centralisé

  • 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

Niveau 3 : CI/CD intégré

  • 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.

Trouver une solution : Comment Keyfactor Signum résout les obstacles courants à la signature sécurisée du code

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. 

Protéger les clés

The challenge: To start, where are your code signing keys stored? Too often, they’re stored on flash drives, build servers, or workstations – all places vulnerable to third-party, unauthorized access.

The solution: Keyfactor Signum protects these sensitive keys by generating and storing them within an HSM. Notably, Keyfactor prevents these keys from leaving that HSM once generated.

Why it matters: Going forward, this key attestation (or the ability to provide proof to your Public CA that keys are generated on an HSM) will be highly critical, as the CAB Forum will soon be enforcing that Public CAs must have this proof to sign any certificates.

Auditabilité

The challenge: Next, who has access to actually sign code, and is there an audit trail of who signed what, when they signed, and what they signed with? It’s not enough to store and generate keys in a secure place, as you also need to control who has access to them.

The solution: Keyfactor Signum establishes this auditability by enforcing rules and policies around who has access to keys, who can use them, and what they can be used for. It also provides a complete audit trail for visibility into everything going on in the environment.

Why it matters: As the volume of use cases that require code signing continues to grow, this level of visibility to verify and validate signing activities will be essential to scaling securely.

Need for speed

The challenge: Finally, developers want something easy to use and won’t change their process. So if you’re storing keys in a secure location and have tight controls over access, how do you still make those keys easily accessible for the teams that need them to sign code?

The solution: Keyfactor Signum makes these protections operationally effective by integrating into native signing tools and dropping into existing build and delivery processes; that way, developers don’t have to change their workflows.

Why it matters: Allowing your developers to continue working the way they already work by introducing native integrations to their existing tools makes it easy for them to get keys as needed (therefore avoiding slowdowns and/or workarounds) while still maintaining security by authenticating through an identity provider.

Comprendre la solution : L'architecture de la solution Keyfactor Signum

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 also offers different authentication models through a SAML/OAuth agent and an admin console. Through the console, admins have control over and visibility into signing policies and can grant approvals for who can do what, and have access to audit trails to see actual activity.

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.

Réunir tous les éléments : Intégrer la signature de code sécurisée dans le pipeline CI/CD

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.

Quelle est la prochaine étape ? Voir Keyfactor Signum en action

Ready for even more on integrating secure code signing into your CI/CD pipeline and how Keyfactor Signum can help? Click here to watch the full webinar, including a live demo of Keyfactor Signum.

S'abonner à La Source

Stay secure with Keyfactor's monthly newsletter, packed with expert insights and practical steps for quantum-readiness.

Lire la suite

Automatisation des certificats AWS et Azure Key Vault avec Keyfactor
Internet des objets (IoT)

Utilisation de certificats numériques pour IoT Root of Trust

En savoir plus
graphic representation of Keyfactor Signum interface
Produit

Présentation de Keyfactor Signum : une nouvelle plateforme de signature en tant que service

En savoir plus
Secure code signing with lock checkmark tech scene
Signature du code

L'importance d'être sérieux avec la signature du bootloader et du firmware

En savoir plus