Organisationsverwaltung

Die Organisationsverwaltung von fremforge liegt unter frem.sh/<your-org>/_admin. Eine Seitenleiste mit fünf Gruppen enthält die Verwaltungsseiten; in der oberen Leiste öffnet Cmd-K (⌘K / Ctrl-K) eine Befehlspalette, die jede Seite nach Bezeichnung und Stichwort durchsucht. Keine versteckten Untermenüs, keine überraschenden Dialoge.

Organisation: Übersicht, Repositorys, Mitglieder, SSO, Abrechnung, Öffentliche Doku, Datenexport, Einstellungen. Sicherheit: Übersicht, Befunde, Komponenten, Priorisieren, Beheben, Berichte, Richtlinien, Zugriff. Siehe Sicherheit weiter unten. Build und Deployment: Umgebungen, Deployments, Secrets, Abhängigkeits-Updates (dieselbe Seite wie Sicherheit › Beheben), Abhängigkeits-Proxy, frembench. Integration: KI-Integrationen, Programmatischer Zugriff, Webhooks, SIEM-Weiterleitung. Berichte: DORA, Audit-Log (kryptografische Integrität in der Audit-Kette), Registry-Zugriffslog, Legal Hold, Aufbewahrung von Nachweisen, Rechtliche Mitteilungen.

Ist die Organisation, deren Seite du öffnen willst, gerade gesperrt oder im 90-tägigen Zeitraum nach einer Kündigung, ist die Verwaltung überall schreibgeschützt, außer bei Abrechnung und Datenexport. Das Banner oben auf jeder Seite sagt das ausdrücklich.

Die Tab-Leiste ist auf jeder Verwaltungsseite gleich; du kannst zwischen den Tabs wechseln, ohne deine Stelle zu verlieren.

Wer die Verwaltung erreicht

Jeder mit der Rolle Owner in der Forgejo-Organisation. Die Rolle wird auf Forgejos Seite <org>/-/teams/owners vergeben; die Prüfung läuft bei jeder Verwaltungsanfrage auf dem Server, sodass ein Entzug der Owner-Rolle die Verwaltungssitzung des Nutzers sofort ungültig macht.

Mitglieder und externe Mitwirkende erreichen /admin nicht. Die Route antwortet mit 403 und der Meldung „not an org owner“.

Tabs

Abrechnung

frem.sh/<org>/_admin/billing deckt alles ab, was mit Geld zu tun hat.

• Aktuelle Zahl der Nutzer und geschätzte Monatsrechnung
• Status der Zahlungsmethode (mit einem Link „Zahlung einrichten“, wenn es noch kein Mandat gibt, oder einem Link zum Ersetzen der Zahlungsmethode, wenn das bestehende Mandat defekt ist)
• Rechnungsverlauf mit Belegen zum Herunterladen
• Ablauf zum Kündigen des Abonnements (abgesichert durch Eintippen des Org-Slugs zur Bestätigung)

Die Kündigung setzt cancellation_scheduled mit einem Zeitraum von 30 Tagen, bevor sie wirksam wird. In diesem Zeitraum kann der Kunde sie in der Verwaltung oder über den Link in der E-Mail rückgängig machen, die bei der Kündigung verschickt wird. Danach wechselt die Organisation auf cancelled (schreibgeschützte Aufbewahrung für weitere 60 Tage) und dann auf deleted (Löschung gemäß AVV §9).

SSO

frem.sh/<org>/_admin/sso: Identitätsföderation mit deinem IdP.

• Verifizierte Domains: Weise per DNS-TXT-Eintrag oder HTTP-Datei unter .well-known nach, dass du eine E-Mail-Domain kontrollierst. Das ist nötig, bevor eine Auth-Quelle aktiviert wird, die diese Domain verwendet.
• Auth-Quellen: Registriere OIDC-Provider.

Sobald beides verifiziert und registriert ist, melden sich deine Nutzer unter frem.sh/<org>/login bei ihrem IdP an. PATs und SSH-Schlüssel bleiben für sich gültig; ist Require SSO aktiviert, prüft fremforge die IdP-Sitzung bei Git-Operationen alle 15 Minuten erneut, sodass ein im IdP deaktivierter Nutzer innerhalb dieses Zeitfensters den Git-Zugriff verliert, auch wenn sein Schlüssel noch am Konto hängt. Das vollständige Durchsetzungsmodell findest du unter OIDC-SSO.

