Orchestrator/bahn/Analyse-O2C-C2S/sources/c2s/C2S-UjKonstruktion/teams/Security-Prozess-in-Team-Ains.md

Security-Prozess in Team Ains

Version: 11 | Last modified: 2026-04-22T15:25:57.763+02:00 Source: confluence page ID 503110205

---

EinleitungDie Anwendungen von Team Ains müssen regelmäßig auf Schwachstellen und Secrets geprüft und von diesen bereinigt werden. Dazu gibt es für jede Iteration eine Blocker-Story "Security-Blocker" (Beispiel). Hier wird der Prozess dazu beschrieben. Die Umsetzung wird von der Rolle des Security-Beauftragten im Team Ains koordiniert, welche wie in der Liste der Security-Beauftragten - C2S | Uj Konstruktion - ariJa Confluence hinterlegt rotierend vergeben wird. Die Prüfung erfolgt regelmäßig, insbesondere zu jedem Iterationsende. Dafür gibt es die Unteraufgabe "Security-Prüfungen" im Security-Blocker. Die Unteraufgabe der aktuellen Iteration muss immer in Arbeit und einer Person zugewiesen sein, normalerweise dem aktuellen Security-Beauftragten. Im morgendlichen Daily wird sichergestellt, dass die zugewiesene Person anwesend ist und ggf. übergangsweise eine neue Person zugewiesen (bspw. im Krankheitsfall). Die Findings werden im Rahmen der Prüfung direkt gefixt oder als Unteraufgaben im Blocker erfasst. Generell müssen Schwachstellen gefunden und im aktuellen Codestand gefixt werden. Anschließend muss darauf ein Release gebaut werden und dieses auf allen Umgebungen deployt werden, damit die Schwachstellen komplett entfernt sind. Daraus ergeben sich folgende Prüfpunkte: Alle Schwachstellen müssen im aktuellen Codestand gefixt sein. Alle diese Schwachstellenfixes müssen im aktuellen (letzten) Release enthalten sein. Auf allen Umgebungen muss ein Release mit diesen Fixes deployt sein (im Zweifelsfall das aktuelle Release). Durchführung der Schwachstellen-PrüfungAktueller CodestandZentrales Tool zur Prüfung des aktuellen Codestands ist PSMT (ehemals "Defect Dojo"). Hierin müssen die aktuellen Findings analysiert werden. Auf befinden sich in der PSMT-Spalte Links auf die Findings je Service mit passendem Filter. Diese Findings sind als relevant einzustufen. Beachte: Für die KapaS-Anwendungen brauchen wir einen speziellen Filter und können nicht einfach nur die "View Active Findings" betrachten. Das liegt daran, dass Findings über die KapaS-Services hinweg auf Duplicate geprüft werden, obwohl sie einzeln zu behandeln sind. Daher werden Findings immer wieder als "Duplicate" und damit "Inactive" markiert, obwohl sie für den jeweiligen Service relevant sind. ReleaseWir lassen diese Prüfung aktuell weg, da Releases normalerweise ohnehin zeitnah deployt werden (siehe ). DeploymentsPrüfung ifp-prodEs laufen regelmäßig Trivy-Scans, die laufende Container auf Schwachstellen prüfen. Die Ergebnisse sind in Grafana einsehbar, für ifp-prod etwa auf diesem Dashboard: https://grafana-v2.cnp.comp.db.de/d/ee86e7da-f001-4b56-b1f8-21dd036cc7f0/vulnerabilities-by-service?orgId=43 (alternativ sind die Links auf das Dashboard in der Trivy-Scans-Spalte auf bereits für den jeweiligen Service parametrisiert). Hier ist zu prüfen, ob es Findings gibt, die in PSMT nicht auftauchen, da diese auch relevant zu fixen sind. Beachte: Gelegentlich setzen wir Findings in PSMT auf "False Positive" oder "Risk accepted". Bei den Trivy-Scans haben wir keine Möglichkeit, eine Ignore-List zu pflegen. Daher sind dort nur Findings relevant, die nicht in PSMT unter diesen beiden Status hinterlegt sind. "Mitigated" Findings in PSMT sollten hier aber sehr wohl als relevant eingestuft werden, da sie unter Umständen bisher noch nicht im aktuellen Produktionsrelease gefixt sind. Prüfung weiterer UmgebungenWenn ifp-prod und der aktuelle Codestand geprüft wurde, ist im wesentlichen nur sicherzustellen, dass auch alle anderen Umgebungen analog zu ifp-prod den aktuellsten Stand und alle Fixes bekommen. Einfache Variante: Prüfung der Release-Stände mit dem QS-Dashboard. Hier werden die aktuellen Versionen je Umgebung angezeigt, allerdings nur mit leichter zeitlicher Verzögerung. Wenn Versionen auf Umgebungen niedriger als auf ifp-prod sind, ist das normalerweise als relevantes Finding zu erfassen, soweit noch nicht erfolgt. Wenn Versionen mit ifp-prod übereinstimmen, sind sie analog zu ifp-prod zu behandeln, weil es sich um dasselbe Artefakt handeln sollte. Wenn Versionen höher als ifp-prod sind, sollte sowieso bald die neueste Version auf ifp-prod eingespielt werden, dann kann die Prüfung wiederholt werden.

