Vorfallprobleme verwalten
Aus Konformitätsperspektive sind das Erstellen, Speichern und Aktualisieren von Vorfallproblemen (Schwachstelle, CVE) als Teil der Pipelines Continuous Integration und Continuous Compliance für die Angabensammlung von wesentlicher Bedeutung.
Während der Ausführung der PR-Pipeline mit aktivierter Beweissammlung, CI- und CC-Pipelines erstellt das collect-evidence Skript Incident Issues, fügt sie den
gesammelten Beweisen zu und speichert sie im Incident Issue Repository.
Das Script collect-evidence verwendet die Funktionen des Befehls cacao incident process, der die bereitgestellten Scanergebnisse verarbeitet und entweder
neue Vorfallprobleme im bereitgestellten Repository pro Sicherheitslücke erstellt oder die vorhandenen Vorfallprobleme basierend auf den Betreff-Vorfallpaaren aktualisiert. Daher werden die Vorfallprobleme an Assets gebunden und entsprechend
den Ergebnissen bestimmter Tools erstellt. Weitere Informationen finden Sie unter Unterschied zwischen Problemverarbeitung in CI-und CC-Pipelines.
Bearbeitung von Vorfallsproblemen in der PR-Pipeline
Die PR-Pipeline mit aktivierter Beweissammlung kann Vorfälle erzeugen, wenn eine Schwachstelle oder ein CVE gefunden wird. Um die Beweissammlung in der PR-Pipeline zu aktivieren, siehe:PR-Pipeline Beweissammlung
Das Problemmanagement in der PR-Pipeline für Vorfallsprobleme ist ähnlich wie das der CI-Pipeline. Der einzige Unterschied liegt in der Logik des Autoklavierens.
Ein von einer PR-Pipeline erstellter Vorfall kann nur von einer PR-Pipeline, die auf demselben PR läuft, autokludiert werden. Das Problem kann nicht automatisch durch eine PR-Pipeline gelöst werden, wenn:
- Das Problem wird von einer PR-Pipeline gefunden, die auf einer anderen PR läuft.
- Das Problem wird von allen CI- oder CC-Pipelines gefunden.
Verarbeitung von Vorfallsproblem
Obwohl die CI-und CC-Pipelines gemeinsame Schritte haben, weist die Problemverarbeitung dieser Pipelines einige Unterschiede auf:
- Vorfallprobleme, die während der CI-Pipeline erstellt werden, tragen kein Fälligkeitsdatum, während Vorfallprobleme, die während der CC-Pipeline erstellt werden, dies tun.
- Vorfallprobleme, die während der CI-Pipeline erstellt werden, werden während des Builds gefunden, während Vorfallprobleme, die während der CC-Pipeline erstellt werden, in der Produktionsumgebung gefunden werden.
Die Abbildungen 1-6 zeigen die möglichen Anwendungsfälle, die auf diesen Unterschieden basieren.
Problemlebenszyklus
Der Problemlebenszyklus reicht von Code-PRs bis zu Produktionsscans.
Anwendungsfall 1: Sicherheitslücke im Build gefunden
Der neue Build führt zu einer Sicherheitslücke, die nicht akzeptiert wird. Die Implementierung wird blockiert, sofern es sich bei der Änderungsanforderung nicht um eine Notfall-CR handelt, die manuell genehmigt wird.
Der Ablauf der Build-Pipeline im Falle einer gefundenen Sicherheitslücke und die entsprechenden Benutzeraktionen werden im folgenden Diagramm erläutert.
Anwendungsfall 2: Im Build gefundene Sicherheitslücke, die sich auch in der Produktion befindet
Der neue Build enthält eine Sicherheitslücke, die sich auch in der derzeit implementierten Produktion befindet. Teams verfügen über einen Zeitplan, um das Problem zu beheben, aber neue Funktionen oder Fixes können weiterhin implementiert werden.
Die CC-Pipeline legt den Zeitplan fest, um solche Schwachstellen zu beheben, die in der Produktion gefunden wurden. Es schlägt nur fehl, wenn die Zeitachse zur Behebung der Sicherheitslücke abgelaufen ist. Der Ablauf ist im folgenden Diagramm skizziert.
Anwendungsfall 2A:-Sicherheitslücke, die in der Produktion gefunden wird, ermöglicht Bedarfsanforderungen
Die Sicherheitslücke in der Produktion verhindert nicht, dass Bedarfsanforderungen zusammengeführt werden.
Anwendungsfall 3: Fehlalarme und Ausnahmen
Wenn das Team ein Problem als „False Positive“ einstuft oder eine Sicherheitsausnahme für eine Schwachstelle erhält, kann das Problem als „Ausgenommen“ gekennzeichnet werden. Das Problem kann dann als nicht blockierendes Problem behandelt werden. Um ein Prüfprotokoll zu verwalten, halten Änderungsanforderungen die Probleme sichtbar.
Anwendungsfall 4: Behoben von Problemen automatisch schließen
Durch regelmäßiges Ausführen der CC-Pipeline können offene Probleme geschlossen und ein Fälligkeitsdatum festgelegt werden. Außerdem kann die relevante Schwachstelle nicht in Scans gefunden werden.
Im folgenden Diagramm wird das Ablaufdiagramm der CC-Pipeline erläutert, die erkennt, welche Probleme geschlossen werden müssen und welche Probleme neu erstellt werden müssen.
Verwaltung von Fristen für Vorfälle
Wenn in der Produktion Fehler festgestellt werden, wird automatisch die Eigenschaft „ Due Date “ hinzugefügt, um die Frist anzugeben, innerhalb derer der Fehler behoben werden muss. Die Dauer der Karenzzeit wird durch den Schweregrad
der gefundenen Sicherheitslücke bestimmt.
Häufige Szenarien für Fälligkeitstermine
Die folgenden Szenarien beschreiben, wie Fälligkeitstermine verwaltet werden:
- Anfängliche Zuweisung eines Fälligkeitstermins: Wenn die CC-Pipeline ein Problem in der Produktion feststellt, berechnet sie automatisch einen Fälligkeitstermin auf der Grundlage des Schweregrads des Problems und legt diesen fest.
- Fristverlängerung: Wenn Sie mehr Zeit benötigen, um ein Problem zu beheben, können Sie die Frist verlängern, nachdem Sie die Genehmigung eines Sicherheitsbeauftragten eingeholt haben. Weitere Informationen finden Sie unter „ Verschiebung des Fälligkeitstermins “.
- Überfällige Issues: Selbst wenn Issues überfällig werden, können CI-Pipelines die Bereitstellungen fortsetzen, solange der neue Build die Produktionsumgebung nicht beeinträchtigt (reiner Risikomanagement-Ansatz). Auf diese Weise können Teams weiterhin Funktionen bereitstellen, während sie gleichzeitig an der Behebung von Sicherheitsproblemen arbeiten.
Weitere Informationen zum Anpassen der Karenzzeiten finden Sie unter Angepasste Karenzzeiten in der CC-Pipeline konfigurieren.
Vorfallprobleme kennzeichnen
Vorfallprobleme, die von den Pipelines für kontinuierliche Integration (CI) oder kontinuierliche Konformität (CC) erstellt werden, können Standardbezeichnungen haben.
Bezeichnungen für Vorfallprobleme, die von Code Risk Analyzer erkannt wurden
Code Risk Analyzer (CRA) erkennt mehrere Arten von Schwachstellen, wie z. B. App-Abhängigkeit und Image-Schwachstellen.
Der Typ der Sicherheitslücke kann name os, python, js, golang oder java sein.
Wenn der Typ der Sicherheitslücke os ist, wird dem Problem die Bezeichnung os-vulnerability zugeordnet. Bei allen anderen Arten von Sicherheitslücken wird dem Problem die Bezeichnung app-vulnerability zugeordnet.
Bezeichnungen für Vorfallprobleme mit verfügbaren Fixes
Bei Vorfallproblemen, die von der Pipeline für kontinuierliche Integration (CI) oder der Pipeline für kontinuierliche Konformität (CC) erstellt werden, enthält der Scanner möglicherweise Korrekturinformationen als Teil des Scanergebnisses.
Wenn Korrekturinformationen verfügbar sind, wird dem Vorfallproblem eine Bezeichnung fix-available mit einem Link zur Korrekturbeschreibung in der Problembeschreibung hinzugefügt.
Das Fehlen der Bezeichnung fix-available bedeutet nicht, dass das Problem nicht umsetzbar ist, da nicht jeder Scanner die Fixinformationen im Scanergebnis enthält. Der Scanner schlägt die Fixinformationen vor und diese Informationen
stammen von allen Quellen, aus denen der Scanner diese "Fixdaten" bezieht. Einige Scanner verfügen möglicherweise nicht über aktuelle Fixwörterbücher oder enthalten keine Informationen zu einem Fix.
Vorfallprobleme mit Fälligkeitsdatum
Wenn Sie das Script collect-evidence verwenden, werden Vorfallprobleme erstellt und an die erfassten Angaben angehängt. Wenn Probleme in der Produktion gefunden werden, können sie einen bestimmten Zeitraum haben, in dem sie behoben werden müssen, damit Implementierungen nicht blockiert werden. Der Zeitrahmen zur Behebung des Problems in der Produktion wird als _Karenzzeit_bezeichnet. Zur besseren Lesbarkeit ist Fälligkeitsdatum jedoch jetzt in Vorfallproblemen verfügbar, sodass Benutzer das Datum kennen, an dem der Fix fällig ist, ohne ihn anhand der Karenzzeit zu berechnen.
Wenn ein Problem wie eine Sicherheitslücke oder CVE in der Produktion gefunden wird und dasselbe Problem auch in einem Build gefunden wird, wird die Situation durch den Build nicht schlechter. Das Feature kann implementiert werden und das Team kann sich auf die Behebung des Problems in der Produktion konzentrieren.
Angepasste Karenzzeiten für die CC-Pipeline konfigurieren
Die CC-Pipeline (Continuous Compliance) berechnet die Fälligkeitstermine von Vorfallproblemen auf der Basis des Schweregrads eines Problems. Sie können die Standardwerte für die Karenzzeit ändern und durch benutzerdefinierte Werte ersetzen.
Die Pipeline berechnet die Karenzzeit gemäß der folgenden Tabelle:
| Wertigkeit | Frist |
|---|---|
| Information | 180 Tage |
| Niedrig | 180 Tage |
| Mittel | 90 Tage |
| Hoch | 30 Tage |
| Kritisch | 30 Tage |
Erstellen Sie zum Ändern der Standardkonfiguration eine neue Eigenschaft in den Umgebungseigenschaften der CC-Pipeline mit dem Namen grace-period-configuration. Diese Umgebungseigenschaft muss eine JSON-Zeichenfolge sein und dem
folgenden Format entsprechen:
{
"informational": 50,
"low": 40,
"medium": 30,
"high": 20,
"critical": 10
}
Wenn die Umgebungseigenschaft nicht mit dem erwarteten Format übereinstimmt oder keine gültige JSON-Zeichenfolge ist, verwendet die Pipeline die Standardwerte.
Die Umgebungseigenschaft grace-period-configuration legt Fälligkeitsdaten für Probleme fest, für die noch kein Fälligkeitsdatum festgelegt ist. Bei Problemen, für die ein Fälligkeitsdatum festgelegt ist, werden diese Fälligkeitsdaten
durch die Neukonfiguration von grace-period-configuration nicht aktualisiert.
Berechnung des Fälligkeitsdatums
Das Datum des Findens ist der Zeitpunkt, an dem die CC-Pipeline (CC = Continuous Compliance) ausgeführt wird und das Problem in der Produktionsumgebung findet. Wenn das Problem besteht, aktualisiert CC es mit dem Fälligkeitsdatum , das ab diesem Zeitpunkt berechnet wird.
<due date> = <date of finding the issue in prod> + <grace period in days (determined by severity)>
Format des Fälligkeitsdatums
Das Fälligkeitsdatum hat das Format ISO 8601 und wird als JJJJ-MM-TT angezeigt.
Beispiel: Due Date: 2022-04-01
Anwendungsfälle
-
Die CC-Pipeline hat in einem der Basisimages in der Produktion eine Sicherheitslücke gefunden. Das Team wird über ein Vorfallproblem mit einer Karenzzeit benachrichtigt, die dem Schweregrad der Sicherheitslücke entspricht. Die Karenzzeit ist die Anzahl der Tage, die das Team einen Fix implementieren muss.
-
Das Team erstellt ein neues Release mit einer neuen Funktion. Der Build sucht ein CVE, das dem Basisimage zugeordnet ist, das für die Anwendung verwendet wird. Das Team führt die CC-Pipeline manuell durch, die bereits in der Produktion befindliche Artefakte scannt. Bei der manuellen CC-Ausführung wird dieselbe CVE in derselben Anwendung in der Produktion erkannt und die Nachfrist zum Vorfallproblem hinzugefügt. Das Team kann jetzt erstellen und implementieren, ohne blockiert zu werden.
Unterschiede zwischen Problemverarbeitung in CI-und CC-Pipelines
Vorfallprobleme werden sowohl in CI-als auch in CC-Pipelines erstellt:
- Ein in CI erstelltes Problem bedeutet, dass es während des Builds gefunden wurde.
- Ein in CC erstelltes Problem bedeutet, dass es in der Produktionsumgebung gefunden wurde.
Ein Fälligkeitsdatum kann nur dann automatisch zu Problemen hinzugefügt werden, wenn sie mit Problemen in der Produktionsumgebung in Zusammenhang stehen. Dies bedeutet, dass nur die CC-Pipeline das Fälligkeitsdatum zu einem Problem hinzufügen kann. Wenn das CI das Problem findet und das Fälligkeitsdatum nicht verfügbar ist, ist der Wert des Fälligkeitsdatums Nicht zutreffend.
Ergebnisse in Probleme verarbeiten
Probleme für gefundene Probleme werden entsprechend den Ergebnissen bestimmter Tools erstellt. Das Script collect-evidence versucht, die Ergebnisdateien in den Anhängen zu verarbeiten und eine Liste mit Problemen erstellen.
Probleme sind an Assets gebunden, bei denen es sich um Festschreibungen in einem Repository oder einem Docker-Image mit einem Digest handeln kann.
Für jede Problem-ID wird ein Problem erstellt-eine Problem-ID besteht aus den folgenden Komponenten:
- Gebundenes Asset
- Das Tool, das die Sicherheitslücke gefunden hat
- Die Sicherheitslücken-ID (z. B. die CVE-ID).
Wenn beispielsweise CVE-2022-001 von zwei separaten Tools gefunden wird, erstellt der Prozess heute zwei Probleme.
Unterstützte Tools
Die Bearbeitung von Vorfällen unterstützt Ergebnisse aus verschiedenen Scan-Tools, die in die Pipelines von „ DevSecOps “ integriert sind. Eine aktuelle Liste der unterstützten Scan-Tools und ihrer Funktionen finden Sie unter „ Unterstützte Scan-Tools “.
Nicht unterstützte Tools oder Ergebnisformate
Wenn das Script collect-evidence einen Anhang von einem nicht unterstützten Tool empfängt oder das Format der Ergebnisdatei während der Verarbeitung nicht erkannt wird, überspringt das Script das Erstellen von Problemen und
verwendet die Ergebnisdatei als einfachen Anhang zu den Angaben.
Inhalt ausgeben
- Problem ist der Name des Problems oder der Sicherheitslücke.
- Fälligkeitsdatum zeigt das Datum an, an dem der Fix fällig ist, oder Nicht zutreffend, wenn kein Fälligkeitsdatum verfügbar ist.
- Subject ist das Asset, an das das Problem gebunden ist.
- URL ist der Link zu der genauen Version des Assets.
- Tooltyp ist das Tool, das den Inhalt des Problems erzeugt hat.
Für Ausgaben, die auf Git Repos and Issue Tracking erstellt werden, wird das Fälligkeitsdatum im Feld GitLab natives Fälligkeitsdatum anstelle der Ausgabenbeschreibung festgelegt.
Die Problembeschreibung enthält die Zeitmarke, zu der das Problem zum ersten Mal erkannt wurde. Beispiel: First found on 2022-04-07. Das Datum hat das Format YYYY-MM-DD. Die Positionen, an denen das Problem auftritt,
sind in den Kommentaren des Problems aufgelistet.
Verlängerung der Frist für die Behebung eines Vorfalls
Sie können die Frist für einen Vorfall verlängern, wenn zusätzliche Zeit für die Umsetzung einer Lösung benötigt wird. Hierfür ist die Genehmigung durch einen Sicherheitsbeauftragten erforderlich, um eine ordnungsgemäße Überwachung von Sicherheitslücken zu gewährleisten.
Verfahren zur Verlängerung von Fristen
- Bitten Sie Ihren Sicherheitsbeauftragten um eine Stellungnahme, in der Sie darlegen, warum die Verlängerung erforderlich ist.
- Nachdem Sie die Genehmigung erhalten haben, aktualisieren Sie das Fälligkeitsdatum:
- Für „ Git Repos and Issue Tracking “: Ändern Sie das Feld „
Due date“ in den Metadaten des Vorfalls. - Für „ GitHub Enterprise “: Bearbeiten Sie das Feld „
Due date“ in der Beschreibung des Issues.
- Für „ Git Repos and Issue Tracking “: Ändern Sie das Feld „
- Verweisen Sie auf die Genehmigung des Sicherheitsbeauftragten in diesem Fall, indem Sie einen Kommentar mit einem Link zu den Prüfungs- oder Genehmigungsunterlagen hinzufügen.
Stellen Sie sicher, dass Sie in der Ausgabe auf den Sicherheitsschwerpunkt verweisen, z. B. indem Sie in einem Kommentar einen Link dazu angeben.
Sicherheitsausnahmen
Sollten Sie ein Problem mit einer Sicherheitsausnahme haben, können Sie die Frist so verlängern, dass sie mit dem Ablaufdatum der Ausnahme übereinstimmt. Dadurch wird sichergestellt, dass die Erfassung von Nachweisen und die Nachverfolgung der Einhaltung der Vorschriften ordnungsgemäß fortgesetzt werden, bis die Ausnahmeregelung ausläuft.
Slack-Alerts für ausstehende und überfällige Probleme für CC-Pipeline
Die CC-Pipeline (Continuous Compliance) kann Fälligkeitstermine für die Vorfallprobleme festlegen. Die Pipeline kann Benutzer auch über Probleme benachrichtigen, die sich einem Fälligkeitsdatum und einem überfälligen Fälligkeitsdatum nähern, wenn die Slack-Integration aktiviert ist.
Weitere Informationen finden Sie unter Toolchain für kontinuierliche Integration einrichten. Weitere Informationen zu Fälligkeitsterminen finden Sie unter [Incident issues with due date](/docs/devsecops? topic = devsecops-incident-issues#devsecops-devsecops-issues-due-date.
Die gemeldeten Probleme werden wie folgt klassifiziert:
- Probleme mit ausstehenden Fälligkeitsterminen innerhalb eines bestimmten Zeitrahmens: Probleme, die offen sind, Fälligkeitstermine haben und innerhalb eines Zeitrahmens fällig sind
- Probleme mit vergangenem Fälligkeitsdatum: offene Probleme mit Fälligkeitsdatum und vergangenem Datum.
Die Zeitrahmendauer ist overdue, due in 1 day, due in 2 days, due in 5 days und due in 10 days.
Es folgt ein Beispiel für diese Funktion:
Overdue issues:
- <issue url#1>
- <issue url#2>
- <issue url#3>
Issues due in 1 day:
- <issue url#4>
Issues due in 2 days:
- <issue url#5>
Issues due in 5 days:
- <issue url#6>
- <issue url#7>
Issues due in 10 days
- <issue url#8>
- <issue url#9>
- <issue url#10>
- <issue url#11>
- <issue url#12>
Die aggregierte Liste wird mit den Problemen sortiert, die zuerst überfällig sind. Die Probleme mit den nächsten Fälligkeitsdaten werden vor denen mit einem späteren Fälligkeitsdatum aufgelistet.
Die Stufe cc-finish in der CC-Pipeline fragt die Probleme basierend auf den Kriterien ab und löst einen Slack-Alert aus.