Unter Migration → GitHub → Schritt 7: Prüfen und Altsystem abschalten findest du die Prüfung der SSO-Anmeldung als Teil einer vollständigen Migration; alternativ folgst du direkt den oben beschriebenen Schritten zur Einrichtung einer Auth-Quelle im SSO-Tab.

Sicherheit

frem.sh/<org>/_admin/security/overview. Die Gruppe Sicherheit in der Seitenleiste hat acht Einträge, in der Reihenfolge, in der du einen Befund bearbeitest: erkennen, priorisieren, beheben, berichten, dazu die Richtlinien, die festlegen, was erlaubt ist und wer hineinkommt.

Jede ältere Adresse dieser Seiten, etwa _admin/security/policies/edge, _admin/code-security/…, _admin/compliance-evidence oder _admin/attestations, leitet auf ihren neuen Tab weiter. „Edge policies“ gibt es nicht mehr: Die Einstellungen liegen jetzt unter Priorisieren (Behebungsfrist (SLA), Pull-Request-Prüfungen), Zugriff (IP-Allowlist, Support-Zugriff, KI-Verbindungen sowie die Angaben zur Zwei-Faktor-Authentifizierung unter Authentifizierungsrichtlinie) und Berichte › Benachrichtigungen (der Sicherheits-Digest).

Push-Schutz

frem.sh/<org>/_admin/security/policies/push-protection. Secret-Scanning bei jedem Push ist immer eingeschaltet. Dieser Tab enthält die Liste der Ausnahmen und das Fehlerverhalten des Scanners.

• Aktuelle Ablehnungen: jeder Push, der blockiert wurde, weil gitleaks ein Secret-Muster mit hoher Zuverlässigkeit erkannt hat. Klicke auf „Freigeben“, um daraus eine einmalige oder eine auf ein Muster beschränkte Ausnahme zu machen.
• Aktive Ausnahmen: deine Allowlist. Jede Ausnahme trägt eine Begründung (im Audit-Log erfasst) und optional eine Einschränkung auf Regel, Pfadmuster, Commit oder Repository. Du kannst jede Ausnahme jederzeit widerrufen.

Ist ein Befund ein echtes Secret, rotiere es zuerst beim ausstellenden Dienst, entferne es dann mit git filter-repo aus der Historie und pushe danach. Ist es ein Fehlalarm (Testdaten, absichtlich öffentliche Zugangsdaten), lege eine auf den Pfad beschränkte Ausnahme an. Siehe Push-Schutz.

Befunde

frem.sh/<org>/_admin/security/findings/sast. Ein Tab pro Scanner: SAST, Abhängigkeiten, Lizenzen, Container-Images, Secret-Scanning, Malware (der Malware-Scan beim Upload) sowie Ausnahmen. Jeder Tab zeigt zuerst seine Befunde, mit einer Zeile dazu, ob der Scanner eingeschaltet ist und ab welchem Schweregrad seine Pull-Request-Prüfung fehlschlägt. Die Einstellungen selbst liegen unter Sicherheit › Richtlinien › Scanner. Die Regeln, nach denen ein Befund bewertet wird, etwa die Lizenzlisten und die Pull-Sperre für Images, liegen unter Sicherheit › Richtlinien (siehe Sicherheitsrichtlinien).

Abhängigkeits-Updates

frem.sh/<org>/_admin/dependency-updates, unter Sicherheit › Beheben (Build und Deployment behält einen Link auf dieselbe Seite). Eine Seite mit zwei Spuren: Sicherheitskorrekturen, ein Pull Request pro verwundbarem Paket auf Grundlage deiner Befunde, und Versions-Updates durch gehostetes Renovate. Sie listet außerdem die teilnehmenden Repositorys und die letzten Aktivitäten.

• Aktivieren: legt einen eigenen Bot-Nutzer für die Organisation an und startet einen nächtlichen Lauf über die Repositorys der Organisation.
• Letzte Läufe: die letzten 10 Renovate-Läufe mit der Zahl der Pull Requests und etwaigen Fehlern.
• Jetzt ausführen: Auslösung außerhalb des Zeitplans (begrenzt auf 1 pro Stunde).
• Deaktivieren: widerruft sofort das Token des Bots und entfernt ihn aus der Organisation. Pull Requests, die der Bot schon geöffnet hat, bleiben offen.

