Barthez Kenwou · DevSecOps

La chaîne jusqu’à la prod,
pas juste jusqu’au build vert.

Ce site est volontairement léger. Ce qu’il prouve ne l’est pas : une colonne vertébrale OCI reproductible — qualité, sécurité, image scannée et signée, déploiement par digest — la même discipline que j’applique en production sur zenora360.com.

/health · live Harbor · Cosign · Compose · NPM fail-closed

En une phrase

J’ai extrait la chaîne DevSecOps que je fais tourner pour livrer un conteneur en production, et je l’ai publiée comme kit : copie .github/ + deploy/, branche tes secrets, livre. L’app ici n’est qu’un nginx statique — le produit, c’est le chemin jusqu’à prod.

Ce que tu vois tourner derrière cette page

CI — Hadolint, Gitleaks, build image + probe /health, SonarQube si configuré
Security — Trivy fs/config, CodeQL (Actions), ZAP baseline (cron / manuel)
Release — build local → gate Trivy image → push Harbor → Cosign keyless → SBOM → provenance GitHub
Deploy — cosign verify avant SSH → image par digest (ou artifact si Harbor 412) → health + rollback → smoke réseau proxy

Preuve de vie

Live : supply-chain-demo.barthez-kenwou.dev · Repo : barthez-kenwou/supply-chain-pipeline · Même doctrine sur ZENORA · K&C Services. Pour brancher la chaîne sur ton projet → onglet .

Rien dans Harbor tant que Trivy image HIGH/CRITICAL n’est pas vert.

Pas de SSH tant que Cosign n’a pas vérifié le digest.

latest est refusé au deploy. Prod = @sha256.

La chaîne, étape par étape

Ci-dessous : ce qui part vraiment dans GitHub Actions — pas un schéma marketing. Chaque étape existe parce qu’elle ferme une classe de risque que j’ai déjà croisée.

CI · Quality

Qualité & hygiène du dépôt

Avant de parler « sécu image », je m’assure que le Dockerfile et les assets de démo sont sains. Sur ce kit static : Hadolint, présence de app/index.html / nginx.conf, build Docker local, probe HTTP /health. Sur une app Node (ZENORA) : lint, typecheck, tests, coverage, build.

hadolint
docker build
curl /health
SonarQube QG (optionnel, fail-closed si secrets présents)

Pourquoi : un Dockerfile pourri ou un healthcheck mort ne doit pas arriver jusqu’à la signature. Sonar Community sans sonar.branch.name — les flags PR/branch cassent l’édition gratuite.

CI · Secrets

Gitleaks — secrets dans le repo

Scan du tree avec Gitleaks en conteneur éphémère. Pas de token Harbor, pas de clé SSH qui se balade dans un commit « oublié ».

gitleaks/gitleaks

Pourquoi : la supply chain commence dans Git. Un secret commité reste un incident même si l’image est parfaite.

Security · SAST / SCA

Trivy filesystem + config, CodeQL

Trivy gate HIGH/CRITICAL sur le filesystem et la config IaC/Compose/Dockerfile (unfixed ignorés volontairement — je ne bloque pas sur ce que le vendor n’a pas encore patché). SARIF poussé vers l’onglet Security GitHub.

CodeQL security-extended : sur ce repo static il n’y a pas de JS applicatif — j’analyse le langage actions (workflows). Sur ZENORA : javascript-typescript.

aquasecurity/trivy
github/codeql-action

Pourquoi : SAST sur le code/workflows + SCA/config avant même de builder l’image runtime. CodeQL mal calibré (JS sur un repo sans JS) fait échouer le gate pour de mauvaises raisons — autant scanner ce qui existe.

Security · DAST

OWASP ZAP baseline

Baseline ZAP en cron hebdo + workflow_dispatch, mode -I (informational) pour ne pas casser le gate sur du bruit edge/Cloudflare. Rapport HTML/JSON en artifact.

zaproxy/zap-baseline
.github/zap-rules.tsv

