Bewaring van bewijs

fremforge bewaart zes soorten bewijs over je organisatie. Elk soort heeft een eigen bewaarinstelling met grenzen, en een gedocumenteerde standaardwaarde: wat elke organisatie had voordat de instellingen bestonden. Een eigenaar wijzigt ze onder Rapporten → Bewaring van bewijs in de beheerconsole, of via de API.

De klassen

Waarom deze grenzen. De twee klassen met persoonsgegevens, de auditpayload en het toegangslog (actor, IP-adres), stoppen bij 730 dagen, de langste termijn die de privacyverklaring §6 en bijlage A.7 van de verwerkersovereenkomst (DPA) noemen voor beveiligingsauditgebeurtenissen. Exportdownloads stoppen bij de 7 dagen die §6 voor exports noemt. De andere klassen bevatten geen persoonsgegevens buiten wat een auditgebeurtenis al vastlegt en lopen tot 10 jaar, de bewaartermijn die de Europese Cyber Resilience Act voor technische documentatie voorschrijft.

Het exportbestand zelf wordt 7 dagen na het aanmaken verwijderd, in eu-de en in de kopie voor noodherstel in eu-nl (sinds 2026-10-08; dat was 90 dagen, en 13 maanden voor de noodherstelkopie). export_bundle kan de download eerder intrekken. Onder een juridische bewaarplicht wordt het bestand in beide regio’s bewaard, en zodra de bewaarplicht is opgeheven, wordt het verwijderd 7 dagen nadat het is aangemaakt. Het record van de export (wat er is geëxporteerd, wanneer, door wie, het manifest) wordt onder een juridische bewaarplicht ook bewaard.

Juridische bewaarplicht

Zolang er voor je organisatie een juridische bewaarplicht geldt, is het verwijderen van elke klasse opgeschort: de auditpayload wordt niet geredigeerd, rijen in het toegangslog, opgeloste bevindingen, SBOM’s, attestaties en exportrecords worden niet verwijderd, bevindingen van pull requests worden niet gewist als de pull request sluit, en de bevindingen van een verwijderde, hernoemde of overgedragen repository worden niet weggehaald. Je instellingen blijven bewaard en gelden weer vanaf de nacht nadat de bewaarplicht is opgeheven. De consolepagina en de API melden allebei wanneer er een bewaarplicht actief is.

Verwijderde, hernoemde en overgedragen repository’s

De bevindingen op de standaardbranch van een repository (codescanning, afhankelijkheden, licenties, secrets, kwaadaardige afhankelijkheden, de Trivy-scan van de repository, SHA-pinning) blijven onder de naam van de repository bewaard zolang een scan ze kan vervangen. Wordt een repository verwijderd, dan blijft hij gedurende de hersteltermijn van 30 dagen in de prullenbak van de organisatie, en zijn bevindingen blijven bij hem: een herstel brengt de repository terug met zijn bevindingen en negeringen zoals ze waren. Bij de eerste dagelijkse run nadat de hersteltermijn is verlopen (of nadat de repository direct is verwijderd, hernoemd of overgedragen, wanneer Forgejo onder de oude naam geen repository meer heeft), worden de bevindingen onder de oude naam weggehaald, samen met hun oordelen over de bereikbaarheid, de scanstatus, de baselines van de pull-request-gate en de negeringen voor de hele repository, zodat een nieuwe repository die later onder dezelfde naam wordt aangemaakt schoon begint. Sinds 2026-10-16; daarvoor bleven ze openstaan.

Elke verwijdering staat in het auditlog als code-security.findings.repo_gone_purged, met de repository en het aantal verwijderde rijen. Het compliancerapport telt de verwijderde bevindingen als opgelost op de dag dat ze worden verwijderd, net als elke andere bevinding die verdwijnt. Eerdere auditgebeurtenissen, waaronder elke negering, blijven bewaard. Bevindingen van de pull requests van de repository worden gewist als de pull requests sluiten, zoals voorheen. Bevindingen van gepubliceerde containerimages volgen het image, niet de 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

Lezen vereist policy:read, wijzigen vereist policy:write. De velden zijn audit_payload_days, access_log_days, findings_history_days, sbom_non_release_days, attestation_days en export_bundle_days; null zet een klasse terug op de standaardwaarde, en een waarde buiten de grenzen wordt geweigerd met 400. Het antwoord noemt elke klasse met configured_days (wat je hebt ingesteld, of null), effective_days (wat de taak nu toepast; null betekent bewaard zolang de organisatie bestaat), default_days, min_days, max_days en of de klasse persoonsgegevens bevat, plus legal_hold.active.

Elke wijziging staat in het auditlog als tenant.evidence_retention.updated, met de waarde van elke gewijzigde klasse ervoor en erna. De data-export bevat dezelfde lijst in policy/settings/retention.ndjson.

De oudere instelling voor het bewaren van het auditlog onder Authenticatiebeleid → Bewaartermijn auditlog en de SBOM-instelling op de SBOM-pagina zijn dezelfde waarden als audit_payload en sbom hier; je kunt ze op beide plekken wijzigen.

Wat bewaring niet dekt

• Het manipulatiebestendige archief van de auditketen (WORM) van 3 jaar, dat geen enkele instelling verkort. Zie Bewaren van het auditlog.
• Back-ups, die volgens hun eigen schema verlopen (DPA §9).
• Wat er gebeurt nadat je organisatie is opgezegd: dat volgt de levenscyclus.