Data Egress Is the Hidden Risk in Atlassian Security Apps

The scanner has to see the thing it scans

A security team evaluates an app that promises to find credentials in Confluence. The feature list looks right, but the first architecture question is missing: does page content stay inside Atlassian’s platform, or is it sent to the vendor’s API for detection?

That is not procurement paperwork. A secret scanner receives exactly the strings an attacker wants: tokens, private keys, connection strings, and the context around them.

Atlassian’s official Forge data residency documentation distinguishes Forge-hosted storage from Forge Remote. Hosted in-scope data can follow the Atlassian app’s pinned location. Remote backends can also qualify for PINNED when configured with region-specific URLs. Atlassian also states that a manifest with an external fetch domain or an undeclared remote is assumed to store in-scope end-user data remotely by default.

PINNED answers one question, not every question

Residency asks where in-scope data is hosted. It does not by itself answer who operates the processor, which subprocessors receive telemetry, how long logs persist, who can access support copies, or what deletion means after uninstall. A region-pinned vendor backend can be a sound architecture; it is still an additional trust boundary.

Ask vendors for a concrete data-flow diagram and verify five stages:

1. Input: which Jira and Confluence fields are read, and under whose authorization?
2. Transit: which domains receive content, metadata, identifiers, or diagnostics?
3. Processing: is detection performed in Forge functions or in a remote service?
4. Persistence: are matches, snippets, hashes, or whole documents stored or logged?
5. Deletion and support: what remains after uninstall, and can vendor staff view it?

Avoid yes/no questions such as “are you GDPR compliant?” They permit a policy answer where an architecture answer is needed.

Why no egress changes the threat model

If processing has no external service, there is no vendor database of findings to breach, no support console containing captured snippets, and no cross-customer processing tier to isolate. The app still needs least-privilege scopes, secure storage, reliable deletion, and careful code; one boundary has been removed, not all risk.

Secret Sentinel is built entirely on Atlassian Forge and declares no external service: scanning, redaction, configuration, and optional Jira escalation remain inside Atlassian infrastructure. That is a narrower and independently understandable claim than “cloud secure.” Review it alongside the app’s requested scopes and documentation.

The same design principle appears in envseal: secret encryption and runtime injection do not require a vendor cloud. These products address different platforms, but the trust proposition is consistent—minimize the systems that ever receive plaintext.