Trust Center

Gültig ab: 2026-05-19 - Version: 1.13

Zuletzt aktualisiert: 2026-10-07

Zusammenfassung #

fremforge ist EU-souveränes Git-Hosting auf Basis von Upstream-Forgejo, betrieben von der fremverk ApS (Dänemark). Jeder Bereich läuft in der Europäischen Union. Keine Kundendaten verlassen den Rechtsraum der EU.

Jede Verarbeitung (Repositorys, CI, Audit, Abrechnung, Authentifizierung, ausgehende E-Mails, eingehende Korrespondenz in den gemeinsamen Postfächern) läuft bei Unternehmen ohne US-Muttergesellschaft. Kein einziger Unterauftragsverarbeiter mit US-Muttergesellschaft auf irgendeinem Pfad. Die vollständige Position steht in §11.3 des Produkt-AVV.

Diese Seite ist die maßgebliche Referenz dafür, wo deine Daten liegen, wer sie verarbeitet, welche Zertifizierungen gelten und wie du uns erreichst.

Verantwortlicher #

fremverk ApS CVR: 39150689 Ringager 4C, 2. tv, 2605 Brøndby, Dänemark E-Mail: compliance@frem.sh · info@fremverk.com

Hosting und Regionen #

Unterauftragsverarbeiter #

Die aktuelle Liste der Unterauftragsverarbeiter wird hier gepflegt. Jede Änderung kündigen wir 30 Tage im Voraus über die Security-Mailingliste und auf dieser Seite an.

Für die Bot-Abwehr setzen wir keinen Drittanbieter ein. Registrierung und Anmeldung im Produkt nutzen selbst gehostetes Altcha (MIT-lizenziert, HMAC-signierter Proof of Work), das im Prozess des API-Monolithen auf demselben T-Cloud-Public-Cluster läuft; kein Widget-JavaScript von Dritten, kein externer Unterauftragsverarbeiter. Zusätzlich greifen serverseitige Kontrollen (Drosselung und Rate Limits pro IP) über alle Bereiche hinweg. Am Edge ist keine Web Application Firewall aktiviert; siehe §Schutz am Edge unten.

Schutz am Edge – DDoS-Abwehr, keine WAF #

Jeder fremforge-Bereich (frem.sh für Forgejo und Git, die API sowie die Websites www, docs, status und cli) liegt hinter dem Edge von Bunny CDN, der volumetrische DDoS-Angriffe abwehrt und Rate Limiting pro IP übernimmt. Auf keinem fremforge-Bereich ist am Edge eine Web Application Firewall (WAF) aktiviert, und das war schon vor dem Go-live so. Das ist eine bewusste Entscheidung. In den Tests vor dem Start erzeugte das OWASP Core Rule Set eine hohe Quote an Fehlalarmen bei den Request-Formen von Forgejo (Pfade des Git-Protokolls, Diff-Routen von Pull Requests, Raw-Blob-Abrufe mit Hex-Kennungen, Query-Strings signierter URLs) und bei den Formular-Bodys der API. Eine übereifrige WAF, die legitime Git-Operationen oder Abläufe in der Forgejo-UI bricht, wäre für Kunden schlechter gewesen als das verbleibende Risiko auf Edge-Ebene. Die Abwehr sitzt stattdessen in der Anwendung: Pre-Receive-Secret-Scanning, Altcha-Proof-of-Work bei Registrierung und Anmeldung, Rate Limits pro IP und pro Mandant in der API, Authentifizierung mit signierten Tokens an jedem Webhook-Empfänger und der Integritäts-Hash der Audit-Kette. Diese Position ist in Anhang A.2 des AVV festgehalten und wird bei jedem vierteljährlichen Betriebsreview erneut geprüft.

Isolation der gehosteten Runner – flüchtige ECS-VM, eine pro Commit #

CI-Jobs, die du zu fremforge pushst, laufen auf T Cloud Public Elastic Cloud Server (ECS): Jeder Commit und jeder Pull Request bekommt eine eigene flüchtige virtuelle Maschine, die frisch bereitgestellt und gelöscht wird, sobald die Jobs dieses Commits fertig sind. Zwei voneinander unabhängige Isolationsebenen:

