Sicherheitsrichtlinie
SPHIOR Ledger for Jira
Diese Sicherheitsrichtlinie beschreibt, wie SPHIOR ("wir") SPHIOR Ledger for Jira (die "App") sowie die Systeme, die ihre Entwicklung und ihren Betrieb unterstützen, absichert. Zur Verarbeitung von Daten siehe unsere Datenschutzerklärung unter https://ledger.sphior.com/privacy.
1. Architektur und Datenschutz
SPHIOR Ledger basiert auf Atlassian Forge und ist für das Runs on Atlassian-Programm berechtigt. · Null ausgehender Netzwerk-Egress. Das Manifest der App deklariert keine externen Hosts; die gesamte Verarbeitung erfolgt innerhalb der von Atlassian verwalteten Forge-Runtime. · Tenant-isolierter Speicher. Alle persistenten Daten liegen im Forge Storage (per-install SQL) innerhalb Ihres Atlassian-Tenants. Wir betreiben keine externe Datenbank, keinen Log-Shipper und keinen Analytics-Endpunkt. · Keine Sub-Auftragsverarbeiter Dritter. Die App hat keine. · Verschlüsselung in Transit: TLS 1.2+ für jeden API-Aufruf, durchgesetzt durch die Forge-Plattform von Atlassian. · Verschlüsselung im Ruhezustand: Forge Storage wird durch Atlassian verschlüsselt. Plattformkontrollen siehe Atlassian Trust Centre unter https://www.atlassian.com/trust.
2. Manipulationssicheres Ledger
Das eigene Audit-Ledger der App ist durch eine SHA-256-Hash-Kette geschützt. Jeder Snapshot referenziert den Hash des vorherigen Eintrags; stille Änderungen am Ledger brechen die Kette und werden im integrierten Integrity-Verifier der App angezeigt. Kunden können Pack-Inhalte unabhängig über die in jedem exportierten Evidence Pack enthaltenen Signaturen verifizieren.
3. Schwachstellenmanagement und sichere Entwicklung
· Automatisiertes Security-Scanning. Da Web-Security-Audits (authentifizierte DAST/SAST/SCA) das Kerngeschäft von SPHIOR sind, führen wir SAST (statische Codeanalyse), SCA (Abhängigkeits-/Open-Source-Scanning) und authentifizierte DAST regelmäßig gegen die erreichbaren Oberflächen der App durch (mindestens vierteljährlich und vor wesentlichen Releases). · Software Bill of Materials (SBOM). Abhängigkeiten werden über Lockfiles gepinnt; eine SBOM wird gepflegt und bei jedem Release überprüft. · Behebungsfristen. Befunde aus Scans werden triagiert und innerhalb definierter Fristen behoben, ausgerichtet an der Atlassian Marketplace Security Bug Fix Policy (kritische Probleme werden für das frühestmögliche Release priorisiert). · Runtime-Patching. Die Forge-Runtime, die Forge-SQL-Engine und Forge Storage werden von Atlassian gewartet; wir übernehmen von Atlassian empfohlene Runtime-Updates zeitnah und betreiben keine nicht unterstützten Runtime-Versionen. · Statische Analyse und Review. TypeScript im strict-Modus, ESLint und forge lint laufen bei jedem Commit; Änderungen werden vor dem Merge in den main-Branch per Peer-Review geprüft. · Keine Secrets im Quellcode. Quell-Repositorys enthalten keine Anmeldedaten, Tokens oder geteilten Geheimnisse; die App fordert keine Endnutzer-PATs oder Passwörter an, und Forge verwaltet alle Plattform-Tokens. · Penetrationstests. Wir führen interne authentifizierte Sicherheitstests durch; unabhängige Penetrationstests durch Dritte stehen auf unserer Roadmap.
4. Reaktion auf Sicherheitsvorfälle
Bei einem bestätigten Sicherheitsvorfall, der die App betrifft: 1. Triage wird innerhalb von 24 Stunden nach Bestätigung eingeleitet. 2. Kundenbenachrichtigung wird per E-Mail an die hinterlegte contact-for-security-issues-Adresse betroffener Installationen innerhalb von 72 Stunden nach bestätigter wesentlicher Auswirkung versandt, ausgerichtet an den Erwartungen von DSGVO Artikel 33. 3. Eine Root-Cause-Analyse wird durchgeführt und ein Behebungsplan erstellt. Kundenbeeinflussende Fixes werden über die Standard-Update-Pipeline im Atlassian Marketplace veröffentlicht. 4. Ein Post-Incident-Bericht wird mit betroffenen Kunden geteilt und bei Bedarf öffentlich auf dieser Seite zusammengefasst. Verdächtige Sicherheitsereignisse können jederzeit an security@sphior.com gemeldet werden. Wir bestätigen den Empfang innerhalb eines Werktags.
5. Zugriffskontrollen (intern)
· Least Privilege. Der Zugriff auf Quell-Repositorys, die Atlassian Developer Console und das Produktions-Deployment ist nach dem Need-to-know-Prinzip auf die Maintainer der App beschränkt. Wir verwenden keine geteilten Konten oder geteilten Produktions-Anmeldedaten. · Quellrepository. Der main-Branch ist durch erforderliche Status-Checks geschützt (TypeScript, Lint und Tests müssen vor dem Merge bestehen). · Developer Console. Der Zugriff ist auf das Publisher-Konto (founder@sphior.com) beschränkt und verwendet Authentifizierung auf Atlassian-Konto-Ebene mit aktivierter Multi-Faktor-Authentifizierung (MFA). · Multi-Faktor-Authentifizierung. MFA wird auf allen Konten erzwungen, die Zugriff auf den Quellcode, die Developer Console und das Deployment-Tooling haben. · Periodische Zugriffsüberprüfung. Die Liste der Konten mit Zugriff auf Entwicklungs- und Deployment-Systeme wird mindestens vierteljährlich überprüft, und der Zugriff wird zeitnah entzogen, sobald er nicht mehr benötigt wird. · Produktions-Deployments erfolgen über die Atlassian Forge CLI; geteilte Produktions-Anmeldedaten werden nicht verwendet.
6. Compliance und Zertifizierungen
Compliance-Status: · DSGVO Data-Processor-Pflichten: übernommen (siehe Datenschutzerklärung §10). · CCPA Service-Provider-Pflichten: übernommen (kein Verkauf personenbezogener Informationen; Verarbeitung auf Geschäftszwecke beschränkt). · Runs on Atlassian-Programm: berechtigt. · SOC 2 Type II: Roadmap (nach Launch). · ISO 27001: Roadmap (nach Launch). · HIPAA: nicht zertifiziert — die App ist nicht für PHI-Speicherung vorgesehen. Wir halten derzeit keine SOC 2- oder ISO 27001-Zertifizierungen. Die Runs on Atlassian-Berechtigung der App erbt die Plattform-Zertifizierungen von Atlassian für die zugrunde liegende Infrastruktur; Kunden, die unsere eigenen Zertifizierungen benötigen, können uns zum Roadmap-Zeitplan kontaktieren.
7. Responsible Disclosure
Wir begrüßen Sicherheitsforschung zur App. Bitte melden Sie Erkenntnisse vertraulich an security@sphior.com mit: · einer Beschreibung des Problems · Schritten zur Reproduktion · Auswirkungsbewertung · vorgeschlagenen Gegenmaßnahmen Wir verpflichten uns zu: · Bestätigung Ihres Reports innerhalb von 1 Werktag · Bereitstellung einer ersten Triage-Entscheidung innerhalb von 5 Werktagen · keinem rechtlichen Vorgehen gegen Researcher in gutem Glauben, die dieser Richtlinie folgen Die Teilnahme am Atlassian Marketplace Security Bug Bounty Program ist ein Roadmap-Item; bis zur Einschreibung legen Sie bitte direkt uns gegenüber offen.
8. Kundenseitige Sicherheitskontrollen
Die App wird über die bestehende Admin-Oberfläche von Jira verwaltet und erbt Jiras Authentifizierung, Autorisierung und Audit-Log. Wir empfehlen dringend: · Jira-Admin-Berechtigungen auf einen minimalen Kreis vertrauenswürdiger Personen zu beschränken. · Zwei-Faktor-Authentifizierung für alle Atlassian-Konten zu aktivieren. · Die In-App-Tabelle Recent activity regelmäßig zu prüfen, um zu bestätigen, dass die Snapshot-Pipeline wie erwartet läuft. · Evidence Packs als Teil Ihrer Audit-Routine zu erzeugen und zu archivieren — Packs enthalten unabhängige Signaturen, die Kunden außerhalb der App verifizieren können.
9. Sicherheit von Workstations und Entwicklern
· Vollständige Festplattenverschlüsselung. Entwickler-Workstations verwenden vollständige Festplattenverschlüsselung (z. B. FileVault). · Bildschirmsperre und MFA. Workstations sperren sich bei Inaktivität automatisch und erfordern eine Authentifizierung; der Kontozugriff erfordert MFA. · Patching. Betriebssysteme und Entwicklungstools werden mit Sicherheitsupdates der Hersteller aktuell gehalten. · Endpoint-Schutz. Workstations betreiben einen vom Hersteller unterstützten Endpoint-Malware-Schutz. · Hygiene bei Anmeldedaten. Secrets und Tokens werden niemals in die Versionskontrolle committet; Plattform-Tokens werden von Forge verwaltet.
10. Logging und Monitoring
· Forge-Plattform-Logs. Ausführungslogs der App sind über die Atlassian-Forge-Plattform (forge logs) und die Developer Console verfügbar; wir leiten keine Logs an externe Systeme weiter. · Keine Kundendaten in Logs. Das Anwendungs-Logging ist so gestaltet, dass keine personenbezogenen Daten oder rohe Kundenkonfigurationen aufgezeichnet werden; Identifikatoren werden minimiert. · In-App-Observability. Die App stellt ihren eigenen Betriebszustand — Erfolgsrate der Captures, Integrität der Hash-Kette und letzte Aktivität — direkt in der Admin-Oberfläche dar, sodass Administratoren den korrekten Betrieb ohne externes Tooling bestätigen können.
11. Business Continuity und Disaster Recovery
· Plattformgestützte Beständigkeit. Persistente Daten liegen im von Atlassian verwalteten Forge Storage, der die Backup-, Replikations- und Beständigkeitskontrollen auf Plattformebene von Atlassian erbt. Siehe Atlassian Trust Centre unter https://www.atlassian.com/trust. · Keine separate Infrastruktur. Da die App vollständig innerhalb der Forge-Runtime läuft, gibt es keinen separaten von SPHIOR betriebenen Server, keine Datenbank und keinen Dienst, der unabhängig von der Atlassian-Plattform ausfallen könnte. · Wiederherstellbarkeit des Quellcodes. Der Quellcode der App ist versioniert und kann über die Standard-Veröffentlichungspipeline erneut im Atlassian Marketplace deployt werden. · Kundenseitiger Export. Administratoren können jederzeit Evidence Packs erzeugen und archivieren und erhalten so eine unabhängig verifizierbare Kopie des Ledgers außerhalb der App.
12. Künstliche Intelligenz
SPHIOR Ledger verwendet in seiner Kernfunktionalität keine künstliche Intelligenz und keine Machine-Learning-Modelle. Konfigurationserfassung, Diffing, Hash-Verkettung, Attribution und Compliance-Mapping sind vollständig deterministisch. Es werden keine Kundendaten an einen KI-/ML-Dienst gesendet — im Einklang mit der Zero-Egress-Architektur der App.
13. Überprüfung und Kommunikation der Richtlinie
Diese Sicherheitsrichtlinie sowie unsere internen Sicherheitspraktiken werden mindestens jährlich überprüft sowie immer dann, wenn eine wesentliche Änderung an der App oder ihrer Betriebsumgebung eintritt. Relevante Praktiken werden an alle an Entwicklung oder Betrieb beteiligten Auftragnehmer oder Dritten kommuniziert. Das oben angegebene Datum "Zuletzt aktualisiert" spiegelt die jüngste Überprüfung wider.
14. Kontakt
Sicherheitsereignisse: security@sphior.com Allgemeiner Kontakt: support@sphior.com Datenschutzanfragen: siehe Datenschutzerklärung unter https://ledger.sphior.com/privacy
Zuletzt aktualisiert: 2026-06-29