← Back to Learn

Project management security

Sharing credentials in project management tools: what goes wrong

Project management tools are where work gets organised, tracked, and documented. They are also, increasingly, where credentials get shared — a staging environment password dropped in a Jira ticket comment, a client login pasted into a Notion page, database credentials added as a note in a Linear issue. It feels convenient. It is also one of the most common ways credentials become permanently exposed.

How credentials end up in project management tools

The scenarios are consistent across organisations of every size. A developer opens a ticket for a staging environment issue and pastes the database URL into a comment so the team can reproduce it. A project manager creates a Notion page for a client project and includes the client's login credentials in a table for “easy access.” A DevOps engineer adds a note to a Linear issue with the SSH credentials for the affected server. Someone creates a Trello card with credential fields. An Asana task assigned to a contractor includes the API key they need.

In each case, the credential is now in a system it was never designed to be in — and it will stay there long after the original reason for putting it there has passed.

Platform by platform: what happens to that credential

Notion

Notion pages and databases are stored on Notion's servers and accessible to all workspace members with page access by default. Pages can be shared with “anyone with the link” — a setting that effectively makes them public, and one that is easy to set accidentally in a collaborative workspace. Notion has no automatic expiry for page content. A credential added two years ago is still there. Notion search indexes all page content, making credentials searchable by anyone with workspace access.

Jira

Jira tickets — including comments, descriptions, and attachments — are retained based on your organisation's configuration, which defaults to indefinite. Jira has powerful search including JQL (Jira Query Language), which allows precise queries across all issue content. An attacker who gains access to a Jira instance can search for credential-related terms across the entire issue history in seconds. Jira integrations are extensive — CI/CD pipelines, monitoring tools, and communication platforms may all have read access to ticket content.

Linear

Linear is the modern alternative to Jira, popular with engineering teams at startups. Issues, comments, and descriptions are retained indefinitely with full-text search across all content. Workspace members generally have broad access to issue content across teams by default.

Asana

Asana is widely used by non-engineering teams — marketing, operations, client services. Asana tasks are frequently shared with external collaborators and clients. Guest access in Asana allows external users to view and comment on tasks they are invited to. A credential added to an Asana task visible to a guest user is now outside your organisation. Task history is retained indefinitely and searchable.

Trello

Trello uses a card-based interface common in smaller teams. Trello boards have a public/private setting, but the default for new boards has historically been public in some configurations. Public Trello boards are indexed by search engines — credentials on a public Trello board are visible to anyone with the URL and potentially discoverable via Google. Private boards restrict access to board members, but the same retention and search risks apply within the workspace.

The shared risks across all project management tools

Retention is indefinite. Project management tools are archives. A credential added to a ticket or page today will be there in five years unless someone actively finds and removes it.

Search surfaces everything. Every major project management tool has powerful search. A credential added to any ticket, comment, or page is indexed and findable by anyone with access.

Access is broad. Project management tools are designed for team-wide visibility. Credentials added to tickets are often visible to entire teams, including contractors, guests, and people who joined the project long after the credential was added.

Integrations multiply exposure. Every connected tool — Slack bridges, CI/CD pipelines, reporting dashboards — is a potential additional copy of the content in your project management tool.

Offboarding gaps. When team members or contractors are offboarded, their access to the project management tool is revoked — but the credentials they could see while employed are not removed from the issues where they appear.

The right approach

Never put credentials in a ticket, task, or page directly. Not in descriptions, not in comments, not in attachments, not in custom fields. Treat any field in a project management tool as a permanent, searchable, shared record — because that is exactly what it is.

Reference the handoff, not the credential. The ticket can say “credentials for the staging database shared via secure link.” The actual credential is shared out-of-band via a one-time encrypted link and never enters the project management tool.

For standing access, use a proper secrets manager. If a credential needs to be referenced repeatedly across multiple tickets or team members, it belongs in a secrets manager (1Password Teams, Bitwarden, HashiCorp Vault) with appropriate access controls — not in a Notion page or a Jira comment.

Audit existing tickets for exposed credentials. Search your project management tools for terms like “password”, “API key”, “credentials”, “token”, “secret”. Review what you find and rotate any credentials that appear in plaintext. This is uncomfortable but important — you may find credentials that have been sitting in plain sight for years.

Using a one-time link for project management credential handoffs

When a ticket requires a credential handoff, the workflow is straightforward. The person with the credential goes to cyph3rdrop.com and generates a one-time encrypted link. They paste the link into the ticket comment or description. The recipient opens the link once — the credential appears in their browser and the link is immediately destroyed. The ticket contains only a URL. No plaintext credential, nothing sensitive in the ticket history.

If the ticket is later exported, audited, or reviewed, it contains a dead link with no sensitive content. If the project management tool is breached, the ticket history reveals nothing useful.

Frequently asked questions

What if the ticket is private and only visible to a small team?

The same risks apply. Private tickets are restricted in who can see them within the UI, but they are subject to the same server-side storage, search indexing, admin access, and integration risks. “Private” means fewer people can see it — it does not mean it is secure.

Can I use a Notion database with restricted access for credentials?

A restricted Notion database is better than a public one, but it is still stored on Notion's servers, accessible to workspace admins, and potentially visible to connected integrations. It is not a secrets manager. Use it for reference material, not for credentials.

Should I delete old tickets that contain credentials?

Yes, where possible. Rotating the exposed credentials is the first priority — change the passwords or regenerate the API keys that appear in plaintext in old tickets. Then clean up the ticket history. Deletion is better than leaving credentials exposed indefinitely.

The short version

Project management tools are archives, not secure channels. Credentials in Jira, Linear, Notion, Asana, or Trello are stored indefinitely, indexed for search, visible to broad teams, and included in integrations and exports. Share a one-time encrypted link in the ticket instead — the credential is destroyed on first access and the ticket history contains nothing sensitive.

Try it now

No account required. Paste a credential, get a one-time link, drop it in the ticket.

Create a secret link →