Komplizierte Variante 1: Da das QS-Dashboard nicht immer aktuell ist, kann man auch die Kubernetes-Deployments durchgehen (bspw. mit kubectl) und dort die Versionsstände analog mit ifp-prod vergleichen. Komplizierte Variante 2: Auch für alle non-prod-Umgebungen gibt es Trivy-Scans mit zugehörigen Grafana-Dashboards, die analog zu Prüfung ifp-prod geprüft werden können. Beachte: Versionsunterschiede kommen typischerweise dadurch zustande, dass gerade ein Release-Prozess im Gange ist (insbesondere bei TTT-Umgebungen ist das langwierig) oder weil schlichtweg vergessen wurde auf allen Umgebungen zu deployen. Behandeln relevanter Schwachstellen-FindingsJira-PflegeUm die Prüfung abzuschließen, müssen nur Jira-Unteraufgaben in dem Security-Blocker (bzw. am Iterationsende bestenfalls schon direkt in dem Blocker der Folgeiteration) angelegt werden. Ähnliche Findings können auch über Services hinweg zu einer Unteraufgabe zusammengefasst werden. Wenn in Deployments Findings auftreten, sollte hier typischerweise die passende Unteraufgabe sein, Releases in den betroffenen Umgebungen einzuspielen, sobald der aktuelle Codestand gefixt und releast ist. Beispiel: Wenn in BBOA und KapaService je zwei Findings CVE-123-456 in der Bibliothek my-java-tools-common und CVE-123-456 in my-java-tools-special auftauchen, kann eine Unteraufgabe "Fix CVE-123-456 in BBOA und KapaService" angelegt werden, da die Findings vermutlich zusammen gefixt werden können. Wenn auf Produktion Findings in KapaService 1.2.3 erfasst werden, kann eine Unteraufgabe "Release KapaService 1.2.4" angelegt werden mit Beschreibung "Wenn CVE-123-456 gefixt ist, muss ein neues Release auf allen Umgebungen eingespielt werden." PSMT-PflegeSofern die Jira-Tickets nicht direkt behoben werden, gilt für PSMT im Zweifelsfall der in https://arija-confluence.jaas.service.deutschebahn.com/spaces/C2SUJK/pages/386397346/Leitfaden+zum+Umgang+mit+DefectDojo beschriebene Prozess. Für weiteren Information zu Umgang mit dem Finding's in PSMT gehe zu [DRAFT] So you've got CVEs in your services. - C2S | Uj Konstruktion - ariJa Confluence  FristenDie Behebungsfristen orientieren sich an der Kritikalität der Schwachstelle. Mit welchem Tool und wann die Schwachstelle gefunden wird, ist dafür irrelevant; die Frist beginnt mit bekanntwerden eines Fixes durch den Hersteller. Das heißt, die Frist beginnt nicht erst, wenn wir durch einen Scan herausgefunden haben, dass die Schwachstelle bei uns vorhanden ist! Gemäß der DB Richtlinie 114.0240A03 - gültig seit Mitte Juli 2019 - gelten die folgenden Behebungsfristen: Kategorisierung | "CVSS Base" Wert | Microsoft CVE-Score | Behebungsfrist | Kritische Schwachstelle | von 9 bis 10 | 0 | 48 Stunden bei Schwachstellen auf Systemen und Anwendungen, die aus Internet erreichbar sind 14 Kalendertage, wenn die Schwachstelle nicht Internet-exponiert ist | Hohe Schwachstelle | von 7 bis <9 | 1 | Mittlere Schwachstelle | von 4 bis <7 | 2 | 30 Kalendertage | Niedrige Schwachstelle | von 0 bis <4 | 3 | 90 Kalendertage |

Quelle: https://dbsystel.wiki.intranet.deutschebahn.com/wiki/display/secops/4-Schwachstellenmanagement  Secret FindingsAufgrund noch ausstehender Aufräum-Arbeiten an Gitlab-Repos und -Rechten sowie DXP-Anbindungen an DefectDojo ist die Source of Truth für Secret-Findings aktuell noch DXP. Dabei werden unter Umständen auch Findings angezeigt werden, für die unser Team nicht verantwortlich ist. Das Bearbeiten von Secret Findings ist auf der DXP-Dokumentation oder der Security-Seite des Arts gut beschrieben.