Confiance

Date d’entrée en vigueur : 2026-05-19 - Version : 1.13

Dernière mise à jour : 2026-10-07

Synthèse #

fremforge est un service d’hébergement Git souverain européen, construit sur Forgejo (version amont) et exploité par fremverk ApS (Danemark). Tous les services fonctionnent dans l’Union européenne. Aucune donnée client ne quitte la juridiction de l’UE.

Chaque traitement (dépôts, CI, audit, facturation, authentification, e-mails sortants, correspondance entrante des boîtes partagées) est assuré par des entités sans société mère américaine. Zéro sous-traitant ultérieur à capitaux américains, sur aucun chemin. Voir le §11.3 du DPA produit pour la position complète.

Cette page est la référence officielle sur l’emplacement de vos données, les entités qui les traitent, les certifications applicables et la manière de nous joindre.

Responsable du traitement #

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

Hébergement et régions #

Sous-traitants ultérieurs #

La liste à jour des sous-traitants ultérieurs est tenue ici. Toute modification est annoncée 30 jours à l’avance sur la liste de diffusion sécurité et sur cette page.

La protection contre les robots ne fait intervenir aucun sous-traitant tiers. Les formulaires d’inscription et de connexion du produit utilisent Altcha, auto-hébergé (sous licence MIT, preuve de travail signée HMAC), qui s’exécute dans le processus du monolithe api, sur le même cluster T Cloud Public ; aucun JavaScript de widget tiers, aucun sous-traitant ultérieur externe. Des contrôles supplémentaires côté serveur (throttling et limitation de débit par IP) s’appliquent à l’ensemble des services. Aucun pare-feu applicatif web n’est activé en edge ; voir la section Protection en edge ci-dessous.

Protection en edge – atténuation DDoS, pas de WAF #

Tous les services fremforge (frem.sh pour Forgejo et Git, l’API, ainsi que les sites www, docs, status et CLI) sont placés derrière l’edge de Bunny CDN, qui assure l’atténuation des DDoS volumétriques et la limitation de débit par IP. Aucun pare-feu applicatif web (WAF) n’est activé en edge sur aucun service fremforge, et ce depuis avant la mise en service. Ce choix est délibéré. Lors des tests précédant le lancement, l’OWASP Core Rule Set a produit un taux élevé de faux positifs sur les formes de requêtes de Forgejo (chemins du protocole Git, routes de diff des pull requests, récupérations de blobs bruts avec identifiants hexadécimaux, chaînes de requête d’URL signées) et sur les corps de formulaire de l’API. Un WAF trop agressif, qui casse des opérations Git légitimes ou des parcours de l’interface Forgejo, aurait été pire pour les clients que le risque résiduel au niveau de l’edge. Les protections se trouvent donc dans l’application : détection de secrets en pre-receive, preuve de travail Altcha à l’inscription et à la connexion, limitation de débit par IP et par locataire dans l’API, authentification par jeton signé sur chaque récepteur de webhook, et hachage d’intégrité de la chaîne d’audit. Cette position est décrite à l’annexe A.2 du DPA et réexaminée à chaque revue opérationnelle trimestrielle.

Isolation des runners hébergés – VM ECS éphémère, une par commit #

Les jobs de CI que vous poussez vers fremforge s’exécutent sur T Cloud Public Elastic Cloud Server (ECS) : chaque commit ou pull request dispose de sa propre machine virtuelle éphémère, provisionnée à neuf et détruite une fois les jobs de ce commit terminés. Deux niveaux d’isolation indépendants :

