Back to Blog
SECRETS SPRAWL8 min readSecret Scanner for Jira

6.1% of Jira Tickets Contain a Leaked Credential. That's the Worst Rate of Any Collaboration Tool.

Your code repos are scanned for secrets. Your Jira instance — full of pasted API keys, passwords, and tokens — almost certainly is not.

Engineers and support agents are pragmatic. When a build fails, someone pastes the failing config — .env file and all — into a Jira comment. When an integration breaks, a ticket gets opened with the full API request, bearer token included. When a customer can't log in, an agent attaches a screenshot of the admin console with the connection string visible. The work gets unblocked. The secret stays in the ticket forever.

Security teams have spent a decade locking down secrets in source code: pre-commit hooks, repo scanning, push protection. Meanwhile, the same credentials are accumulating, unscanned and unrevoked, inside Jira — a system that most organizations grant broad internal read access to, integrate with dozens of apps, and retain data in indefinitely.

GitGuardian's research makes the scale of the blind spot explicit: 6.1% of Jira tickets were found to expose credentials, making Jira the most vulnerable collaboration tool they measured (GitGuardian, State of Secrets Sprawl 2025). This article quantifies what that leak vector costs, why it persists, and what scanning Jira for secrets actually changes.


The Problem Has Moved Out of the Codebase

The headline number for secrets sprawl is staggering on its own: GitGuardian detected 23.8 million new hardcoded secrets in public GitHub repositories in 2024, a 25% increase year over year (GitGuardian, State of Secrets Sprawl 2025). But the more important shift for security leaders is where secrets are now leaking.

Secrets no longer live only in code. They live in the tools where humans talk about code:

  • -6.1% of Jira tickets exposed credentials — the highest rate of any collaboration tool studied
  • -2.4% of corporate Slack channels contained leaked secrets
  • -38% of incidents found in collaboration and project-management tools (Slack, Jira, Confluence) were classified as highly critical or urgent — higher than the 31% critical rate for incidents found in source-control systems

Source: GitGuardian, State of Secrets Sprawl 2025

Read that last point twice. Secrets leaking outside the code repository are not lower-stakes noise — they are, on average, more severe than the ones leaking inside it. That tracks with intuition: a secret pasted into a Jira ticket to debug a production incident is often a live, high-privilege, production credential.

And these secrets do not expire on their own. GitGuardian found that 70% of secrets leaked in 2022 were still valid at the time of the 2025 report, and that over 90% of exposed secrets remained active five days after being leaked (GitGuardian, State of Secrets Sprawl 2024). A credential dropped into a Jira comment in 2022 is, more likely than not, still a working key into your systems today.


What a Leaked Credential Actually Costs

A secret in a Jira ticket is not a hypothetical risk. It is the single most common way attackers get in.

Stolen credentials are the #1 breach vector

  • -31% of all breaches over the past decade involved the use of stolen credentials (Verizon, 2024 DBIR).
  • -68% of breaches involved a non-malicious human element — a person making a mistake or being tricked (Verizon, 2024 DBIR). Pasting a live token into a ticket is exactly that kind of mistake.

Credential breaches are the most expensive and the slowest to catch

IBM's research puts a hard dollar figure on the outcome:

  • -The global average cost of a data breach reached $4.88 million in 2024, a 10% increase year over year and the largest jump since the pandemic.
  • -Stolen or compromised credentials were the single most common initial attack vector, at 16% of breaches — and these breaches took the longest of any type to identify and contain, at nearly 10 months.
  • -Even with response times at a seven-year low, the average breach lifecycle was still 258 days.

Source: IBM / Ponemon, Cost of a Data Breach Report 2024

Put the numbers together. The most common way in is a stolen credential. The credential leaks that are hardest to spot are the ones sitting in collaboration tools nobody scans. And once a credential breach starts, it runs for the better part of a year before anyone contains it — at an average cost approaching five million dollars.

A single API key forgotten in a three-year-old Jira ticket is a fully-loaded version of that risk.


Why Jira Is Such a Rich Target

Jira concentrates several risk factors that make it an ideal place for secrets to hide and an ideal place for an attacker to look.

