Offenlegungsrichtlinie

Stand: 1. November 2026
Kontakt: [email protected]
Sperrfrist: 90 Tage

Geltungsbereich

Diese Richtlinie regelt, wie turingpoint Schwachstellen koordiniert offenlegt und CVE-IDs vergibt. Sie gilt für:

Schwachstellen, die turingpoint selbst findet, in eigener Forschung oder in Penetrationstests
Schwachstellen, die externe Sicherheitsforscher an turingpoint melden, damit wir die Offenlegung koordinieren und eine CVE-ID vergeben
Schwachstellen in Systemen von turingpoint selbst

Schwachstelle melden

Meldungen nehmen wir ausschließlich per E-Mail an [email protected] entgegen, auf Deutsch oder Englisch. Für verschlüsselte Meldungen nutzen Sie eines der S/MIME-Zertifikate aus unserer security.txt und schreiben direkt an die zugehörige Adresse.

Hinweis: Sobald turingpoint als CVE Numbering Authority (CNA) zugelassen ist, stellen wir zusätzlich ein Formular für Meldungen und CVE-Anfragen bereit. Die Aufnahme streben wir unter dem europäischen Root der EU-Agentur für Cybersicherheit (ENISA) an: Schwachstellen sollen in Europa erfasst und koordiniert werden, um die digitale Souveränität Europas zu stärken.

Eine Meldung sollte enthalten:

Hersteller und Produkt, betroffene Versionen und, falls bekannt, die gefixte Version
Art der Schwachstelle, möglichst mit CWE
Reproduktion: Schritte oder Proof of Concept, Voraussetzungen und benötigte Rechte
Auswirkung, optional mit CVSS-Vektor
ob der Hersteller bereits informiert ist
ob bereits eine CVE-ID beantragt wurde
wie Sie genannt werden möchten: Name, Handle, Organisation oder anonym

Eine Anfrage ist an keine Bedingungen geknüpft: keine Verschwiegenheitserklärung, keine Übertragung von Rechten, kein Auftrag.

Reaktionszeiten

Schritt	Frist
Eingangsbestätigung	3 Werktage
Erste Bewertung: Annahme, Ablehnung oder Rückfragen	10 Werktage
Statusmeldung an den Melder während der Koordination	mindestens alle 30 Tage

Alle Antworten werden redaktionell geprüft.

Prüfung

Wir beantragen eine CVE-ID nur, wenn wir die Schwachstelle nachvollziehen konnten oder die Meldung ausreichende Belege enthält. Nicht angenommen werden insbesondere:

Meldungen ohne nachvollziehbaren Proof of Concept sowie ungeprüfte Ausgaben von Scannern oder automatisch erzeugte Reports
Verhalten ohne Sicherheitsauswirkung, etwa fehlende Security-Header ohne konkreten Angriff
Denial of Service allein durch Masse (Brute Force, Ressourcenerschöpfung)
Angriffe mit physischem Zugriff, sofern das Produkt nicht gerade davor schützen soll
veraltete Abhängigkeiten ohne Nachweis, dass das Produkt selbst angreifbar ist
Produkte, die nicht öffentlich verfügbar sind, etwa Individualsoftware einzelner Unternehmen

Ablehnungen begründen wir.

Abstimmung mit dem Hersteller

Zuerst prüfen wir, ob der Hersteller selbst CNA ist oder das Produkt in den Scope eines CNA fällt. Dann melden wir dort oder verweisen Sie dorthin.
Andernfalls informieren wir den Hersteller über dessen Sicherheitskontakt. Haben Sie den Hersteller schon kontaktiert, steigen wir in die laufende Kommunikation ein.
Ihre Kontaktdaten geben wir nur mit Ihrer Zustimmung an den Hersteller weiter. Wir verarbeiten sie ausschließlich für die Koordination, siehe Datenschutzerklärung.

Sperrfrist: 90 Tage

Technische Details veröffentlichen wir, sobald ein Fix verfügbar ist, spätestens aber 90 Tage nach der ersten Benachrichtigung des Herstellers.

Fix vor Fristende: Veröffentlichung in Abstimmung mit dem Hersteller, in der Regel kurz nach dem Release.
Fix in Arbeit: Arbeitet der Hersteller nachweislich an einem Fix und nennt einen Termin, verlängern wir einmalig um bis zu 30 Tage.
Keine Reaktion: Bevor wir ohne Antwort des Herstellers veröffentlichen, versuchen wir ihn über mindestens zwei Wege zu erreichen, etwa security.txt, Support oder ein zuständiges CERT.
Aktive Ausnutzung: Wird die Schwachstelle nachweislich ausgenutzt oder ist sie bereits öffentlich, veröffentlichen wir früher, damit Betroffene sich schützen können.

Wir bitten Melder, deren Fund wir koordinieren, dieselbe Frist einzuhalten.

CVE-IDs

Ist der Hersteller selbst CNA oder fällt das Produkt in den Scope eines CNA, vergibt dieser die CVE-ID. Andernfalls beantragen wir sie bei einem passenden CNA, etwa GitHub für dort gehostete Open-Source-Projekte.
Vor jeder Anfrage klären wir, ob anderswo schon eine ID beantragt wurde, damit keine Doppelvergaben entstehen.
Jede unabhängig behebbare Schwachstelle erhält eine eigene CVE-ID.
Die CVE-ID teilen wir Melder und Hersteller mit, sobald sie vorliegt.
Als öffentliche Quelle dient das Advisory des Herstellers, des Melders oder unser eigenes unter Advisories.
Melder nennen wir auf Wunsch im Advisory und in der CVE-Anfrage.

Funde aus Kundenprojekten

Viele unserer Funde entstehen in Penetrationstests. Schwachstellen in öffentlich verfügbaren Produkten Dritter legen wir nach dieser Richtlinie offen, ohne Bezug auf den Kunden. Schwachstellen in Individualsoftware oder Systemen unserer Kunden veröffentlichen wir nicht.

Meinungsverschiedenheiten

Sind Sie mit einer Entscheidung nicht einverstanden, etwa einer Ablehnung oder dem Inhalt eines CVE-Records, schreiben Sie an [email protected]. Einigen wir uns nicht, gilt das Dispute-Verfahren des CVE-Programms.