• Calcul / noyau – une VM dédiée par commit. Les jobs de chaque commit s’exécutent dans une machine virtuelle ECS dotée de son propre noyau Linux, isolée par l’hyperviseur. Deux clients, ou deux commits, ne partagent jamais un noyau ni une machine : les primitives d’évasion de conteneur côté noyau (évasion de cgroup, évasion par bind-mount de /proc, eBPF, exposition de /sys) n’ont aucune frontière inter-locataires à franchir, puisqu’il n’existe aucun noyau partagé vers lequel s’évader. L’unité d’isolation est une VM entière, et non un conteneur – une frontière plus forte que le modèle de conteneurs à noyau partagé qu’utilise Kubernetes classique (CCE compris) pour les pods de runners. La VM est supprimée dès que les jobs de ce commit sont terminés : rien – cache de build, code cloné, secrets injectés – ne subsiste dans les jobs d’un autre commit ni chez un autre client.
• Au sein d’un même commit, les jobs peuvent partager la machine. Les jobs successifs d’une même exécution de workflow (par exemple build puis deploy sur le même commit) peuvent s’exécuter sur la même VM, détruite à leur issue. C’est voulu : le code relu est le même dans les deux jobs, et une machine neuve par job coûterait environ 40 secondes de latence de démarrage supplémentaire à chaque étape d’un pipeline. La conséquence, que nous préférons énoncer clairement : une étape de build qui exécute du code de dépendances tierces partage la machine avec une étape ultérieure du même commit. Traitez donc un pipeline comme un seul domaine de confiance, et limitez à ce pipeline tout identifiant dont une étape de déploiement a besoin. L’isolation inter-locataires et inter-commits décrite ci-dessus n’en est pas affectée.
• Réseau – un Security Group VPC par VM. Chaque VM de runner est placée derrière son propre Security Group VPC : aucun accès entrant, trafic de VM à VM (intra-sous-réseau) refusé, et trafic sortant limité au proxy sortant des runners protégé contre les SSRF, à l’API Forgejo et au DNS. L’isolation est appliquée au niveau VPC/hyperviseur, et non par une NetworkPolicy dans le cluster qui dépendrait du bon comportement d’un agent CNI. Combiné au proxy sortant obligatoire et à sa liste de refus anti-SSRF, tout mouvement latéral depuis une VM de runner vers autre chose que le contexte de job du client lui-même est refusé, à la fois au niveau de la VM et du VPC.

Si le modèle d’isolation de T Cloud Public évolue sur l’un ou l’autre de ces niveaux dans un sens qui affaiblit ce qui précède (par exemple si les VM par job sont remplacées par des conteneurs à noyau partagé, ou si la frontière du Security Group par VM est supprimée), cette page est mise à jour dans les 30 jours suivant le changement et chaque Client actif est informé conformément au §14 du DPA.

Certifications héritées #

Via T Cloud Public :

• ISO/IEC 27001 – management de la sécurité de l’information
• ISO/IEC 27017 – mesures de sécurité propres au cloud
• ISO/IEC 27018 – protection des données personnelles dans le cloud
• BSI C5 Type 2 – référentiel fédéral allemand de sécurité du cloud
• TISAX – référentiel d’assurance de l’industrie automobile allemande
• Traitement conforme au RGPD dans des centres de données situés dans l’UE

Feuille de route des certifications propres à fremverk #

À la Date d’entrée en vigueur, fremverk ne détient pas en propre de certification ISO 27001, SOC 2 ou BSI C5. La posture de sécurité de fremverk repose sur (i) les certifications héritées de ses sous-traitants ultérieurs listés ci-dessus, (ii) les mesures techniques et organisationnelles de l’annexe sécurité du DPA, et (iii) le programme de sécurité de l’information et de tests de sécurité de fremverk décrit dans cette même annexe.

fremverk s’est engagé à :

• engager l’audit ISO 27001 d’étape 1 dans les 18 mois suivant la Date d’entrée en vigueur et obtenir la certification dans les 24 mois ;
• engager une évaluation de préparation SOC 2 Type II dans les 24 mois.

Les Clients qui exigent une certification directe avant ces échéances peuvent contracter en Enterprise-on-Demand, avec les jalons de préparation à la certification inscrits dans le bon de commande. Voir le §12.1 du DPA.

Transparence sur les accès gouvernementaux #

À la Date d’entrée en vigueur, fremverk n’a reçu aucune demande d’accès gouvernemental portant sur des données personnelles du Client. Le rapport complet – y compris la déclaration sur la période partielle couvrant l’activité avant lancement – est publié sur frem.sh/trust/transparency/. Les rapports suivants couvrent des années civiles complètes et sont publiés au 1er trimestre de l’année suivante.

