Vergleich von Open-Source- und proprietären Enterprise-Passwort-Managern: Risiko und Governance

Open-Source-Software macht ihren Quellcode öffentlich zugänglich, sodass er geprüft, geändert und weiterverbreitet werden kann. Proprietäre Software hält diesen Code privat und unter Kontrolle des Anbieters. Für das Passwort-Management in Unternehmen hat dieser Unterschied direkte Auswirkungen darauf, wie Organisationen Sicherheitsversprechen prüfen, Compliance-Anforderungen erfüllen und langfristige Betriebsrisiken planen.

Entscheidungen zur Verwaltung von Zugangsdaten in Unternehmen drehen sich selten nur um Funktionen. Wenn Beschaffungs- und Sicherheitsteams Passwort-Manager bewerten, wägen sie Risiko, Governance, Compliance und langfristige Wartbarkeit gegen die alltäglichen Anforderungen ab, Tausende von Benutzern in unterschiedlichen Umgebungen zu unterstützen. Zu verstehen, wie Open-Source- und proprietäre Ansätze diese Anliegen adressieren, hilft Organisationen, fundierte Entscheidungen zu treffen.

Bevor wir auf die Anforderungen in Unternehmen eingehen, zeigt dieser Überblick, wie sich Open-Source- und proprietäre Software in wichtigen Dimensionen unterscheiden:

Governance im Kontext von Unternehmenssoftware geht weit über Funktionsumfänge hinaus. Für Sicherheits- und IT-Teams umfassen Governance-Anforderungen die Richtlinien, Kontrollen und Nachweise, die erforderlich sind, um interne Stakeholder, externe Prüfer und Aufsichtsbehörden zufriedenzustellen. Bei der Bewertung von Tools zur Verwaltung von Zugangsdaten gehören dazu in der Regel:

Prüfbarkeit: Organisationen müssen nachweisen, wer worauf, wann und unter welchen Bedingungen zugegriffen hat. Audit-Protokolle müssen umfassend, manipulationsnachweisend und für die Integration in Security-Information-and-Event-Management-Systeme oder für Compliance-Berichte exportierbar sein.

Compliance-Nachweise: Anbieter sollten Artefakte bereitstellen, die Compliance-Frameworks von Organisationen unterstützen, darunter SOC 2 Type II-Berichte, ISO 27001-Zertifizierungen, Zusammenfassungen von Penetrationstests und Verschlüsselungspraktiken.

Anbietersicherheit: Anbieter sollten eine Software-Stückliste (SBOM) bereitstellen, damit sie feststellen können, ob ihre Produkte anfällige Komponenten enthalten, wenn neue Sicherheitsprobleme entdeckt werden. Darüber hinaus zeigen Bescheinigungen zum sicheren Software Development Lifecycle (SDLC), dass Software während der gesamten Entwicklung nach bewährten Sicherheitspraktiken erstellt wurde. Transparente Prozesse zur Offenlegung von Schwachstellen, also klare Abläufe dafür, wie Sicherheitsprobleme gemeldet, nachverfolgt und kommuniziert werden, geben Anbietern die nötige Transparenz, um Daten zu schützen und Compliance-Vorgaben einzuhalten.

Open-Source-Software bietet Unternehmen, die bereit sind, in Bewertungs- und Absicherungsprozesse zu investieren, klare Governance-Vorteile. Open-Source-Software beginnt typischerweise als nicht kommerzielles, communitybasiertes Projekt, und OSS-Start-ups wechseln mit zunehmendem Wachstum häufig von Open Source zu einem kommerziellen Geschäftsmodell.

Für Organisationen, die Open-Source- und proprietäre Software vergleichen, bedeutet Code-Transparenz, dass jede Person – interne Sicherheitsteams, Prüfer von Drittanbietern oder unabhängige Forschende – die tatsächliche Implementierung kryptografischer Algorithmen, Zugriffskontrollen und Datenverarbeitungslogik prüfen kann. Für Käufer in Unternehmen unterstützt diese Transparenz mehrere wichtige Governance-Anforderungen:

Interne Prüfung: Sicherheitsbewusste Organisationen können eigene Code-Audits durchführen und sich dabei auf kritische Bereiche wie Schlüsselableitung, Sitzungsverwaltung oder API-Sicherheit konzentrieren. Diese unabhängige Verifizierung ergänzt die vom Anbieter bereitgestellten Audit-Berichte.

