Jira-Integration

Übertragen Sie validierte Schwachstellenmeldungen als Vorgänge nach Jira, ohne dass Exploit-Details Kit verlassen.

Warum das zählt

Wer eine Schwachstellenmeldung sichtet, behebt sie so gut wie nie selbst. Die Sichtung passiert in Kit, die Behebung auf einem Entwicklungs-Board. Ohne Verknüpfung zwischen beiden kopiert jemand die Meldung von Hand nach Jira – und ab diesem Moment laufen die beiden Systeme auseinander. Der Vorgang steht auf „In Review“, die Meldung auf „Validiert“, niemand kann beantworten, ob das Problem tatsächlich behoben ist, und der Forscher wartet.

Eine Jira-Verbindung schließt diese Lücke. Ein Klick auf einer Meldung erstellt den Vorgang im Entwicklungsprojekt, und die Verknüpfung zwischen beiden ist ein echter Datensatz, den Kit pflegt – keine URL, die jemand in einen Kommentar geklebt hat.

Sie löst außerdem das unauffälligere Problem: Beim Kopieren von Hand landet meist alles im Zielprojekt, Reproduktionsschritte und die E-Mail-Adresse des Forschers inklusive – obwohl niemand geprüft hat, wer dieses Projekt tatsächlich lesen darf. Die Integration von Kit überträgt stattdessen bewusst nur eine Kurzfassung.

Was Sie brauchen

Kit-Konto mit aktiviertem VDP-Add-on
Eine Jira-Cloud-Site (Jira Data Center und Jira Server werden nicht unterstützt)
Ein Atlassian-Konto mit Zugriff auf das Zielprojekt
Modul-Administratorrechte in Kit – eine Tracker-Verbindung ist eine Entscheidung auf Organisationsebene

Note

Kit nutzt OAuth 2.0 (3LO). Ein Feld für ein API-Token gibt es nicht, und das ist kein Versehen: Atlassians Sicherheitsvorgaben verbieten es Apps, API-Token von Nutzern einzusammeln. Sie melden sich stattdessen bei Atlassian an und erteilen den Zugriff.

Einrichtung

1. Atlassian-Konto verbinden

Öffnen Sie VDP > Einstellungen > Issue-Tracker
Klicken Sie auf Jira verbinden
Melden Sie sich bei Atlassian an und bestätigen Sie den angeforderten Zugriff
Wählen Sie die gewünschte Jira-Site, falls Ihr Atlassian-Konto mehrere hat

Die Zugriffsberechtigung hängt an der Person, die sie erteilt hat. Kit hält fest, wer das war – denn verlässt diese Person die Organisation, funktioniert die Verbindung nicht mehr, und Sie müssen wissen, wessen Zugriff zu erneuern ist.

Warning

In manchen Atlassian-Organisationen müssen Apps von Drittanbietern erst administrativ freigegeben werden. Ist eine Freigabe nötig, schlägt der Verbindungsschritt mit einem Hinweis von Atlassian fehl, nicht mit einem Kit-Fehler – leiten Sie die Anfrage an die Verwaltung Ihrer Atlassian-Organisation weiter.

2. Projekt und Vorgangstyp wählen

Klicken Sie auf der Einstellungsseite auf Projekt wählen
Wählen Sie das Projekt, in dem die Arbeit an Schwachstellen landen soll
Wählen Sie den Vorgangstyp, mit dem neue Vorgänge angelegt werden (meist Bug oder Task)

Kit liest dabei den Projekttyp aus. Handelt es sich um ein Jira Service Management-Projekt, sind Kommentare bei Statusänderungen standardmäßig aus: JSM macht Kommentare, die über die Plattform-API entstehen, zwingend öffentlich – Ihre externen Service-Desk-Anfragenden würden sie also mitlesen.

Kit liest außerdem die Prioritätsnamen aus, die Ihr gewähltes Projekt und der gewählte Vorgangstyp akzeptieren, und ordnet ihnen die Schweregrade der Meldungen zu (Kritisch → Highest, Hoch → High und so weiter). Zwei Fälle sollten Sie kennen; die Einstellungsseite weist Sie darauf hin, sobald einer von beiden zutrifft:

