La signature de code s’appuie sur l’infrastructure à clé publique (PKI) pour servir de passeport numérique à votre logiciel. Grâce aux signatures numériques, elle crée une preuve cryptographique de l’authenticité et de l’intégrité. Elle vous authentifie en tant qu’éditeur et garantit l’intégrité du code en prouvant qu’il n’a pas été modifié depuis sa publication.
Lorsque les utilisateurs téléchargent votre logiciel, ils vous confient la sécurité de leur système. Brisez cette confiance une seule fois, et c’en est fini de vous.
Table des matières
- Protégez vos clés privées avec des modules de sécurité matériels
- Mettre en place des contrôles d’accès stricts pour les clés de signature de code
- Horodatez votre code pendant le processus de signature
- Séparer les environnements de test-signature et de validation-signature
- Mettre en œuvre l’authentification du code et la vérification de l’intégrité avant la signature
- Effectuez une analyse antivirus du code avant de le signer
- Rotation des clés et utilisation de plusieurs certificats
- Prenez au sérieux la révocation des certificats
- Exploiter les certificats de signature de code à validation étendue
- Automatiser et centraliser la gestion des signatures de code
- Sécurisez votre chaîne d’approvisionnement en logiciels avec SSL Dragon
Les enjeux sont devenus réels après que la faille de SolarWinds a révélé des vulnérabilités critiques dans la chaîne d’approvisionnement des logiciels, montrant comment des clés de signature compromises peuvent utiliser des mises à jour logicielles légitimes et compromettre des milliers d’organisations. Aujourd’hui plus que jamais, le respect des meilleures pratiques en matière de signature de code n’est pas facultatif – il est fondamental pour protéger vos utilisateurs et votre réputation.
La protection de la chaîne d’approvisionnement des logiciels est devenue une priorité absolue pour les organisations de toutes tailles. Ces lignes directrices vous aideront à mettre en œuvre des mesures de sécurité efficaces, que vous soyez un développeur isolé ou que vous gériez les pipelines DevOps d’une entreprise. Que vous signiez des exécutables Windows, des applications macOS, des paquets Linux ou des applications mobiles pour iOS et Android, ces principes s’appliquent à toutes les plateformes.
Protégez vos clés privées avec des modules de sécurité matériels
Votre clé clé privée est essentielle pour la signature de code. Si vous la compromettez, les pirates peuvent signer des logiciels malveillants avec votre identité. Votre certificat est révoqué, vos clients perdent confiance et votre marque subit un préjudice dont vous ne pourrez peut-être pas vous remettre.
Pourquoi la sécurité des clés privées est essentielle
Considérez votre clé privée comme la clé principale de la crédibilité de votre logiciel : elle génère les signatures numériques qui prouvent votre identité. Si quelqu’un la vole, il peut distribuer un code malveillant qui semble provenir de vous. Vous devrez alors révoquer votre certificat, signer à nouveau tout ce que vous avez publié et espérer que vos clients remarqueront la différence avant d’installer un logiciel infecté.
L’approche traditionnelle consistant à stocker les clés sur des disques durs ou à construire des serveurs est source d’ennuis. Les machines des développeurs sont compromises. Les serveurs de construction sont violés. Même le stockage crypté sur du matériel ordinaire laisse les clés vulnérables à l’extraction.
Solutions matérielles certifiées FIPS 140-2
Les modules de sécurité matériels (HSM) résolvent ce problème en stockant les clés privées dans un matériel inviolable. En tant que pierre angulaire de votre infrastructure PKI, les modules de sécurité matériels fournissent la base de sécurité nécessaire à la confiance basée sur les certificats. Ces dispositifs génèrent et utilisent des clés en interne sans jamais les exposer à votre système. Si vous tentez d’altérer physiquement un HSM, les clés sont détruites.
La certification FIPS 140-2 est importante à cet égard. Le niveau 2 exige une preuve physique d’inviolabilité, tandis que le niveau 3 ajoute une réponse active à l’inviolabilité qui met les clés à zéro lorsque quelqu’un tente de s’introduire dans le système. Pour la plupart des entreprises, le niveau 2 offre une protection solide. Ces solutions matérielles s’intègrent parfaitement aux environnements de développement Windows, macOS et Linux, protégeant ainsi vos clés quelle que soit votre plateforme de développement. Les applications gouvernementales et de haute sécurité devraient envisager le niveau 3.
Les jetons USB offrent une alternative au HSM portable. Il s’agit d’un matériel cryptographique certifié FIPS que vous pouvez emporter avec vous, ce qui ajoute à la sécurité physique par la possession. Les principales autorités de certification prennent en charge les implémentations de HSM et de jetons USB pour les certificats de signature de code.
However, CA policies differ, and you need to plan around them. DigiCert and GoGetSSL issue code signing certificates for 1 year only, and you can use either a CA-provided HSM or your own hardware.
Sectigo (Comodo) propose des certificats pluriannuels jusqu’à 3 ans, mais avec des règles plus strictes. Si vous choisissez un certificat de 2 ou 3 ans, vous devez utiliser votre propre HSM. Le matériel fourni par l’autorité de certification n’est disponible que pour les commandes d’un an.
Vous voulez signer un code ? Vous avez besoin du jeton. Sans jeton, pas de signature, même si quelqu’un compromet l’ensemble de votre réseau.
Mettre en place des contrôles d’accès stricts pour les clés de signature de code
Tous les membres de votre équipe n’ont pas besoin d’accéder aux clés de signature de production. En fait, la plupart des personnes ne devraient pas y avoir accès.
Le principe est simple: moins il y a de personnes ayant accès, moins il y a de vecteurs d’attaque. Mettez en place un contrôle d’accès basé sur les rôles (RBAC) qui limite les autorisations de signature à des rôles spécifiques. Votre équipe d’assurance qualité n’a pas besoin d’un accès à la signature en production. Vos développeurs juniors n’en ont probablement pas besoin non plus.
Créez des flux de travail d’approbation qui nécessitent plusieurs signatures pour les versions de production. Une personne soumet le code à la signature, une autre l’approuve, et ce n’est qu’ensuite que la signature proprement dite a lieu. Cette séparation des tâches permet d’éviter les erreurs et de prévenir les menaces internes.
Conservez des journaux d’audit complets. Enregistrez qui a signé quoi, quand il l’a fait et à partir de quel système. Le livre blanc Code Signing Best Practices du CA Security Council insiste sur le fait qu’une journalisation détaillée est essentielle pour la réponse aux incidents et les enquêtes judiciaires. Lorsque quelque chose ne va pas – et cela finit toujours par arriver – vous devez savoir exactement ce qui s’est passé.
La sécurité physique est également importante :
- Ne laissez pas de clés USB sur les bureaux.
- Ne stockez pas les identifiants d’accès au HSM dans des fichiers texte.
- N’écrivez pas de codes PIN sur des notes autocollantes.
Cela semble évident, mais il s’agit de problèmes courants qui compromettent une sécurité par ailleurs solide.
Horodatez votre code pendant le processus de signature
Le problème est le suivant : les certificats de signature de code expirent, généralement au bout d’un à trois ans. Sans horodatage, votre signature devient invalide lorsque votre certificat expire. Les utilisateurs commencent à voir des messages d’avertissement concernant des logiciels non fiables, même si rien n’a changé dans votre code.
L’horodatage corrige ce problème en ajoutant un horodatage fiable provenant du serveur d’horodatage d’une autorité de certification au cours du processus de signature. Cet horodatage prouve que vous avez signé le code alors que votre certificat était encore valide. La signature reste fiable même après l’expiration ou la révocation de votre certificat.
Il s’agit en quelque sorte d’un cachet de notaire avec une date. Le notaire peut prendre sa retraite ou fermer boutique, mais le cachet qu’il appose sur votre document en 2020 prouve toujours que le document a existé et a été vérifié en 2020.
Le processus technique est simple. Lors de la signature, votre outil contacte un serveur d’horodatage géré par votre autorité de certification. Le serveur renvoie un horodatage signé qui est intégré à la signature de votre code. Lorsque les utilisateurs vérifient votre signature sur n’importe quelle plateforme – Windows, macOS, Linux, iOS ou Android – ils vérifient à la fois votre certificat de signature et l’horodatage. Ce processus de vérification maintient l’intégrité du code dans le temps, même lorsque les certificats expirent et que les normes de sécurité évoluent.
Cela permet également d’économiser de l’argent. Sans horodatage, vous devriez re-signer tous vos logiciels distribués à chaque fois que vous renouvelez votre certificat. Avec l’horodatage, les anciennes versions restent fiables indéfiniment.
Economisez 10% sur les certificats SSL en commandant chez SSL Dragon aujourd’hui !
Délivrance rapide, cryptage puissant, confiance de 99,99 % du navigateur, assistance dédiée et garantie de remboursement de 25 jours. Code de coupon : SAVE10
Séparer les environnements de test-signature et de validation-signature
Votre environnement de test ne doit pas utiliser les mêmes clés de signature que l’environnement de production. Jamais.
Les certificats de test doivent être soit auto-signés, soit délivrés par une autorité de certification de test interne qui s’appuie sur une racine différente de celle de vos certificats de production. Cette séparation architecturale permet d’éviter que le code signé pour les tests soit confondu avec un logiciel prêt à être publié.
Mettez en place une infrastructure de signature distincte pour chaque environnement. Votre signature de test peut être plus accessible et moins restrictive – les développeurs ont besoin d’itérer rapidement. En revanche, la signature de production doit être verrouillée par toutes les mesures de sécurité que nous venons d’évoquer.
Marquez clairement les paquets de test. Incluez « TEST » ou « BETA » dans les noms de fichiers. Utilisez des identifiants de produits différents. Faites en sorte qu’il soit impossible de distribuer accidentellement aux clients un code signé par les testeurs.
Les contrôles d’accès devraient également être très différents. Les développeurs peuvent avoir un accès direct à la signature de test. La signature de production devrait nécessiter des flux de travail d’approbation et éventuellement des informations d’identification différentes.
Mettre en œuvre l’authentification du code et la vérification de l’intégrité avant la signature
La signature de code permet d’authentifier le code, c’est-à-dire de confirmer qui a publié le logiciel. Elle ne confirme pas que le logiciel est sûr.
Cette distinction est importante car vous êtes en fin de compte responsable de tout ce que vous signez, même si vous n’en êtes pas l’auteur. Signer un code que vous n’avez pas vérifié revient à cosigner un prêt sans vérifier les finances de l’emprunteur.
Mettez en place des processus de soumission et d’approbation avant toute signature. Demandez à quelqu’un d’examiner ce qui est signé. Comparez le code de votre serveur de construction à celui de votre dépôt de code source. Assurez-vous qu’ils correspondent exactement.
La faille de SolarWinds nous a appris que les attaquants peuvent injecter du code malveillant dans les pipelines de construction. Cette attaque a mis en évidence l’importance de la sécurité de la chaîne d’approvisionnement des logiciels – chaque composant, dépendance et étape de construction représente un vecteur d’attaque potentiel. Si vous signez sans vérifier, vous faites confiance à chaque partie de votre infrastructure et à chaque morceau de code provenant de sources externes. Ce n’est pas un pari que vous voulez faire.
Mettez en place des contrôles automatisés dans la mesure du possible. Vérifiez les signatures numériques du code que les développeurs déposent dans votre référentiel. Exécutez des outils d’analyse statique. Créez des sommes de contrôle pour les versions approuvées et vérifiez-les avant de les signer.
Enregistrez tout. Lorsque quelqu’un soumet un code à signer, enregistrez ce qui a été soumis, qui l’a soumis, qui l’a approuvé et ce qui a été signé. Ces pistes d’audit s’avèrent cruciales lors des enquêtes sur les incidents.
Effectuez une analyse antivirus du code avant de le signer
La signature de code prouve que vous avez publié le logiciel. Les utilisateurs vous font confiance pour ne pas publier de logiciels malveillants, mais les certificats de signature de code ne vérifient pas la sécurité.
Cela est important lorsque vous incorporez du code provenant de sources externes (bibliothèques à code source ouvert, composants tiers, contributions d’entrepreneurs). Vous signez tout cela sous votre nom.
Analysez tout avant de signer. Utilisez si possible plusieurs moteurs antivirus. Recherchez les signatures de logiciels malveillants connus, les schémas suspects et les vulnérabilités potentielles. Ceci s’applique que vous prépariez des exécutables Windows, des applications macOS, des paquets Linux ou des applications mobiles pour iOS et Android.
La détection d’une insertion malveillante par inadvertance avant la signature protège vos utilisateurs et votre réputation. Si vous la découvrez après avoir distribué des logiciels malveillants signés, vous devrez révoquer le certificat, informer vos clients et limiter les dégâts.
L’analyse n’ajoute qu’un temps minime à votre processus de construction, mais offre une protection essentielle pour l’intégrité et l’authenticité du code. Rendez-le obligatoire, et non optionnel.
Rotation des clés et utilisation de plusieurs certificats
Ne mettez pas tous vos œufs dans le même panier. L’utilisation d’un seul certificat de signature de code pour tout crée un point de défaillance unique.
Envisagez d’utiliser différents certificats pour différentes lignes de produits ou versions majeures. Si vous découvrez une faille de sécurité dans la gestion d’un certificat, il vous suffit de révoquer ce certificat spécifique. Vos autres produits restent fiables.
La rotation régulière des clés limite également l’exposition. Si quelqu’un a compromis votre clé il y a six mois, mais que vous avez depuis changé de certificat, il ne peut pas signer le code actuel en votre nom. Les dommages sont limités aux anciennes versions.
Certaines organisations attribuent des certificats uniques à différentes équipes DevOps ou branches de publication. Cela permet de répartir les risques et de faciliter les enquêtes sur les compromissions. En cas de problème, vous savez exactement quel certificat est impliqué et quelles versions sont concernées.
Établissez un calendrier de rotation qui concilie la sécurité et les coûts opérationnels. Une rotation annuelle ou semestrielle convient à de nombreuses organisations. Dans les environnements hautement sécurisés, la rotation peut être trimestrielle.
Prenez au sérieux la révocation des certificats
La révocation d’un certificat est l’option nucléaire, mais elle est parfois nécessaire.
Révoquez immédiatement votre clé privée si elle est compromise. N’attendez pas d’évaluer les dégâts. N’espérez pas que personne ne l’ait remarqué. Révoquez-la, informez votre autorité de certification et commencez à prendre des mesures de confinement.
La révocation affecte tout le code signé avec ce certificat. Les utilisateurs verront des avertissements. Les systèmes automatisés peuvent bloquer l’installation. C’est pourquoi l’horodatage est essentiel : il limite les dommages au code signé après l’horodatage mais avant la révocation.
Suivez attentivement vos certificats au sein de votre infrastructure PKI. Sachez où ils se trouvent, qui y a accès, quand ils expirent et quel code ils ont signé. La gestion du cycle de vie des certificats devient cruciale à mesure que vous vous développez.
Signalez les compromissions à votre autorité de certification conformément à ses procédures. Elle vous aidera en cas de révocation et pourra vous donner des conseils sur les exigences en matière de notification.
Le fait de disposer d’un plan de révocation avant d’en avoir besoin rend le processus moins chaotique. Documentez les étapes, attribuez les responsabilités et mettez la procédure en pratique.
Exploiter les certificats de signature de code à validation étendue
Les certificats de signature de code Extended Validation (EV) sont des certificats numériques X.509 qui offrent une assurance plus élevée que les certificats standard. L’autorité de certification procède à une vérification plus rigoureuse de l’identité avant de les délivrer.
Les certificats EV nécessitent un stockage matériel conforme aux normes FIPS 140-2 de niveau 2 ou supérieur. Vous ne pouvez pas obtenir un certificat EV et le stocker sur votre disque dur. Cette protection matérielle obligatoire réduit le risque de compromission des clés.
La plupart des certificats EV se présentent sous la forme de jetons USB avec protection par code PIN. Vous avez besoin à la fois du jeton physique et du code PIN pour signer le code. Cette approche à deux facteurs rend la signature non autorisée plus difficile.
Des recherches menées par le laboratoire d’innovation en cyberjustice de Georgia Tech ont montré que les exécutables signés EV ont résisté à 99,99 % des attaques de phishing testées, contre 90 % pour les signatures standard. Les systèmes d’exploitation, notamment Windows, macOS et les plateformes mobiles comme iOS et Android, reconnaissent les signatures EV et affichent des indicateurs de confiance améliorés pour les utilisateurs. Les indicateurs de confiance améliorés et le contrôle rigoureux font une différence mesurable.
Choisissez les certificats EV lorsque vous avez besoin d’une confiance maximale – produits phares, logiciels largement diffusés ou applications traitant des données sensibles. Le surcoût et les frais de gestion supplémentaires se traduisent par une crédibilité et une sécurité accrues.
Automatiser et centraliser la gestion des signatures de code
La gestion manuelle des certificats n’est pas adaptée aux environnements DevOps dans lesquels plusieurs équipes envoient du code en continu.
Les solutions de gestion du cycle de vie des certificats (CLM) centralisent le contrôle tout en s’intégrant aux pipelines CI/CD. Des plateformes telles que Sectigo Certificate Manager et AppViewX CERT+ offrent des capacités CLM de niveau entreprise conçues spécifiquement pour les flux de travail de signature de code. Les développeurs bénéficient d’un accès en libre-service pour générer des signatures numériques sans accès direct aux clés. Les équipes de sécurité maintiennent une visibilité et appliquent des politiques pour toutes les activités de signature.
Ces plateformes assurent le suivi de l’inventaire des certificats, des dates d’expiration et des schémas d’utilisation. La gestion centralisée devient essentielle pour la sécurité de la chaîne d’approvisionnement des logiciels, en particulier lorsque plusieurs équipes et sous-traitants contribuent à votre base de code. Elles automatisent les renouvellements et facilitent les audits. Lorsque vous avez besoin de savoir ce qui a été signé avec tel ou tel certificat, l’information est là.
L’intégration avec les systèmes de construction signifie que les développeurs n’ont pas besoin de penser aux détails des certificats. Ils soumettent leur code, le pipeline gère automatiquement la signature à l’aide du certificat approprié et l’artefact signé sort de l’autre côté.
Des flux de travail prédéfinis permettent d’appliquer vos politiques de sécurité. Le code ne peut pas être signé sans approbation. Les certificats de test ne peuvent pas être utilisés pour la production. Les développeurs d’une unité commerciale ne peuvent pas accéder aux clés de signature d’une autre unité.
La centralisation simplifie la sécurité sans compliquer la vie des développeurs. C’est l’équilibre dont vous avez besoin : une sécurité forte qui fonctionne avec votre processus de développement, et non contre lui.
Sécurisez votre chaîne d’approvisionnement en logiciels avec SSL Dragon
SSL Dragon fournit des certificats de signature de code des principales autorités de certification, y compris DigiCert et Sectigo. Que vous ayez besoin d’une signature de code standard pour des applications internes ou de certificats EV pour des logiciels largement distribués, nous vous aiderons à choisir la bonne solution.
Notre équipe comprend les défis de sécurité auxquels sont confrontés les développeurs de logiciels. Nous pouvons vous guider dans la sélection, la mise en œuvre et la gestion des certificats afin de garantir que votre infrastructure de signature de code respecte les meilleures pratiques de l’industrie.
Découvrez les certificats de signature de code de SSL Dragon ou contactez notre équipe pour discuter de la solution la mieux adaptée à vos besoins en matière de développement et de sécurité des logiciels. Protégez votre chaîne d’approvisionnement en logiciels – vos utilisateurs comptent dessus.
Economisez 10% sur les certificats SSL en commandant aujourd’hui!
Émission rapide, cryptage puissant, confiance de 99,99 % du navigateur, assistance dédiée et garantie de remboursement de 25 jours. Code de coupon: SAVE10
