Aufbewahrung von Nachweisen

fremforge bewahrt sechs Arten von Nachweisen über deine Organisation auf. Jede hat ihre eigene Aufbewahrungseinstellung mit Grenzen und einen dokumentierten Standard, der dem entspricht, was jede Organisation hatte, bevor es die Einstellungen gab. Ein Owner ändert sie in der Admin-Konsole unter Berichte → Aufbewahrung von Nachweisen oder über die API.

Die Klassen

Warum diese Grenzen. Die beiden Klassen mit personenbezogenen Daten, die Audit-Payload und das Zugriffsprotokoll (Akteur, IP-Adresse), enden bei 730 Tagen, dem längsten Zeitraum, den der Datenschutzhinweis §6 und Anhang A.7 der DPA für Sicherheits-Audit-Ereignisse nennen. Export-Downloads enden bei den 7 Tagen, die §6 für Exporte nennt. Die anderen Klassen enthalten keine personenbezogenen Daten über das hinaus, was ein Audit-Ereignis bereits erfasst, und reichen bis zu 10 Jahren, der Aufbewahrungsdauer, die der EU Cyber Resilience Act für technische Dokumentation vorschreibt.

Die Exportdatei selbst wird 7 Tage nach ihrer Erstellung gelöscht, in eu-de und in ihrer Disaster-Recovery-Kopie in eu-nl (seit 2026-10-08; vorher waren es 90 Tage und 13 Monate für die DR-Kopie). export_bundle kann den Download früher zurückziehen. Unter einem Legal Hold bleibt die Datei in beiden Regionen erhalten, und sobald der Hold aufgehoben ist, wird sie 7 Tage nach ihrer Erstellung gelöscht. Der Datensatz des Exports (was wann von wem exportiert wurde, sein Manifest) bleibt unter einem Legal Hold ebenfalls erhalten.

Legal Hold

Solange deine Organisation unter einem Legal Hold steht, ist das Löschen jeder Klasse ausgesetzt: Die Audit-Payload wird nicht geschwärzt, Zeilen des Zugriffsprotokolls, erledigte Befunde, SBOMs, Attestierungen und Exportdatensätze werden nicht gelöscht, Pull-Request-Befunde werden beim Schließen des Pull Requests nicht entfernt, und die Befunde eines gelöschten, umbenannten oder übertragenen Repositorys werden nicht entfernt. Deine Einstellungen bleiben erhalten und gelten in der Nacht nach der Aufhebung des Holds wieder. Die Konsolenseite und die API zeigen beide an, wenn ein Hold aktiv ist.

Gelöschte, umbenannte und übertragene Repositorys

Die Befunde des Standard-Branches eines Repositorys (Code-Scanning, Abhängigkeiten, Lizenzen, Secrets, schädliche Abhängigkeiten, der Trivy-Scan des Repositorys, SHA-Pinning) bleiben unter seinem Namen erhalten, solange ein Scan sie ersetzen kann. Wird ein Repository gelöscht, bleibt es für sein 30-tägiges Wiederherstellungsfenster im Papierkorb der Organisation, und seine Befunde bleiben bei ihm: Eine Wiederherstellung bringt das Repository mit seinen Befunden und Verwerfungen so zurück, wie sie waren. Beim ersten täglichen Lauf nach dem Ende des Wiederherstellungsfensters (oder nachdem das Repository endgültig gelöscht, umbenannt oder übertragen wurde, wenn Forgejo kein Repository mehr unter dem alten Namen hat) werden die unter dem alten Namen abgelegten Befunde entfernt, zusammen mit ihren Erreichbarkeitsurteilen, dem Scan-Zustand, den Baselines des Pull-Request-Gates und den repositoryweiten Verwerfungen, sodass ein neues Repository, das später unter demselben Namen angelegt wird, ohne Altlasten beginnt. Das gilt seit 2026-10-16; vorher blieben sie offen.

Jede Entfernung steht im Audit-Log als code-security.findings.repo_gone_purged, mit dem Repository und der Anzahl entfernter Zeilen. Der Compliance-Bericht zählt die entfernten Befunde an dem Tag als behoben, an dem sie entfernt werden, wie bei jedem Befund, der verschwindet. Frühere Audit-Ereignisse, einschließlich jeder Verwerfung, bleiben erhalten. Befunde der Pull Requests des Repositorys werden wie bisher entfernt, wenn die Pull Requests geschlossen werden. Befunde veröffentlichter Container-Images folgen dem Image, nicht dem Repository.

API

# read
curl -H "Authorization: Bearer ${FREMFORGE_PAT}" \
  https://frem.sh/_app/api/v1/orgs/acme/evidence-retention

# set two classes, reset one to its default
curl -X PATCH -H "Authorization: Bearer ${FREMFORGE_PAT}" -H 'Content-Type: application/json' \
  -d '{"access_log_days": 180, "findings_history_days": 1095, "attestation_days": null}' \
  https://frem.sh/_app/api/v1/orgs/acme/evidence-retention

Lesen erfordert policy:read, Ändern erfordert policy:write. Die Felder sind audit_payload_days, access_log_days, findings_history_days, sbom_non_release_days, attestation_days und export_bundle_days; null setzt eine Klasse auf ihren Standard zurück, und ein Wert außerhalb der Grenzen wird mit 400 abgelehnt. Die Antwort listet jede Klasse mit configured_days (was du gesetzt hast, oder null), effective_days (was der Job jetzt anwendet; null bedeutet so lange, wie die Organisation besteht), default_days, min_days, max_days und ob sie personenbezogene Daten enthält, dazu legal_hold.active.

Jede Änderung steht im Audit-Log als tenant.evidence_retention.updated, mit dem Wert jeder geänderten Klasse vorher und nachher. Der Datenexport enthält dieselbe Liste in policy/settings/retention.ndjson.

Die ältere Einstellung unter Authentifizierungsrichtlinie → Aufbewahrung des Audit-Logs und die SBOM-Einstellung auf der SBOM-Seite sind dieselben Werte wie audit_payload und sbom hier; beide Stellen ändern sie.

Was die Aufbewahrung nicht abdeckt

• Das manipulationssichere Archiv der Audit-Kette über 3 Jahre (WORM), das keine Einstellung verkürzt. Siehe Aufbewahrung des Audit-Logs.
• Backups, die nach ihrem eigenen Zeitplan ablaufen (DPA §9).
• Was nach der Kündigung deiner Organisation geschieht: Das folgt dem Lebenszyklus.