LogMyTime — Security Policy

Publisher: LogMyTime, by Bazoho · Contact: support@bazoho.com · Last updated: 2026-08-25

LogMyTime is built 100% on Atlassian Forge: Atlassian-hosted compute (sandboxed Node.js), Atlassian-hosted storage (Forge SQL), and Atlassian-managed identity. Bazoho operates no servers, domains, or databases of its own, and the app declares no external egress — the Forge platform blocks any undeclared network call at runtime.

Platform

• All app data lives in Forge SQL, hosted by Atlassian inside your Jira Cloud site’s region. Encryption in transit and at rest, backups, and physical security are provided by the Atlassian platform.
• No external egress is declared in the app manifest; undeclared network calls are blocked by Forge at runtime.
• Scopes requested: read:jira-work, write:jira-work (used only for the optional native-worklog mirror/import), read:jira-user (display names and user search for pickers), storage:app (required for Forge SQL).

Authorization model

Authorization is enforced server-side in every resolver:

• Caller identity comes exclusively from the Forge invocation context, never from request payloads.
• Users can only read and modify their own worklogs; approver access is derived from team approver assignments per request; admin endpoints re-check Jira’s ADMINISTER permission on every call.
• The approval state machine prevents approvers from acting on their own timesheets; submitted and approved sheets lock their worklogs; every transition is recorded in the audit trail.
• Jira data (issue summaries, display names, user search) is fetched as the viewing user, so Jira’s browse permissions and profile-visibility settings apply to what each viewer sees.

Application security

• All SQL runs through a single parameterized-prepared-statement wrapper module.
• CSV exports neutralize spreadsheet formula injection (leading =, +, -, @ escaped), covered by unit tests.
• The app holds no secrets: no API keys, tokens, passwords, or webhooks anywhere in the code, configuration, or storage.
• The frontend is Forge Custom UI under a strict Content Security Policy: no external scripts, fonts, images, or network targets; all assets are bundled and served from Atlassian’s CDN.
• Third-party dependencies are continuously scanned for known vulnerabilities and updated in line with Atlassian’s Marketplace security bug-fix policy.

Data protection

• Stored personal data is minimal: Atlassian account IDs and user-entered worklog text. Names, email addresses, and avatars are resolved live from Jira per viewer and never persisted. See the privacy policy for the full data inventory.
• Uninstalling the app permanently deletes the installation’s entire database per Atlassian policy.

Vulnerability management

• Third-party dependencies are continuously scanned for known vulnerabilities (npm audit / automated dependency alerts) and patched in line with Atlassian’s Marketplace security bug-fix policy SLAs: critical issues as soon as possible within the published SLA window, lower severities per policy.
• Reported vulnerabilities are triaged and reproduced, then rated with CVSS to set the fix timeline.
• Every security fix ships with a regression test and is verified on a test site before the staged production rollout. Forge deployments take effect immediately, so fixes reach all customers without any customer-side action.
• We also receive and act on Atlassian vulnerability-management (AMS) tickets via our registered security contact.

Incident response

We maintain a written incident response plan aligned with Atlassian’s Marketplace incident-management guidelines. Because the app has no vendor-operated infrastructure, the relevant incident classes are a defect in the app’s own code, compromise of a developer account, or a platform incident on Atlassian’s side. Our process:

1. Acknowledge reports within 2 business days.
2. Triage and contain — reproduce and severity-rate the issue; because Forge deployment is immediate, containment normally means deploying a fix or disabling the affected feature. Suspected account compromise triggers credential rotation, session revocation, and a deploy-history audit.
3. Assess impact using the app’s audit trail and Forge invocation logs; since data never leaves Atlassian, exposure analysis is scoped to what the flaw allowed within an affected site.
4. Notify — if customer data was or may have been affected, or a critical vulnerability existed, we notify Atlassian and affected customers without undue delay, using Atlassian’s vulnerability-notification format.
5. Learn — every incident ends with a retrospective and any resulting changes to our practices and this policy.

Vendor operational security

• No customer data ever resides on vendor systems — we have no servers, databases, or backups of our own, and the Forge platform gives us no path to read installation data in the ordinary course of operations.
• Developer accounts with publishing or code access (Atlassian developer console, source hosting, email) are protected with multi-factor authentication; deployment credentials are rotated periodically. The app itself holds no secrets of any kind.
• All changes are version-controlled, tested (unit and end-to-end suites run before every deploy), and deployed to a test site before production via separate Forge environments.

Known trade-offs and disclosures

• Jira admins can act on their own timesheets (a small-team escape hatch); organizations requiring strict separation of duties should route approvals through a non-admin approver. A configuration toggle for this is on the roadmap.
• The optional native-worklog mirror writes Jira worklogs as the acting user (write:jira-work); disable the toggle to run the app storage-only.

Vulnerability reporting

Report security issues to support@bazoho.com. We aim to acknowledge reports within 2 business days. Please include reproduction steps, and do not test against Jira sites you do not control.