ĂŰĚŇTV

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.

  • ĂŰĚŇTV Logo

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