Aller au contenu principal

Conservation des preuves

fremforge conserve six types de preuves concernant votre organisation. Chacun a son propre paramètre de conservation, avec des bornes, et une valeur par défaut documentée qui correspond à ce que chaque organisation avait avant l’existence de ces paramètres. Un propriétaire les modifie sous Rapports → Conservation des preuves dans la console d’administration, ou via l’API.

Les classes

ClasseCe que c’estPar défautVous pouvez choisirSupprimée par
audit_payloadL’acteur et les champs de chaque événement du journal d’audit. Après l’échéance, l’événement, son horodatage et son entrée dans la chaîne de hachage subsistent.90 jours (365 sur les offres enterprise, essai personnalisé et internes)90, 180, 365 ou 730 joursle caviardage quotidien des données d’audit
access_logLe journal d’accès au registre : qui a téléchargé, publié ou supprimé quel paquet, depuis quelle adresse IP.suit audit_payload30 à 730 joursla tâche quotidienne de conservation du journal d’accès
findings_historyLes résultats résolus : résultats de paquets, de dépendances malveillantes et d’épinglage SHA. Les résultats ouverts et ignorés constituent l’état actuel et ne sont pas concernés. Également l’instantané quotidien qui alimente la tendance des indicateurs de remédiation, conservé 18 mois lorsque cette classe n’est pas réglée.conservés tant que l’organisation existe (la tendance de remédiation : 18 mois)365 à 3650 joursle nettoyage nocturne de conservation
sbomLes SBOM des builds qui n’ont pas fait l’objet d’une release. Les SBOM des releases, de la tête de la branche par défaut, des images actuelles et des fichiers de paquets sont conservés.14 jours0 à 3650 joursl’élagage quotidien des SBOM
attestationLes attestations de provenance SLSA et leurs bundles Sigstore. Une attestation liée à une release immuable est conservée avec la release, quel que soit son âge.conservées tant que l’organisation existe365 à 3650 joursl’élagage quotidien des SBOM
export_bundleCombien de temps un export de données reste proposé au téléchargement. Le fichier lui-même est supprimé au bout de 7 jours.7 jours1 à 7 joursle nettoyage nocturne de conservation ; le fichier, par la règle de stockage

Pourquoi ces bornes. Les deux classes qui contiennent des données personnelles, les données d’audit et le journal d’accès (acteur, adresse IP), s’arrêtent à 730 jours, la durée la plus longue que la Politique de confidentialité §6 et l’annexe A.7 du DPA prévoient pour les événements d’audit de sécurité. Les téléchargements d’exports s’arrêtent aux 7 jours que le §6 prévoit pour les exports. Les autres classes ne contiennent pas de données personnelles au-delà de ce qu’un événement d’audit enregistre déjà, et vont jusqu’à 10 ans, la durée de conservation que le Cyber Resilience Act de l’UE fixe pour la documentation technique.

Le fichier d’export lui-même est supprimé 7 jours après sa création, dans eu-de et dans sa copie de reprise après sinistre dans eu-nl (depuis le 2026-10-08 ; c’était 90 jours, et 13 mois pour la copie de reprise). export_bundle peut retirer le téléchargement plus tôt. Sous une conservation légale, le fichier est conservé dans les deux régions, et une fois la conservation levée, il est supprimé 7 jours après sa création. L’enregistrement de l’export (ce qui a été exporté, quand, par qui, son manifeste) est lui aussi conservé sous une conservation légale.

Conservation légale

Tant que votre organisation est sous conservation légale, la suppression de toutes les classes est suspendue : les données d’audit ne sont pas caviardées, les lignes du journal d’accès, les résultats résolus, les SBOM, les attestations et les enregistrements d’export ne sont pas supprimés, les résultats de pull request ne sont pas effacés à la fermeture de la pull request, et les résultats d’un dépôt supprimé, renommé ou transféré ne sont pas retirés. Vos paramètres sont conservés et s’appliquent de nouveau la nuit suivant la levée de la conservation. La page de la console et l’API indiquent toutes deux lorsqu’une conservation est active.

Dépôts supprimés, renommés et transférés

Les résultats de la branche par défaut d’un dépôt (analyse de code, dépendances, licences, secrets, dépendances malveillantes, l’analyse Trivy du dépôt, épinglage SHA) sont conservés sous son nom tant qu’une analyse peut les remplacer. Lorsqu’un dépôt est supprimé, il reste dans la corbeille de l’organisation pendant sa fenêtre de restauration de 30 jours, et ses résultats restent avec lui : une restauration ramène le dépôt avec ses résultats et ses dérogations tels qu’ils étaient. Lors de la première exécution quotidienne après la fin de la fenêtre de restauration (ou après la suppression définitive, le renommage ou le transfert du dépôt, lorsque Forgejo n’a plus de dépôt sous l’ancien nom), les résultats enregistrés sous l’ancien nom sont retirés, avec leurs verdicts d’atteignabilité, leur état d’analyse, leurs références de vérification de pull request et les dérogations à l’échelle du dépôt, de sorte qu’un nouveau dépôt créé plus tard sous le même nom démarre vierge. Depuis le 2026-10-16 ; auparavant, ils restaient ouverts.

Chaque retrait figure dans le journal d’audit sous code-security.findings.repo_gone_purged, avec le dépôt et le nombre de lignes retirées. Le rapport de conformité compte les résultats retirés comme corrigés le jour de leur retrait, comme pour tout résultat qui disparaît. Les événements d’audit antérieurs, y compris chaque dérogation, sont conservés. Les résultats des pull requests du dépôt sont effacés à la fermeture des pull requests, comme auparavant. Les résultats des images de conteneurs publiées suivent l’image, pas le dépôt.

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

La lecture nécessite policy:read, la modification policy:write. Les champs sont audit_payload_days, access_log_days, findings_history_days, sbom_non_release_days, attestation_days et export_bundle_days ; null remet une classe à sa valeur par défaut, et une valeur hors bornes est refusée avec une erreur 400. La réponse liste chaque classe avec configured_days (ce que vous avez réglé, ou null), effective_days (ce que la tâche applique actuellement ; null signifie conservé tant que l’organisation existe), default_days, min_days, max_days et si elle contient des données personnelles, ainsi que legal_hold.active.

Chaque modification figure dans le journal d’audit sous tenant.evidence_retention.updated, avec la valeur avant et après de chaque classe modifiée. L’export de données contient la même liste dans policy/settings/retention.ndjson.

L’ancien paramètre de conservation de l’audit sous Politique d’authentification → Conservation du journal d’audit et le paramètre SBOM de la page des SBOM correspondent aux mêmes valeurs que audit_payload et sbom ici ; l’un ou l’autre endroit les modifie.

Ce que la conservation ne couvre pas

  • L’archive de 3 ans de la chaîne d’audit infalsifiable (WORM), qu’aucun paramètre ne raccourcit. Voir Conservation du journal d’audit.
  • Les sauvegardes, qui expirent selon leur propre calendrier (DPA §9).
  • Ce qui se passe après la résiliation de votre organisation : cela suit le cycle de vie.