Ihr Projekt verwendet eigene Prioritätsnamen oder läuft in einer anderen Sprache als Englisch. Kit erfindet keine Priorität, die es nicht zuordnen kann – betroffene Meldungen erhalten deshalb die Standardpriorität des Projekts. Der Schweregrad steht in jedem Fall in der Beschreibung des Vorgangs.
Ihr Projekt hat kein Prioritätsfeld in der Erstellungsmaske, was in teamverwalteten Projekten häufig vorkommt. Kit übermittelt dann überhaupt keine Priorität.

Wollen Sie die Zuordnung selbst festlegen, hinterlegen Sie an der Verbindung eine eigene priority_map – eine Oberfläche dafür gibt es noch nicht.

3. Verbindung bestätigen

Klicken Sie auf Verbindung testen. Kit sendet eine authentifizierte Anfrage an Ihre Site und zeigt das Ergebnis an.

Eine Meldung übertragen

Öffnen Sie eine beliebige Meldung. In der rechten Spalte finden Sie die Karte Issue-Tracker.

Klicken Sie auf Vorgang erstellen
Lesen Sie die Übersicht, was übermittelt wird und was in Kit bleibt
Klicken Sie auf Vorgang erstellen

Während der Vorgang angelegt wird, zeigt die Karte einen Ladeindikator, danach den Vorgangsschlüssel, dessen Status und einen Link, der Jira in einem neuen Tab öffnet.

Das darf jedes Teammitglied, das die Meldung sehen kann – es gehört zur alltäglichen Sichtung und verlangt nicht mehr Rechte als das Anhängen eines Links. Nur das Einrichten der Verbindung bleibt Administratoren vorbehalten.

Was Kit verlässt

Diesen Abschnitt sollten Sie genau lesen. Standardmäßig ist ein übertragener Vorgang eine Kurzfassung: genug, damit ein Entwickler die Arbeit einplanen kann, und nicht mehr.

An Jira übermittelt	Bleibt in Kit
Titel der Meldung und Kit-Referenz	Die Beschreibung der Schwachstelle
Schweregrad und CVSS-Score	Reproduktionsschritte
Schwachstellentyp	Der betroffene Endpunkt
Betroffener Produktbereich	Proof-of-Concept-Dateien und Screenshots
Frist zur Behebung	Name, E-Mail-Adresse und Auszahlungsdaten des Forschers
Ein Link zurück zur Meldung in Kit	Interne Notizen und der Nachrichtenverlauf

Dahinter steckt keine Vorsicht um der Vorsicht willen. Von Kit aus lässt sich nicht absehen, wer in Jira tatsächlich mitliest: organisationsweite Projektberechtigungen, Marketplace-Apps mit Leserechten auf Vorgänge, CSV-Exporte und Backups, die den Vorgang überdauern. Genau die Felder, die Kit zurückhält, verschlüsselt es auch im Ruhezustand – sie zu übertragen hieße, Ihre bestgeschützten Daten in Ihr am wenigsten kontrolliertes System zu verschieben.

Für die Identität des Forschers und die Höhe der Prämie gibt es überhaupt keinen Schalter. Dass die Option fehlt, ist die Garantie.

Vollständige Details dennoch übermitteln

Manche Teams wollen die Beschreibung trotzdem im Vorgang haben. Dafür sind zwei voneinander unabhängige Freigaben nötig:

Eine Administratorin oder ein Administrator aktiviert unter VDP > Einstellungen > Issue-Tracker die Option Vollständige Schwachstellendetails erlauben
Die Person, die die Meldung überträgt, setzt das Häkchen für genau diesen Vorgang

Beides ist standardmäßig aus. Ist die Einstellung auf Programmebene deaktiviert, werden die Kontrollkästchen gar nicht erst angezeigt – und auch eine selbst gebaute Anfrage kommt nicht daran vorbei, weil Kit die Programmeinstellung beim Zusammenstellen der Daten erneut prüft.

Wird Text aus der Meldung mitgeschickt, landet er in einem Codeblock. Jira gibt ihn dann genau so wieder, wie der Forscher ihn geschrieben hat, statt ihn als Markup zu interpretieren.

