La sécurité est un domaine souvent mis en avant lorsque l’on évoque les avantages associés au logiciel libre. Cet aspect suscite de nombreuses controverses et les études qui y sont consacrées ne permettent pas d’apporter un point de vue définitif sur la question. Le but de ce document est de porter un regard nuancé sur le lien entre sécurité et logiciel libre en se référant à l’avis de quelques experts dans le domaine.

1. REPUBLIQUE ET CANTON DE GENEVE
Département des constructions et des technologies de l'information
Centre des technologies de l'information
Logiciel libre et sécurité
Auteurs Patrick GENOUD, Observatoire technologique
Version / Date d’enregistrement V1.0 / 2007-04-05
Pour aller à l'essentiel
Observatoire technologique
Téléphone +41 (22) 388 13 50 • Fax +41 (22) 388 13 57 • www.geneve.ch
Le logiciel libre a le potentiel pour être plus sûr que le logiciel propriétaire. Les
projets open source peuvent en effet réaliser tout ce dont sont capables les projets
réalisés en mode fermé, tout en bénéficiant des avantages liés à l'ouverture du code
et au mode de développement communautaire. De nombreux projets open source
de qualité supérieure sont là pour le prouver.
Mais il faut bien distinguer les potentialités indiscutables offertes par le modèle open
source de leur réelle mise en oeuvre au sein des projets. Pour que ce modèle soit
réellement efficace dans le domaine de la sécurité, il faut ainsi que le projet réunisse
une communauté suffisamment importante, dispose de développeurs sensibilisés et
motivés par les questions de sécurité, revoie et corrige effectivement le code en
terme de sécurité et dispose si possible de spécialistes en la matière.
Cela doit passer par une sensibilisation à la sécurité des communautés et de leur
direction ainsi que par une industrialisation des processus de développement, en y
intégrant étroitement la sécurité.

2. Logiciel libre et sécurité
Contexte
Dans le premier plan de mesures publié en novembre 2006 par le conseil d'État du canton
de Genève, la promotion de l'utilisation de logiciels libres figure en bonne place (mesure n°
28). Le Centre des technologies de l'information (CTI) s'est engagé dans cette démarche
avec une approche éloignée de tout dogmatisme.
Comme nous l'avons détaillé dans un précédent rapport1
, l’intérêt du secteur public pour le
logiciel libre est aujourd’hui indéniable, en particulier parce qu’il met très souvent en œuvre
des standards ouverts, qu’il brise les positions de lock-in et qu’il permet une plus grand
adaptabilité aux besoins particuliers. Les motivations essentielles avancées par les
gouvernements sont une meilleure maîtrise et une pérennité accrue de leurs propres
systèmes d’information, une plus grande neutralité dans le choix de vendeurs de solutions
ainsi qu’une ouverture vers les entreprises et les citoyens désirant ou devant interagir avec
les administrations.
Au delà de ces apports stratégiques indéniables, un nombre croissant de solutions open
source gagnent en popularité en raison de leur excellentes performances, de leur fiabilité et
de leur coût d'achat faible ou nul. La sécurité est également un domaine souvent mis en
avant lorsque l'on évoque les avantages associés au logiciel libre. Cet aspect suscite de
nombreuses controverses et les études qui y sont consacrées ne permettent pas d'apporter
un point de vue définitif sur la question.
Le but de ce document est de porter un regard nuancé sur le lien entre sécurité et logiciel
libre en se référant à l'avis de quelques experts dans le domaine.
Mais en préambule à toute considération relative aux aspects spécifiques liés à la sécurité, il
n'est pas inutile de rappeler que le choix d'une solution informatique de devrait pas être
conditionné par un seul critère particulier (comme la sécurité dans le cas qui nous intéresse),
mais plutôt être envisagé de manière globale comme le suggère par exemple le référentiel
NPT2
.
La sécurité informatique est un vaste domaine et nous limiterons notre argumentaire aux
aspects liés au développement d'applications en mode open source ou en mode fermé (par
opposition au mode open source).
Dans ce document nous utiliserons de manière indifférente les termes de logiciel libre et de
logiciel open source dont nous avons déjà précisé la définition ailleurs1
.
Points de vue d'experts
L'expert en sécurité informatique David Wheeler3
propose dans un excellent document
accessible en ligne un chapitre consacré à la relation entre open source et sécurité. Il y
rappelle notamment le point de vue de plusieurs experts dans le domaine dont plusieurs sont
cités ici. Cette revue n'a pas la prétention d'être exhaustive; elle illustre les principaux
arguments énoncés lorsque l'on évoque le sujet.
Bruce Schneier4
, expert en sécurité et en cryptographie, prétend que tout développeur
devrait exiger de bâtir des solutions de sécurité sur des composants open source. La
1
Standards ouverts et logiciel libre Clarification des notions, P. Genoud et G. Pauletto, Observatoire
Technologique, Centre des technologies de l’information du canton de Genève, 2005, http://ot.geneve.ch
2
Référentiel Nouvelles Plateformes Technologiques, P. Genoud et G. Pauletto, Observatoire Technologique,
Centre des technologies de l’information du canton de Genève, 2003, http://ot.geneve.ch
3
Secure Programming for Linux and Unix HOWTO : Creating secure software, D. A. Wheeler, 2003,
http://www.dwheeler.com/secure-programs
4
Open Source and Security, B. Schneier, 1999, Crypto-Gram. Counterpane Internet Security, Inc.,
http://www.counterpane.com/crypto-gram-9909.html
- 2 -

