/
Security Policy for Enterprise Sprint Automation — Bulk Create & Auto Start/End App

Security Policy for Enterprise Sprint Automation — Bulk Create & Auto Start/End App

Security Policy — Enterprise Sprint Automation — Bulk Create & Auto Start/End

This Security Policy describes how Enterprise Sprint Automation — Bulk Create & Auto Start/End ("the app") is designed, built, hosted and operated, and the safeguards that protect customer data. It applies to all Atlassian Marketplace installations of the app.

1. Hosting and architecture

Enterprise Sprint Automation — Bulk Create & Auto Start/End is a native Atlassian Forge app. It runs entirely inside Atlassian's Forge runtime in the Atlassian cloud. The app has no external servers, no self-hosted infrastructure, and no third-party hosting provider.

All compute, storage and networking is provided by Atlassian's Forge platform. No customer data is handled outside Atlassian's cloud.

Because the app runs inside Forge, Atlassian operates the underlying compute, storage and network infrastructure. Atlassian's own security posture — including SOC 2, ISO 27001, PCI DSS and the Atlassian Trust portfolio — therefore applies to the infrastructure the app runs on.

See Atlassian's Trust Center for details: https://www.atlassian.com/trust.

1.1 Runs on Atlassian program

Runs on Atlassian is an Atlassian Marketplace trust program whose badge is granted automatically, by Atlassian, to Forge apps whose manifest and configuration demonstrate that:

  1. The app is built on Forge and runs only on Atlassian-hosted compute and storage.

  2. All in-scope customer data stays inside Atlassian's infrastructure; there is no non-Atlassian network egress, no remotes: block in the manifest, and no external resource domain.

  3. The app supports the data-residency regions supported by the host product.

  4. Any optional analytics egress is under the customer's control and never contains in-scope end-user data.

Enterprise Sprint Automation — Bulk Create & Auto Start/End is designed to meet these criteria:

  • It contains no remotes: block and declares no external resource domain in its manifest.yml.

  • It does not make outbound network calls to any host outside Atlassian's cloud. The app has no analytics SDK, no third-party error reporter and no customer-messaging integration.

  • All persistent data is held in Forge SQL and Forge KVS, which inherit the data residency of the host Jira Cloud site.

Award of the badge itself is Atlassian's decision and is based on Atlassian's automated manifest analysis.

2. Data residency and data flow

  • No data leaves the Atlassian cloud. The app does not transmit any customer data to Divim, Inc. or to any third party.

  • Jira data is read on demand. The app calls the Jira REST API through the Forge platform to read boards, sprints and issues. Jira data is processed in memory and is not persisted beyond the minimum configuration required to run automation.

  • No external network egress. The app does not make outbound calls to any host outside the Atlassian cloud. There is no telemetry, no analytics SDK and no third-party API call from within the app.

3. Data storage

All data the app persists is stored exclusively within your Atlassian environment using Forge SQL and Forge KVS — the same infrastructure covered by the Runs on Atlassian guarantee in section 1.1. No data is stored on any server operated by the vendor or any third party.

For a description of what data the app retains, see the Privacy Policy, section 3.

4. Authentication and authorization

  • The app authenticates to Jira exclusively through Forge's managed app identity. No OAuth client secrets, refresh tokens or API keys are managed by the app or the vendor.

  • Admin and space-admin checks are enforced server-side for all configuration-changing operations. The Bulk Sprint Creation space page is additionally gated so that only project administrators can access it.

  • The app requests least-privilege Jira scopes. See section 2 of the User Guide for the complete list.

5. Encryption

  • In transit: All communication with Jira, with Forge services and between the Custom UI and the backend uses HTTPS / TLS, terminated by Atlassian.

  • At rest: Forge SQL and Forge KVS encrypt customer data at rest, managed by Atlassian. See the Atlassian Forge documentation for details.

6. Secrets management

The app does not manage any long-lived secrets. Jira access is brokered by Forge on every invocation. No API keys, OAuth refresh tokens, or other credentials are stored inside the app.

7. Software development lifecycle

  • Source control: Source is maintained in a private repository with branch protection on the default branch. All changes land through reviewed pull requests.

  • Static analysis: A linter runs on every change.

  • Testing: The backend has an automated test suite that exercises the core business logic, lifecycle event processing and the scheduled sprint check. Tests are required to pass before a release build.

  • Dependencies: The app pins dependency versions. Advisory checks are run against published security advisory databases before adding or upgrading a dependency.

  • Builds: Production artifacts are built and deployed to the Forge platform. Only a small number of authorized maintainers can publish to the production Forge environment.

8. Change management and release

  • Each Marketplace release has a version string and release notes.

  • Database schema migrations run only from a dedicated, privileged handler that is invoked on app install and upgrade. The migration process is idempotent and is never triggered by user-invoked operations.

9. Logging and monitoring

  • The app emits structured console logs that Atlassian captures in the Forge platform log. Operators (the vendor) access these through Atlassian's operational tooling.

  • A subset of operator-relevant events is also written to Forge KVS as the in-app "Application logs" list, visible to Jira admins under Sprint Automation Configuration → Logs.

  • No personally identifiable information is deliberately logged. Error objects from Jira are serialized to log only their error codes and messages; payload content is not logged.

10. Vulnerability management and disclosure

  • The vendor welcomes responsible disclosure of security issues. Please email support@divim.io with reproduction steps. The vendor will acknowledge receipt within 5 business days and aim to remediate verified high-severity issues within 30 days.

  • Please do not publicly disclose a vulnerability before the vendor has had an opportunity to release a fix.

  • The vendor follows Atlassian's Marketplace Security Requirements and the Cloud Fortified / Cloud Security Participant programs where applicable.

  • A runtime error that the vendor reasonably believes has impacted customer data will be reported to affected customers without undue delay and in line with the Privacy Policy.

11. Incident response

In the event of a confirmed security incident affecting the app:

  1. The vendor will triage, contain and remediate the incident, coordinating with Atlassian where the incident touches Forge infrastructure.

  2. Affected customers will be notified by email to the published support contact and, where appropriate, via a notice on the Marketplace listing.

  3. A post-incident summary will be published in the Divim Trust Center once remediation is complete.

12. Business continuity

Because the app has no vendor-operated infrastructure beyond Atlassian Forge, business continuity and disaster recovery for all app data are inherited from Atlassian Forge's own SLA and DR posture. The vendor does not operate additional infrastructure that would require a separate DR plan.

13. Customer responsibilities

  • Maintain appropriate Jira user and admin permissions. The app respects Jira's permission model, but cannot prevent misuse by a user who has been granted excessive Jira permissions by the customer.

  • Review and approve the Jira scopes requested at install and at upgrade.

  • Keep contact details associated with the Atlassian site current so the vendor can reach the customer in the event of a security notice.

14. Contact

This policy is reviewed at least annually and updated as the app evolves. Material changes will be published in the Trust Center and communicated through the Marketplace listing.