Security

Velum Privacy for Jira and Confluence is a security product, so the smallest attack surface we can ship is the one that never holds your data. The app runs entirely on Atlassian Forge. There is no vendor-operated server, database, or backup that contains customer content. Detection, masking and erasure all run inside your own Atlassian tenant. A compromise of Velum cannot expose your Jira or Confluence data, because we never hold it.

To report a vulnerability, email security@su.engineering.

Architecture

Velum Privacy is Forge-native. There is no Forge Remote, no vendor backend, and no third-party AI service in the request path.

• PII detection runs in-process: a regular-expression engine plus an on-device NER model executing under onnxruntime-web (WASM) inside the Forge function.
• All persistence uses Forge app storage, scoped to your installation. App data is deleted when you uninstall.
• The only outbound request is a one-time download of the public, static AI model file from the Hugging Face CDN at cold start. It carries no customer content, and the two permitted hosts are declared in the app manifest. Forge blocks everything else at the platform level.

Your content never leaves your Atlassian instance.

Data protection

• Encryption at rest. Atlassian platform encryption on all Forge storage.
• Reversal keys. The token-to-value mapping that makes masking reversible is additionally encrypted with AES-256-GCM at the application layer, keyed by a Forge encrypted variable, on top of platform encryption.
• Encryption in transit. TLS 1.2 or above on all requests.
• Tenant isolation. Storage is scoped per installation. No cross-tenant data path exists.
• Credentials. The app collects no Atlassian or third-party credentials and holds no secrets of its own. Forge issues its runtime authentication.

Access control

Authorization is evaluated per product and per method. Every backend method that reads or changes findings, audit records, reversal keys or configuration verifies that the caller administers the Atlassian product the content belongs to: a Jira administrator manages Jira findings, a Confluence administrator manages Confluence findings, and neither sees the other's. Changing detection policy, which governs scanning in both products, requires administrator rights in both.

UI placement is not treated as an authorization boundary. The checks live in the backend, where they cannot be bypassed by calling the app directly.

Admin-initiated content changes execute as the requesting user, so the app's effective access never exceeds that administrator's own permissions. De-anonymization, the highest-risk operation, is admin-gated and audit-logged without exception.

Logging and audit

• The app maintains an in-tenant, append-only audit log of scans, masking, de-anonymization, configuration changes and administrative actions.
• Audit entries are scoped to the product they concern and visible only to an administrator of that product. Entries reference a data subject by salted hash, never by name or email.
• Detected values, credentials and access tokens are never written to platform logs. This is enforced by review on every change.

GDPR

Velum Privacy includes GDPR Article 17 tooling. Locate every occurrence of a data subject across Jira and Confluence, export an audit-ready report, then erase them. Erasure redacts the values in the content itself, deletes the copies Velum stored, and destroys the reversal keys for those locations, so the removal cannot be undone. Because all data stays in your Atlassian instance, you remain the data controller.

Secure development

• Source is held in a private repository; access requires multi-factor authentication.
• Dependencies are reviewed against published advisories; the tree is almost entirely Atlassian's own Forge SDK, and upstream advisories are tracked and shipped when Atlassian releases a fix.
• The app requests the narrowest scopes its functionality allows. Every new scope requires written justification before release.
• The OWASP Top 10 is the reference for security review of application changes.

Vulnerability disclosure

If you believe you have found a security vulnerability, report it to security@su.engineering with enough detail to reproduce it. We acknowledge reports within two business days and keep you updated until the issue is resolved. Please give us reasonable time to ship a fix before public disclosure. We will not pursue legal action against researchers who report in good faith and avoid privacy violations, data destruction or service disruption while testing.

Vulnerabilities may also be reported through Atlassian's Marketplace Security channel. Remediation follows the Atlassian Marketplace security bug fix policy timelines.

Incident response

We maintain a documented incident response plan covering triage, severity classification, containment, remediation and notification. If an incident affects your data, we notify affected installations within 72 hours of confirming impact, using Atlassian's partner notification templates, and notify Atlassian in parallel. Where facts are still uncertain, we say so rather than issue reassurance the evidence does not support.

Compliance

su.engineering does not currently hold ISO 27001, SOC 2 or PCI certification. We would rather state that plainly than imply otherwise. The app's security posture rests on architecture, no vendor-side data, and on the controls described above, and is reviewed at least annually.

Other Velum products

Everything above concerns Velum Privacy for Jira and Confluence. Velum ships the same engine across other surfaces, each with its own posture. They share one principle with the Atlassian app: your content never reaches a vendor server.

Endpoint apps (browser extension, desktop, CLI)

• No network in the masking path. Models are bundled or cached locally, remote model loading is disabled, and this is enforced in the build by a static scan and a runtime network-block test. The desktop app makes five outbound requests and none of them carries document text: an update check on launch, a signed licence revocation list on launch, the optional one-time model download, a single activation report at the moment a licence key is entered, and a single trial registration on first run. The app enumerates all five on its own Protection page and in the protection receipt it exports.
• Mappings stay on the device. They are encrypted at rest with AES-256-GCM, the key held in the OS keychain, or kept in memory only and discarded on quit, at the user's choice.
• Unmasking is never gated, not even by licensing, so nothing already masked is ever locked away. Licence keys are signed offline and verified locally against an Ed25519 public key, so masking keeps working with no network. Two of the five requests concern licensing: the activation report, whose result the app ignores, and the trial registration, which is what stops a free trial being restarted by deleting local files. Each is sent once, and each carries a one-way hash rather than an identifier: the activation report a hash of the install's random id, the trial registration a salted hash of the machine's platform UUID. Neither carries document text, an email address or a licence key.

Embedded loopback service

Runs as a local sidecar bound to 127.0.0.1. Internal applications call POST /mask and POST /unmask. Mappings are held in memory only, loopback-bound and expiring, and are never persisted, so the "no sensitive data at rest" property holds for the AI features you build on it.

Source-available engine

The detection-and-masking core is licensed under PolyForm Noncommercial rather than a closed licence, so it can be read rather than taken on trust. It is not published yet. The packages are prepared for release to npm as @velumprivacy/* and are not on the registry today, so the auditability that licence buys is a commitment and not yet a fact. The licensing page states this the same way. Diagnostics and usage logs contain counts and timings only, never document text. To report a vulnerability in any Velum product, email security@su.engineering.