Häufiges Gegenargument: Closed Source führe zu "Security by Obscurity", sprich: Sicherheit durch Verschleierung. Das interessiert Hacker jedoch wenig, da sie durch Black-Box-Techniken Schwachstellen in Programmen finden können und im Notfall den Binärcode einfach disassemblieren (Reverse Engineering). Durch Obscurity wird proprietärer Code aber vor allem auch denen gegenüber verschleiert, die darin Fehler finden und beheben könnten.
Wer also die Kontrolle der Öffentlichkeit scheut, muss sie mit eigenen Mitteln finanzieren und vornehmen, um ein vergleichbares Sicherheitsniveau zu erreichen. Dass hierbei kommerzielle Interessen vor dem kostspieligen Stopfen von Sicherheitslücken stehen können, ist kein Geheimnis. Einige Unternehmen verstehen Bugs in ihren Produkten sogar als Geschäftsgeheimnis. Prominentes Beispiel hierfür ist das "Ciscogate", als Internet Security Systems (ISS) und Cisco im Juli 2005 die Veröffentlichung eines Bugs in der Router-Software IOS durch Michael Lynn auf der US-Sicherheitskonferenz "Black Hat" mit allen Mitteln verhindern wollten (siehe www.computerwoche.de/564720).
Zur höheren Sicherheit von Linux-basierenden Sicherheitsprodukten trägt aber auch bei, dass Entwickler nicht benötigte Teile des Betriebssystems einfach weglassen können. So kommen dort befindliche potenzielle Schwachstellen gar nicht erst zum Tragen. Bei geschlossenen Betriebssystemen ist dies kaum oder oft nur durch den Hersteller selbst möglich.
Kürzere Reaktionszeiten
Wird etwa in einer Textverarbeitung eine Schwachstelle bekannt, so können sich die Entwickler in der Regel bis zum nächsten Service-Pack Zeit lassen, um sie zu beseitigen. Bei sicherheitsrelevanten Produkten hingegen ist Geschwindigkeit bei der Fehlerbehebung von allerhöchster Wichtigkeit.
Im Rahmen eines auf drei Jahre angelegten Projekts zur Beseitigung von Sicherheitslücken in Open-Source-Software investierte das US-Department of Homeland Security im Januar dieses Jahres 1,25 Millionen Dollar in das "Vulnerability Discovery and Remediation, Open Source Hardening Project". Nachdem das in das Projekt involvierte Unternehmen Coverity 17,5 Millionen Zeilen Quellcode der 32 beliebtesten Open-Source-Projekte geprüft hatte, errechnete es 0,434 Fehler pro 1000 Zeilen Quellcode. Nach einer Woche waren es nur noch 0,371 Defekte - das entspricht der Behebung eines Fehlers alle sechs Minuten. Ein Grund für die Schnelligkeit der Entwickler ist auch hier die Transparenz des Codes und des Entwicklungsprozesses. Closed-Source-Projekte hingegen stehen bei nach außen nicht bekannten Fehlern unter geringerem Druck - was in der Praxis zu längeren Reaktionszeiten führt.
Total Cost of Ownership (TCO)
Anhänger von Open-Source- wie auch von proprietärer Software übertrumpfen sich mit TCO-Analysen zu jeweils ihren Gunsten. Die dem jeweiligen Standpunkt angepassten Untersuchungsmethoden machen einen Vergleich schwierig. Doch während sich die Verfechter von Windows beziehungsweise Linux auf dem Desktop noch regelmäßig schwere Gefechte liefern, spielt diese Diskussion im Security-Bereich keine große Rolle. Hier greift ein Pragmatismus, der auch namhafte Sicherheitshersteller zu Linux oder einem Unix-Derivat als Basissystem greifen lässt. So befindet sich heute in den meisten Security-Appliances eine Software, die auf einem gehärteten Linux oder Unix basiert - egal ob Firewall, Intrusion Detection System (IDS) oder System Log Management. Die Anwender dieser Produkte sparen bei der Anschaffung Lizenzkosten, die für ein proprietäres Betriebssystem anfallen würden, die Hersteller wiederum Aufwendungen für die Entwicklung von Sicherheitsfunktionen, die Linux bereits mitbringt.