So findet ihr API-Tokens und Secrets in Jira-Automation-Regeln

Wo sich Tokens und Secrets in Jira-Automation-Regeln (Flows) verstecken — Web-Request-Header, URLs, Smart Values —, wie ihr den Export danach durchsucht und was ihr als Erstes tut, wenn ihr eines findet.

Niemand nimmt sich vor, ein Geheimnis hart zu verdrahten. Der Weg dorthin ist immer derselbe: eine Regel muss einen externen Dienst aufrufen, Send web request braucht einen Authorization-Header, der Header braucht einen Wert, und es gibt keinen guten Ort dafür. Also wird er ins Feld getippt, die Regel läuft, das Ticket ist zu.

Zwei Jahre später steht der Wert immer noch da. Er läuft nicht ab, liegt in keinem Tresor, steht in keinem Inventar — und er funktioniert weiter, nachdem die Person, die ihn erstellt hat, das Unternehmen verlassen hat.

Warum Automation-Regeln ein blinder Fleck sind

Secret Scanning ist in Repositories ein gelöstes Problem. Jede ernsthafte CI-Pipeline durchsucht Commits nach Token-Mustern. Jira-Automation-Regeln (Flows) liegen außerhalb davon: sie sind Konfiguration, kein Code, sie leben in einer Datenbank statt in einer Datei, und nichts scannt sie.

Das Ergebnis ist eine Klasse von Zugangsdaten, die kein Audit erfasst. Nicht im Repo-Scan, nicht im Secrets-Manager, nicht auf der Offboarding-Checkliste.

Wo sie sich verstecken

• Authorization-Header bei Send web request — Bearer-Tokens, API-Keys, manchmal ein base64-kodierter Basic-Auth-String, der wie Rauschen aussieht, bis man ihn dekodiert
• Tokens in der URL selbst — ?api_key=… oder ?token=… im Query-String, oder eine Slack- oder Automation-Webhook-URL mit dem Secret im Pfad, was zusätzlich in Logs landet. Ein Login der Form user:passwort@host wird nicht erkannt — solche prüft ihr von Hand.
• Ein Smart Value im Vergleich mit einem Literal, etwa {{webhookData.token}} equals …, oder ein Token in einer Variablen, einmal oben in der Regel gesetzt und darunter wiederverwendet
• Webhook-Secrets und Connector-Parameter, inline gehalten, weil die Regel keinen anderen Platz dafür hatte

Alle vier sind strukturelle Muster. Sie lassen sich aus der Konfiguration der Regel finden, ohne irgendetwas über den aufgerufenen Dienst zu wissen.

Finden, ohne es schlimmer zu machen

Eine unangenehme Eigenschaft: die Exportdatei, mit der ihr prüfen würdet, ist selbst voll der Geheimnisse, die ihr sucht. Jira-Einstellungen → System → Automation flows → More actions (…) → Export flows (Export rules auf älteren Instanzen) erzeugt eine Datei, die wie ein Credential-Dump zu behandeln ist — nicht per Mail, nicht im geteilten Laufwerk, nicht an ein Ticket gehängt. Header-Werte, die als Hidden markiert sind, lässt Jira als Einziges weg.

Automation Map durchsucht den Export nach diesen Mustern und nennt die Regel; in der Logik der Regel erscheint der maskierte Wert als Platzhalter an dem Schritt, der ihn enthält. Erkannte Zugangsdaten werden maskiert, bevor irgendetwas gespeichert wird, und der Befund ist in jeder Edition enthalten, auch in Basic — Sicherheitsbefunde stehen nie hinter einem Tarif. Das fertige Sicherheitsticket zum Einfügen liegt auf der Audit-Seite, Advanced und Enterprise.

HINWEIS: Zahlen aus Kundeninstanzen veröffentlichen wir zu diesem Befund bewusst nicht, auch nicht anonymisiert — schon eine Zahl verrät einem Angreifer etwas Nützliches über eine reale Organisation. Eure Zahlen bleiben eure.

Was tun, wenn ihr eines findet

1. Zuerst rotieren. Nehmt an, es ist kompromittiert — es lag in einem Konfigurationsfeld, das jede Person lesen kann, die diese Regel in Jiras Automation-Einstellungen öffnen darf, und womöglich in einem Export, den vor Jahren jemand gezogen hat.
2. Den neuen Wert besser unterbringen. Jira Cloud hat keinen Secret-Speicher für Automation; tragt den neuen Wert also mindestens im Web-Request-Header mit angekreuztem Hidden ein — er lässt sich nicht mehr auslesen, und Jira lässt ihn aus Exporten weg. Besser noch, je nach aufgerufenem Dienst: ein Connect-/Forge-App-Credential, eine OAuth-Integration oder ein Webhook, den der Empfänger per Signatur statt per geteiltem Geheimnis authentifiziert.
3. Den Flow-Actor prüfen — das Konto, unter dem die Regel läuft. Eine Regel, die als ausgeschiedene Admin ausgeführt wird, hat zusätzlich zum Token ein zweites Problem.
4. Regeln ins Offboarding aufnehmen. Wenn jemand geht, werden die Tokens widerrufen — aber nur, wenn jemand weiß, dass eine Regel eines benutzt.

Die ehrlichen Grenzen

Das ist Mustererkennung auf Konfiguration. Sie findet Zugangsdaten, die wie Zugangsdaten aussehen: erkennbare Header-Formen, Tokens in Query-Strings und Webhook-Pfaden, Zeichenketten hoher Entropie an den Stellen, wo Geheimnisse üblicherweise stehen. Ein Geheimnis, das wie ein gewöhnlicher Wert aussieht, wird nicht markiert — und eine harmlose Zeichenkette hoher Entropie womöglich schon. Nehmt Befunde als Ausgangsliste, nicht als Unbedenklichkeitsbescheinigung.

FAQ

Schaut hin, bevor ein Auditor es tut

Die Tokens in euren Regeln liegen seit Jahren dort und funktionieren weiter, bis jemand sie findet. Besser, ihr seid das.

👉 Automation Map für Jira — durchsucht eure Regeln nach eingebetteten Zugangsdaten