Lorsque fremverk reçoit une demande légale contraignante d’une autorité publique, d’un tribunal ou d’un service répressif, fremverk :

• examine la validité juridique de la demande, la compétence de l’autorité et la proportionnalité ;
• conteste toute demande trop large, dépourvue de base légale ou contraire au droit de l’UE (y compris l’article 48 du RGPD pour les demandes émanant de pays hors UE/EEE) ;
• informe le Client concerné dans les 24 heures suivant la réception, sauf interdiction légale ;
• laisse au Client une possibilité raisonnable de demander une mesure de protection ou de contester la demande par tout autre moyen.

Voir le §11A du DPA.

Rapport de transparence DSA (article 15) #

fremforge est un service d’hébergement au sens du règlement (UE) 2022/2065 (règlement sur les services numériques, DSA). Le rapport annuel au titre de l’article 15 – volumes de notifications et d’actions, injonctions des autorités des États membres, modération de contenu à notre initiative et issue des réclamations au titre de l’article 20 – est publié sur frem.sh/trust/dsa/, séparément du rapport sur les accès gouvernementaux ci-dessus. La même URL publie, tous les six mois, le nombre moyen mensuel de destinataires du service dans l’UE exigé par l’article 24(2).

Schrems II – transferts internationaux #

Aucun transfert international de données personnelles du Client n’a lieu, sur aucun chemin de traitement. L’ensemble du traitement (contenu des dépôts, exécutions de CI, journaux d’audit, métadonnées d’authentification, données de facturation, données des moyens de paiement, e-mails transactionnels sortants et correspondance entrante des boîtes partagées) a lieu dans l’UE/EEE, auprès d’entités sans société mère américaine. Aucune garantie au titre de l’article 46 du RGPD, aucune CCT ni aucune analyse d’impact des transferts n’est nécessaire.

Résidence des PoP en edge (Bunny CDN) #

Chaque pullzone Bunny placée devant frem.sh est configurée pour servir uniquement depuis des PoP européens – aucune mise en cache aux États-Unis, en Australie ou en Asie. C’est imposé dans OpenTofu sur chaque ressource pullzone via routing { zones = ["EU"] }. La configuration des pullzones se trouve dans l’arborescence des sources :

• Pullzone Forgejo : fremforge/forgejo/.infrastructure/main.tf – rechercher zones = ["EU"]
• Pullzone API : fremforge/monolith/.infrastructure/bunny.tf – même ligne
• Les pullzones des sites statiques (www, docs, status, cli) héritent du même bloc routing depuis le module partagé fremverk/cloudplatform/modules/static-site/main.tf:103-112.

Un tofu plan sur n’importe quelle pile de pullzone affiche la valeur active de routing.zones : tout écart par rapport à ["EU"] apparaîtrait comme une différence dans le plan. Les preuves auditables deviendront directement consultables une fois l’arborescence des sources hébergée sur l’instance Forgejo accessible aux clients (sur https://frem.sh/fremforge/...) ; en attendant, la documentation de référence sur l’ancrage de la chaîne d’audit et sur le vérificateur d’intégrité est publiée sur docs.frem.sh/security/audit-chain/.

À propos du TLD #

frem.sh est un ccTLD de Sainte-Hélène (.sh) administré par un opérateur de registre enregistré au Royaume-Uni. Il s’agit uniquement d’un fait au niveau DNS. Aucune donnée client, aucun état du plan de contrôle et aucune sauvegarde ne quittent T Cloud Public EU-DE. Les garanties de souveraineté (identité du sous-traitant, liste des sous-traitants ultérieurs, résidence des données) sont fixées dans le DPA et ne dépendent pas de l’hébergement DNS.

Aucune exposition au CLOUD Act, sur aucun chemin de traitement. Toutes les données personnelles du Client sont traitées dans l’UE/EEE par des entités sans société mère américaine. Voir le §11.3 du DPA pour la position complète.

Note sur les réseaux de cartes. La chaîne de traitement des cartes de Mollie, attestée PCI-DSS, fait intervenir Visa Europe Services Inc. (succursale britannique) et Mastercard Europe SA (Belgique) – des entités d’exploitation européennes dont les sociétés mères ultimes (Visa Inc., Mastercard Inc.) sont constituées aux États-Unis. L’affirmation « sans société mère américaine » s’applique à la chaîne de sous-traitants ultérieurs de fremverk au niveau des sociétés d’exploitation ; les réseaux de cartes sont des sous-traitants de rang suivant de Mollie, en vertu des règles des réseaux PCI-DSS. Les Clients qui souhaitent une exposition nulle à des sociétés mères américaines sur le chemin de paiement peuvent payer par prélèvement SEPA (sans intervention des réseaux de cartes). Voir sous-traitants ultérieurs – Note sur les réseaux de cartes.

Vérifiez vous-même la chaîne d’audit #

Chaque action d’administration modifiant l’état de votre organisation est enregistrée dans une chaîne de hachage SHA-256 propre à votre locataire ; la tête de chaîne est ancrée en WORM toutes les deux minutes dans le stockage OBS Object Lock de T Cloud Public (conservation de 3 ans, physiquement impossible à supprimer pendant la durée de conservation). Vous pouvez parcourir la chaîne de bout en bout sans avoir à croire fremverk sur parole.

Avec la CLI fremforge :

# 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

Ou avec curl, directement sur le point de terminaison qu’appelle la CLI :

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}'

