01
Verbindung installieren und berechtigen
Verbinden Sie über OAuth oder eine App-Installation und wählen Sie genau, was GitLab teilt. Sie können den Zugriff jederzeit auf Ihrer Seite widerrufen.
GitLab verbindet sich über OAuth für Zwei-Wege-Remediation-Issues, in der Cloud oder selbst gehostet. Daneben prüfen lesende Checks erzwungene Zwei-Faktor-Authentifizierung, Projekt-Sichtbarkeit und geschützte Default-Branches in Ihrer Gruppe.
5 rein lesende Checks, ausgeführt nach Zeitplan. Jeder Fehlschlag wird zum Finding an einem Control, jeder Check ist gelistet, keiner ist «demnächst».
Confirms the token can read the target group over the GitLab API.
group-connectivity
Fails if the GitLab group does not require all members to enable two-factor authentication. `require_two_factor_authentication` is only accurate when the token owner administers the group.
group-two-factor-required
Fails if the project's visibility is `public`, meaning its source is readable by anyone.
project-not-public
Fails if the project's default branch is not in the protected-branches list, or if that protected-branch entry allows force-push. Only exact-name protection rules are evaluated: a wildcard rule (for example `main*` or `*`) is not matched even though it does protect the branch.
default-branch-protected
Inventories the active access tokens of a group (name, scopes, role, created, last-used and expiry date, age and days to expiry; GitLab returns no token values, and last-used IP addresses are not kept) and fails if a token was created longer ago than the approved maximum age (default 365 days). Passes when there are none, since there is nothing to rotate; the result says so and records a count of 0. Needs read_api and the Owner role on the group. GitLab CI/CD variables are not inventoried: their API carries no dates and returns values. Endpoint: GET /groups/:id/access_tokens (docs.gitlab.com/api/group_access_tokens/).
access-token-inventory
Bringen Sie die Test-Liste Ihrer aktuellen Plattform mit, wir gleichen sie mit diesen Checks ab, Lücke für Lücke
Erstellen Sie Issues in Ihren GitLab-Projekten, Cloud oder selbst gehostet, und halten Sie jedes auf Stand, während sich sein Status ändert, verbunden über OAuth.
Die Einrichtung dauert Minuten, kein Migrationsprojekt, und jeder Schritt bleibt auf Ihrer Seite
Verbinden Sie über OAuth oder eine App-Installation und wählen Sie genau, was GitLab teilt. Sie können den Zugriff jederzeit auf Ihrer Seite widerrufen.
Der erste Lauf startet direkt nach dem Verbinden und wiederholt sich dann nach Zeitplan. Ergebnisse tragen Zeitstempel, Ihre Evidenz hat also eine Geschichte, keinen Schnappschuss.
Bestandene Ergebnisse hängen sich als Evidenz an die zugehörigen Controls; Fehlschläge werden zu Findings, die Sie triagieren. Wenn das Audit kommt, ist der Nachweis bereits verknüpft.
Öffnen Sie eine beliebige Seite für ihr vollständiges Check-Register.
Jeden Zugang erstellen und berechtigen Sie selbst, und Sie können ihn jederzeit widerrufen. Checks lesen nur; Ergebnisse und Evidenz werden in der Schweiz gespeichert und bleiben exportierbar.
Ja. Die Checks authentifizieren sich mit einem Zugang, den Sie selbst erstellen und berechtigen, und lesen ausschliesslich Konfiguration. devguard hat keinen Schreibzugriff auf GitLab und remediiert nichts im Stillen.
Ein fehlgeschlagener Check wird zum Finding am zugehörigen Control, mit der Evidenz im Anhang. Sie entscheiden über die Behandlung: Niemand wird angepiept, und nichts wird automatisch remediiert.
Die Checks laufen auf Schweizer Infrastruktur, Ergebnisse und Evidenz werden in der Schweiz gespeichert. Alles ist exportierbar, Ihre Evidenz gehört weiterhin Ihnen.
20 Minuten dazu, wie Sie Ihre Zertifizierung heute betreiben. Bringen Sie Ihre aktuelle Test- oder Control-Liste mit, und wir gleichen sie mit diesen Checks ab, ehrlich und Lücke für Lücke.