3. Logiciel libre et sécurité
meilleure manière d'augmenter le niveau de qualité d'une solution est selon lui de permettre
son examen par le plus grand nombre d'experts possible. Pour répondre à l'argument du
secret souvent avancé par les défenseurs des logiciel fermés, Bruce Schneier insiste sur le
fait que les composants open source sont conçus pour être sûrs malgré le fait qu'ils soient
publics; c'est dans leur essence même.
Dans un article consacré au sujet Whitfield Diffie5
, le co-inventeur de la cryptographie à clé
publique, conclut en réponse aux arguments des adversaires de l'ouverture du code dans le
domaine de la sécurité: « Il est simplement irréaliste de dépendre du secret en matière de
sécurité des programmes informatiques. On peut prévenir la divulgation du mode de
fonctionnement d'un programme, mais empêchera-t-on le code d'être désassemblé par des
adversaires sérieux ? Probablement pas. ».
Vincent Rijmen6
, l'un des développeurs de l'algorithme d'encryption AES (Advanced
Encryption Standard) pense que la nature même du système d'exploitation open source
Linux permet de mieux détecter et réparer les vulnérabilités de sécurité, non seulement
parce que les gens ont accès au code, mais aussi et surtout parce que le modèle force les
développeurs à adhérer à des standards et à produire du code plus clair, ce qui à son tour
facilite la revue du code.
Mais Hissam et al7
relèvent le fait que l'accessibilité au code ne signifie pas nécessairement
que celui-ci a été revu, notamment au niveau de la sécurité. Mais ils soulignent dans le
même temps que c'est également le cas pour du code propriétaire.
Mais certains comme Fred Schneider8
ne croient pas que le logiciel libre contribue à la
sécurité. Il n'y a selon lui pas de raison de penser que de nombreuses personnes inspectant
un code ouvert soient forcément efficaces dans la détection de bugs liés à la sécurité.
D'autre part, les bugs présents dans le code ne sont selon lui pas la cause majeure des
attaques.
John Viega9
tempère ce point de vue en affirmant: « Les projets open source peuvent être
plus sûrs que les projets dont le code est fermé. Cependant les aspects qui peuvent rendre
un programme plus sûr – la disponibilité du code source et le fait qu'un grand nombre de
personnes peuvent rechercher et réparer des trous de sécurité – peut aussi bercer les gens
dans un faux sentiment de sécurité. ». Dans un article plus récent10
, il considère que le
logiciel libre a, sur le long terme, le potentiel pour être plus sûr que le logiciel propriétaire. Il
se base sur le fait que les projets open source peuvent faire tout ce dont sont capables les
projets commerciaux, tout en bénéficiant des avantages liés à l'ouverture du code. Mais cela
doit passer par une sensibilisation à la sécurité des communautés et de leur direction ainsi
que par une industrialisation des processus de développement, en y intégrant étroitement la
sécurité. Les communautés open source devraient en outre reconnaître l'importance
d'organismes d'audit indépendants.
David Wheeler11
insiste sur le fait qu'il n'est pas nécessaire d'avoir accès au code source
d'un programme pour en découvrir les vulnérabilités, surtout lorsqu'on a uniquement
l'intention de nuire. Il rappelle en outre que garder le secret au sujet d'une vulnérabilité ne la
fera jamais disparaître et compare cette pratique à une bombe à retardement. La conclusion
5
Risky Business: Keeping Security a Secret, W. Diffie, 2003, ZDNet, http://news.zdnet.com/2100-9595_22-
980938.html
6
LinuxSecurity.com Speaks With AES Winner, V. Rijmen, 2000,
http://www.linuxsecurity.com/content/view/117552/49/
7
Trust and Vulnerability in Open Source Software, S. A. Hissam, D. Plakosh et C. Weinstock, 2002, Software
IEE-Proceedings,, Vol 149-1, p 47-51, http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=999090
8
Open Source in Security: Visting the Bizarre, F. B. Schneider, 2000, Proceedings of the 2000 IEEE Symposium
on Security and Privacy, May 14-17, 2000, Berkeley, CA. Los Alamitos, CA: IEEE Computer Society. pp.126-127.
9
The Myth of Open Source Security, J. Viega, 2002, http://www.developer.com/tech/article.php/621851
10
Open source security: still a myth, J. Viega, 2004, O'Reilly publisher (http://www.oreilly.com),
http://www.onlamp.com/pub/a/security/2004/09/16/open_source_security_myths.html
11
Secure Programming for Linux and Unix HOWTO : Creating secure software, D. A. Wheeler, 2003,
http://www.dwheeler.com/secure-programs
- 3 -

