Zuletzt geprüft am 7. August 2026
Diese Seite beschreibt, was umgesetzt ist, was nicht umgesetzt ist und wie ein Problem gemeldet werden kann. Wenn eine Kontrolle entwickelt, aber nicht aktiviert ist, wird das offen benannt.
Verwenden Sie die private Schwachstellenmeldung von GitHub im Repository: Security → Report a vulnerability. Dadurch wird ein privater Austausch mit dem Maintainer eröffnet.
| Phase | Ziel |
|---|---|
| Empfangsbestätigung | 3 Arbeitstage |
| Triage und Schweregrad | 7 Arbeitstage |
| Korrektur für kritisch oder hoch | in der Regel 14 Tage |
| Veröffentlichung | nach vorhandener Korrektur mit der meldenden Person abgestimmt |
Meldende Personen werden genannt, sofern sie nichts anderes wünschen. Bitte gewähren Sie vor einer öffentlichen Bekanntgabe eine angemessene Frist. Die vollständige Richtlinie steht in SECURITY.md.
Zwei direkte Abhängigkeiten. Ein PostgreSQL-Treiber und eine SAML-Bibliothek. Verteiltes Tracing, TOTP und Verschlüsselung im Ruhezustand werden mit der Standardbibliothek umgesetzt, anstatt zusätzliche Pakete einzubinden – denn im Authentifizierungspfad ist eine kompromittierte Abhängigkeit für Angreifer besonders wertvoll.
Releases werden signiert – mit schlüsselloser Signierung – und enthalten jeweils eine SPDX-Softwarestückliste. Die Prüfschritte stehen in SECURITY.md.
Kontrollen werden durch Tests abgesichert, die den verhinderten Fehler benennen und nicht nur das erwartete Verhalten. Eine harmlose, ATT&CK-zugeordnete Validierungssuite läuft stündlich gegen die aktive Bereitstellung und warnt, wenn sich ein Ergebnis ändert.
Die Autorisierung erfolgt zentral und nicht in einzelnen Handlern. Dadurch kann ein neuer Endpunkt seine eigene Prüfung nicht vergessen. Der Mandant wird aus den aufrufenden Zugangsdaten bestimmt und ist Teil der Datenbankabfrage. Eine Datensatz-ID eines anderen Kunden ergibt daher nicht gefunden, statt die Existenz des Datensatzes zu bestätigen. Die Identität wird bei jeder Anfrage neu bestimmt; ein widerrufener Schlüssel funktioniert ab dem nächsten Aufruf nicht mehr.
Agenten authentifizieren sich als Dienstkonten und können niemals eine interaktive Sitzung besitzen. Dadurch lässt sich für Menschen ein zweiter Faktor erzwingen, ohne einen Agenten zu beeinträchtigen.
Dieser Abschnitt verdient besondere Aufmerksamkeit, weil viele Anbieter ihn auslassen.
Direkter Datenbankzugriff durch den Betreiber wird vorab angekündigt. Die Ankündigung wird Teil der manipulationssicheren Audit-Kette und an eine Instanz ausserhalb des Hosts veröffentlicht. Der Zugriff wird unabhängig über das Verbindungsprotokoll der Datenbank beobachtet – durch eine Komponente, deren Zugangsdaten ausschliesslich Meldungen erlauben. Beides wird abgeglichen: Eine Sitzung ohne passende Ankündigung erzeugt einen Audit-Eintrag und eine Warnung.
Der Kopf der Audit-Kette wird an diese externe Instanz veröffentlicht. Sie lehnt eine verkürzte Kette sowie einen abweichenden Kopf für einen bereits gespeicherten Index ab. Ein Betreiber mit Root-Rechten kann den lokalen Verlauf umschreiben, aber nicht die externe Instanz zur Zustimmung bringen.
| Technische Aussagen | Jede Aussage mit dem Befehl zu ihrer Überprüfung |
| Bedrohungsmodell | Wogegen Promtact schützt und wogegen nicht |
| Zugriffskontrolle | Wer Kundendaten erreichen kann und was protokolliert wird |
| Vorfallsreaktion | Schweregrade, Benachrichtigungsfristen und Wiederherstellung |
| Entwurfsentscheidungen | Warum Promtact so entwickelt wurde – einschliesslich verworfener Ansätze |