Die Konfiguration pro Repository erfolgt über renovate.json im Wurzelverzeichnis des Repositorys. Siehe Abhängigkeits-Updates für beide Spuren, Versions-Updates für die Renovate-Referenz und Sicherheitskorrekturen für Korrektur-Pull-Requests auf Grundlage von Befunden.

Secrets

frem.sh/<org>/_admin/secrets: Actions-Secrets auf Organisationsebene, die in jeden CI-Job der Organisation als Umgebungsvariablen eingespeist werden. Forgejo ist die Speicherschicht (im Ruhezustand verschlüsselt); die fremforge-Verwaltung leitet die CRUD-Operationen weiter und erzeugt Audit-Ereignisse mit Secret-Name, Akteur und Zeitstempel (der Wert wird nie in fremforges Datenbank oder Audit-Log gespeichert).

• Secret anlegen / überschreiben: Name (UPPER_SNAKE_CASE; darf nicht mit FORGEJO_ oder GITHUB_ beginnen) und Wert. Wer einen vorhandenen Namen absendet, überschreibt ihn; dasselbe Formular ist der Ablauf für die Rotation.
• Aktive Secrets: Liste der Namen mit Erstellungszeitpunkt. Werte sind nur schreibbar; fremforge liest oder zeigt einen Wert nach dem Anlegen nie wieder an.
• Löschen: mit Bestätigung über eine JS-confirm()-Abfrage. Workflows, die auf das Secret verweisen, schlagen fehl, bis es neu angelegt ist.

Secrets der Organisation werden von jedem Repository der Organisation geerbt. Für den Geltungsbereich eines Repositorys setzt du das Secret in Forgejos eigener Oberfläche unter Repository → Einstellungen → Actions → Geheimnisse. Für den Geltungsbereich einer Umgebung setzt du es unter Organisationsverwaltung → Umgebungen → <env> → Umgebungs-Secrets (frem.sh/<org>/_admin/environments). Der spezifischste Bereich gewinnt; ein Umgebungs-Secret mit demselben Namen wie ein Organisations-Secret überdeckt dieses für Jobs in der Umgebung.

Die vollständige Referenz einschließlich API-Pfad und Rotationsablauf findest du unter Secrets.

Repository-Vorgaben

