# 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.