Zusicherung durch Drittanbieter: Wenn Organisationen externe Prüfer oder Penetrationstester beauftragen, können diese über Black-Box-Tests hinausgehen und den Quellcode auf Logikfehler, Hintertüren oder Implementierungsschwächen prüfen. Diese tiefere Absicherung ist bei proprietären Lösungen oft nicht möglich.

Reaktion auf Sicherheitsvorfälle: Wenn eine Schwachstelle offengelegt wird, können interne Teams den betroffenen Code prüfen, den Umfang der Auswirkungen verstehen und die vorgeschlagene Behebung validieren, bevor sie bereitgestellt wird. Dies beschleunigt interne Risikobewertungen und Änderungsfreigaben.

Aussagen validieren: Open Source ermöglicht es Organisationen, Aussagen von Anbietern zu Verschlüsselung oder Zero-Knowledge-Architektur zu überprüfen. Statt sich ausschließlich auf Dokumentation zu verlassen, können Teams Datenflüsse durch die Codebasis nachverfolgen.

Bei der Bewertung eines Open-Source-Passwort-Managers sollten Organisationen auf zugängliche Repositorys mit klarer Struktur achten. Die Codebasis von Bitwarden ist beispielsweise vollständig dokumentiert und öffentlich einsehbar auf GitHub. Dazu gehören ein Release-Zyklus und Änderungsprotokolle, die aktive Wartung und reaktionsschnelle Sicherheitspraktiken belegen, Sicherheitshinweise, die Schwachstellen transparent offenlegen und zeitnahe Abhilfe bieten, sowie signierte Releases und, sofern anwendbar, Herkunftsnachweise, um sicherzustellen, dass Builds nicht manipuliert wurden.

In der Debatte um Open Source versus proprietäre Software ergänzen sich Community-Prüfung und formelle Absicherung, sie sind jedoch nicht gleichzusetzen. Während Open-Source-Code eine breite Prüfung durch unabhängige Forschende und Sicherheitsbegeisterte ermöglicht, erfordert Unternehmens-Governance in der Regel formelle Audits und Zertifizierungen durch Drittanbieter.

Community-Prüfung bietet eine kontinuierliche, verteilte Untersuchung des Codes. Sicherheitsforschende, White-Hat-Hacker und Teilnehmende an Bug-Bounty-Programmen identifizieren Schwachstellen, die bei geplanten Audits möglicherweise unentdeckt bleiben. Diese fortlaufende Prüfung ergänzt punktuelle Bewertungen.

Formelle Absicherung liefert die Compliance-Artefakte und vertraglichen Verpflichtungen, die Organisationen benötigen. SOC 2 Type II-Berichte, ISO 27001-Zertifizierungen und unabhängige Penetrationstests liefern Nachweise für Prüfer, Aufsichtsbehörden und interne Risikoausschüsse.

Open-Source-Passwort-Manager wie Bitwarden kombinieren beide Ansätze. Die Codebasis steht der fortlaufenden Prüfung durch die Community offen und wird zugleich regelmäßigen formellen Audits unterzogen. Käufer profitieren von Penetrationstests durch Drittanbieter, die von renommierten Sicherheitsfirmen wie Cure53 durchgeführt werden, von SOC 2 Type II-Berichten, die Kontrollen in Bezug auf Sicherheit, Verfügbarkeit und Vertraulichkeit belegen, von Bug-Bounty-Programmen wie dem Bitwarden-Programm auf HackerOne, die verantwortungsvolle Offenlegung und schnelle Behebung fördern, sowie von öffentlicher Sicherheitsdokumentation.

Käufer in Unternehmen sind zunehmend mit Anforderungen an die Sicherheit der Lieferkette konfrontiert, die sowohl durch regulatorische Vorgaben – wie die Executive Order 14028 in den Vereinigten Staaten – als auch durch interne Risiko-Frameworks getrieben werden. Bei der Bewertung von Passwort-Managern sollten Organisationen Nachweise für sichere Entwicklungspraktiken erwarten. Wie oben erwähnt, ist ein Beispiel dafür eine SBOM, die alle Komponenten, Bibliotheken und Abhängigkeiten in einem Softwareprodukt auflistet. Bei Open-Source-Passwort-Managern können Käufer SBOMs häufig selbst aus öffentlichen Repositorys erstellen und so überprüfen, dass Abhängigkeiten aktuell und frei von bekannten Schwachstellen sind. 

