GitHub: Erstprüfung und wöchentliche Scans unterscheiden
Wöchentliche Scans ruhiger Repositories können wie aktive Entwicklung wirken. Weniger Läufe bedeuten aber nicht automatisch weniger Schutz.
GitHub änderte am 1. Oktober 2026 den Beginn geplanter Analysen für code scanning default setup und GitHub Code Quality. Fakten und folgende Betriebsvorschläge sind getrennt zu betrachten.
Die Erstprüfung bleibt
Beim Aktivieren läuft weiterhin eine Validierungsanalyse mit Ergebnissen. Wöchentliche Scans beginnen nach einer durch push oder pull request ausgelösten Analyse. Entscheidend ist die Analysehistorie, nicht frühere Git-Aktivität.
Code scanning und Code Quality teilen die Aktivitätsbewertung. Die Änderung gilt für Enterprise Cloud und ist für Enterprise Server 3.24 vorgesehen. Laut GitHub ist keine Konfigurationsänderung nötig.
Einrichtung und Analyse getrennt erfassen
Unser Vorschlag: Einrichtung, letzten Auslöser, Commit, Ergebniszeit und Verantwortliche separat dokumentieren. Aktivierung allein beweist keinen laufenden Wochenrhythmus.
Ein Archiv mit nur Erstprüfung lässt sich als eingerichtet und initial geprüft erfassen. Ein push- oder pull-request-Lauf gehört als eigener Beleg dazu. Das sind Teamnotizen, keine neuen GitHub-Statusnamen.
Weniger Läufe sind kein Sicherheitswert
Weniger geplante Analysen bedeuten nicht weniger Schwachstellen. Prüfe relevante Meldungen, deren Bearbeitung und die Verbindung zu laufenden Diensten.
Ein ruhiges Repository kann weiterhin Produktionsquellcode enthalten. Prüfe Abdeckung, Abhängigkeiten und Zuständigkeiten statt seine Bedeutung aus Aktivität abzuleiten.
Klein und lesend beginnen
Vergleiche ein gepflegtes Repository mit einem Archiv. Lies Einstellungen und Analysehistorie und trenne Erstprüfung von push- und pull-request-Analysen.
Erzeuge keine sinnlosen Commits und ändere keine geprüften Einstellungen nur für diesen Check. Bei Abweichungen Umgebung und Version festhalten. Die Grafik erklärt den Prüfablauf und ist kein Produktscreenshot.