Contrôle de l’intégrité du logiciel
La méthode de diffusion du logiciel doit permettre à l’utilisateur final de vérifier si le logiciel en sa possession est authentique et s’il n’a pas subi d’altération. Certaines plates-formes, comme Microsoft.Net, permettent de signer le logiciel. Si la signature du logiciel n’est pas possible, il faut, au minimum, publier un haché, par exemple en utilisant l’algorithme SHA-2, pour permettre au client de vérifier l’intégrité et l’authenticité du logiciel.
Définition d’un plan de réponse aux incidents
Malgré toutes les précautions prises durant le développement d’un logiciel, il est impossible de garantir, qu’une faille nécessitant une correction ne sera pas découverte dans celui-ci.
C’est à ce moment-là, que le plan de réponse aux incidents devient utile. Il doit contenir, au minimum, les points suivants :
- Une liste de contacts téléphoniques incluant un responsable en mesure de prendre les décisions nécessaires.
- Une description du processus de réponse aux incidents
Le niveau de ce plan dépend essentiellement du contexte d’utilisation du logiciel. Un logiciel traitant des données sensibles, distribué à large échelle, nécessitera un plan de réponse aux incidents nettement plus sérieux.
La mise en place d’un processus de veille peut permettre de gagner un temps précieux dans ce type de situation et ainsi limiter l’impact d’un incident.
Archivage
En plus du code et du logiciel lui-même, toutes les informations et les décisions relatives à la sécurité de l’information doivent être archivées. Le système d’archivage doit offrir une traçabilité complète. Il est possible d’utiliser une solution d’archivage tel que Git [GIT], Mercurial [MERCURIAL] ou Subversion [SUBVERSION]. Si une telle option est choisie, il est vivement recommandé de ne pas stoquer les binaires logiciels directement, mais simplement leur signature ou leur haché.
Diffusion
Quand le logiciel rempli toutes les exigences de sécurité et que ce point a été dûment vérifié, il est possible de diffuser le logiciel.