Security scanner

Open Apps → UndoTrail → Security scanner. The tab needs an active subscription, and appears for people allowed to use the Security scanner feature on the admin page. It starts as Jira admins only, because it puts every secret a person can see into one list; an admin can open it to a security team’s group, or to everyone, under Settings → Marketplace apps → UndoTrail → Permissions.

Why historical values matter

Jira keeps every value a field ever held. If someone pasted an API key into a description and tidied it away five minutes later, the key is still in the work item’s history, readable by anyone who can browse the project. No Jira API can edit that history. The scanner’s job is to find those values and tell you which are still current and which are only historical.

How to run a scan

1. Set the scope and dates on the Changes tab, since the scanner uses the same query.
2. Open the Security scanner tab and press Run scan. The history is loaded exactly as a report would load it.
3. Filter by minimum severity, category or text.
4. Review the findings, then read the remediation notes for each category.

Everything runs in your browser. Matched values are never sent anywhere, and the only way one leaves the page is if you export the CSV unmasked.

What is scanned

A finding is reported once per work item, field and value. If the same secret appears in several changes, the most recent sighting is kept, and a current sighting always beats a historical one.

The app only claims a value is current when it can tell. Beyond the summary, “current” means “the latest change to that field set it and nothing since has changed it in the loaded range”. Check the work item itself before acting on the distinction.

Detector categories

Shape alone is not enough for the high-risk categories, so several detectors also check the value:

• Card numbers must pass the Luhn checksum and match a real card prefix and length.
• IBANs must match their country’s length and pass the ISO 13616 mod-97 check.
• US Social Security numbers must not use the reserved ranges; routing numbers must pass the ABA checksum.
• Password and API-key matches must look like credentials, so password: changeme, password: <redacted> and password: **** are ignored.
• IP addresses must be valid. 127.0.0.1, 0.0.0.0, 255.255.255.255, :: and ::1 are ignored, and so is an address in text that reads like a version number, for example firmware 1.2.3.4.

Where two detectors match overlapping text, the more severe one wins, then the longer match.

Severity

The list opens at severity 3 and above. Lower the minimum to see email addresses, phone numbers, postcodes and network addresses.

Masking

Every matched value is masked by default. A value under 12 characters is replaced entirely with asterisks; longer values show the first four and last two characters, with asterisks between. The number of asterisks is capped, so it does not give away the value’s length.

• unmask on a row reveals that one value.
• Unmask all values reveals every value on screen. The button then reads Mask all values.
• The CSV export is unmasked only when Unmask all values is on. Values revealed one row at a time stay masked in the file. An unmasked file says so in its header, marking itself as a file to treat as a secret, and it needs the same handling as the credentials inside it.

Remediation, honestly

The app shows guidance for each category of finding, and it does not pretend the problem can be tidied away.

Jira’s change history cannot be edited through any API. Not by this app, not by a Jira administrator, not by Atlassian support through a normal request. Clearing the field today does not remove yesterday’s value from the history.

What that means in practice:

If a value genuinely must be purged, for example for a data-erasure request or to get card data out of scope, the only route is to delete the work item and recreate it, and to restrict who can browse the project until you have. Deleting removes the history with the item. Bear in mind that the app’s own snapshot of a deleted item is held for the retention period, so set retention with that in mind.

Exporting findings

Export CSV writes every filtered finding, including any beyond the 1,000 the table shows, with a short header block recording the query, the generation time, whether values are masked and the number of findings. Columns: Severity, Detector, Category, Work item, Summary, Field, Where (Current or Historical), When (UTC), Changed by, and Value.

The Rovo agent can run the same scan from a question in Rovo chat. Its answers always carry masked values.

Limitations

• The scanner recognises shapes. A secret with no recognisable format, an internal token scheme, or a password written in prose will not be found. “No findings” is not a guarantee, and the app says so on screen.
• It only scans what the current query loaded. To cover a whole site, widen the scope and the date range, and remember the work item limit.
• False positives happen, especially with phone numbers, bank account numbers and long identifiers. Check before acting.
• Comment text is not scanned, because Jira’s change history does not carry it. Comment versions captured by comment history are not scanned either.
• Attachment contents are not scanned.
• Beyond each work item’s summary, “current” is inferred from the latest loaded change, not from a fresh read of every field.
• The findings table shows the first 1,000 matching findings. The CSV holds all of them; narrow the filters, or scan a smaller scope, to see the rest on screen.
• The scan runs in the browser, so a very large history takes time and memory. Scan by project or by month on a big site.