frem.sh/<org>/_admin/repo-defaults leitet weiter auf Sicherheit › Richtlinien › Repository-Regeln (_admin/security/policies/repository-rules#org-baseline): die Standardvorgaben für den Branch-Schutz der Repositorys der Organisation, etwa erforderliche Freigaben, Review durch CODEOWNERS und signierte Commits. Siehe Branch-Schutz.

Webhooks

frem.sh/<org>/_admin/webhooks: Zustellverlauf und erneute Zustellung von Webhooks für Ereignisse aus der ganzen Organisation. Das Anlegen von Webhooks (welche Ereignisse, Ziel-URL, Signatur-Secret) erfolgt in Forgejos eigener Oberfläche unter /<org>/-/settings/hooks (Organisationsebene) oder /<org>/<repo>/settings/hooks (Repository-Ebene). fremforge verantwortet die Übersicht zum Zustellverlauf unter Verwaltung → Webhooks; Forgejo verantwortet die Registrierung.

• Letzte Zustellungen: einzelne Zustellversuche, Antwortcodes und Payloads ansehen.
• Redeliver: ein beliebiges Ereignis aus dem Verlauf erneut auslösen. Nützlich, um nach einem Fix Fehler beim Empfänger zu prüfen.

Webhooks der Organisation werden mit demselben Ereignisformat ausgelöst wie Webhooks pro Repository. Die vollständige Referenz der Ereignistypen und das Payload-Schema findest du unter Webhooks.

Umgebungen

frem.sh/<org>/_admin/environments: Deployment-Umgebungen im Stil von GitHub für CI/CD-Jobs. Jede Umgebung hat einen Namen (im Workflow-YAML referenziert als jobs.<id>.environment: <name>), Schutzmuster für Branches und Tags, eigene Secrets und eigene Variablen.

• Deployment-Branches und -Tags: Glob-Muster (main, release/*, v[0-9]*), die einschränken, welche Refs in diese Umgebung deployen dürfen. Refs, die nicht passen, werden abgewiesen, bevor der Runner den Workflow überhaupt abruft.
• Umgebungs-Secrets: verschlüsselte Secrets, die in Jobs mit environment: <name> eingespeist werden. Sie überdecken Secrets der Organisation mit demselben Schlüssel. Nützlich für Zugangsdaten, die nur für Produktion gelten.
• Umgebungsvariablen: nicht geheime Umgebungsvariablen (Region, Deployment-URL usw.), die an die Umgebung gebunden sind.
• OIDC-Föderation: Jeder Workflow-Lauf trägt ein OIDC-Token, dessen sub-Claim den Namen der Umgebung enthält (repo:owner/repo:environment:prod). Vertraue diesem Token im IdP deiner Cloud, um kurzlebige Deployment-Zugangsdaten ohne langlebige Secrets zu vergeben.

Die vollständige Anleitung zur OIDC-Föderation einschließlich Vertrauensrichtlinien für AWS, Azure, GCP und T Cloud Public findest du unter Deployment-Secrets.

Aufbewahrung von Build-Artefakten

frem.sh/<org>/_admin/artifact-retention: die Aufbewahrungseinstellung der Organisation für Forgejo-Actions-Artefakte (Build-Ergebnisse, Testberichte, Debug-Pakete), in Tagen von 1 bis 90. Der Standard für neue Organisationen ist 30 Tage, und Organisationen, die den Wert nie geändert haben, wurden am 2026-10-21 von 90 auf 30 umgestellt. Einen Wert, den du selbst gesetzt hast, behalten wir bei.

Was heute tatsächlich ein Artefakt löscht. Forgejo lässt ein Artefakt nach den beim Hochladen angegebenen retention-days ablaufen oder nach der Plattformobergrenze von 90 Tagen ([actions].ARTIFACT_RETENTION_DAYS der Forgejo-Instanz), je nachdem, was kürzer ist. Die Einstellung der Organisation oben löscht noch nichts: Der nächtliche Job, der einen kürzeren Wert anwenden soll, braucht eine Artefakt-API, die diese Forgejo-Version nicht hat. Um Artefakte kürzer als 90 Tage aufzubewahren, setze retention-days beim Hochladen:

- uses: actions/upload-artifact@v3
  with:
    name: test-report
    path: report/
    retention-days: 7

Abgelaufene Artefakte zählen nicht mehr gegen das Artefakt-Kontingent der Organisation.

SIEM-Weiterleitung

frem.sh/<org>/_admin/siem: Streame das Audit-Log der Organisation nahezu in Echtzeit an dein SIEM. Unterstützt werden Splunk HEC, Sentinel HTTP Data Collector, Elastic Cloud und ein generischer Webhook mit HMAC-SHA256-Signatur. Splunk und Sentinel brauchen einen schlanken Proxy, der die HMAC-Signatur übersetzt (siehe SIEM-Weiterleitung); Elastic Filebeat und der generische Webhook funktionieren direkt. Jeder Endpunkt lässt sich vor dem Livegang mit einem synthetischen Ereignis testen; fehlerhafte Endpunkte werden mit Backoff erneut versucht, und Fehler erscheinen im Operator-Portal.

Anbieterattestierung und Kontrollnachweise

Beides liegt unter Sicherheit › Berichte: Die Anbieterattestierung (_admin/security/reports/vendor-attestation) ist ein Dokument über fremforge als deinen Anbieter, und die Kontrollnachweise (_admin/security/reports/control-evidence) ordnen die Audit-Ereignisse deiner Organisation den Kontrollen von SOC 2 und ISO 27001 zu. Die SLSA-Build-Provenienz liegt unter Sicherheit › Komponenten › Build-Attestierungen; siehe SLSA-Provenienz.

Lebenszyklus von Organisation und Repository

Einige Vorgänge liegen außerhalb des Tab-Rasters, weil sie einmalig sind und keine laufende Konfiguration. Sie liegen an ihrem natürlichen Ort (der Einstellungsseite des Repositorys oder der Seite zum Umbenennen der Organisation), aber wir verweisen hier darauf, damit sie nicht unsichtbar bleiben.

Eine Organisation umbenennen

frem.sh/<org>/_admin/settings: Ändere den Slug der Organisation. Bestehende Repository-URLs, Clone-URLs, API-Aufrufe und Verweise in Webhook-Payloads mit dem alten Slug werden nach der Umbenennung 90 Tage lang weitergeleitet. Danach kann der alte Slug wieder registriert werden; plane den Umstieg also, aktualisiere deine Integrationen während des Weiterleitungszeitraums und schiebe es nicht auf.

Die Umbenennung ist eine Aktion für Owner der Organisation, wird im Audit-Log erfasst und durch Eintippen des alten Slugs bestätigt.

Ein Repository in eine andere Organisation übertragen

frem.sh/<org>/<repo>/settings → Besitz übertragen. Ein Repository lässt sich in eine andere Organisation übertragen, deren Owner du bist (oder an das Konto eines anderen Nutzers, der zustimmen muss). Bei der Übertragung gilt:

• Alle Branches, Tags, die Historie, Issues, Pull Requests, Releases, Pakete, Webhooks und CI-Workflow-Läufe ziehen mit dem Repository um.
• Forks des Repositorys auf fremforge bleiben, wo sie sind; sie aktualisieren ihren Upstream-Verweis automatisch auf den neuen Ort.
• Bestehende git clone-, git fetch- und HTTP-API-URLs auf den alten Pfad <org>/<repo> werden 90 Tage lang weitergeleitet, derselbe Zeitraum wie bei der Umbenennung einer Organisation. Aktualisiere Remotes bei Gelegenheit; die Weiterleitung ist ein betrieblicher Puffer, keine dauerhafte Zusage.

Die Übertragung unterliegt der Richtlinie der Zielorganisation: Erzwingt die Zielorganisation SSO, signierte Commits usw., übernimmt das übertragene Repository diese Richtlinie bei der Ankunft; bestehende Branch-Schutzregeln des Repositorys bleiben erhalten, sofern die Standardvorgaben der Zielorganisation nicht strenger sind.

Ein Abonnement kündigen

Aktion für Owner, abgesichert durch Eintippen des Org-Slugs. Den Ablauf der Kündigung beschreibt der Tab Abrechnung oben, die Zustände im Lebenszyklus (Kündigung geplant → gekündigt → gelöscht) die Seite Abrechnung.

Ein persönliches Konto löschen

Gehört nicht zur Organisationsverwaltung. Das Löschen eines persönlichen Kontos (DSGVO-Recht auf Löschung) liegt unter Benutzereinstellungen → Konto. Den vollständigen Ablauf, einschließlich dessen, was als historische Zuordnung erhalten bleibt, beschreibt Dein fremforge-Konto.

Branch-Schutz, Konzeptreferenz

Der Branch-Schutz folgt einer dreistufigen Hierarchie: Plattformuntergrenze (von fremforge gesetzt, nicht konfigurierbar) → Standard der Organisation (vom Owner der Organisation gesetzt, gilt für alle Repositorys) → Regeln pro Repository (können die Standards der Organisation verschärfen, aber nicht unter die Untergrenze der Organisation lockern).

Standardschutz der Organisation: Sicherheit › Richtlinien › Repository-Regeln, Standardvorgaben für den Branch-Schutz. Lege Regeln fest, die für alle neu angelegten Repositorys gelten und für alle bestehenden Repositorys, für die keine strengere Regel auf Repository-Ebene existiert.

Schutz pro Repository: Repository → Einstellungen → Branches → Neue Regel hinzufügen. Gib ein Muster für den Branch-Namen ein (z. B. main, release/*). Verfügbare Schutzregeln:

Plattformuntergrenze: Die Plattform erzwingt: Signierte Commits sind auf Plattformebene erlaubt (nicht erzwungen); Secret-Scanning läuft unabhängig von den Einstellungen zum Branch-Schutz; das Audit-Log erfasst alle Force-Pushes, auch wenn Force-Push nicht blockiert ist.

Vererbung von Richtlinien: Verlangt der Standard der Organisation 1 Review und eine Repository-Regel 2, gewinnt die strengere Regel (2). Repository-Regeln können nur verschärfen, nicht lockern.

Datenexport

frem.sh/<org>/_admin/data-export: vollständiger Export in Selbstbedienung.

• Neuen Export starten: stellt eine einzelne signierte .tar.gz zusammen, mit einem git bundle pro Repository, den Issues, Pull Requests, Kommentaren, Labels, Meilensteinen und Releases jedes Repositorys, dem Paketinventar und einem Audit-Ausschnitt über 90 Tage. Was genau enthalten ist, steht unter Datenexport.
• Aktuelle Jobs: die letzten 20 Export-Jobs mit Download-Links (7 Tage nach Fertigstellung gültig) und Status.

Begrenzt auf einen Export pro Organisation alle 24 Stunden. Für Pakete über 50 GB gilt ein anderes Verfahren. Wende dich an den Support.

Den Aufbau des Pakets, Rezepte zur Überprüfung und die API-Endpunkte findest du unter Datenexport.

Einstellungen

frem.sh/<org>/_admin/settings: die Grunddaten der Organisation: Sichtbarkeit (öffentlich / eingeschränkt / privat), Anzeigename, Beschreibung, Website, Standort. Änderungen hier werden über PATCH /api/v1/orgs/{org} an Forgejo weitergereicht und erzeugen ein Audit-Ereignis tenant.org.settings.updated.

Einstellungen, die anderswo liegen:

• Name der Organisation (Slug): Das Umbenennen des Slugs ist eine Forgejo-Aktion mit 90 Tagen Weiterleitung; du verwaltest es in Forgejos eigener Oberfläche unter /<org>/-/settings.
• Avatar / Profilbild: Forgejos eigene Oberfläche unter /<org>/-/settings.
• Abrechnung, SSO, Sicherheitsrichtlinie, Push-Schutz: siehe die eigenen Tabs oben.

Die Abgrenzung: Die fremforge-Verwaltung verantwortet Anzeigename der Organisation, Sichtbarkeit, Website, Beschreibung, Standort neben den eigenen Tabs für Abonnement, Richtlinien, Sicherheit und Audit. Forgejos eigene Oberfläche unter /<org>/-/settings verantwortet Avatar / Profilbild, Umbenennen des Slugs, Forgejo-interne Vorgaben für das Anlegen von Repositorys und tiefere Konfiguration, die es nur in Forgejo gibt. Beides ist von Owner-Konten aus erreichbar; nimm die Oberfläche, die zu deiner Änderung passt.

Audit-Log

frem.sh/<org>/_admin/audit-log: jede zustandsändernde Verwaltungsaktion an deiner Organisation, in Echtzeit durchsuchbar.

• Filter nach Akteur: auf einen bestimmten Forgejo-Nutzer, auf Operator-Aktionen (mit dem Präfix operator:<email>) oder auf einen Agenten einschränken. Er findet den Akteur, die Person, für die ein Agent gehandelt hat, und den Agenten selbst, sodass der Filter auf einen Nutzer auch das einschließt, was Agenten in seinem Auftrag getan haben.
• Chip „über Agent“: Eine Aktion, die ein Agent im Auftrag einer Person ausgeführt hat, nennt die Person als Akteur und ist als über Agent markiert; die ID des Agenten steht im Feld agent des Ereignisses.
• Filter nach Aktion: auf einen Namensraum einschränken (z. B. push-protection oder billing.cancel).
• Filter nach Zeitpunkt: zeitlich begrenzt.
• Operator-Kennzeichnung: Aktionen von fremverk-Mitarbeitenden im Auftrag deiner Organisation sind orange hervorgehoben und nie stillschweigend. Dieselben Daten landen im Audit-Ausschnitt deines Datenexport-Pakets.

Auf dem Bildschirm endet die Liste älterer Ereignisse nach 200 Zeilen. Für vollständige historische Abrufe nutze den Datenexport. Der Audit-Ausschnitt im Paket ist unbegrenzt.

Aufbewahrung. Gemäß AVV Anhang A.7 liegen sicherheitsrelevante Ereignisse (Authentifizierung, Autorisierung, Verwaltungsaktionen) in einer abfragbaren Hot-Stufe mit einer Aufbewahrung pro Organisation, die du unter Sicherheit → Authentifizierungsrichtlinie → Aufbewahrung des Audit-Logs festlegst: Vorgaben sind 90 / 180 / 365 / 730 Tage, Standard ist 90 (Standardtarif) oder 365 (Enterprise-Tarife). Betriebslogs (HTTP, Runner, Infrastruktur) bleiben 30 Tage in der Hot-Stufe (nicht konfigurierbar). Beide Stufen werden in ein unveränderliches WORM-Archiv auf T Cloud Public OBS für 3 Jahre geschrieben, mit einer Verankerung der Hash-Kette alle 2 Minuten als Manipulationsnachweis. Nach dem Ende der Hot-Stufe wird der Inhalt (actor, fields_json) geschwärzt, die SHA-256-Hashes der Kette bleiben aber die vollen 3 Jahre erhalten. Die Ansicht auf dem Bildschirm und der Audit-Ausschnitt des Datenexport-Pakets decken beide den konfigurierten Zeitraum der Hot-Stufe ab. Um ältere Ereignisse aus dem WORM-Archiv abzurufen, wende dich an support@frem.sh.

API-Gleichwertigkeit

Jede Verwaltungsaktion ist auch ein dokumentierter REST-Endpunkt. Die Verwaltungsoberfläche ist selbst ein Client derselben API, die auch ein KI-Agent nutzen würde. Die OpenAPI-Spezifikation findest du unter öffentliche REST-API.

Zwei Namensräume, ein Host. Routen unter /api/v1/... sind Forgejo-nativ (dieselbe Form wie die Upstream-Forgejo-API, ohne fremforge-Präfix; genutzt für CRUD an Organisationen, Repositorys, Nutzern, Issues und Pull Requests, das Forgejo bereits abdeckt). Routen unter /_app/api/v1/... sind fremforge-Erweiterungen (die Ergänzungen der Steuerungsebene, die wir darüberlegen: Abrechnung, Push-Schutz, Datenexport, gehostetes Renovate, SSO-Richtlinie, Attestierungen). Der in §Einstellungen oben genannte Aufruf PATCH /api/v1/orgs/{org} ist die Forgejo-native Form; derselbe Host bedient beide Präfixe über das Routing der Plattform. Nimm das Präfix, das zum dokumentierten Endpunkt passt, und mische sie nicht.

Damit kannst du alles, was du in der Verwaltungsoberfläche tust, auch programmatisch tun:

• POST /_app/api/v1/orgs/<org>/dependency-updates/enrol, entspricht einem Klick auf „Gehostetes Renovate aktivieren“ (fremforge-Erweiterung)
• POST /_app/api/v1/orgs/<org>/exports, entspricht einem Klick auf „Neuen Export starten“ (fremforge-Erweiterung)
• GET /_app/api/v1/orgs/<org>/push-protection/overrides, listet die aktiven Ausnahmen des Push-Schutzes (fremforge-Erweiterung)
• PATCH /api/v1/orgs/<org>, aktualisiert Anzeigename / Website / Standort / Sichtbarkeit (Forgejo-nativ)
• …usw.

Authentifizierung per Token: ein PAT aus deinen Forgejo-Nutzereinstellungen. OAuth 2.0 mit Client-Credentials ist zusammen mit dem Ablauf für Agenten-Identitäten geplant.

Audit-Trail

Jede Verwaltungsaktion schreibt eine strukturierte Logzeile in fremforges Audit-Stream, mit den Feldern actor, action, tenant_id sowie aktionsspezifischen Feldern. Das Audit-Log ist im Paket des Datenexports enthalten, beschränkt auf deine Organisation.

Was du in deinem Audit-Ausschnitt siehst:

• Alle POST/DELETE-Aktionen in der Verwaltungsoberfläche (alles, was einen Zustand ändert)
• Alle API-Aufrufe, die als Mitglied deiner Organisation authentifiziert sind
• Alle Operator-Aktionen, die fremverk-Mitarbeitende im Auftrag deiner Organisation ausführen (gekennzeichnet mit actor=operator:<email>, nie stillschweigend)

Was du nicht siehst (aus Gründen des Datenschutzes und rechtlicher Verfahren):

• Interne Infrastrukturereignisse von fremverk (die gehen in einen eigenen Audit-Stream)
• Organisationsübergreifende Korrelationskennungen (vor dem Export geschwärzt)

Querverweise

• Preise: was im Tarif für 30 € pro Nutzer enthalten ist
• Trust: Unterauftragsverarbeiter, Zertifizierungen, Haltung zur Souveränität
• Öffentliche REST-API: programmatische Entsprechungen jeder Verwaltungsaktion
• Migrationsanleitungen: Einrichtung Schritt für Schritt von GitHub / GitLab / Azure DevOps aus