Infrastructure/eqs-satellite-template
Template
4
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

CI branchée : le proxy de la variante une-adresse tourne en root (Trivy DS-0002) #44

New issue
Open
opened 2026-10-15 08:44:21 +00:00 by nicolas-fryder · 1 comment
nicolas-fryder commented 2026-10-15 08:44:21 +00:00
Owner
Copy link

Salut Marc,

Pour info, au cas où tu sois dessus : on vient de brancher le runner de CI de la forge (un runner d'instance, une file pour toute la forge — D-066 du socle). Le gabarit a eu ce matin sa toute première exécution de CI (run #1, sur #43). Jusqu'ici, Actions était désactivé sur le dépôt : rien n'avait jamais tourné.

check et secrets sont verts. vulns est rouge sur un seul point, dans la variante livrée par #42 (3b9ffb9) :

variantes/une-adresse/proxy/Dockerfile (dockerfile)
DS-0002 (HIGH): Specify at least 1 USER command in Dockerfile with non-root user as argument

Le proxy Caddy tourne en root. Ce n'est pas un faux positif : c'est un vrai service déployé. Je n'y ai pas touché, c'est ta variante. La correction a l'air de toucher un peu plus qu'une ligne :

  • Caddy écoute sur 80, port privilégié : en non-root, il faudrait passer sur un port ≥ 1024 (8080, par exemple), et donc suivre dans le compose de la variante et ses réglages Coolify ;
  • /data et /config doivent être inscriptibles pour l'utilisateur choisi.

S'il y a une raison de le garder en root, une dispense bornée au chemin est possible, sur le modèle d'eqs-demo (trivy.yaml qui désigne .trivyignore.yaml, avec la raison écrite) — mais pour un service qui sert du trafic, je pencherais pour la correction.

Les autres étages du gabarit (intégration, contrat, fuzzing, audit) sont encore dans la file : je complète ce ticket s'ils trouvent autre chose.

🤖 Generated with Claude Code

Salut Marc, Pour info, au cas où tu sois dessus : on vient de brancher le runner de CI de la forge (un runner d'instance, une file pour toute la forge — D-066 du socle). Le gabarit a eu ce matin sa **toute première exécution de CI** ([run #1](https://git.equilibre-structures.fr/Infrastructure/eqs-satellite-template/actions/runs/1), sur #43). Jusqu'ici, Actions était désactivé sur le dépôt : rien n'avait jamais tourné. `check` et `secrets` sont verts. `vulns` est rouge sur un seul point, dans la variante livrée par #42 (3b9ffb9) : ``` variantes/une-adresse/proxy/Dockerfile (dockerfile) DS-0002 (HIGH): Specify at least 1 USER command in Dockerfile with non-root user as argument ``` Le proxy Caddy tourne en root. Ce n'est pas un faux positif : c'est un vrai service déployé. Je n'y ai pas touché, c'est ta variante. La correction a l'air de toucher un peu plus qu'une ligne : - Caddy écoute sur 80, port privilégié : en non-root, il faudrait passer sur un port ≥ 1024 (8080, par exemple), et donc suivre dans le compose de la variante et ses réglages Coolify ; - `/data` et `/config` doivent être inscriptibles pour l'utilisateur choisi. S'il y a une raison de le garder en root, une dispense bornée au chemin est possible, sur le modèle d'eqs-demo (`trivy.yaml` qui désigne `.trivyignore.yaml`, avec la raison écrite) — mais pour un service qui sert du trafic, je pencherais pour la correction. Les autres étages du gabarit (intégration, contrat, fuzzing, audit) sont encore dans la file : je complète ce ticket s'ils trouvent autre chose. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
nicolas-fryder commented 2026-10-15 09:07:58 +00:00
Author
Owner
Copy link

Le run #1 est terminé. Bilan complet :

étage état
check, secrets, sast, workflows, contrat-a-jour, audit ✅
vulns ❌ le proxy en root (ci-dessus)
integration ❌ voir 1
fuzzing ❌ voir 2
mutation sauté (ne tourne que sur main)

Les deux autres rouges ne viennent pas de ta variante : ce sont des pièces que le gabarit n'avait jamais eu à fournir, faute de CI. eqs-demo a eu exactement les mêmes hier.

1. integration — Cannot find module apps/api/dist/main.js. La suite démarre le binaire construit, mais apps/api lance vitest run --config vitest.integration.mts sans construire d'abord. En local ça passait parce qu'un dist/ d'un build précédent traînait — c'est donc aussi un faux vert possible (chasse 5 du socle : lire un dist/ en supposant qu'il est à jour). eqs-demo fait "test:integration": "pnpm build && vitest run --config vitest.integration.mts". La base, elle, a marché : le mode serveur de withTestDatabase() (0.23) a trouvé le PostgreSQL du service.

2. fuzzing — Missing script start. Le workflow démarre pnpm run start à la racine et attend 127.0.0.1:3000/health, avec contracts/openapi.json ; le gabarit a deux applications et son contrat à la racine. Depuis eqs-workflows v1.1, le dépôt le dit dans son ci.yml :

  contract:
    needs: [check]
    uses: Infrastructure/eqs-workflows/.forgejo/workflows/contract.yml@v1
    with:
      contrat: openapi.json
      start: start:api            # à ajouter à la racine : "pnpm --filter api start"
      base-url: http://127.0.0.1:4100
      sante: /health

(exclure existe aussi, pour une route dont le métier est de rendre 500 — la démo en a deux.) Le workflow fournit SERVICE_NAME et un AUTH_SECRET jetable ; si l'API exige d'autres variables pour démarrer, le journal du job le dira — il affiche maintenant la fin du journal de l'application quand elle meurt.

Je n'ai rien poussé sur le gabarit pour ne pas te marcher dessus : dis-moi si tu préfères que je le fasse.

🤖 Generated with Claude Code

Le run #1 est terminé. Bilan complet : | étage | état | |---|---| | `check`, `secrets`, `sast`, `workflows`, `contrat-a-jour`, `audit` | ✅ | | `vulns` | ❌ le proxy en root (ci-dessus) | | `integration` | ❌ voir 1 | | `fuzzing` | ❌ voir 2 | | `mutation` | sauté (ne tourne que sur `main`) | Les deux autres rouges ne viennent pas de ta variante : ce sont des pièces que le gabarit n'avait jamais eu à fournir, faute de CI. eqs-demo a eu exactement les mêmes hier. **1. `integration` — `Cannot find module apps/api/dist/main.js`.** La suite démarre le binaire construit, mais `apps/api` lance `vitest run --config vitest.integration.mts` sans construire d'abord. En local ça passait parce qu'un `dist/` d'un build précédent traînait — c'est donc aussi un faux vert possible (chasse 5 du socle : lire un `dist/` en supposant qu'il est à jour). eqs-demo fait `"test:integration": "pnpm build && vitest run --config vitest.integration.mts"`. La base, elle, a marché : le mode serveur de `withTestDatabase()` (0.23) a trouvé le PostgreSQL du service. **2. `fuzzing` — `Missing script start`.** Le workflow démarre `pnpm run start` à la racine et attend `127.0.0.1:3000/health`, avec `contracts/openapi.json` ; le gabarit a deux applications et son contrat à la racine. Depuis eqs-workflows `v1.1`, le dépôt le dit dans son `ci.yml` : ```yaml contract: needs: [check] uses: Infrastructure/eqs-workflows/.forgejo/workflows/contract.yml@v1 with: contrat: openapi.json start: start:api # à ajouter à la racine : "pnpm --filter api start" base-url: http://127.0.0.1:4100 sante: /health ``` (`exclure` existe aussi, pour une route dont le métier est de rendre 500 — la démo en a deux.) Le workflow fournit `SERVICE_NAME` et un `AUTH_SECRET` jetable ; si l'API exige d'autres variables pour démarrer, le journal du job le dira — il affiche maintenant la fin du journal de l'application quand elle meurt. Je n'ai rien poussé sur le gabarit pour ne pas te marcher dessus : dis-moi si tu préfères que je le fasse. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
dev
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
marc-agbanavor
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Infrastructure/eqs-satellite-template#44
No description provided.