# CI/CD sécurisée — Gitea 1.22.6 La version du serveur `https://gitea.ops.xpeditis.com` a été vérifiée via `/api/v1/version` : **1.22.6**. Les pipelines ciblent Gitea Actions / act_runner, avec des jobs exécutés dans des conteneurs Linux AMD64 ou ARM64. ## Workflows et contrôles Les quatre workflows actifs se trouvent dans `.gitea/workflows/`. Les anciennes copies `.github/workflows/` sont déplacées pour éviter une double exécution. L'action composite `.gitea/actions/security` est appelée directement par chaque pipeline ; aucun workflow réutilisable GitHub ni client `gh` n'est nécessaire. | Pipeline | Déclenchement | Contrôles | | --- | --- | --- | | Dev CI | Push/PR vers `dev` | Lint, types, tests unitaires, sécurité | | PR Checks | PR vers `preprod` ou `main` | Idem + tests d'intégration PostgreSQL/Redis | | CD Preprod | Push vers `preprod` | Idem + build, scan AMD64/ARM64, déploiement, contrôles HTTP | | CD Production | Push vers `main` | Qualité/tests/sécurité, provenance préprod, build frontend, scan AMD64, déploiement SSH, tests de fumée | Le job **Security gate** exécute : - `npm audit --package-lock-only --audit-level=high` sur la racine, le backend, le frontend et le log-exporter, sans installer de dépendances ni exécuter leurs scripts. Les dépendances de développement sont incluses. - Trivy sur les fichiers suivis du commit : détection de secrets et de mauvaises configurations Docker/Kubernetes/Terraform, seuil HIGH/CRITICAL. - La validation statique des workflows et les tests des scripts de promotion/santé. Les images sont analysées par digest, avec HIGH/CRITICAL bloquants, y compris lorsqu'aucun correctif n'est disponible. Les erreurs de scanner ou de registre échouent aussi : aucune exclusion générale ni échec masqué n'est ajouté. Les installations applicatives utilisent `npm ci`, le runtime est Node 22 et les actions sont épinglées par SHA. Trivy, Actionlint et Hetzner CLI sont téléchargés avec détection native AMD64/ARM64 et vérification SHA256. Le lint backend ne réécrit plus les fichiers. Les rapports sont joints aux exécutions **Gitea Actions** avec `actions/upload-artifact` **v3**, compatible avec le protocole de cette version Gitea. `security-reports` est conservé 7 jours, `image-security-*` 14 jours selon la politique de rétention du serveur. Les valeurs et extraits de code des secrets sont retirés du rapport téléchargeable. Les URLs GitHub servent uniquement à récupérer les actions publiques épinglées, pas à exécuter les pipelines. Ces scans ne remplacent pas un audit du code métier ni un test d'intrusion ; la recherche de secrets porte sur le commit courant, pas tout l'historique. ## Promotion sans API GitHub Gitea 1.22.6 n'expose pas d'API de consultation des runs Actions dans son Swagger. La provenance utilise donc le registre Scaleway existant : après scans, webhooks et contrôles HTTP backend/frontend réussis, le job préprod publie des marqueurs `validated-preprod-` pour le backend et le log-exporter, à partir des digests construits et scannés. Le log-exporter est construit/scanné par cette chaîne ; son déploiement n'a pas de webhook ni de contrôle HTTP dédié existant. La production accepte seulement un commit de main ou un de ses parents dont l'arbre Git est identique, avec les deux marqueurs présents. Elle récupère leurs digests, les rescane et les promeut sans reconstruire le backend/log-exporter. Le frontend est reconstruit avec les URLs prod puis scanné par digest. Les tags `prod-SHA` et `latest` ne sont publiés que dans le job de déploiement, après scans. Utiliser un merge classique ou fast-forward de préprod vers main ; un squash ou rebase qui supprime cette provenance sera refusé. Il faut une première préprod réussie avec ces nouveaux workflows avant de promouvoir en production. La preuve repose sur les droits du registre : réserver l'écriture des marqueurs au compte CI et ne pas les créer manuellement. Ce n'est pas une attestation cryptographique. Les images candidates peuvent rester dans le registre après un échec de scan, sans être publiées sous les alias d'environnement par le pipeline. ## Configuration nécessaire sur ton instance Gitea 1.22 ignore notamment `concurrency`, `permissions`, `environment`, les délais YAML de jobs et `workflow_dispatch`. Ces paramètres ne sont donc pas présentés comme des protections effectives dans les workflows adaptés. 1. Activer Actions dans le dépôt et disposer d'un runner Docker Linux AMD64 ou ARM64 avec le label `ubuntu-latest`, Git, Bash, Python 3, curl, tar, timeout et les outils Docker. Les builds multiarchitecture ont besoin du support QEMU/binfmt. Les services d'intégration sont joints via `postgres` et `redis`, sans ports hôte fixes ; un runner en mode host n'est pas la cible de ces workflows. 2. Enregistrer **un seul runner** avec le label **`xpeditis-deploy`**, une capacité **1**, et une limite d'exécution adaptée (par exemple 1 h). Les deux jobs de déploiement utilisent ce label : publication des alias, déploiement, santé et fermeture du firewall restent dans le même job. Ne pas donner ce label à plusieurs runners. Le runner doit être isolé des jobs de PR et disposer de Docker, Git, curl, SSH et rsync. Sans ce runner, les déploiements restent en attente. 3. Protéger `dev`, `preprod`, `main` dans les réglages de branches Gitea : interdire les push directs/force-push et exiger **Security gate**, les deux contrôles qualité et les deux tests unitaires ; ajouter l'intégration pour preprod/main. Choisir les noms exacts proposés après la première exécution. Les approbations humaines doivent être imposées sur les PR, pas via `environment`. 4. Renseigner les secrets/variables dans **Settings → Actions** du dépôt Gitea : registre, webhooks Portainer, URLs préprod, URLs de build et identifiants SSH/Hetzner déjà référencés. Les secrets ne sont pas des secrets d'environnement GitHub. Les clés SSH temporaires sont écrites dans le répertoire du job. 5. Les fonctions manuelles `workflow_dispatch` ne sont pas disponibles sur 1.22. L'ancien workflow de rollback est conservé hors du dossier actif dans `.gitea/manual/rollback.reference.yml` comme référence, sans prétendre qu'il est exécutable sur cette version. Le rollback SSH automatique de production reste actif en cas d'échec du déploiement ou des tests de fumée. Pour une intervention manuelle, utiliser la procédure serveur existante ; ne pas ajouter un faux bouton de lancement Gitea. Ces réglages serveur/runners n'ont pas été modifiés depuis cette session. Aucun pipeline distant ni déploiement n'a été lancé. ## Mises à jour de dépendances Dependabot a été remplacé par `renovate.json`. La configuration propose des PR vers `dev` pour npm, Docker et les actions, sans fusion automatique. Elle n'installe ni ne démarre un bot. Un service Renovate doit être configuré séparément avec `RENOVATE_PLATFORM=gitea`, `RENOVATE_ENDPOINT=https://gitea.ops.xpeditis.com/api/v1`, un compte bot et son token, et le dépôt `David/xpeditis2.0`. Conserver le token hors du dépôt. Les hashes des outils téléchargés dans les scripts doivent être mis à jour en même temps que leurs versions. ## Alertes déjà constatées Audits npm des lockfiles au 22 septembre 2026 : | Projet | HIGH | CRITICAL | | --- | ---: | ---: | | Racine | 0 | 0 | | Backend | 50 | 0 | | Frontend | 13 | 1 | | Log-exporter | 0 | 0 | Ce sont des entrées de dépendances signalées, pas nécessairement autant de CVE distinctes. L'entrée critique frontend concerne `next` ; npm propose une migration majeure. Aucune mise à jour applicative forcée n'a été faite pour masquer ces résultats. Le scan local des configurations a relevé 11 alertes Kubernetes HIGH : systèmes de fichiers inscriptibles, droits de monitoring et accès hôte. Elles restent à examiner et bloquantes. Certains accès peuvent être nécessaires au monitoring. Les secrets Stripe en dur de la stack préprod ont été remplacés par les variables Portainer obligatoires `STRIPE_SECRET_KEY` et `STRIPE_WEBHOOK_SECRET`. Renseigner ces variables avant redéploiement. Si les anciennes valeurs sont actives, les révoquer/renouveler dans Stripe : elles restent dans l'historique Git. Le scan de ces configurations ne signale plus ce secret après modification. ## Validation Les 27 tests offline de promotion et santé passent : arbre différent, marqueurs manquants, panne du registre, digest invalide, mauvaise branche, saisie hostile et échec HTTP sont refusés. Les tests vérifient aussi que les échecs et délais des audits restent bloquants et que le rapport masque les valeurs de secrets. Actionlint valide la syntaxe après normalisation des URLs d'actions Gitea ; ce contrôle ne remplace pas une exécution avec act_runner. ```bash ACTIONLINT_BIN=/chemin/vers/actionlint bash scripts/ci/validate-workflows.sh ``` La correction du 23 septembre 2026 a aussi été exécutée dans un conteneur Linux ARM64 : Trivy 0.74.0, Actionlint 1.7.12 et Hetzner CLI 1.49.0 démarrent avec leurs archives officielles vérifiées. `activate-node.sh` place le Node 22 natif du cache en tête du PATH et vérifie son exécution ; un Node 18 préinstallé ne peut plus être sélectionné silencieusement. Node 22.23.2 a été vérifié dans l'étape suivante. Le téléchargement/affichage de version dans `setup-node` ne suffit pas à confirmer le runtime utilisé par les étapes shell ; la nouvelle étape affiche le chemin absolu et la version réellement activés. L'installateur commun est `scripts/ci/install-tool.sh`. Chaque architecture a sa propre archive et son empreinte. QEMU couvre AMD64 et ARM64 dans les builds préprod et frontend prod, dont la cible reste AMD64 même si le runner est ARM64. Les installations ont été vérifiées avec `npm ci --dry-run --offline --ignore-scripts --legacy-peer-deps`. Les builds Docker, les tests applicatifs sous Node 22, le transport réel des artefacts et les déploiements sont encore à valider sur les runners de l'instance. Références : [différences Gitea 1.22](https://docs.gitea.com/1.22/usage/actions/comparison/), [Renovate sur Gitea](https://docs.renovatebot.com/modules/platform/gitea/). ## Diagnostic du run Gitea 146 Le [journal complet du job sécurité](https://gitea.ops.xpeditis.com/David/xpeditis2.0/actions/runs/146/jobs/0/logs) confirme que Node 22 et Trivy démarrent, que les validations passent et que l'artefact `security-reports` est bien téléversé. L'affichage de l'action composite s'arrête pourtant visuellement au lancement de Trivy. Les quatre workflows exposent désormais installation, validation, audit, résumé et téléversement comme étapes distinctes. Le résumé s'exécute même si l'audit échoue, sans afficher de valeurs de secrets. Un rapport absent ou invalide est signalé comme indisponible. Ce run échoue réellement sur les audits : 50 vulnérabilités élevées backend, 13 élevées et une critique frontend, quatre détections de secrets et douze alertes d'infrastructure. Ces nombres décrivent ce run, pas un audit futur. Les seuils restent bloquants ; cette correction d'affichage ne corrige pas les vulnérabilités. Les douze erreurs Prettier du job backend ont été corrigées et le lint sans correction automatique passe localement.