Einwand: „Ist Open Source sicher?“
Diese Seite ist für Fürsprecher, die hören: „Open Source ist weniger sicher“, „Jeder kann den Code lesen und Lücken finden“ oder „Wer behebt es, wenn etwas gefunden wird?“ Diskutieren Sie nicht über Open Source im Allgemeinen. Zeigen Sie den Prozess, den Exponential dokumentiert, und wie man ihn prüft.
Inhalt
- Die Frage umformulieren
- Der Prozess, Schritt für Schritt
- Was ein Website-Betreiber tun kann
- Antwortvorlagen
- Sagen Sie nicht
Die Frage umformulieren
„Ist es sicher?“ lässt sich für keine Software mit Ja oder Nein beantworten. Machen Sie daraus Fragen, die Antworten haben:
| Statt | Fragen Sie |
|---|---|
| „Ist es sicher?“ | „Wie werden Sicherheitslücken gemeldet und behoben?“ |
| „Können Angreifer den Code lesen?“ | „Können Verteidiger ihn auch lesen und jede Änderung sehen?“ |
| „Wer ist verantwortlich?“ | „Wer beantwortet eine Meldung, und wie schnell?“ |
| „Ist unsere Website sicher?“ | „Was müssen unsere Administratoren tun?“ |
Der Prozess, Schritt für Schritt
| Schritt | Was geschieht | Quelle |
|---|---|---|
| 1. Melden | Vertraulich per E-Mail oder über die vertrauliche Meldung von Sicherheitslücken bei GitHub; nie öffentlich | SECURITY.md, Wenn etwas schiefgeht |
| 2. Erste Antwort | „innerhalb eines Werktags“ | SECURITY.md |
| 3. Entscheidung | Die meldende Person erfährt, ob die Meldung angenommen wird, und wird auf dem Laufenden gehalten | ebenda |
| 4. Korrektur | Auf main, veröffentlicht mit der nächsten Version 6.0.x | Sicherheitskorrekturen |
| 5. Release | Eine neue Version; veröffentlichte Versionen ändern sich nie | Releases und Versionsnummern |
| 6. Upstream | Sicherheitskorrekturen gehen auch an Abhängigkeiten (Zeta Components) | Der PHP-Stack |
Offener Code hilft hier: Jeder kann jede Änderung in der öffentlichen Historie lesen, auch Sicherheitskorrekturen, und prüfen, was ein Release enthält (Grundsätze, die man im Code sieht).
Was ein Website-Betreiber tun kann
Die meisten Vorfälle bei jedem CMS entstehen durch die Art, wie eine Website betrieben wird. Die Dokumentation gibt Administratoren:
- eine Anleitung zur Härtung Bedrohung für Bedrohung, mit einer Checkliste;
- die Content Security Policy;
- das Prüfprotokoll und die Request-Logs;
- die zweistufige Anmeldung;
- erzeugte Administratorpasswörter bei neuen Installationen (Das Standardpasswort des Administrators).
Antwortvorlagen
SHORT
Security is a process, not a claim. Exponential's is written down: private reports, a first answer within
one business day, fixes in the next 6.0.x release (SECURITY.md). Admins get a hardening guide and checklist.
LONGER
Open code cuts both ways: attackers can read it, but so can defenders, and every fix is visible in the
public history. What matters is the process. For Exponential: reports go privately to the address in
SECURITY.md with a first answer within one business day; accepted issues are fixed on main and shipped in
the next 6.0.x release; published versions never change. For your own site, the hardening guide and its
checklist are the place to start. (links)Sagen Sie nicht
- „Open Source ist immer sicherer.“ Das ist eine Debatte, keine Tatsache.
- „Es wurde nie gehackt.“ Keine Quelle sagt das.
- „Sicherheit ist garantiert.“ Nichts ist garantiert.
- Details einer Sicherheitslücke, die nicht öffentlich ist. Wenn Ihnen jemand eine erzählt, folgen Sie Sicherheitsmeldungen bleiben vertraulich.
Verwandte Seiten
- Gesprächspunkte: Sicherheit
- Für Sicherheit eintreten
- Mit Einwänden umgehen, Sicherheit
- Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.
Werden Sie Exponential-Partner
Partner teilen ihre Informationen, stellen Mittel bereit, geben Beiträge zurück und entwickeln die Produkte mit uns, und so wächst Exponential. Eine Partner-Website und ein Dashboard sind für Mitte 2027 geplant: Werden Sie noch heute Partner, damit wir schneller wachsen und neue Funktionen früher liefern.