Security Policy

This policy describes the security practices of T&J Małgorzata Ośródka (operating under the brand “VelociBit”) (“we”, “us”, the “Vendor”) for the Blobify – Cloud Attachments for Jira app (the “App”) distributed through the Atlassian Marketplace.

1. Summary (the short version)

• We operate no servers. Blobify runs entirely inside Atlassian Forge. There is no VelociBit infrastructure between you and your data.
• File contents never reach us. The App signs a short-lived URL inside Forge; your browser transfers the file directly to your own cloud storage. The bytes never pass through, or rest on, any system we control.
• Your storage stays yours. Files live in a bucket or container you own, at a provider and in a region you choose.
• The App's backend cannot make outbound network calls. This is enforced by the Forge platform, not merely by our code — see section 3.

2. Architecture and data flow

Blobify is a Forge-native app. All App code executes either in Atlassian's Forge runtime or in the end user's browser. There is no third location.

An upload proceeds as follows:

• The Forge backend verifies the user's Jira permissions, then computes an object path and signs a URL locally using the storage credentials you configured.
• The signed URL is returned to the browser. The browser performs the transfer directly to your storage endpoint over TLS.
• The browser confirms completion, and the backend records metadata (filename, size, MIME type, timestamp, and the uploader's Atlassian account ID) as a Jira issue property.

Downloads follow the same pattern in reverse. At no point does the App receive, buffer, proxy, or store file contents.

3. Network egress

The App's Forge manifest declares client-side egress only — permitted destinations are the storage providers' own domains. The manifest declares no backend egress permission at all, which means the Forge platform will refuse any outbound network call attempted by the App's backend. This is a platform-enforced guarantee rather than a policy commitment.

Administrators using a self-hosted or arbitrary S3-compatible endpoint (for example MinIO or Ceph) must explicitly register and approve that endpoint for their own installation. The App cannot reach an endpoint that the installation's own administrator has not approved.

4. Encryption

• In transit — all traffic to Atlassian and to storage endpoints uses TLS.
• At rest — file contents rest in your own storage account and are protected by the encryption-at-rest controls of the provider you chose and configure. We do not weaken, intercept, or substitute those controls, and because we never hold the files we cannot encrypt them on your behalf.
• Signing — signed URLs are generated with HMAC-SHA256 computed inside the Forge runtime. Signing keys never leave Forge, and no signing is delegated to any external service.

5. Signed URL lifetime

Signed URLs are deliberately short-lived, scoped to a single object, and limited to a single operation:

A leaked URL is therefore useful only for a narrow window, against a single object, for a single action.

6. Credentials and secrets

• Storage credentials you configure are held in Forge encrypted secret storage. They are never written to logs, never returned to the browser, and never transmitted anywhere other than as part of a signature computation inside Forge.
• We recommend configuring least-privilege, scoped credentials for the App, restricted to the specific container or bucket it needs.

7. Access control

Blobify does not implement a parallel permission system. Authorization decisions are enforced server-side in the Forge backend on every request:

• By default, the App honours Jira's own attachment permissions — browse, create, and delete checks are evaluated against the calling user for the specific issue.
• Administrators may instead map access to custom project permissions for finer-grained control.
• Jira Service Management portal access is verified against Jira Service Management's own visibility rules for the request, checked as the calling customer before any attachment data is read, written, or signed for — so a customer sees exactly the requests the portal itself would show them, including requests shared with their organisation. Portal access is read-only unless an administrator explicitly enables portal uploads, and portal customers can never delete attachments.
• A signed URL is issued only after the permission check for that user and that operation has passed.

8. Logging

The App writes diagnostic logs only. Log entries contain Jira issue keys, HTTP status codes, and size counts — they do not contain file contents, filenames, personal data, or credentials. Logs remain within Atlassian's infrastructure and are not transmitted to any third-party logging or monitoring service; as noted in section 3, the backend has no egress permission with which to do so.

9. Secure development

• The App is written in TypeScript with strict type checking.
• Type checking, linting, an automated test suite, dependency vulnerability scanning (SCA), and static analysis (SAST) are run before each release.
• Dependencies are deliberately minimal — the App's runtime dependencies are Atlassian's own Forge packages, React, and a small number of well-established open-source libraries. There is no analytics SDK, error-tracking SDK, or telemetry library of any kind.
• Dependencies are reviewed and updated on an ongoing basis, and promptly when a security advisory affects a package we use.
• Source is maintained in a private repository with access limited to authorised personnel.

10. Vulnerability management

11.1 Reducing the attack surface

Our first line of defence is having less to defend. The App runs on Atlassian Forge and we operate no servers, so there is no host, network, container, or operating system of ours to patch. The App's runtime dependency tree is deliberately small, consisting of Atlassian's own Forge packages, React, and a limited set of well-established open-source libraries; we use no analytics, error-tracking, or telemetry libraries. A small dependency tree means fewer advisories to act on and a smaller supply-chain surface. A software bill of materials is maintained and available on request.

11.2 Identifying vulnerabilities

We become aware of vulnerabilities through:

• Dependency advisories — we monitor security advisories affecting the packages the App depends on, and review dependencies on an ongoing basis.
• Automated scanning — we run software composition analysis (SCA) over our dependencies and static analysis (SAST) over our source code, and generate a CycloneDX software bill of materials, as part of our pre-release security checks.
• Platform advisories — security notices published by Atlassian for the Forge platform and its SDKs.
• Reports from customers and researchers — see section 12.
• Our own review — changes affecting authentication, authorisation, signing, or secret handling receive particular scrutiny before release.

11.3 Triage and remediation

Reported and discovered vulnerabilities are assessed for severity based on exploitability and impact, taking into account the App's architecture — in particular that file contents never reside on systems we control. We aim to remediate according to the internal targets below. These are targets to guide prioritisation, not a contractual service level; actual timelines depend on severity, complexity, and any dependency on the Atlassian platform.

Every fix passes the same automated checks as any other change (section 9) before release. Because Blobify is a Forge app, a remediated version is deployed by us and propagates to installations without customers needing to take action.

11.4 Platform vulnerabilities

Vulnerabilities in the Atlassian Forge platform itself are Atlassian's to remediate, under the security programme published at atlassian.com/trust. Where a platform advisory requires action on our side — for example an SDK upgrade — we treat it under the same triage process above.

11.5 Customer-side responsibilities

The security of your own cloud storage account — its access policies, network restrictions, encryption settings, and the scope of the credentials you supply to the App — remains yours to manage. We recommend least-privilege, scoped credentials, and rotating them periodically.

11. Infrastructure and sub-processors

The only sub-processor we engage is Atlassian Pty Ltd, as the Forge platform on which the App runs and where App data at rest resides. Atlassian maintains its own certifications and security programme, published at atlassian.com/trust.

The cloud storage provider you configure is your own sub-processor under your agreement with them, not ours. We have no relationship with, contract with, or access to that account beyond the scoped credentials you supply to the App.

12. Reporting a vulnerability

We welcome reports from security researchers and customers.

Please report suspected vulnerabilities through our support portal or by email to support@velocibit.io with the subject line SECURITY. Include enough detail to reproduce the issue — affected component, steps, and impact.

• We aim to acknowledge your report within 3 business days.
• We aim to provide an assessment and remediation plan within 10 business days. These are targets rather than a guarantee.
• We ask that you allow us a reasonable opportunity to remediate before public disclosure, and that you avoid accessing, modifying, or destroying data belonging to others while testing.
• We will credit reporters who wish to be named.

We do not currently operate a paid bug bounty programme.

13. Incident response

In the event of a security incident affecting the App, we will investigate promptly, take action to contain and remediate, and notify affected site administrators without undue delay, describing what happened, what data was involved, and what steps we and they should take. Where the incident constitutes a personal data breach, we will support the customer (as data controller) in meeting their obligations under Article 33 GDPR, and will notify them without undue delay after becoming aware, consistent with our role as processor.

Because file contents never reside on systems we control, a compromise of the Vendor could not expose your file contents.

14. Certifications and assessments

We believe in stating our posture plainly rather than implying more than we have. As of the “Last updated” date above:

• The App runs on Atlassian Forge and inherits the platform security controls and certifications Atlassian maintains for it.
• We hold no independent SOC 2 or ISO 27001 certification, and we have not commissioned an independent penetration test of the App.
• We have not completed a CAIQ Lite questionnaire.

We will update this section as our security programme develops. If your procurement process requires an assessment we have not listed here, contact us and we will discuss it with you directly.

15. Changes to this Policy

We may update this Policy from time to time. Material changes will be reflected by updating the “Last updated” date above and, where appropriate, via the Marketplace listing.

---

Related documents: Privacy Policy · Terms of Use · Data Processing Agreement

16. Contact

T&J Małgorzata Ośródka (brand: VelociBit)
NIP: 7262479786
Jozefow 14B, Jozefow 95-002, Poland
Email: support@velocibit.io