Sécurité des logiciels open source

La sécurité des logiciels open source est la mesure de l’assurance ou de la garantie de l’absence de danger et de risque inhérent à un système logiciel open source .

• Les logiciels propriétaires obligent l'utilisateur à accepter le niveau de sécurité que le fournisseur de logiciels est prêt à offrir et à accepter le rythme auquel les correctifs et les mises à jour sont publiés.
• On suppose que tout compilateur utilisé crée du code auquel on peut faire confiance, mais Ken Thompson a démontré qu'un compilateur peut être subverti en utilisant une porte dérobée de compilateur pour créer des exécutables défectueux qui sont produits involontairement par un développeur bien intentionné. Avec l'accès au code source du compilateur, le développeur a au moins la possibilité de découvrir s'il y a une mauvaise intention.
• Le principe de Kerckhoff repose sur l'idée qu'un ennemi peut voler un système militaire sécurisé sans pouvoir compromettre les informations. Ses idées ont servi de base à de nombreuses pratiques de sécurité modernes, et ont permis de conclure que la sécurité par l'obscurité est une mauvaise pratique.

• Le simple fait de mettre à disposition le code source ne garantit pas une vérification. Un exemple de ce phénomène est celui de Marcus Ranum , un expert en conception et mise en œuvre de systèmes de sécurité, qui a publié sa première boîte à outils de pare-feu public. À une époque, plus de 2 000 sites utilisaient sa boîte à outils, mais seules 10 personnes lui ont fait part de leurs commentaires ou de leurs correctifs.
• Le fait qu'un grand nombre d'utilisateurs examinent le code peut « donner à l'utilisateur un faux sentiment de sécurité ». Le fait que de nombreux utilisateurs examinent le code source ne garantit pas que les failles de sécurité seront détectées et corrigées.

Il existe une variété de modèles et de mesures permettant de mesurer la sécurité d'un système. Voici quelques méthodes qui peuvent être utilisées pour mesurer la sécurité des systèmes logiciels.

On prétend qu'un système est plus vulnérable après la découverte d'une vulnérabilité potentielle, mais avant la création d'un correctif. En mesurant le nombre de jours entre la vulnérabilité et le moment où elle est corrigée, on peut déterminer la base de la sécurité du système. Cette approche comporte quelques réserves : toutes les vulnérabilités ne sont pas aussi graves et il n'est peut-être pas préférable de corriger rapidement un grand nombre de bugs que de n'en trouver que quelques-uns et de prendre un peu plus de temps pour les corriger, compte tenu du système d'exploitation ou de l'efficacité du correctif.

Le processus de Poisson peut être utilisé pour mesurer les taux auxquels différentes personnes trouvent des failles de sécurité entre les logiciels open source et les logiciels à source fermée. Le processus peut être décomposé en fonction du nombre de bénévoles N _v et de réviseurs rémunérés N _p . Le taux auquel les bénévoles trouvent une faille est mesuré par λ _v et le taux auquel les réviseurs rémunérés trouvent une faille est mesuré par λ _p . Le temps attendu pour qu'un groupe de bénévoles trouve une faille est de 1/(N _v λ _v ) et le temps attendu pour qu'un groupe rémunéré trouve une faille est de 1/(N _p λ _p ).

En comparant une grande variété de projets open source et de projets fermés, un système d'étoiles pourrait être utilisé pour analyser la sécurité du projet, de la même manière que Morningstar, Inc. évalue les fonds communs de placement. Avec un ensemble de données suffisamment important, des statistiques pourraient être utilisées pour mesurer l'efficacité globale d'un groupe par rapport à l'autre. Voici un exemple d'un tel système :

• 1 étoile : De nombreuses vulnérabilités de sécurité.
• 2 étoiles : Problèmes de fiabilité.
• 3 étoiles : respecte les meilleures pratiques de sécurité.
• 4 étoiles : Processus de développement sécurisé documenté.
• 5 étoiles : A réussi un examen de sécurité indépendant.

Coverity, en collaboration avec l'université de Stanford, a établi une nouvelle référence en matière de qualité et de sécurité open source. Le développement est réalisé grâce à un contrat avec le ministère de la Sécurité intérieure. Ils utilisent des innovations dans la détection automatique des défauts pour identifier les types critiques de bugs trouvés dans les logiciels. Le niveau de qualité et de sécurité est mesuré en échelons. Les échelons n'ont pas de signification définitive et peuvent changer à mesure que Coverity publie de nouveaux outils. Les échelons sont basés sur la progression de la résolution des problèmes détectés par les résultats de l'analyse Coverity et le degré de collaboration avec Coverity. Ils commencent par l'échelon 0 et vont actuellement jusqu'à l'échelon 2.

• Échelon 0

Le projet a été analysé par l'infrastructure Scan de Coverity, mais aucun représentant du logiciel open source ne s'est manifesté pour connaître les résultats.

• Échelon 1

Au niveau 1, il y a une collaboration entre Coverity et l'équipe de développement. Le logiciel est analysé avec un sous-ensemble des fonctionnalités d'analyse pour éviter que l'équipe de développement ne soit submergée.

• Échelon 2

Il y a 11 projets qui ont été analysés et mis à niveau vers le statut de Rung 2 en atteignant zéro défaut au cours de la première année de l'analyse. Ces projets incluent : AMANDA, ntp , OpenPAM , OpenVPN , Overdose, Perl , PHP , Postfix , Python , Samba et tcl .