Keelcroft / GitHub Issues Sync for Jira / Security

Security

Effective 27 October 2026. This page describes the GitHub Issues Sync for Jira release and its explicit limits.

Architecture

The app runs on Atlassian Forge. Jira data is sent directly from Forge to the customer-selected GitHub destination; Keelcroft operates no relay or vendor-hosted backend. Persistent app records use Forge storage, and credentials use Forge encrypted secret storage.

Access controls

• Connection, mapping, health check, webhook repair, enable, pause, link, unlink and replay actions require Jira project administrator permission, checked by the backend for every request.
• Each connection is scoped to one numeric Jira project ID and one GitHub repository.
• Linking re-reads the Jira issue and refuses issues outside the connected project.
• Changing the GitHub destination is blocked while sync is enabled or linked pairs remain.

Credentials and webhooks

• The customer supplies a repository-scoped GitHub personal access token. It is never returned to the user interface or written to application logs.
• GitHub webhook requests are authenticated with HMAC-SHA256 over the raw request body before parsing.
• Webhook setup is serialized per connection and recovers idempotently after ambiguous requests.
• Setup, repair, pause and configuration changes use the same connection lock. Pause records the disabled state before attempting remote cleanup; a cleanup failure is reported rather than silently treated as removal.
• Read-only health checks expose credential access, required webhook events, TLS verification and GitHub's last delivery status, not callback URLs, secrets or provider error bodies. A delivery snapshot is not an end-to-end availability guarantee.
• GitHub Enterprise Server hosts must be customer-approved HTTPS egress destinations; local, private and link-local hosts are rejected.

Data integrity

• Every write is followed by an independent read from the destination and a value comparison.
• At-least-once events are durably claimed, processed serially per connection and safe to replay.
• Conflicting edits are held or resolved by the configured policy and never silently discarded.
• The app never deletes Jira or GitHub issues. Missing records mark the pair failed.
• The event journal stores identifiers, outcomes and field names, not issue content.
• Optional new-comment copying excludes restricted/internal Jira comments and pull-request comments. Five pages of 100 comments per platform and 10 copied comments per direction bound a pass; incomplete histories fail closed. Comment edits and deletions are not mirrored.
• Explicit assignee mappings use administrator-supplied Jira account IDs and GitHub logins. Additional GitHub assignees are preserved; unassignment is blocked if it would remove them.
• Expired/revoked-token and non-retryable access failures stop with a failed, replayable pair. Transport/rate-limit failures retain bounded retries. Recovery requires fixing access and replaying; no automatic recovery of every missed historical edit is promised.

Vulnerability reporting

Report suspected vulnerabilities privately to support@keelcroft.com with the subject line “Security”. Include reproducible steps and impact, but do not access data that does not belong to you or send credentials. Critical security reports receive an initial response within one business day.

The app does not claim SOC 2, Cloud Fortified, an independent penetration test, or participation in the Marketplace Security Bug Bounty Program.