Wir haben in den letzten acht Sessions Scanner in unsere GitHub DevSecOps Pipeline eingebaut — SCA, SAST, Container Scanning, Secret Detection, DAST. Die Scanner produzieren jetzt einen kontinuierlichen Strom von Findings, und die Frage lautet: Wo managen wir sie? In Teil 9 schauen Patrick Steger und ich uns das eingebaute Vulnerability Management von GitHub an — den Security Tab — und benennen, was funktioniert und was fehlt.
Wo Vulnerabilities auf GitHub leben#
Alles passiert im Security Tab. Es gibt zwei verschiedene Sektionen. Code Scanning enthält Findings aus den Scannern, die wir in die Pipeline eingebaut haben — CodeQL plus alle SARIF-fähigen Tools. Secret Scanning ist GitHubs eigenes integriertes Secret Detection — mit eigener UI.
Warum zwei verschiedene UIs? Wir wissen es nicht wirklich. Unsere Vermutung: Secret Scanning wird als Plattform-Feature mit Spezial-Workflow behandelt, während Code Scanning der generische Ingestion-Punkt für alles andere ist. In der Praxis wechselt man oft zwischen den beiden — die Inkonsistenz braucht Eingewöhnung.
Vulnerabilities werden über alle Branches getrackt, auf denen die Pipeline mit den Scannern gelaufen ist. Die Branches nahe Produktion sind natürlich die wichtigsten, aber bei Bedarf kannst du nach Branch filtern.
Die Capabilities, die GitHub bietet#
Für jedes Finding kannst du nach Tool, Branch, Severity und Regel sortieren und filtern (der Regel-Filter ist ehrlich gesagt nicht sonderlich nützlich, ausser du suchst etwas ganz Bestimmtes). Aus einem Finding kannst du:
- Ein Issue erstellen, um die Arbeit an einen Entwickler zu übergeben. Vulnerability und Issue sind beidseitig verlinkt.
- Dismissen mit Begründung: false positive, won’t fix (Risiko akzeptiert) oder used in tests (es ist in Test-Code, nicht in Produktion). Wichtig: Du kannst — und solltest — einen Kommentar mit der Entscheidung anhängen.
- Historie tracken. GitHub zeigt, wann das Finding zuerst entdeckt wurde, auf welchem Branch es auftauchte, wann es gefixt wurde und ob es wieder auftauchte.
Es gibt keinen expliziten “resolved”-Button. Sobald der Scanner das Finding im nächsten Pipeline-Lauf nicht mehr meldet, schliesst GitHub es automatisch.
Du kannst zusätzliche Scanner integrieren, solange sie SARIF liefern. SARIF ist immerhin ein Standard — also keine schwere Einschränkung.
Die Limitierungen, die du einplanen musst#
Patrick benennt die Schwächen direkt.
Kein zeitlich begrenztes Dismiss. Du kannst ein Finding nicht für zwei Wochen oder zwei Monate dismissen. Manchmal will man ein Finding “vorerst” loswerden — es gibt noch keinen Fix oder das Team muss erst etwas anderes ausliefern — aber GitHub erlaubt kein sauberes Aufschieben.
Du kannst die Severity nicht ändern. Sagt das Tool “high”, bleibt es “high”. Kompensierende Massnahmen in deiner Umgebung können es real auf medium oder low senken — GitHub erlaubt nicht, das abzubilden.
Manuelle Triage ist unvermeidlich. Jedes Vulnerability-Management-Tool braucht menschliche Reviews für False Positives und Duplikate. Das ist nicht GitHub-spezifisch, aber rechne mit dem Aufwand.
Keine manuellen Einträge. Den hasst Patrick wirklich. Wenn du einen externen Penetration Test beauftragst und der Tester findet zehn neue Vulnerabilities, kannst du sie nicht ins GitHub Vulnerability Management eintragen. Du brauchst ein zweites Tool für alles, was ausserhalb der Plattform gefunden wird — eine ernsthafte Einschränkung, wenn Pen-Testing zu deinem Prozess gehört.
Triage-Workflow in der Praxis#
In der Demo gehen wir den realistischen Flow durch. In Secret Scanning sind die Findings klar: Titel, Referenz auf das Secret und Remediation-Empfehlung. Du weisst, was das Problem ist und was zu tun ist.
In Code Scanning filtern wir auf CodeQL und öffnen ein “use of broken or risky cryptography”-Finding — eine MD5-Stelle, die wir zuvor schon bewertet hatten. Wir nutzen sie für Indexierung, nicht für Security, also dismissen wir als false positive mit dem Kommentar “it’s just for indexing”. Dieser Kommentar ist der Unterschied zwischen einem brauchbaren Audit Trail und einer Black Box.
Als Nächstes öffnen wir ein echtes Cross-Site-Scripting-Finding — eine Message, die an den Caller zurückgegeben und dort reflektiert wird. Echtes Issue. Wir erstellen ein Issue direkt aus dem Finding. GitHub springt in das neu erstellte Issue mit dem Link zurück zur Vulnerability, und die Vulnerability-Seite zeigt das verknüpfte Issue. Beidseitiges Linking funktioniert gut.
Zum Fixen nutzen wir die File View, navigieren zur Quelle, wechseln auf den Main Branch, editieren inline und speichern. Die Pipeline läuft in Actions, CodeQL scannt erneut, und der Open-Counter für die Regel fällt auf null. Unter dem closed-Filter taucht das Cross-Site-Scripting-Finding als vor wenigen Minuten resolved auf.
Eine Sache solltest du wissen: Das Issue, das wir erstellt haben, wird nicht automatisch geschlossen, wenn die Vulnerability geschlossen wird. Der Entwickler (oder du) muss es manuell schliessen. Vertretbar — manuelles Schliessen ist die Bestätigung des Entwicklers, dass der Fix deployed ist — aber eben nicht automatisch.
Key Takeaways#
Ein Tab, zwei UIs. Secret Scanning und Code Scanning leben im selben Security Tab, haben aber unterschiedliche UIs. Gewöhn dich ans Wechseln.
Default Branch ist nicht der einzige Branch. GitHub trackt Findings über mehrere Branches — flexibler als die Default-Branch-only-Sicht mancher anderer Plattformen.
Dismiss-Gründe sind First-Class. False Positive vs. won’t fix vs. used in tests, plus Kommentarfeld. Nutze sie — sie sind dein Audit Trail.
Kein zeitlich begrenztes Dismiss. Brauchst du “ignorieren für zwei Monate”, musst du das ausserhalb von GitHub tracken. Ein Label plus Kalendererinnerung ist der realistische Workaround.
Keine manuellen Einträge ist die grösste Lücke. Findings aus externen Penetration Tests können nicht eingetragen werden. Wenn Pen-Testing zu deinem Prozess gehört, plane ein zweites Tool ein.
Issues und Vulnerabilities verlinken sich beidseitig, schliessen aber unabhängig. Issue aus Finding erstellen, Code fixen, Vulnerability schliesst sich automatisch — aber denk daran, das Issue ebenfalls zu schliessen.