Skip to content

Trivy-Scan in Scan-Pipeline statt Build-Pipeline

Warum?

Grundsätzlich möchten wir Software ausliefern und betreiben, die keine Sicherheitslücken hat. Projekte, bei denen länger keine Codeänderung stattgefunden hat (OAuth-Server etc.), könnten zwischenzeitlich bekannte CVEs enthalten, ohne dass wir darüber informiert sind.

Relevante Links und Bemerkungen

  • Der Trivy-Scan sollte zusätzlich für alle deployten Versionen (Tags/Branches) in täglichen CVE-Pipelines (Trivy) ausgeführt werden.
  • Der Trivy-Scan soll weiterhin in den Build-Pipelines des jeweiligen main-Branches, sowie in jedem Pull-Request auf den main-Branch ausgeführt werden.
  • Der Trivy-Scan soll auf allen anderen Branches per Default nicht ausgeführt werden.
  • CVEs, die über die .trivyignore ausgenommen sind, sollen weiterhin ignoriert werden.
  • Jede Komponente sollte das Dateisystem des Repos scannen und wenn möglich auch das Image.
  • Das Team sollte darüber in Kenntnis gesetzt werden, wenn ein neues CVE im Scan erkannt wird.

Liste zu scannender Komponenten/Repos:

  • oauth-server
  • entwicklungsportal (included trivy aber nutzt es nicht)
  • token-validator
  • fake-dvdv
  • self-service-portal
  • self-service-portal-frontend
  • zustelldienst
  • sdk-* (aktuell mind. Java)

Ausgeschlossene Repos (die aktuell den Trivy Scan nutzen):

  • fit-connect-monorepo/self-service-portal → weil noch unklar ist, in wie fern das Monorepo Projekt fortgeführt wird.
  • static-assets → wird bald wegfallen (#538 (closed))

Akzeptanzkriterien

  1. Potentiell relevante CVEs werden zeitnah nach Bekanntmachung entdeckt (es gibt Pipelines die fehlschlagen, wenn ein neues CVE erkannt wird).
  • Potentiell relevant, da nicht alle CVEs im kritischen Pfad liegen und evtl. ignoriert werden könnten.
  • Entdeckt: Team ist darüber informiert ist (z.B. über Benachrichtigung).
  • Zeitnah: 1 Tag
  1. Es gibt eine Policy (baw. im "onboarding" Guide niedergelegt), welche beschreibt, wie mit .trivyignore-Konfigurationen umzugehen ist, z.B.
  • Ignores werden regelmäßig (einmal im Monat) einem Review unterzogen, ob sie weiterhin relevant sind bzw. ob sie weiterhin ignoriert werden können.
  • Für jedes neue Ignore wird dokumentiert, warum es ignoriert werden kann. Dabei ist ein 4-Augen-Prinzip sicherzustellen, bei der zwei Personen gemeinsam über die Irrelevanz entscheiden. Die Dokumentation ist versioniert (kann baw. über Kommentare in .trivyignore erfolgen). Die Dokumentation enthält, welche Personen die Entscheidung getroffen haben.
  • Das Ignorieren von Incidents ab einer bestimmten Severity wird mit IT Security abgestimmt.
  1. Es gibt eine Policy (baw. im "onboarding" Guide niedergelegt), welche beschreibt, wie mit neuen Incidents umzugehen ist, z.B.
  • Incidents eines deployten Branches (Test, Stage, Produktion) sind je nach Severity (Abstimmung mit IT Security) innerhalb einer festen Frist zu lösen bzw. zu ignorieren (s.o.).
  • Incidents, die in einem MR oder auf dem jeweiligen main-Branch gefunden werden, sind unmittelbar zu lösen.

Durchführungsplan (von Entwickler:in bei Umsetzungsplanung auszufüllen)

zentraler Scan:

Ergebnisse der ersten Scans

  • Ergebnisse der ersten Scans sammeln → #755 (comment 73804)
  • Klären, ob je Finding ein Issue eröffnet werden soll → ist einer der nächsten Schritte

Scan in einzelnen Repos aktualisieren oder einbauen:

Dokumentation erstellen:

Definition of Done

Edited by Christoph Metzger