Thema: Sicherheit #

Diese Seite ist für Journalisten, die über die Sicherheit von Open-Source-Software berichten. Keine ehrliche Quelle sagt, eine Software „ist sicher“; was die Quellen von Exponential beschreiben, ist ein Prozess und eine Reihe von Schutzmaßnahmen. Diese Seite liefert beides, mit Daten und Quellen, und sagt Ihnen, wie Sie mit einer Sicherheitslücke umgehen, die Ihnen jemand zeigt.

Inhalt #

1. Das Thema in einem Absatz
2. Was neu ist, und seit wann
3. Fakten, die Sie drucken können
4. Was Sie nicht behaupten sollten
5. Wenn Ihnen jemand eine Sicherheitslücke zeigt
6. Blickwinkel und Ideen für Überschriften
7. Wen Sie fragen können
8. Verwandte Seiten

Das Thema in einem Absatz #

Die Sicherheitsrichtlinie von Exponential passt auf eine Seite. „Please report security issues privately by e-mail to [email protected], not in the public issue tracker or the discussions. You can expect a first answer within one business day.“ Korrekturen entstehen auf main und werden „published with the next 6.0.x release“, und „A published tag is never changed“ (SECURITY.md). Rund um diesen Prozess ergänzt die Linie 6.0.15 Schutzmaßnahmen, die ein Administrator sehen kann: eine Content Security Policy, ein manipulationssicheres Prüfprotokoll, die zweistufige Anmeldung, das Ablehnen allgemein bekannter Passwörter und eine Administration ohne Inline-Scripts (Changelog 6.0.15).

Was neu ist, und seit wann #

Alles in der Linie 6.0.15. Die Daten sind Daten der Änderungen, keine Veröffentlichungsdaten; ob der Tag v6.0.15 existiert, zeigt git tag -l 'v6.0.*' --sort=version:refname.

Fakten, die Sie drucken können #

Was Sie nicht behaupten sollten #

• „Exponential ist sicher“, „unhackbar“, „Sicherheit auf Bankniveau“. Beschreiben Sie den Prozess und die Schutzmaßnahmen.
• „Es hatte nie eine Sicherheitslücke.“ Keine Quelle sagt das.
• „Konform mit“ irgendeinem Gesetz oder Standard. Konformität hängt davon ab, wie eine Website gebaut und betrieben wird.
• „Der Support antwortet innerhalb von N Stunden.“ Die einzige dokumentierte Zeit ist die erste Antwort auf eine Sicherheitsmeldung.
• Einzelheiten einer Sicherheitslücke, die noch nicht zusammen mit ihrer Korrektur veröffentlicht wurde.

Wenn Ihnen jemand eine Sicherheitslücke zeigt #

Veröffentlichen Sie keine Einzelheiten einer nicht behobenen Sicherheitslücke. Bitten Sie die Person, sie vertraulich an [email protected] zu melden, wie es SECURITY.md verlangt, und berichten Sie erst, wenn die Korrektur veröffentlicht ist. Testen Sie sie nicht an einer Website, die nicht Ihnen gehört. Das Vorgehen für Fürsprecher gilt auch für Reporter: Sicherheitsmeldungen bleiben vertraulich.

Blickwinkel und Ideen für Überschriften #

"One business day: how an old open source CMS answers security reports"
"Fixed in the next release, never in the old one: Exponential's rule for security fixes"
"Process, not promises: inside Exponential's security work"

Wen Sie fragen können #

Verwandte Seiten #

• Gesprächspunkte: Sicherheit
• Thema: die Content Security Policy
• Thema: das Prüfprotokoll
• Thema: zweistufige Anmeldung
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.