4. Logiciel libre et sécurité
de son argumentaire rejoint celle de John Viega: le fait de rendre un programme open
source ne garantit pas une meilleure sécurité. Un processus de revue effective de code
devrait être mis en place avec un regard particulier sur les questions relatives à la sécurité.
De plus le projet devrait inclure des spécialistes qui savent comment concevoir, développer
et examiner des programmes sûrs. Enfin un processus de correction des vulnérabilités et de
distribution des patches de corrections devrait être mis en place.
Pour compléter ce tableau, mentionnons l'article de Alain Boulanger12
dans lequel l'auteur
compare les modèles libre et propriétaire au niveau de la sécurité. Il y discute des aspects
liés à la sécurité et à la fiabilité de ces modèles en examinant deux points clés: l'ouverture du
code et le taux d'erreurs du logiciel. Boulanger réfute les arguments développés dans le livre
blanc publié en 2002 par l'organisation Alexis de Tocqueville Institution13
(fondée en partie
par Microsoft) et qui présente l'usage du logiciel libre dans les organismes gouvernementaux
comme un risque de sécurité majeur en raison de la visibilité du code pour les pirates
informatiques.
Outre les arguments déjà énoncés plus haut, Boulanger constate que les études recensant
le nombre et la fréquence des rapports de vulnérabilités dans les logiciels parlent plutôt en
faveur des logiciels libres que de leurs équivalents propriétaires, spécialement dans le cas
de projets d'envergure comme GNU/Linux, Apache (serveurs Web) ou MySQL (bases de
données). Comme plusieurs autres auteurs Boulanger conclut son article sans déclarer de
vainqueur: les arguments analytiques favorisant l'une ou l'autre approche ne sont en effet
pas concluants. Il est convaincu que les projets open source ayant atteint une masse critique
suffisante produiront des résultats supérieurs à leurs équivalents propriétaires, et ceci à un
moindre coût.
Pour résumer un sentiment largement partagé concernant le lien entre logiciel libre et
sécurité nous terminerons avec la citation de Elias Levy, ancien modérateur de Bugtraq (l'un
des forums de discussion majeurs consacrés à la sécurité), qui résume son point de vue sur
la question ainsi: « Cela signifie-t-il que le logiciel libre n'est pas meilleur que le logiciel
propriétaire en terme de sécurité ? La réponse est non. Le logiciel libre a certainement le
potentiel d'être plus sûr que son son équivalent propriétaire. Mais ne vous y trompez pas, le
simple fait d'être ouvert ne constitue pas une garantie de sécurité ».
Principaux arguments
Comme le propose un récent rapport du Gartner Group14
sur la question, on peut
sommairement regrouper les bénéfices et les risques associés à l'ouverture du code source
selon les quatre thèmes (très liés) développés ci-dessous. Chacun de ces thèmes fait
référence à bon nombre d'arguments développés au chapitre précédent.
Une multitude de réviseurs
L'opinion selon laquelle le logiciel libre est fondamentalement plus sûr que son équivalent
propriétaire s'appuie principalement sur l'une de ses qualités intrinsèques qu'est l'ouverture
du code source à une large communauté. Cette dernière, qui peut compter plusieurs milliers
de personnes dans certains projets, est capable de détecter et de corriger rapidement des
problèmes éventuels, au niveau de la sécurité notamment. Mais ce n'est pas seulement la
mutilitude des réviseurs qui fait la force du modèle open source; c'est surtout le mode de
12
Open-source versus proprietary software Is one more reliable and secure than the other?, A. Boulanger, 2005,
IBM Systems Journal, http://findarticles.com/p/articles/mi_m0ISJ/is_2_44/ai_n14707716
13
Opening the Open Source Debate: A White Paper, Alexis de Tocqueville Institution, 2002,
http://www.adti.net/ip/opensource.pdf
14
Open-Source and Closed-Source AD Security: Combining the Benefits of Both Paradigms, J. Feiman, Gartner
Group 2006, http://www.gartner.com
- 4 -

