Rapport explicatif

Ch. 24.1 : Les outils de développement dont il est question ici sont les outils qui revêtent une importance pour la sécurité du développement du logiciel. Il s’agit notamment des outils de l’IDE (Integrated Development Environment), des outils de construction (build tools) et des outils de gestion de la configuration, mais aussi des options de configuration qui peuvent avoir une influence sur la sécurité du développement.

Comme il a été précise au ch. 17.2, les interfaces sont les éléments qui permettent au logiciel d’échanger des informations avec son environnement. Il peut s’agir d’interfaces graphiques, de lignes de commande ou d’interfaces de programmation (API).

Une liste de configuration est un groupe d’éléments de configuration cohérents entre eux qui représentent l’état du logiciel et de la documentation à un moment donné. Dans l’idéal, il permet de reconstituer une version précédente du logiciel.

Ch. 24.3 : Il s’agit de garantir la mise à disposition correcte du système depuis le code source jusqu’à son installation en production (construction et déploiement). Il incombe à cet égard au fournisseur du système d’utiliser une méthode de construction et de déploiement à la fois éprouvée et traçable, laquelle permettra d’atteindre les objectifs suivants :

- s’assurer que le logiciel utilisé est conforme à la version publiée, testée et autorisée ;

- en plus de cette traçabilité, empêcher autant que possible toute manipulation des composants du

système ;

- éviter que les outils de développement et librairies utilisés n’introduisent des vulnérabilités perti-

nentes pour le logiciel qui rendraient le système vulnérable aux attaques.

Pour ce faire, on a fixé de nouvelles exigences, lesquelles se fondent sur les directives de l’État américain du Colorado qui régissent l’utilisation des systèmes de vote électronique¹⁰, sur la documentation de l’entreprise GitHub relative au trusted build (construction fiable)¹¹ et sur la documentation intitulée « Reproducible Builds », qui est issue du projet éponyme¹².

Ch. 24.4 : Les utilisateurs sont toutes les personnes qui entrent en contact avec le logiciel de quelque façon que ce soit. Il peut s’agir de collaborateurs du canton, d’électeurs, de testeurs et, en fin de compte, de toutes les personnes qui portent un intérêt au système.

Pour que le développeur puisse traiter de façon appropriée les rapports qu’il reçoit concernant des failles et mener une activité de communication efficace dans ce domaine, il est important que les utilisateurs sachent comment lui transmettre ces rapports et comment s’enregistrer auprès de lui pour obtenir les informations en la matière.

Pour contribuer à améliorer la sécurité d’un système, il faut dresser une liste aussi complète que possible des vulnérabilités supposées et les traiter de manière systématique. Les exigences en la matière viennent compléter la publication du code source (art. 11 et 12 P-OVotE) et la mise en place d’un programme de bug bounty (art. 13 P-OVotE).

Ch. 25 Qualité du code source et de la documentation

La qualité du code source et de la documentation est un élément capital pour la sécurité du vote électronique. Les bases légales actuelles imposent plusieurs exigences en la matière. Il s’agit toutefois plutôt de descriptions générales, telles que l’obligation de préparer et de documenter le code source conformément aux bonnes pratiques et de mettre en œuvre certains éléments des Common Criteria. Aussi a-t-il fallu préciser les critères de qualité qui s’appliquent aujourd’hui. Des critères clairs devront garantir une qualité élevée des systèmes de vote électronique, ce qui profitera à la sécurité, car cela facilitera les contrôles effectués par tous les acteurs et par le public. Pour définir ces critères de qualité, on a établi un modèle de qualité pour les systèmes de vote électronique. Ce modèle repose sur la norme ISO 25010 et sur le