ZenUML Security Overview

1. Scope

This overview covers the ZenUML Confluence Cloud apps (all editions, including ZenUML Diagrams, ZenUML Diagrams Lite, Diagramly and AsyncAPI for Confluence) and the ZenUML backend services that support them.

2. Platform architecture and data protection

• Built on Atlassian Forge. The apps run on Atlassian's Forge platform. The app user interface runs inside Forge's sandboxed iframes, and the app can access only the Confluence permission scopes declared in its manifest.
• Confluence is the system of record. Diagram content is stored in Atlassian Confluence. Our backend is not required storage for your diagrams (see the Privacy Policy for the mirrored copy and its retention).
• Authenticated backend requests. Every request from the app to our backend carries an Atlassian Forge invocation token. The backend verifies the token's RS256 signature against Atlassian's published signing keys and checks its issuer and required claims before processing the request.
• Tenant isolation. The backend takes the Confluence site (tenant) identity from the verified invocation token, not from request parameters. A request cannot read or write another site's data by naming it.
• Encryption in transit. All traffic to our services uses TLS/HTTPS, including secure WebSockets (wss).
• Encryption at rest. Data in our backend (Cloudflare D1, R2 and KV) is encrypted with AES-256 (GCM), with keys managed by Cloudflare.
• Data minimization. We do not collect email addresses or passwords through the Confluence app. Product analytics carry metadata only, never diagram content. Optional features that send data to third parties (AI features, Live Agent Link) are off by default.

3. Vulnerability management

• Dependency monitoring. Automated dependency-update tooling (GitHub Dependabot) checks our dependencies every week and opens pull requests for updates, which are built and tested like any other change.
• Severity rating. We rate vulnerabilities with CVSS v3 and fix them within the timeframes set by Atlassian's Security Bug Fix Policy for Marketplace apps, counted from when the issue is reported or triaged:

Vulnerabilities reported to us through Atlassian (for example via the Atlassian Marketplace Security program) are handled on the same timeline.

4. Responsible disclosure

If you believe you have found a security vulnerability in a ZenUML product, please report it to us privately:

• Contact: [email protected], subject "Security vulnerability report", or our support portal at ZenUML support portal.
• What to include: the affected product and version, steps to reproduce, the potential impact, and any proof of concept.
• Our commitment: we acknowledge your report within 3 business days, keep you informed while we investigate and fix it, and let you know when it is resolved.
• Please: test only against Confluence sites you own, do not access or modify other customers' data, avoid degrading the service, and give us reasonable time to fix the issue before public disclosure.

5. Incident response and breach notification

We handle security incidents in four stages:

1. Detect and triage. We identify suspected incidents from monitoring, alerts, customer reports and Atlassian notifications, then assess their scope and severity.
2. Contain. We limit the impact, for example by revoking or rotating credentials, disabling the affected feature or rolling back a release.
3. Eradicate and recover. We remove the root cause, deploy a fix and restore normal service.
4. Review. After the incident we review what happened and put in place measures to prevent it recurring.

Customer notification: if we confirm a security breach that affects customer data, we notify affected customers within 72 hours of confirmation. The notice describes what happened, what data is affected, what we are doing about it and any steps customers should take. Where required, we also notify Atlassian and the relevant authorities. If a breach involves one of our sub-processors, we notify affected customers within the same timeframe after the sub-processor informs us.

6. Access control and internal security practices

• Multi-factor authentication. MFA is required on all team accounts with access to our source code, Atlassian developer and Marketplace accounts, and cloud infrastructure (GitHub, Atlassian and Cloudflare).
• Least privilege, role-based access. Access to production systems and customer data is limited to the core team members whose role requires it.
• Scoped credentials. Service credentials and API tokens are scoped to the systems they need. Production secrets are stored in the platform secret stores (Cloudflare and GitHub Actions encrypted secrets), not in the source repository.
• Minimal app permissions. The apps request only the Confluence scopes they need to render and store diagrams.

7. Secure software development lifecycle

• Version control. All code changes are tracked in version control. The source repository does not accept pull requests from outside contributors (forks).
• Automated testing. Every change is built and runs automated unit tests and end-to-end tests in continuous integration before it reaches production.
• Pipeline-only deployment. Staging and production deployments run through our CI/CD pipeline, not from developer machines. Each change is verified on staging before release.
• Staged production rollout. Production releases go out to one edition first as a canary before the others, and each release is followed by a production validation check.
• Dependency hygiene. Dependencies are pinned in a lockfile and updated through the automated process in section 3.

8. Sub-processors

The sub-processors we use, what each one receives, and their encryption and compliance posture are listed in Section 10 of our Privacy Policy.

9. Changes to this document

We may update this Security Overview as our practices change. Updates will be posted on this page with a new "Last updated" date.

10. Contact

Security questions and reports: [email protected] or our support portal.