5. Logiciel libre et sécurité
travail des communautés qui collaborent en réseau en incluant de manière active
développeurs et utilisateurs de la solution.
Cet argument n'est cependant réellement valable que dans le cas où la communauté est
nombreuse et qu'elle peut compter sur des développeurs expérimentés, sensibilisés et
motivés par les questions relatives à la sécurité. Le fait de pouvoir s'appuyer sur des
spécialistes dans le domaine de la sécurité est également essentiel, ne serait-ce que pour
initier un projet sur de bonnes bases (architecture, méthodologie, etc.).
Comme le soulignent de nombreux spécialistes, il faut bien distinguer les potentialités
indiscutables offertes par le modèle open source de leur réelle mise en oeuvre au sein des
projets. Pour que ce modèle soit effectivement efficace dans le domaine de la sécurité, il faut
ainsi que le projet réponde à un minimum de critères:
réunir une communauté suffisamment importante
disposer de développeurs sensibilisés et motivés par les questions de sécurité
revoir et corriger effectivement le code en terme de sécurité
disposer si possible de spécialistes en la matière
Ouverture du code source
Les éditeurs de logiciels propriétaires prétendent souvent que le fait de cacher le code
source empêche les pirates potentiels d'exploiter les vulnérabilités d'un programme. Mais il
n'est pas nécessaire d'avoir accès au code source pour cela. Il existe des outils permettant
de désassembler les programmes ou de mettre en évidence des modèles de comportement
lors de leur utilisation comme les programmes de type Web application security vulnerability
scanners (WASVS) qui sont conçus pour détecter des vulnérabilités sans devoir accéder au
code source. Certains d'entre eux sont d'ailleurs des logiciels libres.
De nombreux experts réfutent l'argument de la sécurité par l'obsucrité qui a notamment pour
défaut de bercer les propriétaires d'une solution fermée dans l'illusion d'une fausse sécurité.
Si le fait de cacher le code source peut avoir un sens lorsque l'on désire préserver un
avantage concurrentiel, cela en a cependant peu, voir pas du tout en terme de sécurité.
L'ouverture du code source est à mettre directement en regard du point précédent. Elle ne
porte ses fruits au niveau de la sécurité que si le projet est correctement engagé dans une
démarche de révision prenant en compte la sécurité.
Certains experts affirment également que l'ouverture du code a un impact indirect sur la
sécurité car elle pousse les développeurs à écrire du code plus lisible, ce qui contribue à
améliorer la qualité du code, à facilite sa révision et à diminuer le nombre d'erreurs.
Détection précoce des problèmes
Dans le cas du logciel libre, lorsqu'un problème de sécurité est détecté, la communauté des
développeurs et des utilisateurs en est très vite informée. Cela augmente les chances de
résoudre rapidement le problème. Ce point est naturellement directement lié à l'ouverture du
code, mais également au mode de fonctionnement des communautés du libre. La rapidité de
réaction de la communauté dépend entre autres de la popularité et de la vitalité du projet.
Cet argument est très théorique. Il dépend d'une part de la taille de la communauté, de la
popularité du projet, de la sensibilité des utilisateurs et des développeurs à la sécurité ainsi
que de leur motivation à résoudre le problème soulevé. Mais il se trouve que dans de
nombreux projets, c'est effectivement le cas, comme le détaille Alain Boulanger13
.
- 5 -

