How to find secrets in Jira and Confluence: Scan, triage and clean up page history

Jira tickets and Confluence pages hold years of passwords, API tokens and private keys that were pasted to unblock someone and never removed. Unlike a code repository, these sites are searchable by large groups, keep every page version, and are rarely covered by the secret scanning that protects Git. This runbook shows how to find those secrets in Atlassian Cloud: a Guard Detect content scan of data at rest, targeted CQL and JQL searches, an API export for an external scanner when you do not have Guard Premium, and the parts of the site that every method misses. It then covers revoking what you find and removing it from page history without destroying evidence. It is for secrets management, security operations and Atlassian administrators. For the wider habit across chat and ticketing tools, see Secrets in chat and tickets.

This is an independent guide from NHI Mgmt Group, based on Atlassian's public documentation as of November 2026. It is not sponsored or reviewed by Atlassian. Product features change, so confirm settings against Atlassian's current documentation.

Key takeaways

• Run a content scan for history. Guard Detect's real-time detection only sees content when it is created or changed; a content scan is the documented way to inspect Jira and Confluence data at rest, and it runs every detection regardless of your alert settings.
• Know what is never scanned. Whiteboards, databases, attachment names, labels, space and project descriptions, attachments over 5 MB, compressed files and older attachments are outside Guard Detect, so they need a separate pass.
• Searches find candidates, not secrets. CQL text ~ and JQL text ~ are word searches; they are good for triage on keywords and token prefixes, but they do not apply secret detection rules or validate anything.
• Revoke first, then redact. Redaction changes only the current Confluence version unless an admin also deletes the historical versions, and deleted versions cannot be restored, so capture evidence before you remove them.
• Treat the scanner as a privileged identity. An API token that can read every space and project is exactly what an attacker wants; give it an owner, an expiry and a short life.

When you need this

• After an Atlassian account compromise: anyone with a valid session can search a site in seconds. In the Schneider Electric Jira breach, infostealer credentials gave the attacker a Jira login and they claimed more than 40 GB of projects and issues, taking any embedded secrets with them. MITRE ATT&CK tracks this collection as T1213.001 Confluence under T1213 Data from Information Repositories.
• Before switching on Guard Detect or a DLP rollout: a baseline scan tells you how large the backlog is and which teams to talk to first.
• Before a migration or consolidation: moving from Data Center to Cloud, or merging sites, copies every secret with the content.
• Periodic hygiene: a quarterly or annual sweep supports NIST SP 800-53 IA-5(7) No Embedded Unencrypted Static Authenticators, which applies to documentation as much as to code.

Before you start

Decide three things before running anything. First, scope: which sites, spaces and projects, and whether restricted spaces are in. A search or export only sees what the account can see, so an account without access to restricted pages gives a false clean result. Second, where findings live: Atlassian notes that the content scan CSV lists where sensitive data is but not the data itself, and that you should store the files securely; apply the same rule to any external scan by storing location, type and a fingerprint rather than the value. Third, who acts: agree with credential owners that a confirmed live secret is revoked first and discussed second.

Create the scanning identity as a named non-human identity with an owner and an expiry. See the Atlassian API Tokens Security Guide and, after the work, check for leftover tokens with How to find long-lived personal access tokens across Atlassian.

Step-by-step

Steps 1 to 5 are read-only. Steps 6 and 7 change content; step 7 includes a destructive option.

1. Add custom detections before scanning. Atlassian's content scan runs every built-in detection, but internal token formats (for example an internal service prefix) need a custom detection with a regular expression. Atlassian says to create and test it before you start the scan, because the scan uses the detections that exist when it runs. Review the built-in list under Detections, Content scanning so you know which credential types are covered.
2. Run a Guard Detect content scan. Start a content scan of data at rest for the Jira and Confluence apps in scope. The Content scan dashboard shows each scan's ID, number of apps, dates, volume inspected, status (pending, in progress, done or failed) and who started it. When it finishes, download the zipped CSV per app from the Actions menu and move it to the restricted findings store. Then work findings from the Findings page, where Guard Detect is moving inside Atlassian Administration.
3. Triage with CQL in Confluence. Use keyword and prefix searches to find candidates, including content types and areas the scan does not cover. Run them with the Confluence search UI or the REST endpoint GET /wiki/rest/api/content/search?cql=.... Examples:

   type in (page, blogpost, comment) and text ~ "password"
   type = page and text ~ "\"BEGIN RSA PRIVATE KEY\""
   text ~ "AKIA*" and lastmodified >= 2020-01-01
   type = attachment and title ~ "env"

   The text field covers title, body and labels. Phrase searches need escaped quotes as shown. Search terms are tokenised, so punctuation-heavy strings such as password= may not match as typed; search the keyword alone. Avoid expand=body.storage.value on broad queries: Atlassian documents a silent cap of 50 results when that expansion is set.
4. Triage with JQL in Jira. In the issue navigator or through /rest/api/3/search/jql (GET for short queries, POST for long ones), search all text fields, then narrow by project and date:

   text ~ "password" AND created >= -730d ORDER BY created DESC
   text ~ "\"client secret\"" AND project in (OPS, SUP)
   summary ~ "credentials" OR text ~ "token*"

   Page with nextPageToken; Atlassian's knowledge base states that the legacy /rest/api/3/search endpoint is deprecated and fully removed from Jira Cloud, so update old scripts. Boolean operators must be in capitals. Service desk projects, access request projects and incident projects are usually the richest sources; start there.
