SBOM-Befunde lesen: OWASP Dependency-Track

Diese Anleitung verbindet OWASP Dependency-Track, damit kanman die Schwachstellen und Richtlinienverstöße liest, die es in deinen SBOMs findet, und darauf reagiert wie auf jeden anderen öffentlichen Sicherheitshinweis.

Standardmäßig liest kanman Dependency-Track nur. Es ändert nie eine Analyse, unterdrückt nie einen Befund und lädt SBOMs nur hoch, wenn ein Admin das an der Verbindung erlaubt hat und ein Team es gewählt hat.

Für Schritt 1 bist du Owner oder Admin des Workspace, für die Schritte 2 und 3 Lead des Teams (oder Owner oder Admin des Workspace). Alle Mitglieder sehen die Zuordnungen und die Karten.

1. Dependency-Track verbinden (einmal pro Workspace)

1. Öffne die Workspace-Einstellungen, wähle Verbindungen und öffne OWASP Dependency-Track.
2. Gib ein:
   • die Adresse deines Dependency-Track-API-Servers, zum Beispiel https://dependency-track.example.com
   • von wo kanman ihn erreicht: kanmans Cloud oder dein Runner (in deinem Netzwerk), wenn der Server nur im Firmennetz erreichbar ist. Dann liest dein selbst gehosteter Runner Dependency-Track, und kanmans Cloud verbindet sich nie damit.
   • wie sich kanman anmeldet: mit einem Token oder mit einer Variable auf dem Runner
   • den Secret-Namen, unter dem der API-Key liegt, zum Beispiel DTRACK_API_KEY
3. Hinterlege den API-Key auf eine von zwei Arten:
   • Einmal eingeben. kanman speichert ihn verschlüsselt als Workspace-Secret unter diesem Namen und zeigt ihn nie wieder.
   • Auf deinen Runnern setzen. Setz stattdessen eine Variable mit diesem Namen in der Umgebung des Runners oder des Teams. Dann sieht kanman ihn nie.
4. Leg den API-Key in Dependency-Track unter Administration > Access Management > Teams für ein Team mit den Rechten VIEW_PORTFOLIO und VIEW_VULNERABILITY an (dazu VIEW_POLICY_VIOLATION für Richtlinienverstöße und BOM_UPLOAD nur, wenn du Uploads willst).
5. Lass SBOM-Uploads auf Aus (nur lesen) oder wähle Erlaubt für Teams, die es wählen.
6. Klick auf Verbindung testen. kanman prüft, dass die Adresse als Dependency-Track-Server antwortet und der Key das Portfolio lesen darf.

2. Bestätigen, welche Projekte zu deinem Team gehören

Sobald die Verbindung steht, vergleicht kanman die Dependency-Track-Projekte mit den Repositories jedes Teams (Projektnamen, Versionen und die Package-URLs ihrer Komponenten mit dem, wovon jedes Repository abhängt) und schlägt die Projekte vor, bei denen es sich sicher ist. Die Leads des Teams erfahren es einmal im Team-Chat.

1. Öffne die Team-Einstellungen des Teams, wähle Verbindungen und öffne Dependency-Track.
2. Unter Projekte, die ich vorschlage zeigt jeder Vorschlag das Projekt, das Repository und warum kanman sie zusammengehörig findet.
3. Korrigier bei Bedarf das Repository und klick auf Bestätigen oder auf Nicht dieses. Ein abgelehntes Projekt schlägt kanman nie wieder vor; bitte kanman im Chat, wenn du es später doch zuordnen willst.

Bestätigte Projekte zeigen, wie viele offene Befunde das letzte Lesen gefunden hat und wann. Mit Vergessen hört kanman auf, ein Projekt zu lesen. Ein Projekt erscheint außerdem auf der Seite des Service, zu dem es gehört, unter Was ich für diesen Service lese, wo Leads es ebenfalls vergessen können.

3. Wählen, wie SBOMs dorthin kommen

Auf derselben Seite:

• Nur Befunde lesen (Standard): kanman liest, was Dependency-Track schon weiß.
• CI-Job pro Repository (empfohlen): kanman schlägt pro Repository eine Story vor, die einen CI-Job ergänzt, der bei jeder Änderung des Standard-Branches ein CycloneDX-SBOM an das Projekt sendet. Der API-Key kommt aus einer maskierten CI-Variable, die dein Team setzt, nie aus dem Repository.
• Ich lade SBOMs hoch: kanman baut ein SBOM aus den Abhängigkeiten, die es scannt, und lädt es hoch, sobald sie sich ändern. Diese Option erscheint nur, wenn ein Admin Uploads an der Verbindung erlaubt hat.

Richtlinienverstöße als Befunde (standardmäßig an) macht Verstöße gegen Lizenz- und Versionsrichtlinien zu Karten auf dem Board deines Teams.

Was kanman mit den Befunden macht

• Eine Karte pro Sicherheitshinweis. Etwa stündlich liest kanman jedes bestätigte Projekt. Seine Schwachstellen fließen als zusätzliche Quelle neben OSV.dev in die Beobachtung der Sicherheitshinweise ein: Dieselbe CVE oder GHSA wird eine Karte für alle betroffenen Repositories, nie zwei.
• Die Analyse deines Teams zählt. Ein Befund, den dein Team in Dependency-Track als Not affected oder False positive markiert oder dort unterdrückt hat, wird nie zur Karte. Ist schon eine Karte offen, wandert sie mit diesem Grund nach Erledigt.
• Richtlinienverstöße werden Karten mit Richtlinie, Komponente und Projekt. Meldet Dependency-Track einen Verstoß nicht mehr, wandert seine Karte nach Erledigt.
• Danach prüft kanman wie bei jedem Sicherheitshinweis, ob der verwundbare Code erreicht wird, und behebt es im Rahmen der Rechte des Teams. Abhängigkeits-Updates werden nie von selbst gemergt.