Ebenfalls oben erwähnt: SDLC-Bescheinigungen bieten die Sicherheit, dass Code sicher entwickelt, getestet und bereitgestellt wird. Nachweise dafür sollten Code-Review-Prozesse, automatisierte Sicherheitstests wie SAST und DAST, Abhängigkeitsscans und sichere Build-Pipelines umfassen. Open-Source-Projekte veröffentlichen ihre Entwicklungsworkflows häufig öffentlich und ermöglichen so eine unabhängige Verifizierung.

Darüber hinaus sollten Käufer in Unternehmen überprüfen, dass die bereitgestellte Software dem geprüften Quellcode entspricht. Signierte Releases, reproduzierbare Builds und Herkunftsnachweise für Builds verringern das Risiko von Manipulationen in der Lieferkette und geben Unternehmen die benötigten Nachweise und die erforderliche Sicherheit.

Bei der Bewertung eines Passwort-Managers für den Unternehmenseinsatz benötigen Beschaffungs- und Sicherheitsteams mehr als Feature-Checklisten. Sie benötigen die Gewissheit, dass die Sicherheitsarchitektur der Plattform einer Prüfung standhält, dass administrative Kontrollen Organisationsrichtlinien skalierbar durchsetzen können und dass Compliance-Nachweise leicht verfügbar sind. Die Open-Source-Grundlage von Bitwarden erfüllt jede dieser Anforderungen, indem sie ihr Sicherheitsmodell transparent und unabhängig verifizierbar macht – und zugleich die Governance-Funktionen bereitstellt, die Unternehmensumgebungen erfordern.

Bitwarden basiert auf einem Zero-Knowledge-Verschlüsselungsmodell. Wenn ein Benutzer einen Tresoreintrag erstellt oder aktualisiert, erfolgen Verschlüsselung und Entschlüsselung vollständig auf dem Gerät des Benutzers. Das Hauptpasswort verlässt dieses Gerät nie, und die Bitwarden-Server speichern ausschließlich verschlüsselte Tresordaten. Die praktische Konsequenz ist klar: Selbst im Fall einer Sicherheitsverletzung sind die verschlüsselten Daten, die ein Angreifer erlangen würde, ohne die Anmeldedaten des jeweiligen Benutzers nicht lesbar.

Da die vollständige Codebasis öffentlich verfügbar ist auf GitHub, ist dies keine Behauptung, die ein Benutzer einfach glauben muss. Ein Sicherheitsteam kann die Verschlüsselungsimplementierung direkt prüfen, auditieren, wie Schlüssel abgeleitet und verwaltet werden, und nachverfolgen, wie sich die Codebasis im Laufe der Zeit entwickelt. Die Architektur ist ausführlich dokumentiert im Bitwarden-Sicherheits-Whitepaper.

Enterprise-Passwort-Management bringt echte Governance-Herausforderungen mit sich: die Durchsetzung von Multifaktor-Authentifizierung, die Einschränkung der Weitergabe von Anmeldedaten, die Verwaltung des Zugriffs beim Ein- oder Austritt von Mitarbeitenden und die Aufrechterhaltung einer Audit-Spur, die Compliance-Anforderungen erfüllt. Bitwarden begegnet diesen Herausforderungen mit rollenbasierten Zugriffskontrollen, mit denen Administratoren granulare Berechtigungen in der gesamten Organisation definieren können, sowie mit organisationsweiten Richtlinien, die Verhaltensweisen wie verpflichtende MFA oder Einschränkungen bei der Weitergabe von Passwörtern durchsetzen können.

Im Bereich Audits erfasst Bitwarden über 60 verschiedene Arten von Benutzer- und Administratoraktionen in detaillierten Ereignisprotokollen. Diese Protokolle können exportiert werden und lassen sich dadurch problemlos in eine SIEM-Plattform für die zentrale Überwachung einspeisen oder bei einer Audit-Prüfung vorlegen. Wenn ein Vorfall eintritt oder ein Compliance-Prüfer fragt, „wer wann worauf zugegriffen hat“, sind die Daten vorhanden.