• Rechenleistung / Kernel – eine eigene VM pro Commit. Die Jobs jedes Commits laufen in einer ECS-VM mit eigenem Linux-Kernel, isoliert durch den Hypervisor. Nie teilen sich zwei Kunden oder zwei Commits einen Kernel oder eine Maschine. Kernelseitige Container-Escape-Techniken (cgroup-Escape, Escape über /proc-Bind-Mounts, eBPF, offenliegendes /sys) finden daher keine mandantenübergreifende Grenze, die sie überwinden könnten: Es gibt keinen gemeinsamen Kernel, in den man ausbrechen könnte. Die Isolationseinheit ist eine ganze VM, kein Container – eine stärkere Grenze als das Containermodell mit gemeinsamem Kernel, das klassisches Kubernetes (auch CCE) für Runner-Pods verwendet. Die VM wird gelöscht, sobald die Jobs dieses Commits abgeschlossen sind; nichts – Build-Cache, geklonter Code, eingespeiste Secrets – bleibt für die Jobs eines anderen Commits oder eines anderen Kunden erhalten.
• Innerhalb eines Commits können sich Jobs die Maschine teilen. Aufeinanderfolgende Jobs desselben Workflow-Laufs (etwa build und danach deploy für denselben Commit) können auf derselben VM laufen, die gelöscht wird, wenn sie fertig sind. Das ist Absicht: Beide Jobs führen denselben geprüften Code aus, und eine frische Maschine pro Job kostet bei jedem Schritt einer Pipeline rund 40 Sekunden zusätzliche Latenz bis zum Start. Die Konsequenz, die wir klar benennen: Ein Build-Schritt, der Code aus Abhängigkeiten Dritter ausführt, teilt sich die Maschine mit einem späteren Schritt desselben Commits. Behandle eine Pipeline deshalb als eine einzige Vertrauensdomäne und beschränke jede Zugangsberechtigung, die ein Deploy-Schritt braucht, auf diese Pipeline. Die oben beschriebene Isolation zwischen Mandanten und zwischen Commits bleibt davon unberührt.
• Netzwerk – VPC-Sicherheitsgruppe pro VM. Jede Runner-VM liegt hinter einer eigenen VPC-Sicherheitsgruppe: kein eingehender Zugriff, Verkehr zwischen VMs (innerhalb des Subnetzes) unterbunden und ausgehender Verkehr beschränkt auf den gegen SSRF abgesicherten ausgehenden Runner-Proxy, die Forgejo-API und DNS. Die Isolation wird auf VPC- bzw. Hypervisor-Ebene durchgesetzt, nicht auf einer clusterinternen NetworkPolicy-Ebene, die davon abhängt, dass sich ein CNI-Agent korrekt verhält. Zusammen mit dem erzwungenen ausgehenden Proxy und dessen SSRF-Sperrliste ist eine seitliche Bewegung von einer Runner-VM zu irgendetwas außerhalb des eigenen Job-Kontexts des Kunden sowohl auf VM- als auch auf VPC-Ebene unterbunden.

Ändert T Cloud Public sein Isolationsmodell auf einer der beiden Ebenen so, dass es das Obige schwächt (z. B. wenn VMs pro Job durch Container mit gemeinsamem Kernel ersetzt werden oder die Sicherheitsgruppe pro VM entfällt), aktualisieren wir diese Seite innerhalb von 30 Tagen nach der Änderung und informieren alle aktiven Kunden gemäß AVV §14.

Geerbte Zertifizierungen #

Über T Cloud Public:

• ISO/IEC 27001 – Informationssicherheits-Managementsystem
• ISO/IEC 27017 – cloudspezifische Sicherheitskontrollen
• ISO/IEC 27018 – Schutz personenbezogener Daten in der Cloud
• BSI C5 Typ 2 – Cloud-Sicherheitsstandard des Bundes
• TISAX – Prüfstandard der deutschen Automobilindustrie
• DSGVO-konforme Verarbeitung in Rechenzentren in der EU

Eigene Zertifizierungs-Roadmap von fremverk #