5. Export for an external scanner where Guard is absent or blind. Pull page bodies, comments, the older versions you care about and attachments through the REST APIs into an isolated workspace, then scan the files. The Confluence v2 API exposes GET /attachments/{id} and GET /attachments/{id}/versions (up to 250 results per page) for files the content scan skipped. Open source scanners have no Jira or Confluence source of their own, so scan the export as files: gitleaks dir <export-dir> --redact --report-format json --report-path findings.json or trufflehog filesystem <export-dir> --results=verified,unknown --json. Use verification only where you are allowed to test a credential against its provider, and delete the export when the scan ends.
6. Revoke or rotate at the source. For each confirmed finding, identify the system and the identity it belongs to, check the target system's logs for use since the posting date, then rotate through the secrets manager and revoke the old value. Follow the Leaked Credential Response Playbook.
7. Redact and clean history. In Guard Detect, redact text findings: the value is replaced with a solid bar whose length does not reveal the original. For Confluence, only the current version is redacted unless an admin chooses to delete the historical versions that contain the value; this removes those versions entirely, including other people's edits in them, and they cannot be restored. Attachments are deleted rather than redacted and replaced by a placeholder in current and historical versions. Without Guard, edit the content manually and delete the affected page versions through page history. The author receives an email and an in-app notification when Guard redacts their content.

Where each method is blind

Screenshots of consoles are a common case. Guard Detect can extract text from images by OCR when the relevant detection is enabled, and Atlassian notes that images inside PDFs are not scanned although the PDF text is. External scanners do not read images at all.

Choosing an approach

• Guard Premium available: run the content scan for the baseline, keep real-time detection on for new content, and add a targeted export only for attachments, old versions and the blind spots above.
• No Guard Premium: start with CQL and JQL keyword triage in the highest-risk spaces and projects, then export and scan those areas. The cost is a sensitive copy of content and more manual effort.
• Data Center sites: Guard Detect is a cloud feature, so use REST export and an external scanner, and apply the same storage and token rules. The Confluence Data Center Hardening Guide and Jira Data Center Hardening cover the platform side.
• Small site or large organisation: a team with a few spaces can triage with search in an afternoon. A large organisation with service desks and thousands of spaces should use the content scan, route findings to space and project owners, and track backlog by team.

Verify it worked

• Credential side: the revoked value fails authentication at its provider, and the replacement is held in a secrets manager rather than in the ticket or page.
• Content side: the CQL or JQL query that found the item no longer returns it, and page history shows no version holding the value where you chose to delete versions.
• Findings side: the finding is resolved in Guard Detect, and a repeat scan of the same scope shows a falling count.
• Access side: the scanning token is revoked or expired once the job ends.

Rollback and common errors

Common failure patterns

• Deleting the ticket comment and calling it done: the credential still works, and copies sit in notifications, exports and older versions.
• Scanning only current content: runbooks edited many times keep the original admin password in version 3 of 40.
• Running searches as an account that cannot see restricted spaces: the most sensitive pages are often restricted, so the sweep reports clean.
• Keeping full secret values in the findings spreadsheet: the clean-up creates a new, well-organised leak.
• Leaving the scan token in place: a site-wide read token with no expiry outlives the project and becomes the next exposure.

Hardening afterwards

• Keep real-time detection on: Guard Detect alerts on new and changed content, and alerts can feed a SIEM; pair it with an automation that comments to the author with the approved way to share.
• Give people a faster route: a vault reference or one-time share link in the access request template removes the reason to paste. See the Secrets Management Guide.
• Fix the templates: access request and onboarding templates that ask for a password field invite the problem; replace the field with a link to the vault request.
• Limit search exposure: review who can browse service desk and operations projects, and restrict incident spaces.

Metrics

Framework mapping

Practitioner checklist

• Agree scope, including restricted spaces and private projects, and a findings store that never holds secret values.
• Create the scanning identity with an owner, read-only access and an expiry.
• Add and test custom detections for internal token formats before the content scan.
• Run the content scan and work the CSV findings by space and project owner.
• Triage high-risk projects and spaces with CQL and JQL keyword and prefix searches.
• Export and scan attachments, archives, old versions and other blind spots.
• Revoke or rotate every confirmed live secret before redacting.
• Capture evidence, then redact and delete historical versions that hold the value.
• Revoke the scanning token and keep real-time detection running.

Standards and references

• Atlassian: What is a content scan?
• Atlassian: What sensitive data is detected?
• Atlassian: What happens when data is redacted or deleted from findings?
• Atlassian Developer: Advanced searching using CQL
• Atlassian: Run JQL search query using Jira Cloud REST API
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: Data from Information Repositories: Confluence
• Gitleaks: project documentation

Related NHI Mgmt Group resources: Secrets in chat and tickets · Atlassian Cloud Security Guide · How to find long-lived personal access tokens across Atlassian · OWASP NHI Top 10 NHI2 Secret Leakage Guide