Pourquoi : DAST sur une URL réelle complète la vue « code + image ». Je ne veux pas qu’un faux positif WAF fasse croire que la supply chain est rouge chaque lundi.

Release · Build

Build local, push : false

Buildx charge l’image en local (supply-chain-web:ci-candidate). Aucun push Harbor tant que le scan image n’est pas vert. C’est non négociable : le registry n’est pas une poubelle de candidats.

docker/build-push-action · load: true

Release · Image gate

Trivy image HIGH/CRITICAL

Scan vuln + secret + misconfig sur l’image candidate. Échec = pas de tag sha-* dans Harbor. SARIF image uploadé aussi.

trivy-action · scanners vuln,secret,misconfig

Pourquoi : scanner le Dockerfile ne suffit pas. La surface runtime (nginx alpine + packages) est ce que tu exposes vraiment.

Release · Registry

Push Harbor + digest immuable

Push sha-<7 chars> (+ latest sur main comme alias pratique, jamais utilisé pour le deploy). Digest résolu via RepoDigests locaux après push — pas de crane digest GET qui se fait jeter par une policy Cosign Harbor (HTTP 412).

Harbor OCI
docker push + retry

Release · Sign & SBOM

Cosign keyless, SBOM SPDX, provenance

Cosign keyless OIDC GitHub Actions (Fulcio / Rekor) — pas de clé privée à rotater dans les secrets pour la démo. Signatures sur REPO@DIGEST. SBOM SPDX via Anchore/Syft attaché à l’image. Provenance build : GitHub Attestations (push-to-registry: false — Harbor 412 sur upload OCI d’attestations).

sigstore/cosign keyless
anchore/sbom-action · SPDX
actions/attest-build-provenance

Pourquoi keyless : identité = workflow GitHub + OIDC. Auditable, pas de PEM Cosign qui fuit. Pourquoi SBOM : inventaire exploitable le jour du prochain CVE nginx/openssl.

Deploy

Verify → SSH mux → runtime → smoke

1) cosign verify sur le digest avant toute ouverture SSH.
2) Une session SSH ControlMaster (UFW limit + scp/ssh en rafale = timeouts — déjà vécu).
3) Image : pull @sha256, ou docker load de l’artifact release-image si Harbor Cosign policy bloque le pull (412).
4) Health /health, rollback avec preuve, smoke sur le réseau Docker du reverse proxy (pas seulement HTTPS public — Cloudflare peut 403).

Cosign verify
Docker Compose
Nginx Proxy Manager
known_hosts piné

Architectures

Trois vues du même système. Les animations suivent le flux réel des workflows — pas une illustration décorative.

1 · Carte des workflows

2 · Release → signature → runtime

1 Quality

2 Build local

3 Trivy image

4 Push Harbor

5 Cosign + SBOM

6 Verify + Deploy

7 Smoke proxy

Échec à l’étape 3 = aucun artefact registry. Échec verify = aucun SSH. Health KO = rollback avec log explicite rollback healthy|failed.

3 · Runtime VPS (derrière le proxy)

Edge Cloudflare (optionnel)

Nginx Proxy Manager :80 / :443 · réseau web-proxy

supply-chain-web :8080 · user 1001 · read-only rootfs

Harbor image@sha256 + signatures Cosign

Pas de bind hôte :80 sur l’app si NPM tient déjà 80/443. Upstream = nom DNS Docker du conteneur. Smoke critique = curl depuis le même réseau proxy — le HTTPS public peut 403 (Bot Fight).

Pourquoi j’ai choisi ça — et pas autre chose

Option B : site static nginx

Le portfolio doit montrer la chaîne, pas un second monolithe React à maintenir. Static HTML = surface d’attaque minimale, build trivial, même Dockerfile multi-stage discipline (user non-root, read-only, healthcheck). Tu swaps app/ pour ton vrai service ; tu gardes .github/ + deploy/.

Digest, jamais `latest` en prod