Zum Gültigkeitsdatum hält fremverk keine eigenen Zertifizierungen nach ISO 27001, SOC 2 oder BSI C5. Die Sicherheitslage von fremverk stützt sich auf (i) die oben aufgeführten geerbten Zertifizierungen der Unterauftragsverarbeiter, (ii) die technischen und organisatorischen Maßnahmen im Sicherheitsanhang des AVV und (iii) das Programm von fremverk für Informationssicherheit und Sicherheitstests, das ebenfalls im Sicherheitsanhang des AVV beschrieben ist.

fremverk hat sich verpflichtet,

• innerhalb von 18 Monaten ab dem Gültigkeitsdatum mit dem Stage-1-Audit nach ISO 27001 zu beginnen und die Zertifizierung innerhalb von 24 Monaten zu erreichen;
• innerhalb von 24 Monaten mit einem Readiness-Assessment für SOC 2 Type II zu beginnen.

Kunden, die schon vor diesen Meilensteinen eine eigene Zertifizierung benötigen, können einen Vertrag im Rahmen von Enterprise-on-Demand schließen, bei dem die Meilensteine zur Zertifizierungsreife im Bestellformular festgeschrieben werden. Siehe AVV §12.1.

Transparenz bei Behördenzugriffen #

Zum Gültigkeitsdatum hat fremverk null Anfragen von Behörden auf Zugriff zu personenbezogenen Kundendaten erhalten. Der vollständige Bericht – einschließlich der Erklärung für den Teilzeitraum vor dem Start – ist unter frem.sh/trust/transparency/ veröffentlicht. Folgende Berichte decken volle Kalenderjahre ab und erscheinen jeweils im 1. Quartal des Folgejahres.

Erhält fremverk eine verbindliche rechtliche Anordnung einer Behörde, eines Gerichts oder einer Strafverfolgungsbehörde, dann

• prüft fremverk die Anfrage auf rechtliche Gültigkeit, Zuständigkeit und Verhältnismäßigkeit;
• fechtet fremverk jede Anfrage an, die zu weit gefasst ist, keine Rechtsgrundlage hat oder dem EU-Recht widerspricht (einschließlich Art. 48 DSGVO bei Anfragen von außerhalb der EU/des EWR);
• informiert fremverk den betroffenen Kunden innerhalb von 24 Stunden nach Eingang, sofern dies nicht gesetzlich untersagt ist;
• gibt fremverk dem Kunden angemessen Gelegenheit, eine Schutzanordnung zu beantragen oder die Anfrage auf anderem Weg anzufechten.

Siehe AVV §11A.

DSA-Transparenzbericht (Artikel 15) #

fremforge ist ein Hostingdienst im Sinne der Verordnung (EU) 2022/2065 (Digital Services Act). Der jährliche Bericht nach Art. 15 über das Aufkommen an Meldungen und Abhilfemaßnahmen, Anordnungen von Behörden der Mitgliedstaaten, Moderation von Inhalten aus eigener Initiative und die Ergebnisse von Beschwerden nach Art. 20 ist unter frem.sh/trust/dsa/ veröffentlicht – getrennt vom oben genannten Bericht über Behördenzugriffe. Unter derselben URL steht auch die halbjährlich veröffentlichte durchschnittliche monatliche Zahl der Nutzer in der EU, die Art. 24(2) verlangt.

Schrems II – internationale Übermittlungen #

Auf keinem Verarbeitungspfad werden personenbezogene Kundendaten international übermittelt. Die gesamte Verarbeitung (Repository-Inhalte, CI-Läufe, Audit-Logs, Authentifizierungs-Metadaten, Abrechnungsdaten, Daten zu Zahlungsmitteln, ausgehende Transaktions-E-Mails und eingehende Korrespondenz in den gemeinsamen Postfächern) findet innerhalb der EU/des EWR bei Unternehmen ohne US-Muttergesellschaft statt. Es sind weder Garantien nach Artikel 46 DSGVO noch Standardvertragsklauseln oder ein Transfer Impact Assessment erforderlich.

Standort der Edge-PoPs (Bunny CDN) #

