Einrichtungs-Checkliste: Erreichbarkeit, Sicherheitskorrekturen und bekannt ausgenutzte Schwachstellen
Sicherheit › Übersicht (/<org>/_admin/security/overview) beginnt für Owner der Organisation mit einer Checklisten-Karte. Sie zeigt, was Erreichbarkeit, Sicherheitskorrekturen und die Triage bekannt ausgenutzter Schwachstellen von deiner Organisation brauchen. Jeder Punkt wird bei jedem Laden der Seite aus dem aktuellen Zustand deiner Organisation berechnet. Er hält nie nur fest, dass du hingeschaut hast.
Jeder Punkt sagt, was er ist, warum er wichtig ist und wie sein aktueller Zustand ist, und gibt einen Link. Ein Badge kennzeichnet ihn als Erledigt, Handlung nötig, Bitte prüfen oder Optional. Die Überschrift zählt die Punkte, die nichts mehr von dir brauchen.
Die Punkte
| Punkt | Aktueller Zustand | Link |
|---|---|---|
| Scan-Abdeckung | Wie viele Repositorys einen gescannten Standard-Branch haben, bei wie vielen davon Abhängigkeiten gefunden wurden, und bis zu drei, die keine listen: Keine Abhängigkeiten gefunden. Ein Repository ohne Lockfile oder Manifest kann keinen Abhängigkeitsbefund und keine Sicherheitskorrektur haben. Handlung nötig, solange kein Repository gescannt wurde (pushe Code oder migriere ein Repository; es wird gescannt, sobald es angelegt ist), Bitte prüfen, wenn jedes gescannte Repository keine Abhängigkeiten listet. Ein Repository, dessen Stückliste noch nicht indiziert ist, wird nicht als leer gezählt. | Unterstützte Ökosysteme: Abhängigkeits-Scanning |
| Als ausgenutzt bekannte Schwachstellen | Wie viele offene Abhängigkeitsbefunde eine CVE haben, die von ENISA EUVD oder CISA KEV als in freier Wildbahn ausgenutzt gelistet ist. Handlung nötig, solange es mindestens einen gibt. | Die Liste der Abhängigkeiten, gefiltert auf bekannt ausgenutzte |
| Go-Binärdateien mit Symbolen bauen | Welche Images Go-Binärdateien enthalten, die mit -ldflags=-s gebaut wurden. govulncheck liest aus ihnen keine Symboltabelle, deshalb bleiben ihre Befunde unknown (no_symbol_table). Handlung nötig, solange es mindestens eine gibt. Baue ohne -s; -w ist in Ordnung. | Erreichbarkeit: die Gründe |
| KI-Korrekturen: dein eigener KI-Anbieter | Nicht eingerichtet, Eingerichtet (und ob KI-Korrekturen an sind) oder Schlüssel abgelehnt, wenn der Anbieter den Schlüssel bei der letzten Nutzung abgewiesen hat (HTTP 401 oder 403). | KI-Integrationen |
| Limits für Sicherheitskorrekturen | Die pro Repository erlaubten offenen Pull Requests und die Anfragen pro Organisation in 24 Stunden, und ob es die Standardwerte sind. Bitte prüfen, wenn ein Limit 0 ist, was AutoFix ausschaltet. Ein Korrektur-Pull-Request öffnet sich nur, wenn jemand auf Korrektur-PR öffnen klickt, es sei denn, automatische Sicherheitskorrekturen sind an. | Limits für Sicherheitskorrekturen |
| Warnungen: neu erreichbar oder als ausgenutzt bekannt | An oder aus für die Organisation, mit einer Schaltfläche zum Umschalten. | Warnungen zu Befunden |
| SLA-Faktor für nicht erreichbare Befunde | Aus, oder an mit seinem Faktor. Optional. | Behebungsfrist (SLA) |
| Bei nicht erreichbar nicht blockieren | Aus, an für jedes Repository oder an für eine Anzahl von Repositorys. Optional. | Die Richtlinie |
| Automatische Sicherheitskorrekturen | Aus oder an: an, wenn der Modus der Sicherheitskorrekturen einer der automatischen ist. Eine Organisation, die am oder nach dem 2026-10-27 angelegt wurde, beginnt mit an (Automatisch für kritische und bekannt ausgenutzte). Optional. | Automatische Sicherheitskorrekturen |
| Anonyme Zahlen beitragen | Aus (Standard) oder an. Optional: Aus braucht nichts weiter von dir. | Anonyme Zahlen |
Scan-Abdeckung bietet außerdem Mit einem Beispiel-Repository ausprobieren: Damit wird das Sicherheitsbeispiel von fremforge in die Organisation kopiert, sodass du Befunde und eine Sicherheitskorrektur sehen kannst, bevor du eigenen Code pushst. Das Beispiel zählt nie als Abdeckung, und seine Befunde erscheinen nur in der Konsole.
Ein optionaler Punkt, der aus ist, ist kein Problem; er zählt als einer, der nichts mehr von dir braucht.
Ausblenden
Checkliste ausblenden klappt die Karte für alle in der Organisation auf eine Zeile zusammen, mit einer Schaltfläche Checkliste anzeigen, die sie wieder öffnet. Der Zustand wird beim Anzeigen neu berechnet, ist also immer aktuell. Aus- und Einblenden wird als code-security.checklist.updated auditiert.
API
GET /_app/api/v1/orgs/{org}/security/checklist (policy:read) gibt die Checkliste so zurück, wie die Karte sie gerade berechnet: dismissed, complete, total und die items, jeweils mit ihrer id, ihrem status (done, todo, optional oder warn) und den Fakten dahinter, zum Beispiel open für known_exploited, max_open_per_repo für autofix_limits oder scanned_repos, with_dependencies, no_dependencies und no_dependency_examples für scan_coverage. PUT mit {"dismissed": true} oder false (policy:write) blendet die Karte aus oder ein.
Auditoren
Ein Auditor mit Lesezugriff sieht die Karte. Die Schaltflächen werden Auditoren verweigert, wie jede Änderung.
Siehe auch
- Sicherheits-Digest: Ergebnisse der Sicherheitskorrekturen und die neu erreichbaren und bekannt ausgenutzten Befunde der Woche.
- Warnungen zu Befunden.