Une réponse saine indique "integrity_status": "ok" et contient un bloc worm_anchor dont la valeur agrees_with_db_walk: true confirme que la chaîne en base de données correspond à la tête ancrée dans OBS. Une rupture (hash_mismatch / prev_hash_mismatch) renvoie l’identifiant de la ligne en cause et la raison – un format conçu pour être lisible par un auditeur. Schéma complet, codes de sortie et modèle de menace dans docs.frem.sh – intégrité de la chaîne d’audit.

Garde des identifiants opérateur #

Les identifiants d’administration d’amorçage (l’AK/SK racine T Cloud Public au niveau du domaine, utilisé uniquement pour la création initiale de l’IAM, des buckets OBS et des agences liées aux services) sont stockés sur le portable de l’opérateur, avec chiffrement intégral du disque FileVault et des permissions de fichier chmod 600, renouvelés chaque trimestre, jamais transmis par chat ou partage d’écran, et révocables en moins de 10 minutes via la console OTC. Les déploiements courants utilisent des clés de déploiement à portée limitée par composant, et non l’identifiant racine.

Contact sécurité #

• Signaler une vulnérabilité : security@frem.sh
• Politique de divulgation : sécurité
• Empreinte de la clé PGP : DBA3 184D 0EFA E4C2 51ED EB46 53FA 57F8 698C 3488 (clé publique – armure RFC 4880, RSA-4096, expire le 2031-05-14). À utiliser pour les signalements de vulnérabilité chiffrés envoyés à security@frem.sh. La clé n’est publiée que depuis frem.sh/.well-known/ ; nous ne la déposons pas sur les serveurs de clés publics (pour éviter une racine de confiance tierce). Copie disponible sur /pgp.txt pour plus de commodité.

Divulgation des vulnérabilités #

Une politique de divulgation lisible par machine est publiée sur frem.sh/.well-known/security.txt conformément à la RFC 9116 ; elle couvre la protection juridique des recherches menées de bonne foi, le périmètre et le canal de signalement. Les rapports de tests d’intrusion réalisés par des tiers, lorsqu’ils sont commandés, sont mis à la disposition des Clients sous NDA, sur demande écrite, conformément au §12.1 du DPA ; les contrats Enterprise-on-Demand peuvent prévoir une fréquence de tests précise dans le bon de commande.

Divulgation des incidents #

Les post-mortems de tout incident affectant les données ou la disponibilité pour les clients sont publiés sur cette page dans un délai de 14 jours, conformément à notre politique de sécurité.

Correctifs de sécurité #

fremforge s’engage sur les délais maximaux suivants pour corriger les vulnérabilités de sécurité de la plateforme, comptés à partir de la publication de la version corrective amont ou de l’avis de sécurité, selon la date la plus tardive.

