Overview and setup
What it scans, what it stores, and the exact order to switch it on.
What it is. A scanner that watches your Jira issues for credentials and personal data, and shows you a queue of what it found.
Why this happens in the first place. Jira is where debugging happens. Someone pastes a stack trace that contains a connection string. Someone attaches a config file to explain a problem. Someone drops an API key in a comment to unblock a colleague on a Friday. None of them are careless people; the ticket just felt like a private conversation.
Who sets it up. A Jira administrator. The screens are global, because the findings cover every project.
What gets scanned, and when
It starts scanning the moment you install it
There is a master switch — Secret & PII Scanner, at the top of Scanning Rules — and it ships on. So with no configuration saved, every one of the 165 patterns is active and any issue created, updated or commented on is scanned. To narrow it, switch categories or rules off on the same tab, or exclude projects on Project Exclusions. Nothing is scanned retroactively, so your history stays untouched until you run a bulk scan.
Scanning happens as things change. There is no batch job running overnight, and nothing slows down for the user.
| What | When | Notes |
|---|---|---|
| Summary, description and every text custom field | Any issue create, update or new comment | Always on. Each event triggers a full re-scan of the whole issue, not just the part that changed. |
| Every comment on the issue | Any issue create, update or new comment | Always on. Editing an existing comment is not itself a trigger — the edit is picked up on the issue's next scan. |
| Change history | The same events | Optional, off by default. Reads both sides of every change, so a value pasted and later replaced is caught. |
| Attachments | The same events | Optional, off by default. Text-based files up to 1 MB — 55 extensions including .env, .yaml, .json, .sql, .tf, .properties, .pem and .key, against an allowlist of 24 MIME types. Binary files are not read. |
| Everything that already exists | When you run it | The bulk scan, driven by a JQL query. |
| Nothing, when an issue is deleted | An issue is deleted | The app listens for the deletion too, and clears that issue's findings out of the queue rather than leaving rows pointing at an issue nobody can open. |
The secret itself is never stored
A finding keeps the issue key, the field, which pattern matched, a masked preview showing only the first four characters, and a one-way hash of the value so the same finding is not reported twice. The hash cannot be turned back into the secret. This matters, because a security tool that kept a database of your passwords would be the problem, not the solution.
What you need first
- Jira Cloud. Works with Jira Software, Jira Work Management and Jira Service Management.
- Jira administrator rights.
- A project where remediation tickets should be created, if you want to use the Create Issue button on a finding. A small
SECproject works well.
Switch it on in this order
- 1Install the app and open Jira → Apps → Secret Scanner.
- 2Understand that scanning is already running: the Secret & PII Scanner master switch ships on, so from the moment the app is installed every issue create, update and comment event is scanned with all 165 patterns.
- 3Open Scanning Rules first and review the 17 categories. Switch off anything that will be pure noise in your instance — this is how you narrow the scope.
- 4On the same tab, enable Scan Issue Changelog and Scan Attachments. These are where most real findings hide, and they are off by default.
- 5Leave Auto-Redaction off. Do not enable it yet; see the warning below.
- 6Go to Settings → Issue Creation and set the Tracking project, Issue Type and Priority used when a remediation ticket is raised from a finding. Leave Create the tracking ticket automatically unticked until you trust the findings.
- 7Open Project Exclusions and exclude projects that legitimately contain credential-shaped sample text, such as a sandbox or a training project.
- 8Run a bulk scan over the last year of one project, to see what your instance looks like.
- 9Work through that queue before scanning everything else.
Do not enable auto-redaction on day one
Auto-redaction edits real issue content, replacing the value with
[REDACTED]. Until you know your false-positive profile, you would be editing your colleagues' tickets based on patterns you have not reviewed. Turn it on later, once the findings have proven accurate.The eight tabs
| Tab | What it is for |
|---|---|
| Findings | Your working queue. Everything the scanner found, with the actions to deal with it. |
| Dismissed | What was dismissed or resolved, by whom, when and why — and where you undo it. |
| Bulk Scan | Scan issues that already exist, using a JQL query. |
| Analytics | Trends over 90 days, by day, category and field. |
| Scanning Rules | The master Secret & PII Scanner switch, the 17 categories and individual rules, your own regular expressions, and the four scanning switches: Scan Issue Changelog, Scan Attachments, Auto-Redaction and Require Reason When Dismissing. |
| Project Exclusions | Projects the scanner skips silently. |
| Settings | One card: Issue Creation — the tracking project, issue type and priority for tickets raised from a finding, and whether to raise them automatically. |
| Audit Log | App events for 90 days, filterable and exportable as CSV. |