Jede Bunny-Pullzone vor frem.sh ist so konfiguriert, dass sie nur aus EU-PoPs ausliefert – kein Caching in den USA, in Australien oder Asien. Durchgesetzt wird das in OpenTofu an jeder Pullzone-Ressource über routing { zones = ["EU"] }. Die Konfiguration der Pullzones liegt im Quellbaum unter:

• Forgejo-Pullzone: fremforge/forgejo/.infrastructure/main.tf – nach zones = ["EU"] suchen
• API-Pullzone: fremforge/monolith/.infrastructure/bunny.tf – dieselbe Zeile
• Die Pullzones der statischen Websites (www, docs, status, cli) erben denselben routing-Block aus dem gemeinsamen Modul unter fremverk/cloudplatform/modules/static-site/main.tf:103-112.

Ein tofu plan gegen einen beliebigen Pullzone-Stack gibt den aktiven Wert von routing.zones aus; jede Abweichung von ["EU"] würde also als Plan-Diff sichtbar. Prüfbare Nachweise werden direkt einsehbar, sobald der Quellbaum auf der kundenseitigen Forgejo-Instanz liegt (unter https://frem.sh/fremforge/...); bis dahin ist die maßgebliche Dokumentation zum Anker der Audit-Kette und zum Integritätsprüfer unter docs.frem.sh/security/audit-chain/ veröffentlicht.

Hinweis zur TLD #

frem.sh ist eine ccTLD von St. Helena (.sh), verwaltet von einem im Vereinigten Königreich registrierten Registry-Betreiber. Das betrifft ausschließlich die DNS-Ebene. Keine Kundendaten, kein Zustand der Control Plane und keine Backups verlassen T Cloud Public EU-DE. Die Souveränitätsgarantien (Identität des Auftragsverarbeiters, Liste der Unterauftragsverarbeiter, Datenresidenz) sind im AVV festgelegt und vom DNS-Hosting nicht berührt.

Auf keinem Verarbeitungspfad besteht eine Angriffsfläche für den CLOUD Act. Alle personenbezogenen Kundendaten werden innerhalb der EU/des EWR von Unternehmen ohne US-Muttergesellschaft verarbeitet. Die vollständige Position steht in AVV §11.3.

Fußnote zu den Kartennetzwerken. An der nach PCI-DSS attestierten Kartenverarbeitung von Mollie sind Visa Europe Services Inc. (Niederlassung UK) und Mastercard Europe SA (Belgien) beteiligt – EU-Gesellschaften, deren oberste Muttergesellschaften (Visa Inc., Mastercard Inc.) in den USA eingetragen sind. Die Aussage „keine US-Muttergesellschaft“ bezieht sich auf die eigenen Unterauftragsverarbeiter von fremverk auf Ebene der Betreibergesellschaft; die Kartennetzwerke sind nach den Netzwerkregeln von PCI-DSS weitere Unterauftragsverarbeiter von Mollie. Wer auf dem Zahlungspfad keinerlei Berührung mit US-Muttergesellschaften möchte, kann per SEPA-Lastschrift zahlen (ohne Beteiligung von Kartennetzwerken). Siehe Unterauftragsverarbeiter – Fußnote zu den Kartennetzwerken.

Prüfe die Audit-Kette selbst #

Jede zustandsändernde Admin-Aktion in deiner Organisation wird in einer SHA-256-Hash-Kette pro Mandant erfasst. Der Kopf der Kette wird alle zwei Minuten in WORM-Speicher verankert, nämlich in T Cloud Public OBS mit Object Lock (3 Jahre Aufbewahrung, innerhalb der Aufbewahrungsfrist physisch nicht löschbar). Du kannst die Kette von Anfang bis Ende prüfen, ohne fremverk beim Wort nehmen zu müssen.

Mit der fremforge-CLI:

# Install (one-liner; see docs.frem.sh/get-started/cli/ for manual download + SHA-256 verify)
curl -sSfL https://cli.frem.sh/cli/install.sh | sh

export FREMFORGE_TOKEN='<your PAT, audit:read scope>'
fremforge audit-verify <your-org-slug> --human

Oder mit curl direkt gegen denselben Endpunkt, den auch die CLI aufruft:

curl -sSf \
  -H "Authorization: Bearer $FREMFORGE_TOKEN" \
  https://frem.sh/_app/api/v1/orgs/<your-org-slug>/audit/integrity \
  | jq '{integrity_status, walked_rows, verified_count, last_verified_hash, worm_anchor}'

Eine gesunde Antwort enthält "integrity_status": "ok" und einen worm_anchor-Block, dessen agrees_with_db_walk: true bestätigt, dass die Kette in der Datenbank mit dem in OBS verankerten Kopf übereinstimmt. Bei einem Bruch (hash_mismatch / prev_hash_mismatch) kommen die ID der betroffenen Zeile und der Grund zurück – so aufbereitet, dass Prüfer es lesen können. Das vollständige Schema, die Exit-Codes und das Bedrohungsmodell stehen in docs.frem.sh – Integrität der Audit-Kette.

Verwahrung der Operator-Zugangsdaten #

Die Bootstrap-Admin-Zugangsdaten (der domänenweite Root-AK/SK für T Cloud Public, der nur für die erstmalige Einrichtung von IAM, OBS-Buckets und dienstgebundenen Agencies verwendet wird) liegen auf dem Laptop des Operators, mit FileVault-Vollverschlüsselung und den Dateirechten chmod 600. Sie werden vierteljährlich rotiert, nie per Chat oder Bildschirmfreigabe weitergegeben und lassen sich über die OTC-Konsole in weniger als 10 Minuten widerrufen. Routine-Deploys nutzen eng begrenzte Deployer-Schlüssel pro Komponente, nicht die Root-Zugangsdaten.

Sicherheitskontakt #

• Schwachstellen melden: security@frem.sh
• Offenlegungsrichtlinie: Sicherheit
• Fingerabdruck des PGP-Schlüssels: DBA3 184D 0EFA E4C2 51ED EB46 53FA 57F8 698C 3488 (öffentlicher Schlüssel – ASCII-armored nach RFC 4880, RSA-4096, gültig bis 2031-05-14). Für verschlüsselte Schwachstellenmeldungen an security@frem.sh. Wir veröffentlichen den Schlüssel nur unter frem.sh/.well-known/ und laden ihn nicht auf öffentliche Keyserver hoch (so entfällt die Vertrauenswurzel eines Dritten). Eine Kopie liegt der Einfachheit halber unter /pgp.txt.

Offenlegung von Schwachstellen #

Eine maschinenlesbare Offenlegungsrichtlinie nach RFC 9116 ist unter frem.sh/.well-known/security.txt veröffentlicht, mit Safe Harbour für Forschung in gutem Glauben, Geltungsbereich und Meldeweg. Berichte externer Penetrationstests stellen wir Kunden, sofern beauftragt, auf schriftliche Anfrage unter NDA gemäß AVV §12.1 zur Verfügung; in Enterprise-on-Demand-Verträgen kann im Bestellformular ein bestimmter Testrhythmus vereinbart werden.

Offenlegung von Vorfällen #

Post-Mortems zu jedem Vorfall, der Kundendaten oder die Verfügbarkeit betrifft, veröffentlichen wir innerhalb von 14 Tagen auf dieser Seite, gemäß unserer Sicherheitsrichtlinie.

Sicherheits-Patches #

fremforge verpflichtet sich zu den folgenden maximalen Fristen für das Patchen von Sicherheitslücken in der Plattform, gemessen ab dem korrigierten Upstream-Release oder der Veröffentlichung des Advisorys, je nachdem, was später eintritt.

Notfall-Releases außerhalb des Plans sind zu erwarten. Das wöchentliche Wartungsfenster ist eine Obergrenze, keine Untergrenze. Sicherheits-Patches werden nie zurückgestellt, um ein Wartungsfenster eines Mandanten einzuhalten; das steht in der Nutzungsrichtlinie (AUP) und wird im Sicherheitsanhang des AVV wörtlich zitiert.

Ausstieg und Datenportabilität #

Alles ist exportierbar – Repositorys, Issues, Pull Requests, Actions-Logs, Audit-Trail, SLSA-Attestierungen – über die API und in Standardformaten. Es gibt keinen Lock-in über Aufbewahrungsfristen und keine Exportgebühr.

Manipulationserkennbarer Export in Eigenregie. Jeder Admin eines Mandanten kann jederzeit in der Admin-UI ein vollständiges Paket anstoßen. Es wird als eine einzige ZIP-Datei mit einem SHA-256-Manifest über jede Datei im Archiv ausgeliefert (manifest.json + archive.tar.gz.sha256), sodass du nach dem Download bestätigen kannst, dass der Inhalt nicht manipuliert wurde. Das Paket enthält git bundle-Dateien der Repositorys, LFS-Manifeste, Actions-Logs, einen Audit-Ausschnitt und SLSA-Attestierungen. Zum Vergleich: Der Organisationsexport von GitHub ist eine Reihe von REST-API-Aufrufen, die Organisations-Ownern zur Verfügung stehen und ein Archiv erzeugen, das für den Import in GitHub Enterprise Server gedacht ist (GitHub-Dokumentation, gelesen am 17. Oktober 2026). fremforge liefert den Export in jedem Tarif, für jeden Kunden, an jedem Tag. Das Manifest ist mit unserem SLSA-Builder-Schlüssel signiert (DSSE-Envelope, manifest.json.intoto.jsonl); du prüfst es mit derselben Vertrauenswurzel unter https://www.frem.sh/.well-known/slsa-trust-root.json, die wir für die SLSA-Build-Attestierungen veröffentlichen. Für die Prüfung des Manifests brauchst du überhaupt kein Sigstore – weder die öffentliche Instanz noch das selbst gehostete Fulcio und die TSA, mit denen wir Build-Attestierungen zusätzlich signieren. Aufbau des Pakets, Prüfanleitungen und die API-Endpunkte findest du unter docs.frem.sh/data-export.

Fristen und Abläufe für das Offboarding eines Mandanten sind im AVV festgelegt.

Cookies und Tracking #

fremforge setzt in den angemeldeten Produktbereichen nur technisch notwendige Cookies und auf Website, Dokumentation, Statusseite und anonymen Seiten überhaupt keine. Ein Consent-Banner ist nicht nötig – nicht, weil wir die Frage versteckt hätten, sondern weil wir keine Cookies setzen, die eine Einwilligung erfordern würden.

Angemeldete Produktbereiche setzen vier First-Party-Cookies, alle technisch notwendig im Sinne von Artikel 5(3) der ePrivacy-Richtlinie:

Website, Dokumentation und Status (www.frem.sh, docs.frem.sh, status.frem.sh) sind mit Hugo gebaute statische Websites ohne Cookies, ohne Analytics, ohne Einbettungen und ohne Tracking jeglicher Art. Nachprüfbar in den Entwicklertools deines Browsers.

Aufrufe an Dritte aus der Produkt-UI sind standardmäßig deaktiviert: kein Gravatar, keine föderierten Avatare, keine über CDNs geladenen Schriften oder Skripte, keine Analytics von Dritten. Avatare werden lokal gespeichert; Schriften kommen vom selben Origin wie die Forge.

Das ist eine bewusste Produktentscheidung, kein Compliance-Minimum. Das vollständige Cookie-Verzeichnis und die Betroffenenrechte sind in der Datenschutzerklärung des Produkts dokumentiert.

Änderungen an Sicherheitsmaßnahmen #

Anhang A des AVV führt die technischen und organisatorischen Maßnahmen auf, die fremverk anwendet, und legt fest, dass wesentliche Änderungen daran hier bekanntgegeben werden. Änderungen ab dem 2026-10-04 stehen unten, die neuesten zuerst; frühere Änderungen sind im Änderungsprotokoll des AVV erfasst. Eine Änderung, die eine Zusage abschwächt, tritt 30 Tage nach einer Mitteilung an alle Administratoren der Kunden in Kraft, mit dem Kündigungsrecht nach AGB §17; alle anderen gelten ab Veröffentlichung. Jede Version verlinkt auf ihren Text.

Änderungen an dieser Seite #

Änderungen werden in Git versioniert und über die Security-Mailingliste angekündigt. Das Datum oben auf dieser Seite gibt die letzte inhaltlich relevante Änderung wieder.

Änderungsprotokoll #