[Epic] Dependency-Track (SBoM)

Warum?

Für eine dauerhafte, stetige Analyse der im Projekt eingesetzten Bibliotheken auf bekannte Schwachstellen braucht es automatisierte Maßnahmen zur Überwachung der eingesetzten Bibliotheken, z.B. so etwas wie https://dependencytrack.org/.

Relevante Links und Bemerkungen

• Dokumentation zum Umgang mit CVEs: https://git.fitko.de/fit-connect/entwicklungshandbuch/-/blob/main/cve-handling.adoc
• Aktuelles Vorgehen: https://wiki.fit-connect.fitko.dev/de/dev/dependency-management
• Wir nutzen schon https://github.com/aquasecurity/trivy und https://github.com/hadolint/hadolint für Docker-Images
  • siehe https://codecentric.slack.com/archives/C01TW631805/p1649761089772619
• Offene MRs zur Konfiguration von Renovate: https://git.fitko.de/groups/fit-connect/-/merge_requests?scope=all&state=opened&search=%22Configure+Renovate%22
• Dependency Track: https://dtrack.fit-connect.dev/

Informationsquellen

• Talk: "Dependency-Management für faule Software-Entwickler" auf der GPN20
• Blog-Artikel zum Thema
  • https://medium.com/zoom-techblog/continuous-security-using-owasp-feeda9571384
  • https://grudgets.com/programming/find-vulnerabilities-in-java-dependencies/
  • https://jonas-havers.de/articles/how-to-check-your-java-dependencies-for-owasp-vulnerabilities-and-security-issues/
• What is VEX and What Does it Have to Do with SBOMs?
  • A Deeper Dive into VEX Documents

Tools

• https://dependencytrack.org/
• https://docs.gitlab.com/ee/user/application_security/dependency_scanning/
• https://github.com/renovatebot/renovate
• https://github.com/quay/clair
• https://scancode-toolkit.readthedocs.io/
• https://www.blackducksoftware.com/
• https://www.greenbone.net/
• https://openvas.org/
• https://wid.cert-bund.de/portal/wid/csaf

Etablierte SBoM-Formate

• Software Package Data eXchange (SPDX)
• CycloneDX
• Software Identification (SWID) Tags

Akzeptanzkriterien

1. Es besteht ein Überblick über alle eingesetzten Bibliotheken in Form eines Software Bill of Materials (SBOM) in einem etablierten SBoM-Format (z.B. CycloneDX) inkl. Informationen zu bekannten CVEs.
2. Das SBOM erfüllt die Anforderungen aus BSI TR-03183-2: Cyber-Resilienz-Anforderungen an Hersteller und Produkte - Teil 2: Software Bill of Materials (SBOM)
3. Benachrichtigung der jeweiligen zuständigen (Komponenten) Teams (z.B. mittels Matrix-Bot (oder MS Teams Integration))
4. Es werden automatisierte Merge-Request bei neuen Dependency-Versionen erstellt.
5. Die Lösung ist wiederverwendbar für verschiedene Repos (Pipeline-Templates!)
6. Die Lösung erfasst auch JS-Dependencies des Self-Service-Portals
7. Lösung ist für alle Software-Artefakte umgesetzt
   • Self-Service-Portal
   • OAuth-Dienst (Überwachung der Versionssnummer des Connect2ID-Servers an sich ist ausreichend) -> #417
   • Token Validator
   • Zustelldienst
   • Routingdienst
   • fitconnect-tools (python)
   • SDKs
   • Entwicklungsportal
   • Alle Docusaurus-Instanzen + im Docusaurus-template (siehe #406 (closed))
8. Die Nutzung der Lösung ist im Betriebshandbuch ( #157) dokumentiert.
9. Umgebungen im Dashboard sind mit jeweiligen Komponentenversionen dargetellt

Durchführungsplan (vom Entwickler bei Storyplanung auszufüllen)

1. Talk: "Dependency-Management für faule Software-Entwickler" auf der GPN20 schauen
2. Neue Kriterien sammeln die erfüllt werden müssen
3. Prüfen welche Kriterien Dependency Track abdecken kann
4. Tools für Kriterien evalueieren, die nicht von DT abgedeckt werden
5. Dependency Track konfigurieren
6. Alternative Tools konfigurieren
7. Testing
8. Abnahme
9. Definition of Done wurde geprüft