How Secret Sentinel Detects Secrets: An Open Methodology

“Detects 50+ secret types” is not a methodology

A buyer cannot evaluate a scanner from a detector count. Fifty narrow prefixes, fifty generic keywords, and fifty validated credential formats have different coverage and false-positive behavior. The more useful questions are observable:

• which content surfaces are scanned;
• which engine and additional rules perform detection;
• how exploitability affects severity;
• whether redaction and incident escalation are separate;
• where content is processed;
• how a customer can reproduce expected behavior safely.

This page answers those questions for Secret Sentinel using only capabilities documented in the product and its public walkthrough.

Scope: the collaboration surface

Secret Sentinel for Confluence scans pages and comments. Secret Sentinel for Jira scans work items and comments. The apps are separate installations; either can redact inside its host product, and an optional cross-product setup can create Jira incidents for findings.

This is not repository scanning. GitHub, GitLab, pre-commit, CI artifacts, local files, and chat systems require their own controls. A credential pasted only into Jira cannot be found by a tool that reads only git, and Secret Sentinel does not claim to replace that tool.

Detection: an open-source engine you can read

Since 6 November 2026 detection runs on keysnitch, our open-source engine (MIT, on GitHub). It has 250 rules from 128 companies and projects: every gitleaks rule for text, plus its own rules for Atlassian tokens, Azure Storage keys and passwords written next to a label, in a setting, a URL, a header, a table or a sentence. Every rule is checked for linear-time matching before it runs. Until then Secret Sentinel used secretlint with two rules of its own (a JWT detector and bare AWS identifiers). A test of 1,400 fake leaks showed that secretlint missed every Atlassian API token, which is why we moved. Bare identifiers that are not usable credentials by themselves still get a lower severity.

Advanced customers can define internal credential formats with custom regular expressions. Those patterns run through RE2, whose linear-time matching avoids catastrophic-backtracking ReDoS. Custom patterns enter the same type, severity, redaction, and escalation pipeline as built-in detections.

Response: redact broadly, escalate proportionately

The default severity model distinguishes complete usable credentials from partial or generic identifiers. A paired AWS credential, private key, provider token, or connection string is high risk; a generic assignment or bare identifier can be medium or low. Administrators can override severity and escalation per type.

Redaction and escalation are deliberately separate. A detected value is redacted regardless of whether it creates a Jira incident. Exact known-safe values are the narrow exception: an admin can ignore a specific placeholder, stored as a hash rather than retained in plaintext. Exclusion controls can suppress incident creation for selected spaces, projects, or comments without turning off ordinary redaction.

Processing boundary: Forge without an external service

Detection, configuration, redaction, and escalation run inside Atlassian infrastructure. There is no vendor-operated external scanner receiving page or issue content. That removes one data processor from the threat model; customers should still review requested scopes, Atlassian’s platform controls, and their own Jira and Confluence permissions.

Reproduce the claim safely

The documentation includes synthetic copy-paste input and exact expected redaction output, including a combined check for the supported text-detectable classes and a separate GCP service account JSON example. It also documents a limitation: raw AWS private-key .p12 detection in the upstream engine depends on filesystem access and cannot be exercised through pasted Confluence or Jira text.

Run tests in a dedicated test project and space. Use only inert examples from the documentation, record the app version and settings, test descriptions and comments separately, and verify both redaction and escalation. Add safe negative examples—hashes, placeholders, and IDs—to observe noise behavior. Never create a live credential for a scanner demonstration.

Finally, treat successful redaction as containment, not revocation. If a real credential is ever found, rotate it at the provider and verify the exposed value no longer works. Transparent methodology means documenting both what the scanner does and where its responsibility ends.