Tip

Lassen Sie die Option aus. Der Vorgang verweist zurück auf Kit, und wer die Reproduktionsschritte braucht, öffnet einfach die Meldung – unter Ihren Zugriffsregeln und mit protokolliertem Zugriff.

Status der Behebung

Die Karte zeigt die Statusbezeichnung des Vorgangs genau so, wie Ihr Board sie formuliert („In Review“, „Ready for QA“), denn das ist, was die Entwicklerinnen und Entwickler sehen. Intern ordnet Kit sie einem von fünf Zuständen zu – Nicht begonnen, In Bearbeitung, Behoben, Wird nicht behoben, Unbekannt – und stützt sich dabei auf Jiras feste Status-Kategorien statt auf die Statusnamen. Eine Workflow-Zuordnung je Projekt ist deshalb nicht nötig.

Kit schließt eine Meldung niemals ab, nur weil in Jira „Done“ steht. „Done“ heißt auf einem Entwicklungs-Board regelmäßig „gemergt, aber nicht ausgeliefert“. Und der Abschluss einer Meldung hat Folgen, die man der Person, die eine Karte verschiebt, nicht unterstellen kann: Der Forscher wird benachrichtigt, der Prämienprozess startet, und die Fristen zur Veröffentlichung verschieben sich. Kit zeigt den fertigen Vorgang an und überlässt die Entscheidung einem Menschen.

Verknüpfung aufheben und erneut versuchen

Verknüpfung aufheben entfernt die Verbindung nur in Kit. Der Vorgang bleibt in Jira, wo längst Kommentare aus dem Entwicklungsteam und ein Branch mit dem Fix daranhängen können – dort ist nicht Kit das führende System.
Erneut versuchen wiederholt eine fehlgeschlagene Übertragung. Ein zweiter Klick schadet nicht: Kit versieht jeden Vorgang mit einem eindeutigen Schlüssel und sucht vor dem Anlegen nach dieser Markierung. Lief eine Anfrage also in eine Zeitüberschreitung, nachdem Jira den Vorgang bereits erstellt hatte, übernimmt Kit den vorhandenen Vorgang, statt einen zweiten anzulegen.
Trennen entfernt die bei Kit gespeicherte Zugriffsberechtigung samt der zugehörigen Verknüpfungen. Alle bereits erstellten Vorgänge bleiben in Jira.

Fehlerbehebung

Symptom	Ursache	Lösung
„Der Jira-Zugriff wurde widerrufen“	Die Berechtigung wurde in Atlassian widerrufen oder die autorisierende Person wurde deaktiviert	Verbinden Sie Jira auf der Einstellungsseite erneut; auch eine andere Administratorin oder ein anderer Administrator kann die Freigabe erteilen
„Dieses Projekt hat keinen nutzbaren Vorgangstyp“	Das Projekt bietet nur Untervorgangstypen an	Wählen Sie ein anderes Projekt oder legen Sie in Jira einen Standard-Vorgangstyp an
Der Vorgang wurde wegen eines Feldes abgelehnt	Ein benutzerdefiniertes Pflichtfeld, das die Kurzfassung nicht füllt	Prüfen Sie den Fehler auf der Karte und passen Sie dann die Feldkonfiguration des Projekts so an, dass das Feld beim Anlegen optional ist
Es erscheint keine Schaltfläche Vorgang erstellen	Es ist kein Tracker verbunden oder das VDP-Add-on ist nicht aktiv	Verbinden Sie einen unter VDP > Einstellungen > Issue-Tracker

Auf einen Blick

VDP-Add-on im Konto aktiv
Atlassian-Konto verbunden, und Sie wissen, wer die Freigabe erteilt hat
Zielprojekt und Vorgangstyp gewählt
Verbindungstest erfolgreich
Einstellungsseite auf einen Hinweis zur Prioritätszuordnung für das gewählte Projekt geprüft
Bewusst entschieden, ob vollständige Schwachstellendetails übermittelt werden dürfen
Bei einem Jira-Service-Management-Projekt geprüft, dass Kommentare bei Statusänderungen aus sind