Bitwarden fügt sich in bestehende Identitätsinfrastrukturen ein, anstatt Workarounds zu erfordern. Es unterstützt SAML-2.0-basiertes Single Sign-On mit führenden Identitätsanbietern – darunter Azure AD, Okta und Google Workspace –, sodass Benutzer sich über dieselbe SSO-Erfahrung authentifizieren, die sie auch für alles andere nutzen. Für das Benutzer-Lifecycle-Management automatisiert die SCIM-basierte Verzeichnissynchronisation die Bereitstellung und Aufhebung der Bereitstellung. So erhalten neue Mitglieder der Organisation Zugriff auf die richtigen gemeinsam genutzten Anmeldedaten, und beim Ausscheiden wird dieser Zugriff automatisch entzogen. Dadurch sinkt der manuelle Aufwand, der Programme zur Passwortverwaltung in großem Maßstab anfällig macht.

Nicht jede Organisation möchte Tresordaten an eine Drittanbieter-Cloud senden, und regulatorische Anforderungen oder Vorgaben zur Datenresidenz können dies unpraktikabel machen. Bitwarden bietet sowohl cloudgehostete als auch selbst gehostete Bereitstellungsmodelle. Die Cloud-Option bietet verwaltete Infrastruktur mit minimalem Betriebsaufwand, während die selbst gehostete Option Organisationen die volle Kontrolle darüber gibt, wo ihre Daten gespeichert werden und wie die Umgebung konfiguriert ist. Beide Optionen bieten denselben Funktionsumfang, sodass die Entscheidung von betrieblichen Präferenzen und Compliance-Anforderungen abhängt – nicht von Kompromissen bei den Funktionen.

Bitwarden erfüllt die SOC-2-Type-II-Compliance, ist nach ISO 27001 zertifiziert, unterzieht sich regelmäßigen Penetrationstests durch Drittanbieter und betreibt ein öffentliches Bug-Bounty-Programm über HackerOne. Zusammen mit der Open-Source-Codebasis schaffen diese Maßnahmen mehrere Ebenen unabhängiger Assurance. Käufer müssen sich nicht allein auf vom Anbieter bereitgestellte Dokumentation verlassen; sie können Aussagen anhand des Quellcodes überprüfen, die Ergebnisse von Drittanbieter-Audits einsehen und die Erkenntnisse der Sicherheitsforschung verfolgen – alles, bevor sie einen Vertrag unterzeichnen.

Ob der Schwerpunkt auf der Sicherheitstransparenz von Open Source oder der Verantwortlichkeit proprietärer Anbieter liegt – diese Fragen helfen Organisationen, evidenzbasierte Entscheidungen zu treffen.

• Welche Verschlüsselungsstandards und -protokolle werden verwendet: AES-256, RSA, PBKDF2, Argon2 oder etwas anderes?

• Ist die Architektur Zero-Knowledge? Hat der Anbieter Zugriff auf unverschlüsselte Tresordaten?

• Wie werden Verschlüsselungsschlüssel abgeleitet, gespeichert und verwaltet?

• Gibt es Drittanbieter-Audits der kryptografischen Implementierungen?

• Welche Funktionen für rollenbasierte Zugriffskontrolle sind verfügbar?

• Können Organisationen organisationsweite Richtlinien wie Passwortkomplexität, Anforderungen an die Multi-Faktor-Authentifizierung oder IP-Beschränkungen durchsetzen?

• Sind Audit-Protokolle umfassend, manipulationssicher und exportierbar?

• Lässt sich die Lösung in bestehende SSO-Anbieter wie Azure AD, Okta oder Google Workspace integrieren?

• Wird SCIM-basierte Verzeichnissynchronisation für automatisiertes Benutzer-Lifecycle-Management unterstützt?

• Sind APIs für benutzerdefinierte Integrationen oder Automatisierung verfügbar?

• Kann der Anbieter aktuelle SOC-2-Type-II-Berichte bereitstellen?

• Verfügt der Anbieter über ISO 27001, ISO 27018 oder andere relevante Zertifizierungen?

• Sind Zusammenfassungen von Penetrationstests durch Drittanbieter verfügbar?

• Gibt es eine öffentliche Richtlinie zur Offenlegung von Schwachstellen oder ein Bug-Bounty-Programm?

• Kann der Anbieter eine Software Bill of Materials oder eine Bescheinigung für einen sicheren SDLC bereitstellen?

• Welche Service-Level-Agreements gelten für Verfügbarkeit, Support-Reaktionszeiten und Eskalation von Vorfällen?

• Welche Datenexportformate sind verfügbar, und wie einfach ist die Migration zu einer anderen Lösung?

• Für Open-Source-Lösungen: Welche Lizenz gilt für die Software, und hat die Organisation das Recht, sie zu forken oder selbst zu hosten?