Wenn du in einem Repository eine Sicherheitslücke findest oder meldbar machen willst, stehen dir zwei GitHub-Mechanismen zur Verfügung, die oft verwechselt werden: eine SECURITY.md-Datei und Private Vulnerability Reporting. Beide beantworten dieselbe Frage, wie eine Lücke gemeldet wird, aber nur einer davon ist ein tatsächlicher Meldeweg mit Formular, Benachrichtigung und privatem Arbeitsbereich.
Was SECURITY.md leistet, und was nicht
Eine SECURITY.md ist eine Datei im Repository, die Informationen dazu bereitstellt, wie sich eine Sicherheitslücke im Projekt melden lässt (Quelle: GitHub-Dokumentation „Adding a security policy to your repository“). GitHub zeigt sie an, sobald du im Security-Tab des Repositories unter „Reporting“ den Punkt „Security policy“ aufrufst. Üblicher Inhalt sind Angaben zu unterstützten Versionen und dazu, auf welchem Weg jemand eine Lücke melden soll, etwa eine Kontaktadresse.
Damit endet aber auch schon, was die Datei tut. Sie ist eine statische Textdatei. Kein Formular, kein automatischer Ablauf, keine Benachrichtigung, kein Status, den irgendjemand nachverfolgen kann. Wer die SECURITY.md liest, bekommt eine Anleitung. Ob jemand sich daran hält, ob die genannte Adresse noch aktiv ist und was nach dem Absenden passiert, sagt die Datei nicht.
Private Vulnerability Reporting: der Meldeweg im Security-Tab
Private Vulnerability Reporting (PVR) ist ein eigenständiges GitHub-Feature. Laut Dokumentation können „owners and administrators of public repositories“ es für ihr Repository aktivieren; die genaue Freigabe erfolgt in den Sicherheitseinstellungen des Repositories. Eine Aktivierung für viele Repositories auf einmal ist über eine organisationsweite „custom security configuration“ möglich, laut GitHub-Doku ohne dass Details dazu auf derselben Seite stehen.
Ist PVR aktiv, sieht jemand, der eine Lücke findet, im Security-Tab den Button „Report a vulnerability“ und öffnet damit ein Formular. Pflichtfelder sind laut Dokumentation nur Titel und Beschreibung, empfohlen wird aber, so viele Informationen wie möglich mitzugeben. Nach dem Absenden bestätigt GitHub, dass die Maintainer benachrichtigt wurden und die Meldung als Grundlage für eine Security Advisory mit Credit vorgemerkt ist.
Warum eine Datei ohne Workflow eine Lücke lässt
GitHub stellt klar, dass beide Mechanismen unabhängig voneinander funktionieren: „Private vulnerability reporting is separate from a repository’s SECURITY.md file.“ Ein Repository kann also eine SECURITY.md ohne PVR haben, oder PVR ohne SECURITY.md, oder beides zusammen.
Das erklärt auch die Lücke im ersten Fall. Eine SECURITY.md ohne PVR beschreibt einen Meldeweg, meist eine E-Mail-Adresse oder ein externes Formular, erzwingt aber nichts. Es gibt keinen strukturierten, privaten Ort, an dem Meldung und Reaktion nachvollziehbar zusammenlaufen, und keinen Mechanismus, der einen Fix entstehen lässt, bevor die Lücke öffentlich sichtbar wird. Mit PVR entsteht bei einer Meldung ein Draft Security Advisory, ein privater Bereich, in dem Maintainer und die meldende Person zusammenarbeiten, bevor irgendetwas öffentlich wird. Wer in diesem Draft mitliest, folgt aus der Advisory-Berechtigung selbst, nicht aus einem CODEOWNERS-Eintrag für den betroffenen Pfad. Beide Systeme regeln Sichtbarkeit unabhängig voneinander (mehr dazu im Beitrag zu CODEOWNERS).
Abgrenzung zu security.txt: Repo-Feature statt Domain-Standard
SECURITY.md und Private Vulnerability Reporting sind GitHub-native Repository-Features. Sie gelten pro Repository und setzen ein GitHub-Konto mit entsprechenden Rechten voraus. Das ist ein anderer Mechanismus als security.txt nach RFC 9116: eine statische Datei unter /.well-known/security.txt, die für die gesamte Domain gilt, nach einem IETF-Standard aufgebaut ist und unabhängig davon funktioniert, ob dahinter überhaupt ein Repository oder eine Plattform wie GitHub steht. Wer beides betreibt, deckt zwei unterschiedliche Zielgruppen ab: security.txt findet, wer die Domain nach einem Kontakt absucht, PVR findet, wer bereits im Repository nach einem Weg sucht, eine Lücke im Code zu melden.
Einrichtung: Repo-Settings, Draft Advisory, privater Fork
Zur Einrichtung gehören drei Schritte. Erstens die Aktivierung von PVR in den Sicherheitseinstellungen des Repositories durch eine Person mit Owner- oder Admin-Rechten. Zweitens, optional, eine SECURITY.md, die kurz beschreibt, was gemeldet werden soll und was nicht; sie ersetzt PVR nicht, kann aber auf den Meldeweg im Security-Tab verweisen. Drittens der Ablauf nach einer Meldung: GitHub legt einen Draft Security Advisory an, den nur eingeladene Personen sehen, und bietet optional einen temporären privaten Fork an, in dem der Fix entwickelt wird, ohne dass er vor der Veröffentlichung sichtbar ist. Nur die Repository-Maintainer können Änderungen aus diesem privaten Fork in das eigentliche Repository übernehmen.
Für private Repositories macht die von GitHub referenzierte Dokumentation zu PVR keine Aussage, sie beschreibt die Funktion ausdrücklich für öffentliche Repositories.
Wo Unterstützung ansetzt
Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über drei Felder: Implementation (Delivery- und Nachweiskontrollen in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit dort schaffen, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen) und Maintenance (die Übergabefrage: wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem gehört). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.
Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.
Hinterlasse einen Kommentar