Unter „Sicherheit → Ergebnisse“ befindet sich die einzige Liste aller von der Komponente Sicherheit festgestellten Probleme – unabhängig davon, welche Quelle sie entdeckt hat. Jede Quelle schreibt in denselben Speicher, sodass dasselbe Problem, das von zwei Quellen gemeldet wird, als ein einziges Ergebnis erscheint.
Ergebnisse, Auftritte und Quellen
- Ein Ergebnis ist ein klar definiertes Problem in einem Repository: ein anfälliges Paket, ein preisgegebener Zugangsdatenwert oder ein unsicheres Muster im Code.
- Seine Auftritte zeigen den Ort des Problems an: einen Manifest- und Abhängigkeitspfad, eine Datei und Zeile oder den Commit und Pfad, an dem ein Geheimnis auftritt. Zwei installierte Versionen desselben Pakets stellen zwei Auftritte dar.
- Seine Quellen geben an, wer das Problem entdeckt hat, wann und in welchem Umfang: OSV-Scanner, GitHub Dependabot, GitHub Code-Scanning, GitHub Secret-Scanning, der Secret-Scan von Coroid, die Code-Regeln von Coroid, Ihr eigener Scan-Befehl, die Coroid Rezension sowie die Sicherheitsprüfung.
Die Liste ist nach Projekten gruppiert. Sie können sie nach Projekt, Art, Schweregrad, Status, Quelle, Offenlegung und Nachweis filtern. Ein Abhängigkeits-Ergebnis wird nach Paket gruppiert – zusammen mit dem Update, das es behebt, sofern eines bekannt ist.
Schweregrad und Fristen
Jedes Ergebnis hat nach seiner Öffnung eine festgelegte Bearbeitungsfrist:
| Schweregrad | Frist bis zur Behebung |
|---|---|
| Kritisch | 2 Tage |
| Hoch | 7 Tage |
| Mittel | 30 Tage |
| Niedrig | 90 Tage |
In der Übersicht werden die überfälligen Ergebnisse sowie diejenigen mit einer Frist von bis zu drei Tagen angezeigt.
Status
| Status | Bedeutung |
|---|---|
| Offen | Das Problem ist im Standardzweig vorhanden. |
| Im Code behoben | Laut einem vollständigen Scan sind alle Auftritte im Standardzweig nicht mehr vorhanden. |
| Rotation bestätigt | Ein preisgegebener Zugangsdatenwert, bei dem bestätigt wurde, dass er rotiert oder widerrufen wurde. Siehe Preisgegebene Geheimnisse. |
| Gilt nicht mehr | Alle zu dem Ergebnis gehörenden Warnhinweise wurden zurückgezogen. Das bedeutet jedoch nicht, dass das Problem „behoben“ ist. |
| Auf einem pull request | Nur auf einem pull request sichtbar. Es gehört zum pull request und wird beim nächsten Scan des Standardzweigs erfasst, sobald die Änderung zusammengeführt wird. |
Keine stille Bestätigung
Ein Auftritt gilt erst dann als nicht mehr vorhanden, wenn ein vollständiger Scan des aktuellen HEAD den entsprechenden Status meldet. Ein teilweiser Scan, ein fehlgeschlagener Scan, ein Scan ohne Berechtigung oder ein Scan eines Commits, den der Zweig bereits hinter sich gelassen hat, ändern nichts daran. Die Abdeckung zeigt jeden Fall auf:
- Teilweise: einige Dateien konnten nicht vollständig gelesen werden; dies wird in der Abdeckung angegeben.
- Veraltet: der Bestand stammt nicht vom aktuellen HEAD des Standardzweigs oder ist älter als ein Tag.
- Unbekannt seit …: die Quelle hat ihre Berechtigung verloren oder konnte nicht gelesen werden. Ergebnisse, die nur von dieser Quelle gemeldet wurden, zeigen ab diesem Zeitpunkt den Status „Unbekannt“.
- Warnhinweis-Feed verzögert: solange dieser Zustand anhält, weist kein Projekt eine saubere Abdeckung auf.
Die Ergebnisse werden in der Reihenfolge angezeigt, in der Coroid die Zweig-Heads erfasst hat – nicht nach Commit-Datum. Wenn jemand einen Zweig mit einem älteren Commit zurücksetzt, ist der Scan dieses Commits das neueste Ergebnis; ein spätes Ergebnis für einen HEAD, den der Zweig bereits verlassen hat, ändert nichts daran.
Im Code behoben und am Deploymentsort behoben
Das Zusammenführen einer Behebung bedeutet nicht, dass die Behebung bereits aktiv ist. Die Komponente Sicherheit verfolgt beide Zustände getrennt:
- Im Code behobenDer Standardzweig weist das Problem nicht mehr auf.
- Pro Umgebung: für jede Umgebung, die angibt, welche Version sie ausführt, scannt Coroid exakt diese Revision. Das Ergebnis gilt dort nur als behoben, wenn der Scan abgeschlossen ist und das Problem nicht mehr findet. Eine Rückgängigmachung oder ein Rollback, der das Problem wiederherstellt, öffnet das Ergebnis für diese Umgebung erneut.
Die Umgebungen eines Ergebnisses zeigen für jede Umgebung an, ob das Problem „In der Produktion läuft“, „Nur im Code vorhanden“ oder „Deploymentsstatus unbekannt“ ist. „Deploymentsstatus unbekannt“ bedeutet, dass Coroid keine beobachtete Revision für die Umgebung hat oder noch keinen vollständigen Scan durchgeführt hat. Ein Projekt ohne Deployments-Tracking gibt an: „Nur Repository-Zustand – es wird keine Deployments-Revision verfolgt.“ Um Deployments zu verfolgen, siehe Deployments-Ereignisse.
Übersicht → Die Fortschrittszählung der Behebungen zeigt an, welche Probleme noch in der Produktionsumgebung aktiv sind, welche im Code behoben, aber noch nicht deployed wurden, welche noch nicht bewertet werden können, welche Pull Requests zur Behebung auf die Überprüfung warten sowie die mediane Zeit von der Entdeckung bis zur Merge der Behebung und bis zum Deployment.
Ausnahmen
Eine Ausnahme versteckt ein Ergebnis aus der offenen Liste, ohne es zu löschen. Inhaber und Administratoren können für ein Ergebnis eine Ausnahme hinzufügen:
| Art | Erforderlichkeiten |
|---|---|
| Risiko akzeptieren | Ein Grund, die höchste zulässige Schweregradstufe und ein zukünftiges Ablaufdatum. |
| Kein Problem (falscher positiver Befund) | Ein Grund und die höchste zulässige Schweregradstufe. Ein Ablaufdatum ist optional. |
Das Ergebnis wird wieder angezeigt, sobald die Ausnahme abläuft, jemand sie widerruft oder der Schweregrad des Ergebnisses die von der Ausnahme zugelassene Stufe überschreitet. Eine Erhöhung des Schweregrads macht die Ausnahme dauerhaft ungültig. Die durch die Ausnahme verborgenen Beobachtungen bleiben erhalten; benennen Sie die Ausnahme entsprechend. Jede Ausnahme wird im Audit-Log der Organisation festgehalten.
Ein weitergeleitetes Zertifikat ist anders: Es wird nur geschlossen, wenn jemand bestätigt, dass es rotiert oder widerrufen wurde. Siehe Weitergeleitete Geheimnisse.
Reagieren auf ein Ergebnis
Aus einem Ergebnis heraus können Inhaber und Administratoren Folgendes tun:
- Beheben: Das zugehörige Behebungs-Arbeitselement öffnen. Bei einem Ergebnis zu einer öffentlichen Abhängigkeit einen Pull Request zur Behebung oder eine Maßnahme zur Abmilderung, falls keine korrigierte Version existiert. Bei einem Code-Ergebnis eine Behebungs-Aufgabe. Bei einem weitergeleiteten Geheimnis die Checkliste zur Rotation. Siehe Pull Requests zur Behebung.
- Risiko akzeptieren oder als „Kein Problem“ kennzeichnen Kein Problem.
- Die offene Behebungsaufgabe sowie pull request verfolgen.
Aufbewahrung
Ergebnisse, ihre Auftretensfälle und die zugehörigen Beweise werden so lange aufbewahrt, wie das Repository verbunden ist. Wenn ein Repository getrennt wird, werden diese nach 30 Tagen gelöscht und bei einer Wiederverbindung innerhalb dieses Zeitraums wiederhergestellt. Gemeinsam genutzte Beratungsdaten gehören Ihnen nicht und werden aufbewahrt. Audit-Einträge zu Ausnahmen, Bestätigungen und Offenlegungen folgen der Aufbewahrungsrichtlinie des Audit-Logs.