Un tag est mutable. Un digest est un pointeur de contenu. Deployer @sha256:…, c’est savoir exactement ce qui tourne — et pouvoir prouver que Cosign a signé ce bytes-là. sha-* reste un alias humain ; latest est refusé dans le workflow Deploy.

Cosign keyless (OIDC GitHub)

Pas de clé Cosign longue durée dans les secrets du repo démo. L’identité de signature = le workflow + le dépôt. Verify côté Deploy avec issuer token.actions.githubusercontent.com et regexp sur release.yml.

Trivy avant push, pas « on verra au runtime »

Si Harbor contient déjà l’image vulnérable, tu as perdu. Gate image HIGH/CRITICAL fail-closed sur le candidat local. SARIF pour la piste d’audit dans GitHub Security.

SSH ControlMaster + known_hosts piné

UFW en mode limit + une rafale scp/ssh = i/o timeout fantôme. Une session muxée. StrictHostKeyChecking=yes + secret DEPLOY_SSH_KNOWN_HOSTS obligatoire — pas de TOFU en CI.

Actions pinées SHA

Les actions critiques sont pinées sur un commit SHA, pas sur un tag flottant @v4. Supply chain du CI elle-même.

Slack : bruit maîtrisé

Échecs Release seulement. Deploy : succès et échec. Un Release vert ne spam pas le canal — le badge Actions suffit.

Ce que je n’ai pas mis (volontairement)

Kubernetes pour une image nginx — complexité ops sans gain ici.
Policy Harbor « Cosign » activée avec signatures keyless GitHub — casse les pulls (412). Enforcement = verify dans Actions.
Microservices, service mesh, « enterprise » cosmétiques.

Retours terrain — ce qui a cassé, ce que j’ai fait

Une supply chain « powerpoint » ne montre jamais les 412 et les timeouts. Voici ce que ce kit a absorbé en conditions réelles.

Harbor HTTP 412 — Cosign project policy

Symptôme : docker pull …@sha256:… → Precondition Failed / PROJECTPOLICYVIOLATION: not signed by cosign, même après un cosign sign keyless réussi.

Cause : le toggle Harbor « Deployment security → Cosign » ne traite pas correctement les signatures Sigstore keyless GitHub comme « signed » pour autoriser le pull.

Remède kit : artifact release-image (docker save) → Deploy fait docker load après verify. Remède ops : désactiver le toggle ; l’enforcement reste cosign verify avant SSH.

CodeQL « no JavaScript/TypeScript »

Repo static : pas de sources JS. CodeQL en javascript-typescript finalisait en erreur fatale. Fix : langage actions — on scanne ce qui existe vraiment (les workflows).

`crane digest` vs RepoDigests

Après push, un GET manifesto non signé se fait jeter (412). Digest pris depuis docker image inspect … RepoDigests en local, puis sign.

SSH timeouts sous UFW limit

Plusieurs connexions scp/ssh rapprochées → timeout. Une seule session ControlMaster pour copy + remote-deploy + smoke.

Dependabot npm sans `package.json`

Écosystème npm sur un repo static = job en erreur permanent. Dependabot limité à docker + github-actions.

Smoke HTTPS public 403

Cloudflare Bot Fight peut 403 le runner. Smoke qui compte = conteneur + réseau proxy. /health public = best-effort + exception edge recommandée.

Intégrer la supply chain dans ton projet

Tu ne réécris pas la chaîne. Tu greffes la colonne vertébrale sur ton app (Node, Go, static, peu importe) et tu adaptes les noms. Voici le mode d’emploi que je donnerais à un collègue qui démarre lundi.

Étape 01

Récupérer le squelette

Depuis supply-chain-pipeline, copie dans ton repo :

.github/workflows/ · .github/scripts/ · dependabot.yml · zap-rules.tsv
deploy/remote-deploy.sh · deploy/smoke-test.sh
docker-compose.yml (+ docker-compose.local.yml si tu veux le même modèle local)

Ce que tu ne copies pas forcément : mon app/ vitrine. Remplace-le par ton Dockerfile / ton service. Garde un endpoint /health (ou adapte les scripts).

