Andererseits hilft ein konkrekter Exploit, den DBAs bei der Abschätzung, wie kritisch eine Lücke wirklich ist (im Gegensaz zur Fehlerbeschreibung “Fehler im SQL Compiler”) und ob ein CPU eingespielt werden soll.

Zur (minimale) Zeitspanne von 3 Monaten:
Von den üblichen Researcher die Sicherheitslücken finden, veröffentlichen manche Exploits niemals (Steven), manche vorher oder direkt (Cesar, Esteban, Joxean), manche unterschiedlich (David, ich). Daraus kann ich leider keine 3-Monatsregel oder eine andere Regel erkennen. Dies kann ich natürlich mit den entsprechenden Links belegen

Nicht jeder kennt/liest Ihre genannten Webseiten. Ich rede hier nicht von den Security-Experten, sondern z.B. von den unzufriedenen Mitarbeitern, die damit eventuell eine Möglichkeit in die Hand bekommen, sich zu “rächen”. Diese sind typischerweise nicht in der Lage, anhand einer Überschrift eigene Exploits zu schreiben.

>>Mir ist allerdings neu, dass DBAs normalerweise 3 Monate Zeit haben,
>>bevor gefundene Sicherheitslücken veröffentlicht werden
An diese (minimalen) Zeitspanne – sprich an diese ungeschriebene Regel – habe sich doch viele gehalten. Öfters wurde der Exploit noch später veröffentlicht.

>>Dass die erste Veröffentlichung von solchem Exploit Code negativ ist, gebe ich Ihnen vollkommen recht
Ich denke, da sind wir uns einig – ich gehe aber eben noch einen Schritt weiter

Dass die erste Veröffentlichung von solchem Exploit Code negativ ist, gebe ich Ihnen vollkommen recht. Oftmals ist es aber auch trivial (zumindest für Security Experten), eigenen Exploit Code für Sicherheitslücken zu schreiben. Da reicht alleine eine Überschrift.

Mir ist allerdings neu, dass DBAs normalerweise 3 Monate Zeit haben, bevor gefundene Sicherheitslücken veröffentlicht werden. Von solch einer “Regel” habe ich nicht gehört. Es gab eine Firma (NGS), die mal solch eine Policy hatte, davon aber wieder Abstand genommen hat.