1. FAQ
  2. Confiance pour la signature de code
  3. Quelles sont les bonnes pratiques de signature de code ?
FAQ Hero
Confiance pour la signature de code

Quelles sont les bonnes pratiques de signature de code ?

Quelles sont les bonnes pratiques de signature de code ?

La signature de code permet de contrôler l’identité de l’éditeur ou du développeur du logiciel, puis de vérifier l’intégrité du code après le téléchargement. L’utilisateur a ainsi la garantie que le logiciel n’a pas été modifié depuis sa signature. Cela prouve que le code est digne de confiance. Seulement voilà, les cybercriminels tentent constamment de déjouer les bonnes pratiques de signature de code pour intégrer des malwares dans du code de confiance.

Voici donc quelques bonnes pratiques pour limiter le risque d’attaque :

  • Sécurisez le stockage des clés : si la clé privée de signature d’une entreprise est compromise ou volée, elle peut être utilisée pour signer un logiciel incluant un malware. Dans ce cas, le logiciel publié passera pour un logiciel légitime provenant de l’organisation victime de l’attaque. D’où la nécessité de mettre les clés privées à l’abri dans un module de sécurité matériel (HSM) ou de les chiffrer au repos. Selon les exigences du CA/Browser Forum (CA/B), les clés destinées à garantir la confiance publique doivent être stockées dans un HSM.
  • Appliquez des contrôles d’accès pour les clés et pour les signatures : élaborez des politiques et appliquez des contrôles d’accès aux clés afin que seuls les développeurs et les utilisateurs autorisés puissent signer avec des clés spécifiques. Et pour éviter qu’elles ne soient partagées, perdues ou volées, générez les clés dans le cloud. En parallèle, respectez le principe de la séparation des tâches. Autrement dit, les personnes qui génèrent les clés et les signataires ne doivent pas avoir les mêmes responsabilités. Implémentez également l’authentification multifacteur (MFA) pour confirmer l’identité de toute personne qui accède aux signatures. Enfin, révoquez les accès des personnes qui ont quitté l’entreprise ou qui n’ont plus besoin d’accéder aux signatures ni de générer des clés.
  • Surveillez et auditez les workflows de signature : consignez le nom des signataires, du code et la date pour pouvoir réagir rapidement en cas de signature non autorisée et y remédier. Dans le même temps, auditez régulièrement toutes les activités associées aux paires de clés : génération, opérations relatives aux certificats, affectation des clés, accès aux signatures, etc.
  • Tenez-vous au courant des standards cryptographiques et appliquez les politiques relatives dans toute l’entreprise : les exigences sectorielles évoluent pour aider les organisations à garder un coup d’avance sur les cybercriminels. Depuis le 1er juin 2021, les nouvelles exigences du CA/Browser Forum fixent comme minimum une clé RSA 3 072 bits pour les certificats d’horodatage et de signature de code publiquement approuvés. Or il se peut que ces changements de réglementation soient méconnus des développeurs et des utilisateurs générant des clés ou signant du code au sein de votre structure. C’est pourquoi vous devez appliquer les exigences sectorielles afin d’empêcher les collaborateurs de générer des clés ou de demander des certificats avec des algorithmes, des tailles de clés ou des courbes trop faibles ou non conformes.
  • Automatisez la signature de code dans les processus du cycle de développement logiciel (SDLC) : si vous souhaitez limiter les risques inhérents au code non signé ou aux signatures non conformes, vous avez tout intérêt à intégrer et à automatiser les signatures dans les processus SDLC, notamment dans les pipelines CI/CD. Pour cela, vous pouvez mettre en place des contrôles de sécurité et implémenter l’automatisation afin de concevoir des logiciels sécurisés et conformes qui suivent le rythme rapide du développement logiciel.
  • Comparez les signatures de différents serveurs de builds : récemment, des attaques contre la supply chain logicielle ont ciblé des organisations reconnues aux quatre coins du monde, entraînant des perturbations opérationnelles et financières majeures. Le mode opératoire des cybercriminels est bien rodé : ils infiltrent les opérations de développement de l’entreprise cible et intègrent des malwares dans le code au cours du processus SDLC. Le code manipulé est ensuite publié et déployé dans les systèmes des clients. Pour repérer d’éventuelles différences entre les builds, signez et comparez le hash du logiciel à partir de différents serveurs de builds. Dès lors qu’au moins deux builds sont identiques, on peut considérer qu’ils sont sécurisés et dépourvus de code inconnu.
  • Révoquez les certificats compromis : si vous découvrez des clés compromises ou un malware signé, signalez-le à votre autorité de certification (AC) qui se chargera de révoquer le certificat de signature. Le logiciel sera alors invalide, ce qui stoppera la propagation du malware.
  • Horodatez la signature de votre code : évitez que votre logiciel expire inopinément lors de l’expiration du certificat de signature de code. Les certificats de signature de code sont valables pendant 1 à 3 ans. Lorsqu’un certificat de signature de code expire, la validité du logiciel signé expire également, sauf si le logiciel a été horodaté lors de sa signature. Dans ce cas, le système enregistre l’horodatage et le logiciel reste valide tant qu’il est en production. En prime, l’horodatage du code permet aussi de minimiser l’impact d’une révocation de certificat. Concrètement, si un malware est découvert et que le certificat associé doit être révoqué, la révocation n’affecte que les versions publiées après la date de la compromission.

  • DigiCert Logo

    Le fournisseur mondial de confiance pour les solutions TLS/SSL, PKI, IoT et de signature à haute assurance.