Étape 02

Renommer pour ton produit

Cherche-remplace (grep) ces identifiants :

IMAGE_NAME → ex. mon-api
supply-chain-web → nom du conteneur Compose
sonar.projectKey
titres Slack / summaries
environment production (si tu en as plusieurs)

Si ton app est Node (comme ZENORA) : remplace reusable-quality.yml par la variante lint/test/build/coverage. Si static / binaire : garde le pattern Hadolint + build image + health.

CodeQL : aligne languages sur ton vrai code (javascript-typescript, go, actions…). Un mauvais langage = gate rouge pour rien.

Étape 03

Préparer Harbor

Projet Harbor créé (ex. acme).
Robot account avec push + pull.
Cosign deployment security = OFF si tu signes en keyless GitHub (sinon pulls 412). L’enforcement reste cosign verify dans Deploy.

Secrets repo GitHub :

HARBOR_REGISTRY
HARBOR_PROJECT
HARBOR_USERNAME
HARBOR_PASSWORD

HARBOR_REGISTRY = host only, lowercase, sans https:// (ex. harbor.example.com).

Étape 04

Préparer le VPS + reverse proxy

Docker + Compose installés ; user SSH dans le groupe docker.
Réseau partagé avec le proxy : docker network create web-proxy (ou le nom que tu choisis).
Nginx Proxy Manager / Traefik / Caddy : upstream TON_CONTENEUR:8080 (ou ton port interne) sur ce réseau — pas de bind hôte :80 sur l’app.
Répertoire app sur le serveur (ex. /opt/mon-projet) — le workflow y scp compose + scripts.

Smoke qui compte = curl depuis le réseau Docker du proxy. Le HTTPS public peut 403 (Cloudflare) : exception /health si tu veux le smoke edge.

Étape 05

Secrets & vars environment `production`

GitHub → Settings → Environments → production (branches : main only) :

DEPLOY_SSH_HOST
DEPLOY_SSH_USER
DEPLOY_SSH_PORT
DEPLOY_SSH_KEY
DEPLOY_APP_DIR
DEPLOY_SSH_KNOWN_HOSTS

ssh-keyscan -p "$PORT" "$HOST"
# coller la sortie complète dans DEPLOY_SSH_KNOWN_HOSTS

Variables d’environment :

PROXY_NETWORK (défaut web-proxy)
PUBLIC_BASE_HOST (hostname public)

Optionnel repo : SONAR_HOST_URL + SONAR_TOKEN, SLACK_WEBHOOK_URL.

Étape 06

Protéger `main` + premier vert

Branch protection : checks requis CI summary + Security summary.
Actions : permissions workflows en lecture/écriture (Release a besoin d’artifacts / attestations).
Push sur une branche feature → valider CI seul.
Merge main → Release (image + Cosign) → Deploy auto via workflow_run.

Premier Deploy : vérifie les logs SSH (mux), le health conteneur, puis le smoke réseau proxy. Si Harbor 412 au pull : le kit livre déjà l’artifact release-image (docker load) après verify.

Étape 07

Checklist « c’est en prod »

Image Harbor taguée sha-… + digest signé Cosign
Conteneur healthy sur le réseau proxy
/health répond OK en interne
Rollback testé au moins une fois (health KO volontaire)
Badges CI / Security / Release sur ton README
Personne ne deploy latest à la main

Stack typique

Briques de la stack et leur rôle
Brique	Rôle
GitHub Actions	orchestration fail-closed
Harbor	registry OCI + signatures
Cosign keyless	signature OIDC
Trivy	fs, config, image gates
CodeQL / ZAP	SAST / DAST
Syft (SBOM)	inventaire SPDX
Compose + NPM	runtime derrière proxy

Doc technique

Deep-dive .github/README.md — secrets, mermaid, séquences
Code source du kit
Preuve prod · zenora360.com

La chaîne jusqu’à la prod, pas juste jusqu’au build vert.