6. Logiciel libre et sécurité
Méthodologies de développement
L'un des arguments avancés lorsque l'on parle de sécurité logicielle est celui de la
méthodologie de développement utilisée, que celle-ci soit générale (comme CMMI15
ou
TST/PSP16
) ou plus spécifique à la sécurité (comme SSE-CMM17
ou TST/PSP-secure18
).
Selon le Gartner Group, l'usage de ces méthodologies influe directement sur le niveau de
sécurité des solutions. Leur faible adoption par les projets open source peut être compensée
par les compétences de la communauté, pour autant que cette dernière soit suffisamment
importante, expérimentée et motivée à prendre en compte les aspects liés à la sécurité.
La sensibilisation des développeurs à de telles méthodologies ne peut qu'augmenter la
qualité des projets open source de moindre envergure.
Conclusion
Le logiciel libre a le potentiel pour être plus sûr que le logiciel propriétaire. Les projets open
source peuvent en effet réaliser tout ce dont sont capables les projets réalisés en mode
fermé, tout en bénéficiant des avantages liés à l'ouverture du code et au mode de
développement communautaire. De nombreux projets open source de qualité supérieure
sont là pour le prouver.
Mais il faut bien distinguer les potentialités indiscutables offertes par le modèle open source
de leur réelle mise en oeuvre au sein des projets. Pour que ce modèle soit réellement
efficace dans le domaine de la sécurité, il faut ainsi que le projet:
réunisse une communauté suffisamment importante,
dispose de développeurs sensibilisés et motivés par les questions de sécurité,
revoie et corrige effectivement le code en terme de sécurité et
dispose si possible de spécialistes en la matière.
Cela doit passer par une sensibilisation à la sécurité des communautés et de leur direction
ainsi que par une industrialisation des processus de développement, en y intégrant
étroitement la sécurité.
15
Capability Maturity Model Integration : http://www.sei.cmu.edu/cmmi
16
Team Software Process (TSP) and the Personal Software Process (PSP) : http://www.sei.cmu.edu/tsp
17
Systems Security Engineering Capability Maturity Model : http://www.sse-cmm.org/index.html
18
TST/PSP-secure : http://www.sei.cmu.edu/tsp/tsp-security.html
- 6 -