Security Policy
SPHIOR Ledger for Jira
This Security Policy describes how SPHIOR ("we", "us", "our") secures SPHIOR Ledger for Jira (the "App") and the systems supporting its development and operation. For how we handle data, see our Privacy Policy at https://ledger.sphior.com/privacy.
1. Architecture & data protection
SPHIOR Ledger is built on Atlassian Forge and is eligible for the Runs on Atlassian program. · Zero outbound network egress. The App's manifest declares no external hosts; all processing happens inside the Atlassian-managed Forge runtime. · Tenant-isolated storage. All persistent data lives in Forge Storage (per-install SQL), inside your Atlassian tenant. We do not operate any external database, log shipper, or analytics endpoint. · No third-party sub-processors. The App has none. · Encryption in transit: TLS 1.2+ for every API call, enforced by Atlassian's Forge platform. · Encryption at rest: Forge Storage is encrypted by Atlassian. See Atlassian's Trust Centre at https://www.atlassian.com/trust for platform-level controls.
2. Tamper-evident ledger
The App's own audit ledger is protected by a SHA-256 hash chain. Each snapshot references the prior record's hash; silent edits to the ledger break the chain and are surfaced in the in-app integrity verifier. Customers can independently verify pack contents via the signatures included in every exported evidence pack.
3. Vulnerability management & secure development
· Automated security scanning. As web security audit (authenticated DAST/SAST/SCA) is SPHIOR's core business, we run SAST (static code analysis), SCA (dependency / open-source scanning), and authenticated DAST against the App's reachable surfaces on a regular basis (at least quarterly and before significant releases). · Software bill of materials (SBOM). Dependencies are pinned via lockfiles; an SBOM is maintained and reviewed on each release. · Remediation timelines. Findings from scans are triaged and remediated under defined timelines aligned with Atlassian's Marketplace Security Bug Fix Policy (critical issues prioritized for the earliest possible release). · Runtime patching. The Forge runtime, Forge SQL engine, and Forge Storage are maintained by Atlassian; we adopt Atlassian's recommended runtime updates promptly and do not run unsupported runtime versions. · Static analysis & review. TypeScript strict mode, ESLint, and forge lint run on every commit; changes are peer-reviewed before merge to the main branch. · No secrets in source. Source repositories contain no credentials, tokens, or shared secrets; the App requests no end-user PATs or passwords, and Forge manages all platform tokens. · Penetration testing. We perform in-house authenticated security testing; independent third-party penetration testing is on our roadmap.
4. Security incident response
In the event of a confirmed security incident affecting the App: 1. Triage is initiated within 24 hours of confirmation. 2. Customer notification is sent via email to the contact-for-security-issues address on file for affected installations, within 72 hours of confirmed material impact, aligned with GDPR Article 33 expectations. 3. Root-cause analysis is conducted and a remediation plan is prepared. Customer-impacting fixes are released to the Atlassian Marketplace through the standard update pipeline. 4. Post-incident report is shared with affected customers and summarized publicly on this page when appropriate. Suspected security issues can be reported to security@sphior.com at any time. We acknowledge receipt within one business day.
5. Access controls (internal)
· Least privilege. Access to source repositories, the Atlassian Developer Console, and production deployment is restricted to the App's maintainers on a need-to-know basis. We do not use shared accounts or shared production credentials. · Source repository. The main branch is protected with required status checks (TypeScript, lint, and tests must pass before merge). · Developer Console. Access is restricted to the publisher account (founder@sphior.com) and uses Atlassian account-level authentication with multi-factor authentication (MFA) enabled. · Multi-factor authentication. MFA is enforced on all accounts with access to source code, the Developer Console, and deployment tooling. · Periodic access review. The list of accounts with access to development and deployment systems is reviewed at least quarterly, and access is revoked promptly when no longer required. · Production deployment is performed via the Atlassian Forge CLI; no shared production credentials are used.
6. Compliance & certifications
Compliance status: · GDPR Data Processor obligations: Adopted (see Privacy Policy §10). · CCPA Service Provider obligations: Adopted (no sale of personal information; processing limited to business purposes). · Runs on Atlassian program: Eligible. · SOC 2 Type II: Roadmap (post-launch). · ISO 27001: Roadmap (post-launch). · HIPAA: Not certified — the App is not intended for PHI storage. We do not currently hold SOC 2 or ISO 27001 certifications. The App's Runs on Atlassian eligibility inherits Atlassian's platform-level certifications for the underlying infrastructure; customers requiring our own certifications should contact us about roadmap timing.
7. Responsible disclosure
We welcome security research on the App. Please report findings privately to security@sphior.com with: · A description of the issue · Steps to reproduce · Impact assessment · Any suggested mitigations We commit to: · Acknowledging your report within 1 business day · Providing an initial triage decision within 5 business days · Not pursuing legal action against good-faith researchers who follow this policy Atlassian Marketplace Security Bug Bounty Program participation is a roadmap item; until enrolled, please disclose directly to us.
8. Customer-side security controls
The App is administered through Jira's existing admin interface and inherits Jira's authentication, authorization, and audit-log infrastructure. We strongly recommend: · Restricting Jira admin permissions to a minimal set of trusted individuals. · Enabling two-factor authentication on all Atlassian accounts. · Reviewing the in-app Recent activity table periodically to confirm that the snapshot pipeline is operating as expected. · Generating and archiving evidence packs as part of your audit routine — packs contain independent signatures customers can verify outside the App.
9. Workstation & developer security
· Full-disk encryption. Development workstations use full-disk encryption (e.g. FileVault). · Screen lock & MFA. Workstations auto-lock when idle and require authentication; account access requires MFA. · Patching. Operating systems and development tooling are kept current with vendor security updates. · Endpoint protection. Workstations run vendor-supported endpoint malware protection. · Credential hygiene. Secrets and tokens are never committed to source control; platform tokens are managed by Forge.
10. Logging & monitoring
· Forge platform logs. App execution logs are available through the Atlassian Forge platform (forge logs) and Developer Console; we do not ship logs to any external system. · No customer data in logs. Application logging is written to avoid recording personal data or raw customer configuration; identifiers are minimized. · In-app observability. The App surfaces its own operational health — capture success rate, hash-chain integrity, and recent activity — directly in the admin UI, so administrators can confirm correct operation without external tooling.
11. Business continuity & disaster recovery
· Platform-backed durability. Persistent data lives in Atlassian-managed Forge Storage, which inherits Atlassian's platform-level backup, replication, and durability controls. See Atlassian's Trust Centre at https://www.atlassian.com/trust. · No separate infrastructure. Because the App runs entirely inside the Forge runtime, there is no separate SPHIOR-operated server, database, or service to fail independently of the Atlassian platform. · Source recoverability. Application source is version-controlled and can be redeployed to the Atlassian Marketplace through the standard publishing pipeline. · Customer-side export. Administrators can generate and archive evidence packs at any time, providing an independently verifiable copy of the ledger outside the App.
12. Artificial intelligence
SPHIOR Ledger uses no artificial intelligence or machine-learning models in its core functionality. Configuration capture, diffing, hash-chaining, attribution, and compliance mapping are fully deterministic. No customer data is sent to any AI/ML service — consistent with the App's zero-egress architecture.
13. Policy review & communication
This Security Policy and our internal security practices are reviewed at least annually, and whenever a significant change to the App or its operating environment occurs. Relevant practices are communicated to any contractors or third parties engaged in development or operations. The "Last updated" date above reflects the most recent review.
14. Contact
Security issues: security@sphior.com General contact: support@sphior.com Privacy inquiries: see Privacy Policy at https://ledger.sphior.com/privacy
Last updated: 2026-06-29