grundschutz-checks — Prüfungen, die Grundschutz++-Anforderungen jede Nacht messen.
Ein ISMS sagt, was umgesetzt ist. grundschutz-checks schaut nach, ob es stimmt. Fünf Prüfungen lesen GitLab und TLS-Endpunkte aus und schreiben das Gesehene in eine Lauf-Datei. Daraus macht grundschutz-worksheets OSCAL-Prüfergebnisse. Laufen sie jede Nacht, entsteht pro Anforderung eine datierte Reihe: Hat die Maßnahme über einen Zeitraum gewirkt, nicht nur an einem Tag?
- Im Einsatz: als Test, jede Nacht gegen mein eigenes GitLab; ob die Prüfungen ohne Fehlalarm laufen, zeigen 14 Nächte bis zum 27. Oktober 2026
- Prüfungen: Branch-Schutz, Zwei-Faktor-Pflicht, TLS, SBOM, Abhängigkeits-Updates
- Voraussetzung: Node 24, ein GitLab-Token mit
read_api, keine Abhängigkeiten - Lizenz: MIT · nur lesend, kein Schreibrecht nötig
Behauptet ist nicht gemessen
Bisher
- Der Status einer Anforderung steht im ISMS-Tool und wird zum Audit von Hand nachgezogen
- Nachweise sind Screenshots von einem Tag, nicht von einem Zeitraum
- Ob eine Einstellung zwischen zwei Audits kippt, fällt niemandem auf
- Ausnahmen leben in Köpfen, nicht in einer Datei mit Begründung
Mit grundschutz-checks
- Jede Nacht ein Lauf pro Prüfung, als OSCAL-Prüfergebnis mit Datum
- Pro Projekt, Gruppe oder Endpunkt steht, was erfüllt ist und was nicht, mit Grund
- Eine Prüfung, die nicht nachsehen konnte, schreibt nichts und bricht ab, statt „erfüllt“ zu melden
- Ausnahmen stehen in der Config, mit Begründung, und jeder Lauf nennt sie
Passt das zu meinem ISMS?
Nutze es wenn …
- dein Code in GitLab liegt und du Branch-Schutz, Zwei-Faktor-Pflicht, SBOMs und Abhängigkeits-Updates belegen willst
- du öffentliche Endpunkte hast, deren TLS jemand regelmäßig ansehen soll
- du mit Grundschutz++ arbeitest und Prüfergebnisse als OSCAL brauchst
- du lieber eine kleine Prüfung liest als ein Compliance-Tool konfigurierst
Nutze es nicht wenn …
- dein Code auf GitHub oder Bitbucket liegt: die vier Repository-Prüfungen sprechen nur mit der GitLab-API
- du eine fertige Abdeckung von Grundschutz++ erwartest: fünf Prüfungen belegen neun Anforderungen, die meisten davon nur teilweise
- du ein Ergebnis ohne eigene Prüfung der Zuordnung übernehmen willst
- du Nachweise für Laptops, Büros oder Menschen suchst
Warum eigene Prüfungen
Das BSI veröffentlicht Grundschutz++ als maschinenlesbaren Katalog. Mit grundschutz-worksheets wird daraus ein OSCAL-Profil, ein Sicherheitsplan und ein Maßnahmenplan. Was fehlte, war die Messung: Prüfergebnisse, die nicht ich schreibe, sondern ein Lauf. Diese fünf Prüfungen sind der Anfang. Sie decken ab, was sich an GitLab und TLS ohne Agenten auf dem System ablesen lässt.
Eine Prüfung liest nur. Konnte sie nicht nachsehen, etwa wegen einer fehlgeschlagenen Anfrage oder einer leeren Config, schreibt sie keine Lauf-Datei und endet mit Exit 1. Eine Prüfung, die nicht nachsehen konnte, hat auch nichts als erfüllt gefunden. Welche Anforderung eine Prüfung nur teilweise belegt, steht in der Lauf-Datei unter partial. Im Sicherheitsplan bleibt ein teilweises Bestehen dann teilweise.
Getestet wird jede Prüfung gegen ein Fake-GitLab und eine Fake-TLS-Probe. In der CI laufen die Prüfungen außerdem echt, gehen durch results.mjs von grundschutz-worksheets und werden gegen das NIST-Schema validiert. Lesen lässt sich das Ergebnis mit grundschutz-viewer, als eine HTML-Seite mit dem Verlauf aller Läufe.
So wird aus einer Prüfung ein Prüfergebnis
Die Config nennt, was angesehen wird: die GitLab-Instanz, Gruppen und Projekte, TLS-Endpunkte, Grenzwerte und Ausnahmen. Tokens kommen aus der Umgebung, nie aus der Config. GITLAB_TOKEN braucht nur read_api.
# was es gibt
node run.mjs --list
# eine Prüfung, ein Lauf, ein Ergebnis
GITLAB_TOKEN=... node run.mjs branch-protection --config checks.config.json > run.json
node ../grundschutz-worksheets/results.mjs run.json > results.json
Die fünf Prüfungen und die Anforderungen, die sie belegen:
branch-protection: Standard-Branch geschützt, kein Force-Push, Push nur für Maintainer, Merge nur nach grüner Pipeline. DEV.2.4, TEST.4.1, beide teilweisemfa-enforced: jede genannte Gruppe verlangt Zwei-Faktor, Karenzzeit höchstens 48 Stunden. BER.5.9, teilweisetls-endpoints: TLS 1.2 oder 1.3, kein 1.0 oder 1.1, Zertifikat noch mindestens 14 Tage gültig. KONF.14.1, KONF.14.1.1, beide teilweisesbom-present: das neueste Release jedes Projekts hat eine SBOM. DEV.4.3, ASST.2.3.2, letztere teilweisedependency-updates: Scan-Job in der letzten Pipeline bestanden, kein Update des Bots länger als 14 Tage offen. DET.5.3, DET.5.10, beide teilweise
Bewusste Ausnahmen stehen in der Config unter accept, mit Projekt und Grund. Ein akzeptiertes Projekt wird nicht geprüft, und jeder Lauf nennt es mit seinem Grund. So bleibt eine Ausnahme sichtbar, statt zu verschwinden.
Die Dokumentation
Die Prüfungen
Was jede Prüfung ansieht, welche Anforderungen sie belegt und welche davon nur teilweise. Dazu die Aufrufe von der Liste bis zum Prüfergebnis.
Beispiel-Config
Jede Einstellung an einer Stelle: Katalog, Prüfplan, GitLab-Gruppen, TLS-Endpunkte, Grenzwerte und Ausnahmen mit Begründung.
Änderungen
Jede Version mit dem, was sich geändert hat, bis zum Commit von grundschutz-worksheets, gegen den die Prüfungen getestet sind.
grundschutz-worksheets
Node 24+ · MIT
Macht aus den Lauf-Dateien OSCAL-Prüfergebnisse und aus dem Katalog Profil, Sicherheitsplan und Maßnahmenplan. Ohne worksheets bleibt ein Lauf eine JSON-Datei.
GitHub
Node 24+ · MIT
Quellcode, Releases, Issues. Entwickelt wird in GitLab, GitHub ist der öffentliche Spiegel. Pull-Requests übernehme ich von Hand.
Grundschutz++ messen statt behaupten?
Ich helfe beim Einstieg: erst eine Prüfung gegen dein GitLab, dann die Kette bis zum Maßnahmenplan.