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: open-source engine plus documented additions

Most built-in detection uses secretlint, a maintained open-source engine. Secret Sentinel documents additional handling where upstream defaults do not cover the desired collaboration risk: a generic JWT detector and enabled detection for bare AWS identifiers. The latter receive lower severity when they are not usable credentials by themselves.

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.