Les fonctionnalités de sécurité en un coup d’œil
Tout ce que fremforge fournit, dans un tableau facile à parcourir. Chaque ligne renvoie à la page dédiée pour la configuration, le processus de dérogation et la documentation de l’outil sous-jacent.
fremforge est délibérément transparent sur l’outillage open source qui se trouve sous chaque contrôle : les clients soumis à BSI C5, ISO 27001, BaFin ou à un examen réglementé par l’ENISA ont besoin d’une piste d’audit au niveau de l’outil, et nous préférons que vous puissiez lire notre source avec grep plutôt que de faire de la rétro-ingénierie sur une boîte noire. La différence tient à l’intégration (hooks, RBAC, chaîne d’audit, résidence dans l’UE, pas de Microsoft, pas d’AWS) — pas à l’analyseur.
Contrôles au push du code
| Contrôle | Ce qu’il fait | Outil | Configurable par tenant |
|---|---|---|---|
| Protection des push | Analyse des secrets en pre-receive ; rejette les commits contenant des identifiants avant qu’ils n’entrent dans l’historique git | Gitleaks v8 (plus de 120 motifs) | Règles de dérogation + contournement par motif |
| Protection de branche | Règles par branche : relecteurs requis, vérifications d’état, exigence de commits signés, blocage du force-push | Natif Forgejo | Oui (par branche) |
| Authentification à deux facteurs | TOTP pour chaque compte utilisateur ; l’obligation WebAuthn est disponible au niveau de l’organisation (l’enrôlement WebAuthn côté utilisateur se fait sur la page de sécurité des paramètres utilisateur de Forgejo). Peut être imposée par organisation | Natif Forgejo + hooks d’application personnalisés | Oui (obligation pour toute l’organisation, adhésion par utilisateur) |
| Vérification de la MFA OIDC | Vérifie cryptographiquement que votre IdP a attesté la MFA à chaque connexion, via la claim OIDC amr (RFC 8176). Remplace l’ancienne case « faire confiance à la MFA de l’IdP » attestée par l’opérateur — le jeton indique ["pwd","mfa"], sinon ce n’est pas de la MFA | Middleware de vérification de claim personnalisé | Politique d’amr requis par tenant |
| Accès de secours SSO | Lorsque votre IdP est indisponible, mal configuré ou que la connexion SSO est rompue, des propriétaires d’organisation nommément désignés peuvent récupérer l’accès par un chemin d’identifiants de secours géré séparément. Consigné dans le journal d’audit | Personnalisé (écrit par fremforge) | Propriétaires désignés par tenant |
| Signature de commits sans clé (sigstore / gitsign) | Signature liée à OIDC — votre identité IdP (Entra, Okta, Google Workspace, Authentik) signe le commit via un certificat Fulcio valable 10 minutes. Forgejo affiche Verified by sigstore: <email> via <IdP>. CA racine dans T Cloud Public DEW KMS (HSM FIPS 140-2 niveau 3, Allemagne). Fulcio sur sign.frem.sh, TSA sur tsa.frem.sh. Délibérément sans Rekor ni journal de transparence — horodatage ancré sur la TSA uniquement, ce qui tient les signatures à l’écart de tout journal tiers | Fulcio v1.8.5 + TSA auto-hébergés sur T Cloud Public eu-de, gitsign côté client | Administration de l’organisation → émetteurs OIDC autorisés + niveau d’exigence |
| Signature de commits — clé SSH | Signez vos commits avec la même clé SSH que celle utilisée par Forgejo pour le push. Le badge « Verified » apparaît nativement dans l’interface web. Coexiste avec la signature sans clé ; l’administrateur de l’organisation fixe le niveau d’exigence | OpenSSH + allowedSignersFile de Forgejo | Activation par utilisateur |
| Signature de commits — GPG | Flux standard git commit.gpgsign. Téléversez la clé publique dans les paramètres utilisateur ; Forgejo vérifie et affiche le badge « Verified » | GnuPG + natif Forgejo | Activation par utilisateur |
Qualité du code + analyse des vulnérabilités
Ces analyses s’exécutent de façon centralisée sur les propres analyseurs de fremforge, sur chaque pull request et sur la branche par défaut. Il n’y a aucun fichier de workflow à installer dans vos dépôts. Les résultats sont listés sous Sécurité › Résultats.
| Contrôle | Ce qu’il fait | Outil | Configurable |
|---|---|---|---|
| SAST | Analyse statique sur chaque PR et sur la branche par défaut, exécutée de façon centralisée sur les propres analyseurs de fremforge — aucun fichier de workflow à installer ni à maintenir dans votre dépôt. Détecte les injections, le XSS, les secrets codés en dur et les API dangereuses en C, C++, C#, Go, Java, JavaScript et TypeScript, Kotlin, PHP, Python, Ruby, Rust, Scala, Swift et Bash | OpenGrep avec les sast-rules de GitLab, les règles C/C++ de 0xdea et les règles propres à fremforge | Gravité bloquante ; vos propres règles OpenGrep, chacune vérifiée sur son propre échantillon avant de s’exécuter |
| Analyse des secrets | gitleaks sur chaque pull request (la vérification fremforge/secret-scan) et un balayage hebdomadaire de l’historique complet de chaque dépôt ; la protection des push bloque les secrets au moment du push | Gitleaks | Vérification de pull request activée ou désactivée |
| Analyse IaC | Vérifications de mauvaise configuration trivy config (Dockerfile, Compose, Kubernetes, Helm, Terraform et plus) sur chaque PR, sous la forme de la vérification fremforge/iac-scan avec son propre onglet de résultats, plus les vérifications Rego propres à votre organisation ; ne bloque que sur ce qu’une PR ajoute ; résultats regroupés par benchmark CIS et par domaine NIS2 dans le rapport de conformité | Trivy | Mode et seuil sous Sécurité › Politiques › Analyseurs |
| Analyse des dépendances (OSV) | Analyse CVE/GHSA des dépendances sur chaque PR, exécutée de façon centralisée sur les propres analyseurs de fremforge. Fait ressortir les CVE corrigeables avec la mise à niveau suggérée | osv-scanner | Seuil de gravité |
| Atteignabilité | Marque chaque résultat de dépendance et d’image comme atteignable, non atteignable ou inconnu, avec la preuve (fichier et ligne, ou fonction concernée), et s’en sert pour trier les listes, les Recommandations et le récapitulatif. Go : govulncheck sur les binaires de vos images. JavaScript et TypeScript : Jelly, au niveau des imports sauf si l’avis nomme des fonctions. Python, Java et Kotlin : au niveau des imports, y compris à travers d’autres paquets, jamais unreachable. Rien n’est masqué ni rejeté ; ce qui bloque une fusion reste inchangé sauf si vous l’activez | govulncheck, Jelly, lecteurs d’imports de fremforge | Multiplicateur de SLA optionnel (1-4) pour les résultats non atteignables ; option « ne pas bloquer les pull requests sur les résultats non atteignables » |
| Exploitation connue | Signale les résultats dont la CVE est listée comme exploitée par l’EU Vulnerability Database de l’ENISA ou le catalogue KEV de la CISA : un badge et un filtre, classés avant l’EPSS, jamais de SLA allongé, AutoFix en premier. Les deux listes sont actualisées chaque jour | Miroirs ENISA EUVD + CISA KEV | - |
| Correctifs de sécurité | Un clic ouvre une pull request qui fait passer une dépendance vulnérable à la plus petite version corrigeant tous les avis ouverts (pour les écosystèmes listés dans Écosystèmes pris en charge) ou qui met à jour le FROM de base d’une image ; Tout corriger par dépôt. Jamais fusionnée automatiquement. Des correctifs IA optionnels pour une courte liste de règles SAST utilisent uniquement votre propre fournisseur de modèles et sont désactivés par défaut | Renovate hébergé ; votre propre fournisseur d’IA pour les correctifs SAST | Limites par dépôt et par organisation ; correctifs IA désactivés par défaut |
| Correctifs à base de règles | Ouvrir une demande de correctif sur un résultat de secret déplace l’identifiant dans une variable d’environnement (Go, Python, JavaScript, TypeScript) ; sur six vérifications IaC, il fixe la propriété à sa valeur sûre. Une règle fixe, sans IA : rien ne quitte fremforge. Syntaxe vérifiée et nouvelle analyse au préalable, jamais fusionné automatiquement | gitleaks et Trivy, les analyseurs qui ont produit le résultat | Limites par dépôt et par organisation |
| Analyse des images de conteneurs | L’analyseur central de fremforge exécute Trivy (aucune étape d’installation) : trivy fs et trivy config sur chaque PR, trivy image sur chaque image de votre registre et sur chaque image tirée via le proxy de dépendances. Les résultats sont listés sous Sécurité › Résultats › Images de conteneurs, rattachés à l’image et au commit. Une action de blocage d’image (none, warn, block_pull) s’applique aux résultats égaux ou supérieurs au seuil d’image, élevé (high) par défaut | Trivy | Action de blocage, seuil et fichiers d’exclusion |
| Analyse des licences | Détection des licences par Trivy sur chaque PR, exécutée de façon centralisée sur les propres analyseurs de fremforge. Classe la licence de chaque dépendance dans une gravité de politique SPDX à 7 niveaux (permissive → réciproque → restreinte → interdite) ; bloque la fusion sur les résultats égaux ou supérieurs au seuil configuré. Visible sous Sécurité › Résultats › Licences | Trivy | Gravité bloquante + liste d’autorisation SPDX + rejet par résultat |
| OpenSSF Scorecard | Score hebdomadaire de bonnes pratiques par dépôt. Pas un workflow par dépôt — s’exécute chaque semaine sur une infrastructure de plateforme isolée, avec un bot par tenant disposant d’un accès en lecture seule aux dépôts ; les dépôts inchangés sont ignorés et seul le JSON du score est conservé. Fait apparaître les lacunes (protection de branche, obligation de MFA, dépendances épinglées, couverture de la revue de code) dans une colonne de la page Dépôts | scorecard | Cadence hebdomadaire + saut si HEAD inchangé |
| Paquets malveillants | Avis OSV MAL-* comparés au SBOM de la branche par défaut de chaque dépôt et aux paquets de langage de chaque image de conteneur publiée, après chaque push et chaque jour. Toujours critiques ; les tirages d’images ayant un résultat ouvert sont refusés | osv-scanner + Trivy | Rejet avec motif et date de fin |
| Politiques de paquets | Une politique par organisation décide quels paquets du registre peuvent être téléchargés : seuils de vulnérabilité (gravité, CVSS, EPSS, correctif disponible), listes de licences SPDX, listes d’autorisation et de refus avec plages de versions, et un âge minimal. Les exceptions doivent être approuvées par une seconde personne. Enforce refuse avec 403, Shadow (par défaut) consigne ; un fichier embarquant un logiciel malveillant connu est refusé dans tous les modes. Images de conteneurs : shadow uniquement | Syft + osv-scanner | Mode, règles, dérogations par type, exceptions |
| Analyse antimalware des téléversements | ClamAV sur les objets Git-LFS, les pièces jointes web et les téléversements de paquets. Le proxy de dépendances analyse avec ClamAV les paquets et les couches d’images récupérés lorsque votre organisation l’active (désactivé par défaut) | ClamAV avec les signatures SaneSecurity, YARA-Forge Core et Linux Malware Detect | Dérogation sur les signatures connues comme faux positifs |
| Contrôle de sécurité des workflows | Une vérification pre-receive analyse chaque YAML de workflow modifié et rejette les pushs qui introduisent : des références docker:// vers des registres non autorisés, des motifs d’injection dangereux pull_request_target + script, des références uses: non épinglées vers des organisations non mises en miroir | Règles personnalisées (écrites par fremforge) | Dérogation à la liste d’autorisation d’URI docker par tenant |
| Liste d’autorisation d’IP | Une liste unique par organisation de plages CIDR autorisées pour chaque surface HTTPS : administration web, API fremforge, interface web des dépôts, API REST de Forgejo, Git sur HTTPS, LFS et registres de paquets. Git sur SSH n’est pas couvert. Aperçu en mode audit seul et accès de secours de 24 heures pour les propriétaires | Règles personnalisées (écrites par fremforge) | Liste CIDR par tenant + option pour les runners |
Provenance de la chaîne d’approvisionnement
| Contrôle | Ce qu’il fait | Outil | Configurable |
|---|---|---|---|
| SBOM | SBOM CycloneDX 1.6 et SPDX 2.3 générés de façon centralisée sur chaque PR (les deux formats sont acceptés à l’ingestion). Publier une release lie à la release le SBOM déjà détenu pour ce commit au lieu de le réanalyser ; un SBOM de release ne nécessite donc aucun build et apparaît immédiatement. Consultable sous Sécurité › Composants › SBOM | Syft | Fenêtre de rétention + refs de release |
| Attestation de publication signée | Une enveloppe DSSE in-toto / SLSA-provenance générée côté serveur par fremforge sur les webhooks Forgejo release.published / package — aucun fichier de workflow dans vos dépôts. fremforge calcule l’empreinte de chaque asset et signe avec une clé Ed25519 détenue par la plateforme (keyid fremforge-slsa-builder-v1, builder https://frem.sh/runner-controller/v1), téléversée à côté de l’asset sous la forme <asset>.intoto.jsonl, plus une seconde signature sans clé auprès du Fulcio auto-hébergé de fremforge + d’une TSA RFC3161 sous la forme <asset>.sigstore.json. Pas de Sigstore public, pas de Rekor, pas de journal de transparence. Vérifiez localement avec la racine de confiance publiée — voir Provenance SLSA. Délibérément non présentée comme un niveau SLSA : elle atteste ce qui a été PUBLIÉ, pas la façon dont cela a été construit ; la re-dérivation et ce qui manque figurent dans Provenance SLSA | Signataire côté serveur personnalisé (crypto de la bibliothèque standard Node, DSSE Ed25519) + Sigstore auto-hébergé | — |
| Signature + vérification d’images avec cosign | La vérification centrale de pull request fremforge/cosign-verify vérifie les signatures des images épinglées par digest, qu’elles proviennent des propres workflows de votre organisation via le Sigstore de fremforge ou du Sigstore public, et indique quand elle n’a pas pu vérifier. Elle est informative. La politique de signature des images peut aussi exiger des images signées au moment du tirage, avec vos identités de confiance. La CI du client signe avec sa propre identité OIDC — aucune clé de signature de longue durée | cosign + Fulcio auto-hébergé | Politique de signature (shadow ou enforce) |
| Épinglage des workflows | Une analyse quotidienne liste chaque uses: dans .forgejo/workflows/, .gitea/workflows/ et .github/workflows/ qui pointe vers un tag ou une branche au lieu d’un SHA de commit de 40 caractères, et chaque image d’étape docker:// référencée par tag plutôt que par digest ; un clic ouvre une pull request qui épingle les actions | Personnalisé (écrit par fremforge) | — |
| Miroir des actions | uses: actions/checkout@v4 se résout en frem.sh/actions/checkout — miroir pull natif de Forgejo de l’amont, synchronisé toutes les 8 heures. Aucune récupération sur github.com au moment du build sur le chemin critique du client. Les organisations mises en miroir incluent actions, docker, pnpm, aws-actions, azure, google-github-actions, peter-evans, softprops, sonarsource, step-security, dorny | Miroir pull natif de Forgejo (résolution des actions uniquement dans l’UE) | (Géré par l’opérateur ; transparent pour les clients) |
| Surface de compatibilité Marketplace | Les 20 actions GitHub Marketplace les plus utilisées, vérifiées pour fonctionner sans modification sur fremforge — GITHUB_TOKEN, GITHUB_SHA, GITHUB_REF, GITHUB_API_URL etc. tous renseignés à l’identique | Runtime Forgejo Actions | — |
| Mises à jour des dépendances | Mises à jour de versions par Renovate pour chaque organisation inscrite, chaque nuit, plus Exécuter maintenant. Identifie les dépendances obsolètes, les versions d’actions et les images de base de conteneurs. Les dépôts peuvent se désinscrire | Renovate + orchestration personnalisée | Désinscription par dépôt |
Isolation à l’exécution (runners CI hébergés)
| Contrôle | Ce qu’il fait | Outil | Configurable |
|---|---|---|---|
| Bac à sable des runners hébergés | Un commit = une VM dédiée = un noyau. La plateforme crée une nouvelle VM ECS éphémère par commit, enregistre forgejo-runner --ephemeral pour que chaque enregistrement soit consommé par une seule tâche, puis détruit la VM une fois les jobs de ce commit terminés. Jamais deux clients, ni deux commits, ne partagent un noyau — les jobs d’un même commit peuvent partager la VM, traitez donc un pipeline comme un seul domaine de confiance. Chaque VM dispose de sa propre ENI + de son propre Security Group (isolation réseau) et n’a aucune agence IAM attachée (aucun accès aux API de la plateforme depuis l’intérieur). Un nettoyeur hors bande, en filet de sécurité, supprime les VM orphelines dont le runner ne s’est jamais enregistré ou n’a jamais terminé. Même modèle que les runners hébergés par GitHub et par GitLab | T Cloud Public ECS + ENI par VM + forgejo-runner (act_runner) | Type de VM (plafond CPU/RAM), limite de simultanéité par tenant |
| Limite de simultanéité par tenant | 2 jobs simultanés garantis par utilisateur (au moins 10, au plus 60), et jusqu’à 60 lorsque de la capacité est inutilisée (hébergé par GitHub : Free 20, Pro 40, Team 60). Plus sur demande | Application au niveau de la plateforme | Dérogation par tenant |
| Réserve de minutes de runner | seat_cap × 1000 min/month. Les tenants en essai disposent d’une réserve fixe de 500 min — voir Facturation. Les tenants avec dépassement activé continuent de s’exécuter ; les autres voient leur dispatch refusé | Vérification avant dispatch par rapport à l’utilisation mesurée | Dérogation de plafond par tenant |
| Proxy de sortie | Les workflows clients atteignent l’internet public via le proxy de sortie des runners (refus SSRF uniquement, CGNAT autorisé — même comportement que les runners hébergés par GitHub) | Proxy personnalisé (écrit par fremforge, basé sur Hono) | — |
| Durée réelle d’un job | 60 min par job par défaut, plafond strict de 360 min. Un balayeur hors bande supprime les VM orphelines, avec une limite absolue de 6 h 10 min | Balayeur hors bande | timeout-minutes au niveau de l’étape |
Secrets + contrôle d’accès
| Contrôle | Ce qu’il fait | Outil | Configurable |
|---|---|---|---|
| Secrets de déploiement | Secrets chiffrés par environnement. AES-256-GCM au repos avec une MASTER_ENCRYPTION_KEY détenue dans DEW KMS. Déchiffrés uniquement dans la VM de runner qui en a besoin. La rotation des clés prend en charge une fenêtre à deux clés (actuelle + précédente) pour une rotation sur place | Personnalisé (crypto de Node) + portée par environnement + DEW KMS | Par environnement / par dépôt / par organisation |
| RBAC + portée par tenant | Le RBAC natif de Forgejo + la couche de cloisonnement par tenant de fremforge ; tous les endpoints de l’API de la plateforme imposent le tenant_id issu du JWT, sans fuite de données entre tenants. Administration de l’organisation → Membres | Forgejo + middleware de l’API fremforge | Granularité par équipe |
| Authentification unique OIDC | Chemin IdP privilégié. Connectez Okta, Entra, ADFS, Google Workspace, Authentik, Keycloak, Auth0 — tout fournisseur OpenID Connect — pour la fédération entrante. Vérification de domaine, provisionnement des utilisateurs à la volée, correspondance groupe → équipe. Se configure dans Administration de l’organisation → SSO → Sources d’authentification | Source d’authentification OIDC native de Forgejo | Configuration IdP par tenant |
| Authentification unique SAML 2.0 | Pas encore disponible. Connectez plutôt Entra ID ou ADFS via OIDC | — | — |
| Provisionnement des utilisateurs SCIM 2.0 | Poussez les utilisateurs de votre IdP vers votre organisation fremforge via SCIM 2.0. Authentification par jeton porteur par tenant, fenêtre de rotation à deux jetons, CRUD idempotent sur les utilisateurs Forgejo. Fonctionne avec tout IdP conforme à SCIM | Endpoints d’API personnalisés sous /<slug>/scim/v2/* | Jeton SCIM par tenant |
| CA SSH | L’accès SSH à git utilise un certificat signé par une CA, et non des empreintes de clés brutes. Certificat par utilisateur avec TTL ; révocable depuis l’interface d’administration de l’organisation | CA OpenSSH + émission de certificats gérée par fremforge | TTL + révocation par utilisateur |
| Politique d’authentification | Ensemble d’options d’application par organisation : clés matérielles (WebAuthn uniquement, pas de TOTP), durée de vie maximale des PAT (plafond sous la valeur par défaut de 90 jours de la plateforme), commits signés obligatoires (bloque les pushs non signés), SSH désactivé (HTTPS uniquement), 2FA obligatoire, connexion SSO uniquement (bloque le nom d’utilisateur/mot de passe Forgejo local). Reprend la surface de politiques d’entreprise de GHEC. Chaque option émet un événement d’audit lorsqu’elle change | Patchs maintenus sur Forgejo + hooks d’application de fremforge | Ensemble de politiques par tenant |
| Liste d’autorisation des domaines e-mail | Liste d’autorisation par organisation de motifs de noms d’hôte e-mail. Lorsqu’elle est activée, les membres ne peuvent ajouter que des adresses du type @acme.com correspondant aux motifs configurés. Ferme la porte au scénario « s’attribuer des commits en tant que attacker@arbitrary-domain.com » lors d’une analyse forensique. Les adresses existantes ne sont pas retirées automatiquement ; la connexion OIDC est exemptée (l’IdP atteste). Les motifs acceptent les formes exactes + *.subdomain | Règles personnalisées + interception à la périphérie Bunny sur /user/settings/account/email | Motifs par tenant + option d’application |
| Secrets de workflow | Secrets Actions au niveau de l’organisation + du dépôt, injectés dans chaque job CI comme variables d’environnement. Forgejo les stocke chiffrés au repos ; l’administration fremforge sert de proxy pour le CRUD avec des événements d’audit (la valeur n’est jamais conservée dans la base de données ni dans le journal d’audit de fremforge). Remplacer le secret via le même formulaire constitue le processus de rotation | Secrets natifs de Forgejo + proxy d’administration fremforge | Par organisation / par dépôt / par environnement |
| OIDC de workflow pour l’authentification cloud | Les VM de runner reçoivent un nouveau JWT OIDC avec aud=fremforge à chaque job. Les politiques de confiance cloud du client s’appuient dessus pour un échange d’identifiants de courte durée (pas de clés AWS de longue durée, de JSON de compte de service GCP ni de secrets client Azure dans les secrets de workflow) | Émetteur OIDC personnalisé signé par la clé runner-OIDC de fremforge (rotation tous les 180 j ; rotation manuelle, rotation automatique pas encore livrée) | — |
| Authentification native pour les agents | Trois modèles côté IdP pour les appelants non humains : (1) Jeton porteur JWT direct de l’IdP du client — présentez un JWT d’identité de charge de travail Entra / de compte de service Okta / de compte de service Google directement en Authorization: Bearer sur n’importe quel endpoint /api/v1/* ; (2) Échange de jetons RFC 8693 + OBO — POST /_app/api/v1/auth/token-exchange accepte un subject_token et un actor_token optionnel ; la personne est l’actor de l’audit et l’agent un détail de la ligne (fields.agent), sans identité d’agent propre ; (3) client_credentials RFC 6749 — POST /_app/api/v1/oauth/token pour les applications sans IdP. Liaison d’audience par tenant (https://frem.sh/<slug>), assertions de claims par source (tid/hd), contrainte UNIQUE au niveau de la base de données empêchant deux tenants de revendiquer le même émetteur pour le jeton porteur direct | Personnalisé (auth_sources + oauth_clients + pipeline d’échange de jetons utilisant jose) | Activation par source ; plafond de portée par client |
Observabilité DevOps
| Contrôle | Ce qu’il fait | Outil | Configurable |
|---|---|---|---|
| Tableau de bord DORA | Les quatre métriques DORA canoniques — fréquence de déploiement, délai de mise en production des changements, taux d’échec des changements, MTTR — calculées sur une fenêtre glissante de 30 jours à partir des événements de déploiement enregistrés pour votre tenant. Le chemin d’ingestion est le webhook Forgejo release, plus un POST /_app/api/v1/dora/deployments manuel pour les workflows qui ne taguent pas de releases. Visible dans Administration de l’organisation → DORA | Personnalisé (écrit par fremforge, sur la base de données du tenant) | Fenêtre glissante + ingestion manuelle |
| Vue d’ensemble de la sécurité | Sécurité › Vue d’ensemble : résultats ouverts par analyseur, avec des liens vers chaque onglet, et la liste de contrôle de mise en place | Agrégateur personnalisé | — |
| Panneau d’utilisation des runners | Nombre mensuel de minutes de runner + tableau des durées par job dans Administration de l’organisation → Build et déploiement → Utilisation de la CI. Alimente les lignes de facture via la table metering_events | Personnalisé (agrégation de runner_jobs) | — |
Posture IA
| Contrôle | Ce qu’il fait | Outil | Configurable |
|---|---|---|---|
| IA de votre choix — accès natif pour les agents | fremforge est agnostique en matière d’IA. Claude Code / Cursor / Windsurf / Codex CLI / Aider côté client opèrent sur la même surface Git + REST que les humains (spécification OpenAPI lisible par machine). Combinés à l’authentification native pour les agents (jeton porteur JWT direct de l’IdP, échange de jetons RFC 8693 + OBO, client_credentials RFC 6749), les agents s’authentifient comme des principaux à part entière — sans emprunter le PAT d’un humain. Pas de produit d’IA verrouillé sur la forge, pas de fonctionnalités agentiques exigeant un fournisseur particulier | Git + REST conformes aux standards | Contrôlé par le client |
| Intégrations IA (BYOK) | Administration de l’organisation → Intégrations IA : enregistrez votre propre clé de fournisseur d’IA (Anthropic, OpenAI, Mistral, autres). Active : la revue de PR par IA (rédige des commentaires de revue sur le diff), les explications IA de Renovate (résumés de changelog en langage clair sur les PR de mise à jour de dépendances), et la passerelle /_app/api/v1/orgs/<slug>/ai/complete pour les appels LLM depuis les workflows | Passerelle personnalisée (écrite par fremforge) | Fournisseur + clé par organisation |
Conformité + audit
| Contrôle | Ce qu’il fait | Outil | Configurable |
|---|---|---|---|
| Journal d’audit | Chaque opération modifiant un état (push, changement de rôle, création de secret, dérogation de runner, changement de facturation) est consignée avec l’acteur + l’horodatage + l’avant/après. Rétention à deux niveaux : niveau chaud interrogeable (90 / 180 / 365 / 730 jours, configurable par tenant) + archive à chaîne cryptographique de 3 ans dans T Cloud Public OBS WORM | Personnalisé en ajout seul (table audit_events) | Fenêtre de rétention par tenant |
| Chaîne d’audit | Journal d’audit chaîné par hachage + chaîne de hachage linéaire ancrée toutes les 2 min dans T Cloud Public OBS WORM. Une tâche cron de vérification contrôle l’intégrité de la chaîne toutes les heures + un balayage complet toutes les 30 min. Les clients peuvent vérifier qu’« aucun événement n’a été supprimé ni modifié après coup » | Personnalisé (écrit par fremforge, aligné sur BSI C5) | — |
| Diffusion SIEM | Flux en temps réel des événements d’audit vers un endpoint fourni par le client (Splunk HEC, Sentinel, ELK, OpenSearch, webhook HTTPS générique). Relais résidant dans l’UE, aucune donnée ne quitte la région eu-de. L’état de santé de l’endpoint par tenant est visible par l’opérateur + l’administrateur du tenant | Transmetteur personnalisé + table siem_endpoints | Configuration d’endpoint par client |
| Export des données (portabilité RGPD) | Export en libre-service des données du tenant : dépôts (sous forme de bundles git), tickets, pull requests et releases (NDJSON), inventaire des paquets, résultats d’analyse, état des politiques de paquets, attestations signées, SBOM des dépôts et des images de conteneurs, événements d’audit (NDJSON), avec un manifeste signé DSSE. Téléchargé depuis une URL OBS signée valable 7 jours. Requis pour la portabilité au titre de l’art. 20 du RGPD + la sortie de service | Exportateur personnalisé | Déclenchable à tout moment |
| Politiques de cycle de vie | Automatisation de la rétention + de la suppression par tenant : archivage des dépôts inactifs, comportement du plafond de minutes de runner, fenêtre de rétention du journal d’audit, délai de grâce de suspension du tenant, SLA d’effacement des données en fin de contrat | Personnalisé (table tenant_lifecycle) | Politique par tenant |
| Mise en miroir de dépôts (migrations entrantes) | Mettez en miroir pull les dépôts clients depuis GitHub, GitLab, Bitbucket ou tout autre hôte Git vers fremforge, avec authentification par identifiants + synchronisation périodique. Utilisé lors de migrations par phases ; le miroir peut être retiré une fois la bascule terminée | Miroir pull natif de Forgejo + proxy d’administration fremforge | Source + intervalle par dépôt |
| Préférences de notification | Routage des événements à l’échelle de l’organisation : quels événements d’audit émettent un e-mail/webhook/SIEM, quels rôles sont alertés sur les résultats critiques, contacts d’escalade pour les événements de facturation | Personnalisé (table notification_preferences) | Routage par tenant |
| Divulgation des vulnérabilités | security.txt publié, SLA d’accusé de réception de 24 h pour security@frem.sh, page publique de remerciements, politique d’absence de poursuites pour la recherche de bonne foi | — | — |
| Délai de correction (SLA) | Pastille de SLA par organisation à côté de chaque résultat ouvert. Échéances par défaut (critique 7 j / élevée 30 j / moyenne 90 j / faible aucune) — pouvant être resserrées par tenant. Ancré sur NIST SP 800-40r4 | Personnalisé (écrit par fremforge) | Resserrement par tenant |
Ce que nous ne faisons pas, explicitement
| Anti-fonctionnalité | Pourquoi |
|---|---|
| Aucune empreinte Microsoft (pas de GitHub, pas d’Azure AD, pas d’Office 365, pas de Defender, pas de GHAS CodeQL) | Souveraineté européenne + Schrems II — voir trust |
| Pas de Sigstore / Fulcio / Rekor hébergé aux États-Unis dans le chemin de vérification | Idem. fremforge exploite son propre Fulcio + sa propre TSA sur T Cloud Public eu-de, avec la CA racine dans DEW KMS (HSM FIPS 140-2 niveau 3, Allemagne). Pas de Sigstore public, pas de Rekor ni de journal de transparence — horodatage par TSA uniquement, par conception |
| Aucune dépendance à AWS, GCP ou à un cloud contrôlé par les États-Unis sur le chemin critique de la plateforme | Idem |
| Aucune police chargée depuis un CDN tiers (Google Fonts, etc.) | Auto-hébergées sur www.frem.sh/fonts/ via la périphérie européenne de Bunny |
| Aucun analyseur tiers propriétaire : chaque analyseur est open source ou propre à fremforge, et chaque jeu de règles, base d’avis et source de signatures de malware qui les alimente est nommé, avec sa licence, dans la nomenclature | La piste d’audit du client exige une transparence qui nomme les outils |
| Aucun identifiant de compte de service de longue durée dans les workflows clients | OIDC uniquement pour l’authentification cloud ; les clés de longue durée sont un chemin optionnel et déprécié |
Transparence des outils — nomenclature complète
Si vous en avez besoin pour un appel d’offres, un audit BSI C5 ou une revue de sécurité interne, la liste de référence — avec les versions, les sources de récupération et les composants de la plateforme — se trouve sur docs.frem.sh/security/bill-of-materials/. Le tableau ci-dessous en est un sous-ensemble de consultation rapide.
| Couche | Outil | Utilisation | Licence |
|---|---|---|---|
| Cœur de la gestion de sources | Forgejo v15 | Hébergement des dépôts, revue de code, protocole des runners Actions | GPLv3 |
| Binaire du runner CI | forgejo-runner (act_runner) v13.2.0 | VM ECS éphémère par job | MIT |
| Analyse des secrets | Gitleaks v8 | Hook pre-receive | MIT |
| SAST | OpenGrep v1.21 | Analyse au moment de la PR | LGPLv2.1 |
| Analyse CVE des conteneurs | Trivy | CI du client + intégré à l’image du runner | Apache 2.0 |
| Analyse des dépendances | osv-scanner | Analyse au moment de la PR | Apache 2.0 |
| Génération de SBOM | Syft | Workflow de tag de release | Apache 2.0 |
| Signature + vérification d’images | cosign | Vérification au tirage, et la vérification informative de pull request fremforge/cosign-verify | Apache 2.0 |
| Signature de code sans clé — CA | Fulcio v1.8.5 (chart Helm 2.9.0) | Auto-hébergé sur T Cloud Public eu-de à sign.frem.sh | Apache 2.0 |
| Signature de code sans clé — TSA | Sigstore TSA (autorité d’horodatage) | Auto-hébergée sur T Cloud Public eu-de à tsa.frem.sh | Apache 2.0 |
| gitsign côté client | gitsign | Client git du client ; signature de commits liée à OIDC | Apache 2.0 |
| Mise à jour des dépendances | Renovate | Bot hébergé, cron toutes les 15 min, désinscription par dépôt | AGPLv3 |
| Build d’images (rootless) | kaniko | Build de conteneurs dans les workflows clients | Apache 2.0 |
| Analyse antimalware | ClamAV | Analyse pre-receive + téléversement LFS | GPLv2 |
| Score de bonnes pratiques OpenSSF | scorecard | Hebdomadaire, par dépôt | Apache 2.0 |
| CDN + WAF de la plateforme | Bunny CDN | Périphérie résidant dans l’UE, pas de Cloudflare/Fastly | (Fournisseur — basé dans l’UE, pas de sous-traitant américain) |
| Plateforme cloud | T Cloud Public (Deutsche Telekom) | Calcul, stockage, réseau, base de données | (Fournisseur — exclusivement la région eu-de) |
| E-mail (transactionnel) | Lettermint (NL) | E-mails d’authentification, factures, alertes | (Fournisseur — UE) |
| Boîte aux lettres | mailbox.org | Boîte aux lettres opérationnelle | (Fournisseur — UE) |
| Paiements | Mollie (NL) | Facturation | (Fournisseur — UE) |
| Comptabilité | Dinero (DK) | Émission des factures | (Fournisseur — UE) |
Chaque fournisseur de cette liste est contractuellement résident dans l’UE, sans sous-traitant américain sur le chemin des données. Consultez la page trust pour l’ensemble du DPA et de la chaîne de sous-traitants.
Feuille de route (selon la demande)
| Fonctionnalité | Statut | Déclencheur |
|---|---|---|
KMS fourni par le client pour la MASTER_ENCRYPTION_KEY (CMK DEW fournie par le client dans son propre compte T Cloud Public) | Conçu | Engagement d’un premier client |
| Provenance de build SLSA (capture du digest de sortie au moment du build, afin que la déclaration signée se réfère à une exécution de build réelle — prérequis pour revendiquer un niveau SLSA ; les deux clauses de Build L3 sont déjà satisfaites) | Cadré | Demande des clients |
| Signature MCP + vérificateur pour la chaîne d’approvisionnement des agents IA | Conçu | Finalisation d’un standard du secteur |