Broad internal access. Repos tend to have tight, role-based permissions. Jira projects are frequently open to large internal groups — entire engineering orgs, support teams, contractors, and increasingly, AI agents and integrations that index ticket content wholesale.

Indefinite retention. Code gets refactored and rotated. Tickets are archived but rarely deleted, and their full edit history is preserved. A secret pasted into a comment in 2022 is still queryable today — and so is the version of the description it was later "removed" from.

It's where debugging happens. The whole point of a ticket is to capture the messy reality of a problem: logs, configs, stack traces, request bodies, screenshots. Those are precisely the artifacts that carry live secrets.

It's outside the scanning perimeter. Push protection and pre-commit hooks stop secrets at the repo boundary. None of that tooling sees a comment typed directly into a Jira issue or a .env file dragged in as an attachment. The control that works for code simply isn't watching this surface.

The result is a high-blast-radius leak vector that most secret-management programs don't cover at all — which is exactly why GitGuardian found leaks outside the codebase to be disproportionately critical.


How Secret Scanner for Jira Closes the Gap

The fix is not to ask people to stop pasting secrets — that has never worked and never will, because the leak happens in the moment someone is trying to solve a problem. The fix is to scan the place the secrets land, the same way you already scan your repos.

That is what Secret Scanner for Jira does. It brings repo-grade secret detection inside your Jira instance.

Scans the full ticket surface — not just the description. Secrets hide in comments, in attachments, and in edit history, not only in the obvious fields. Secret Scanner inspects issue summaries, descriptions, comments, and attached files so a credential pasted into a reply or dragged in as a config file doesn't slip through.

Detects the credentials that actually matter. Out of the box it recognizes high-value secret types — API keys, cloud access keys, OAuth and bearer tokens, SSH and private keys, database connection strings, and passwords — using pattern detection tuned to real credential formats rather than naive keyword matching.

Catches custom and internal secrets with your own rules. Every organization has internal token formats and service credentials that generic detectors miss. Custom regex rules let you extend coverage to your own secret shapes, so the scanner reflects your real estate, not a generic template.

Surfaces findings fast — instead of in month ten. The reason credential breaches run 258 days is that nobody is looking. Secret Scanner flags exposures as tickets are created and updated, turning a leak that would otherwise sit undetected for the better part of a year into an alert your team can act on the same day. Given that 90% of leaked secrets stay live within the first five days, speed of detection is the whole game.

Gives security a defensible inventory. Centralized findings and exportable reports let you triage by severity, prove coverage to auditors, and track remediation — turning "we think Jira is probably fine" into a measured, evidenced control.

In other words: the same discipline you already apply to source code, applied to the collaboration tool that GitGuardian's data identifies as the worst offender.


The Bottom Line

Secrets sprawl has outgrown the codebase. The data is unambiguous: Jira is the most credential-leaky collaboration tool measured, the leaks found there are more critical than the ones in your repos, stolen credentials are the #1 breach vector, and the resulting breaches are the most expensive and the slowest to contain — averaging nearly ten months and approaching $4.88 million.

You have invested heavily in keeping secrets out of your code. The credentials hiding in your Jira tickets are just as live, far less guarded, and completely unwatched. Scanning them is the cheapest insurance you're not yet buying.


Sources

[1] GitGuardian — State of Secrets Sprawl 2025 (2025). https://blog.gitguardian.com/the-state-of-secrets-sprawl-2025/

[2] GitGuardian — State of Secrets Sprawl 2024 (2024). https://blog.gitguardian.com/the-state-of-secrets-sprawl-2024/

[3] Verizon — 2024 Data Breach Investigations Report (2024). https://www.verizon.com/about/news/2024-data-breach-investigations-report-vulnerability-exploitation-boom

[4] IBM / Ponemon Institute — Cost of a Data Breach Report 2024 (2024). https://newsroom.ibm.com/2024-07-30-ibm-report-escalating-data-breach-disruption-pushes-costs-to-new-highs

Secret Scanner for Jira

See how Secret Scanner for Jira solves this.

Secret Scanner for Jiraruns natively on Atlassian Forge — no external infrastructure, no data leaving your tenant. Let's show you how it fits your service desk.

Request a Demo