Des versions d’urgence hors cycle sont à prévoir. La fenêtre de maintenance hebdomadaire est un plafond, pas un plancher. Les correctifs de sécurité ne sont jamais reportés pour respecter la fenêtre de maintenance d’un locataire ; c’est indiqué dans l’AUP et repris mot pour mot dans l’annexe sécurité du DPA.

Réversibilité et portabilité des données #

Tout est exportable – dépôts, tickets, pull requests, journaux Actions, piste d’audit, attestations SLSA – via l’API, dans des formats standard. Aucun verrouillage par la conservation, aucuns frais d’export.

Export infalsifiable en libre-service. Tout administrateur de locataire peut déclencher à tout moment un export complet depuis l’interface d’administration. Il est livré sous forme d’un unique zip accompagné d’un manifeste SHA-256 couvrant chaque fichier de l’archive (manifest.json + archive.tar.gz.sha256), afin que le client puisse vérifier que le contenu n’a pas été altéré après le téléchargement. L’export contient les fichiers git bundle des dépôts, les manifestes LFS, les journaux Actions, l’extrait d’audit et les attestations SLSA. À titre de comparaison, l’export d’organisation de GitHub est un ensemble d’appels à l’API REST, réservé aux propriétaires de l’organisation, qui produit une archive destinée à être importée dans GitHub Enterprise Server (documentation GitHub, consultée le 17 octobre 2026). fremforge le fournit sur toutes les offres, à tous les clients, tous les jours. Le manifeste est signé avec notre clé de builder SLSA (enveloppe DSSE, manifest.json.intoto.jsonl) ; les clients le vérifient avec la même racine de confiance, publiée sur https://www.frem.sh/.well-known/slsa-trust-root.json pour les attestations de build SLSA. La vérification du manifeste ne nécessite aucun Sigstore – ni l’instance publique, ni les Fulcio et TSA auto-hébergés que nous utilisons comme seconde signature des attestations de build. Voir docs.frem.sh/data-export pour la structure de l’export, les procédures de vérification et les points de terminaison de l’API.

Les délais et procédures de sortie d’un locataire sont détaillés dans le DPA.

Cookies et traçage #

fremforge ne dépose que des cookies strictement nécessaires sur les services produit authentifiés, et aucun cookie sur le site vitrine, la documentation, la page de statut et les pages anonymes. Aucun bandeau de consentement n’est nécessaire : non pas parce que nous aurions esquivé la question, mais parce que nous ne déposons aucun cookie qui exigerait un consentement.

Les services produit authentifiés déposent quatre cookies internes, tous strictement nécessaires au sens de l’article 5(3) de la directive ePrivacy :

Le site vitrine, la documentation et la page de statut (www.frem.sh, docs.frem.sh, status.frem.sh) sont des sites statiques générés avec Hugo, sans cookies, sans outil d’analyse, sans contenus intégrés et sans traçage d’aucune sorte. Vérifiable dans les outils de développement de votre navigateur.

Les appels tiers depuis l’interface du produit sont désactivés par défaut : pas de Gravatar, pas d’avatars fédérés, pas de polices ni de scripts chargés depuis un CDN, pas d’outil d’analyse tiers. Les avatars sont stockés localement ; les polices sont servies depuis la même origine que la forge.

C’est un choix délibéré de produit, pas un minimum réglementaire. L’inventaire complet des cookies et les droits des personnes concernées sont documentés dans la politique de confidentialité du produit.

Modifications des mesures de sécurité #

L’annexe A du DPA liste les mesures techniques et organisationnelles appliquées par fremverk et précise que leurs modifications importantes sont notifiées ici. Les modifications à partir du 2026-10-04 figurent ci-dessous, de la plus récente à la plus ancienne ; les modifications antérieures sont consignées dans le journal des modifications du DPA. Une modification qui réduit un engagement prend effet 30 jours après une notification à chaque administrateur du Client, avec le droit de résiliation prévu au §17 des Conditions ; les autres prennent effet dès leur publication. Chaque version renvoie vers son texte.

Modifications de cette page #

Les modifications sont versionnées dans Git et annoncées sur la liste de diffusion sécurité. La date en haut de cette page correspond à la dernière modification significative du contenu.

Historique des versions #