Security
Last updated: August 30, 2026
Sullins Labs builds apps for the Atlassian Marketplace. This page explains how they are built and where your data goes. It covers PIER, our Mermaid diagram rendering app for Confluence and Jira; SOUNDING, our Confluence permissions-inventory app; and DRYDOCK, our Confluence stale-page finder. It will be updated as further apps ship.
No connections outside Atlassian's infrastructure
PIER makes zero connections outside Atlassian's infrastructure. The Mermaid library is bundled into the app rather than loaded from a content delivery network, and rendering happens entirely in your browser. There are no external servers, no third party services, no CDNs, and no analytics. Nothing you write leaves Atlassian's infrastructure.
SOUNDING also makes no connections outside Atlassian's own infrastructure. It calls Confluence's own REST API to build its permissions-inventory dashboard, but talks to no third-party service, analytics provider, CDN, or external API.
DRYDOCK also makes no connections outside Atlassian's own infrastructure. It calls Confluence's own REST API and Confluence Analytics to run its staleness scan and archive pages, but talks to no third-party service, analytics provider, CDN, or external API. Drydock stores no personal data of any kind; see the privacy policy for exactly what it stores instead.
Built on Forge
PIER, SOUNDING, and DRYDOCK are Atlassian Forge apps. Each runs on Atlassian's own platform rather than on infrastructure we operate. Sullins Labs does not run any servers or databases, so there is no system of ours for your content to be copied to.
Permissions
PIER requests a single scope, storage:app.
That scope grants access only to the app's own storage namespace. It
does not grant access to page content, space data, user records, or
any other product data.
The Confluence macro requires no scopes at all. Diagram source is held in the macro's own configuration, alongside the page it belongs to.
SOUNDING requests these scopes: read:space:confluence,
read:space.permission:confluence, read:page:confluence,
read:content-details:confluence, read:content.permission:confluence,
read:user:confluence, read:group:confluence, and
storage:app. The read scopes are what let it read your
spaces, pages, and permission grants to build its permissions-inventory
dashboard; storage:app grants access only to the app's own
Forge KVS storage namespace, where it holds scan results. As covered in
the privacy policy, SOUNDING does not use the
content of your pages, only the structural and permissions metadata
these scopes expose.
DRYDOCK requests these scopes:
read:analytics.content:confluence,
read:content.metadata:confluence,
read:page:confluence, write:page:confluence,
read:space:confluence, and storage:app. The
read scopes let it list pages, check their age and analytics
view-count, and confirm space-admin status; write:page:confluence
is used only for the single-page archive call. storage:app
grants access only to the app's own Forge KVS storage namespace, where
it holds scan progress and results. Drydock never stores an accountId,
a display name, or page content. Confluence returns some of these
fields in its own API responses, and Drydock discards them at the API
boundary rather than persisting them. The one accountId it sees is used
only for an in-memory space-admin check and is never written to
storage.
Where data is stored
In Confluence, PIER's diagram source lives in the macro's configuration, so it travels with the page and is covered by your existing Confluence permissions, backups, and retention. Nothing is duplicated elsewhere.
SOUNDING's scan results are stored in Forge KVS, in the app's own storage namespace within your Atlassian site.
DRYDOCK's scan data (page-level metadata and scan-run bookkeeping, no personal data) is stored in Forge KVS, in the app's own storage namespace within your Atlassian site. Drydock keeps the current scan run and the run immediately before it, and cleans up older runs as later scans complete, rather than overwriting on every scan.
Reporting a vulnerability
Send suspected vulnerabilities to security@sullinslabs.com. Please include enough detail to reproduce the issue. We will acknowledge your report and keep you updated as we investigate.
Please do not disclose publicly until we have had a reasonable opportunity to respond.
Related
The privacy policy covers what data is collected and how long it is kept. The PIER documentation, Sounding documentation, and Drydock documentation cover installation and use for each app.