Nomenclature des composants
fremforge est délibérément transparent sur l’outillage qui se trouve derrière chaque contrôle. Les clients soumis à une revue BSI C5, ISO 27001, BaFin ou réglementée par l’ENISA ont besoin d’une piste d’audit au niveau des outils, et nous préférons que vous puissiez faire un grep dans notre code source plutôt que de devoir rétro-ingénierer une boîte noire.
Cette page est l’inventaire de référence. Le tableau plus court de l’aperçu des fonctionnalités de sécurité en est un sous-ensemble à consulter rapidement ; celui-ci est le registre complet : versions, sources de récupération, emplacement d’exécution de chaque composant, attestation de chaîne d’approvisionnement qui l’accompagne et licence.
Intégrité de la chaîne d’approvisionnement
Chaque dépendance, image de conteneur et binaire de cet inventaire passe par la règle de contact amont de fremforge :
- Le code hébergé sur GitHub transite par le miroir natif de Forgejo (pull mirror) à
frem.sh/<canonical-org>/<repo>(synchronisation toutes les 8 heures). Les workflows clients qui résolventuses: actions/checkout@v4atteignentfrem.sh/actions/checkout: aucune récupération directe sur github.com dans le chemin critique du client. - Les images de conteneur (docker.io / ghcr.io / quay.io / public.ecr.aws) sont mises en cache via un miroir interne situé dans l’UE. Les manifestes de production ne référencent jamais directement un registre amont.
- Les binaires de release qui ne sont pas distribués en OCI (par exemple
opengrep,cosign) sont encapsulés dans de petites images de cache servies depuis ce même miroir interne dans l’UE. Renovate suit la version de la release GitHub amont et ouvre chaque semaine une pull request de mise à jour.
La CI vérifie les Dockerfile et les manifestes à la recherche de toute référence qui contournerait le miroir, de sorte que chaque dépendance amont est résolue via le cache hébergé dans l’UE plutôt que directement depuis un registre public.
CI et outillage de chaîne d’approvisionnement
| Outil | Version | Utilisation | Licence | Source de récupération |
|---|---|---|---|---|
| Forgejo | v15.x | Hébergement des dépôts, revue de code, protocole des runners Actions, sources d’authentification SSO | GPLv3 | Miroir interne UE (build fremforge) |
| forgejo-runner (act_runner) | v13.2.0 | Enregistrement d’un runner éphémère sur une VM ECS par commit | MIT | Miroir interne UE |
| Gitleaks | v8.x | Détection de secrets en pre-receive | MIT | Miroir interne UE |
| OpenGrep | v1.22 | SAST sur chaque PR (successeur libre de Semgrep, issu du changement de licence) | LGPLv2.1 | Miroir interne UE |
| Trivy | v0.74 | Analyse des images de la CI client + contrôle des CVE intégré à l’image des runners | Apache 2.0 | Miroir interne UE |
| osv-scanner | Dernière | Analyse des CVE/GHSA des dépendances au moment de la PR | Apache 2.0 | Miroir interne UE |
| Syft | Dernière | SBOM CycloneDX 1.6 + SPDX 2.3 à chaque analyse de PR (les deux sont acceptés à l’ingestion) | Apache 2.0 | Miroir interne UE |
| cosign | Dernière | Signature et vérification d’images (CI client via cosign-verify.yaml) | Apache 2.0 | Miroir interne UE |
| Fulcio | v1.8.5 (Helm 2.9.0) | Autorité de certification de signature de code auto-hébergée à sign.frem.sh. CA racine dans T Cloud Public DEW KMS (HSM FIPS 140-2 niveau 3). Ce n’est PAS le Fulcio public de Sigstore : fremforge exploite le sien | Apache 2.0 | Miroir interne UE |
| Sigstore TSA | Dernière | Autorité d’horodatage RFC 3161 à tsa.frem.sh. Clé dans DEW KMS. Ce n’est PAS la TSA publique de Sigstore | Apache 2.0 | Miroir interne UE |
| gitsign | Dernière | Client git côté client ; signature de commits liée à OIDC auprès du Fulcio local | Apache 2.0 | Installation côté client (brew install sigstore/tap/gitsign) |
| Renovate | Dernière | Bot hébergé de mise à jour des dépendances, cron toutes les 15 min, désactivable par dépôt | AGPLv3 | Miroir interne UE |
| kaniko | Dernière | Build de conteneurs sans root dans les workflows clients (alternative à BuildKit lorsque le client ne peut pas exécuter de conteneur privilégié) | Apache 2.0 | Miroir interne UE |
| ClamAV | Dernière | Analyse antimalware des téléversements (objets LFS, pièces jointes, téléversements de paquets) et analyse optionnelle du proxy de dépendances. Les sources de signatures sont listées sous Contenu de détection | GPLv2 | Miroir interne UE |
| scorecard | Dernière | Exécution hebdomadaire des bonnes pratiques OpenSSF par dépôt | Apache 2.0 | Miroir interne UE |
openssl + python3 (bibliothèque standard) | n/a | Vérification côté client des attestations de publication émises par fremforge : les enveloppes DSSE sont signées avec une simple clé Ed25519, la vérification se résume donc à une courte recette curl/jq/openssl/python3 (voir Provenance SLSA), et non au slsa-verifier amont | — | Outils fournis par défaut par la distribution |
Contenu de détection
Les règles, bases d’avis de sécurité et signatures de malwares auxquelles les scanners se comparent. Chacun est épinglé ou actualisé selon la fréquence indiquée, et aucun n’est récupéré par une analyse pendant son exécution.
| Contenu | Utilisé par | Licence | Source de récupération |
|---|---|---|---|
| GitLab sast-rules, uniquement les dossiers par langage (C#, Go, Java, JavaScript, Python, Scala) | SAST, et /opt/sast-rules dans l’image des runners hébergés | MIT ; les règles Go sous Apache-2.0 (dérivées de gosec). Le reste du dépôt amont, qui contient du contenu sous d’autres licences, est supprimé au moment du build, et le build échoue si un fichier conservé porte une licence autre que MIT, Apache-2.0 ou BSD | Miroir frem.sh, commit épinglé |
0xdea semgrep-rules, rules/c | SAST pour C et C++ | MIT | Miroir frem.sh, commit épinglé |
| Règles SAST de fremforge | SAST pour JavaScript et TypeScript, Python, Bash, PHP, Ruby, Rust, Kotlin et Swift | MIT | Code source de fremforge |
Bases de vulnérabilités Trivy (trivy-db, trivy-java-db) | Analyse des images de conteneur, trivy fs sur les pull requests | Apache-2.0 pour le build de la base ; chaque enregistrement conserve les conditions de sa source (GitHub Advisory Database, données de sécurité Red Hat et SUSE : CC-BY-4.0) | Miroir interne UE, actualisé quotidiennement |
| Base OSV, copie hors ligne | Analyse des dépendances, paquets malveillants, politiques de paquets, audits du proxy de dépendances | CC-BY-4.0 ; chaque enregistrement conserve les conditions de sa source | Miroir interne de l’export OSV, actualisé quotidiennement |
| Base de vulnérabilités Go | Atteignabilité Go (govulncheck) | CC-BY-4.0 | Export Go du miroir OSV, actualisé quotidiennement |
| GitHub Advisory Database | Via OSV et les bases Trivy | CC-BY-4.0 | Via les miroirs OSV et Trivy |
| Signatures SaneSecurity | Analyse antimalware ClamAV | Conditions de SaneSecurity : gratuites, financées par les dons | Un miroir public SaneSecurity, toutes les 4 heures |
| YARA-Forge Core | Analyse antimalware ClamAV | Detection Rule License 1.1 ; usage commercial autorisé avec attribution aux auteurs des règles | Toutes les 4 heures, releases amont hebdomadaires |
| Signatures Linux Malware Detect | Analyse antimalware ClamAV | GPLv2 | Toutes les 4 heures, amont quotidien |
| Signature de test EICAR | Test de fumée de l’analyse antimalware | Libre d’utilisation (EICAR) | Statique, livrée avec le scanner |
Fondation de la plateforme
| Couche | Outil / fournisseur | Utilisation | Licence / positionnement |
|---|---|---|---|
| Registre de conteneurs | T Cloud Public SWR | Toutes les images fremforge. Source unique pour les récupérations à l’exécution ; miroir de chaque registre amont | Fournisseur (Deutsche Telekom, eu-de) |
| Kubernetes | T Cloud Public CCE Turbo (Cloud Native Network 2.0) | Charges de travail de la plateforme (Forgejo, monolithe du plan de contrôle, jobs). ENI + groupe de sécurité par pod via le CNI Yangtse. Les runners CI ne s’exécutent pas ici : voir la ligne ECS ci-dessous | Fournisseur (Deutsche Telekom, eu-de) |
| Calcul des runners CI hébergés | T Cloud Public ECS (VM éphémère par commit) | Une VM ECS éphémère par commit/PR ; noyau dédié (isolé par hyperviseur), supprimée après le job ; groupe de sécurité VPC par VM (aucun trafic entrant, trafic VM à VM refusé, sortie via le proxy des runners protégé contre le SSRF) | Fournisseur (Deutsche Telekom, eu-de) |
| Stockage objet (opérateur) | T Cloud Public OBS | Ancre WORM de la chaîne d’audit, archive des SBOM, export de données, état OpenTofu | Fournisseur (Deutsche Telekom, eu-de) |
| Base de données relationnelle | T Cloud Public RDS (PostgreSQL 15) | État de l’API, tables des tenants et des résultats, chaîne d’audit | Fournisseur (Deutsche Telekom, eu-de) |
| Cache en mémoire | T Cloud Public DCS Redis | Compteurs de limitation de débit, IP déjà vues lors de l’échange de jetons, cache de session | Fournisseur (Deutsche Telekom, eu-de) |
| Gestion des clés | T Cloud Public DEW | MASTER_ENCRYPTION_KEY, CA racine Fulcio, clé de signature de la TSA | Fournisseur (HSM FIPS 140-2 niveau 3, Allemagne) |
| Function-as-a-service | T Cloud Public FunctionGraph | Tâches cron planifiées et tâches de nettoyage | Fournisseur (Deutsche Telekom, eu-de) |
| Journaux et métriques | T Cloud Public LTS + CES | Journaux applicatifs, alarmes par mot-clé, métriques de SLO | Fournisseur (Deutsche Telekom, eu-de) |
| Edge / CDN | Bunny CDN | Terminaison TLS, mise en cache en périphérie dans l’UE, règles edge, plancher de limitation de débit | Fournisseur (siège en Slovénie, hébergé dans l’UE, aucun sous-traitant américain) |
| E-mail transactionnel | Lettermint | E-mails d’authentification, avis de facturation, alertes | Fournisseur (Pays-Bas, conforme au RGPD) |
| Boîte aux lettres opérationnelle | mailbox.org | Courrier d’administration entrant *@frem.sh | Fournisseur (Allemagne) |
| Traitement des paiements | Mollie | Carte et prélèvement SEPA | Fournisseur (Pays-Bas, conforme au RGPD) |
| Comptabilité | Dinero | Émission des factures et comptabilité | Fournisseur (Danemark, conforme au RGPD) |
| Sonde de disponibilité externe | updown.io | Sondes de disponibilité hors réseau (API, Forgejo, Kuma, site marketing, Authentik) | Fournisseur (France) |
Chaque fournisseur de cette liste est contractuellement hébergé dans l’UE, sans sous-traitant américain dans le chemin des données. Le DPA complet et la chaîne de sous-traitants figurent sur la page de confiance.
Ce que nous n’utilisons délibérément pas
| Fournisseur / outil écarté | Pourquoi |
|---|---|
| github.com (en direct) | Souveraineté européenne + Schrems II + règle de contact amont. Uniquement via miroir. |
| GitHub Advanced Security (CodeQL, etc.) | Règles de détection propriétaires que vous ne pouvez pas auditer. Nous utilisons OpenGrep + Trivy + osv-scanner : tous open source, tous auditables. |
| Microsoft 365, Entra, Defender | Même raison. Le produit fremforge n’a aucune empreinte Microsoft. (L’informatique interne de fremverk relève d’un monde d’identité distinct.) |
| Fulcio/Rekor publics de Sigstore (sigstore.dev) | Hébergés aux États-Unis ; le chemin de vérification ferait un aller-retour hors de l’UE. Nous exploitons notre propre Fulcio + TSA dans eu-de, avec la CA racine dans DEW KMS. Pas de Rekor ni de journal de transparence, par conception : l’horodatage ancré par la TSA est la primitive d’intégrité. |
| AWS, GCP, Azure | Clouds sous contrôle américain. T Cloud Public est exploité par Deutsche Telekom sur une pile dérivée de Huawei ; le provider OpenTofu est le fork maintenu pour OTC (opentelekomcloud/opentelekomcloud, jamais huaweicloud/huaweicloud). |
| Cloudflare, Fastly, Akamai | Edge sous contrôle d’un cloud américain. Bunny CDN a son siège dans l’UE et est contractuellement hébergé dans l’UE. |
| Ressources chargées depuis les CDN Google Fonts, jsDelivr, unpkg | Un CDN tiers expose les schémas de trafic à des points de présence américains. Toutes les polices et tous les JS/CSS sont auto-hébergés à www.frem.sh/fonts/ via Bunny UE. |
| Identifiants de compte de service à longue durée de vie dans les workflows clients | La fédération de jetons OIDC (OIDC des workflows) et l’authentification native pour les agents les remplacent. Les clés à longue durée de vie sont une voie optionnelle et dépréciée, signalée par une bannière de dépréciation. |
Comment intégrer cette nomenclature à votre propre dossier d’audit
Pour une réponse à un appel d’offres ou un questionnaire fournisseur : liez directement cette page. L’URL est stable : https://docs.frem.sh/security/bill-of-materials/.
Pour des preuves BSI C5 ou ISO 27001 : demandez l’instantané PDF daté à security@frem.sh. Nous pouvons aussi produire sur demande un SBOM au format CycloneDX de la plateforme elle-même (et pas seulement par release), utile pour rapprocher les CVE transitives.
Pour une vérification continue : chaque release de chaque composant fremforge publie un SBOM CycloneDX généré par Syft, et la provenance SLSA-L2 côté client épingle le condensé de chaque artefact attesté. La provenance est une enveloppe DSSE / in-toto signée en Ed25519 (<asset>.intoto.jsonl) ; vérifiez-la par rapport à la racine de confiance publiée par fremforge avec la recette curl/jq/openssl/python3 de Provenance SLSA.
Dérive : cette nomenclature est aujourd’hui maintenue à la main. Écrivez à security@frem.sh si vous avez besoin d’un instantané à jour avant un audit.
Voir aussi
- Page de confiance : DPA, liste des sous-traitants, attestations de conformité.
- Mentions tierces de l’image des runners : mentions de licence, offre de code source d’opengrep et attribution des données d’avis de sécurité et des signatures de malwares.
- Fonctionnalités de sécurité en un coup d’œil : ce que fait réellement chaque outil, avec des liens directs.
- SBOM : comment les SBOM CycloneDX/SPDX côté client sont générés.
- Provenance SLSA : comment l’attestation de publication est signée côté serveur avec la clé Ed25519 de la plateforme, comment la vérifier, et pourquoi elle n’est délibérément pas présentée comme un niveau SLSA.
- Divulgation des vulnérabilités :
security@frem.sh, accusé de réception sous 24 h.