De l’intention à la prod,
avec des preuves à chaque étape.

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.

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.

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.

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.

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

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 vous exposez vraiment.

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

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.

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é

Depuis supply-chain-pipeline, copiez dans votre dépôt :

• .github/workflows/ · .github/scripts/ · dependabot.yml · zap-rules.tsv
• deploy/remote-deploy.sh · deploy/smoke-test.sh (si vous déployez par SSH)
• docker-compose.yml si le modèle Compose vous convient

Ce que vous ne copiez pas forcément : le dossier app/ vitrine. Remplacez-le par votre Dockerfile / service. Conservez un endpoint /health (ou adaptez les scripts).

Recherchez-remplacez ces identifiants :

• IMAGE_NAME → ex. mon-api
• supply-chain-web → nom du conteneur / service
• sonar.projectKey
• titres Slack / summaries
• environment production (si vous en avez plusieurs)

Application Node : remplacez reusable-quality.yml par lint / test / build / coverage. Static ou binaire : conservez Hadolint + build image + health.

Harbor (référence du kit) — secrets HARBOR_REGISTRY, HARBOR_PROJECT, HARBOR_USERNAME, HARBOR_PASSWORD. Host only, lowercase, sans https://. Cosign project policy OFF si vous signez en keyless GitHub (sinon pulls HTTP 412).

GHCR — authentifiez avec GITHUB_TOKEN / packages: write, poussez vers ghcr.io/<org>/<image>, signez le digest, vérifiez avant deploy. Adaptez les noms de secrets dans Release / Deploy.

ECR / autre cloud — login via OIDC ou clés IAM, même séquence : build → scan → push digest → Cosign → verify → rollout.

Le kit livre aussi un artifact release-image (docker save) pour les cas où le registry bloque le pull (ex. Harbor 412) : utile en VPS, souvent inutile sur un orchestrateur cloud qui tire directement le digest.

VPS + Compose (référence) — Docker, réseau partagé avec le reverse proxy (PROXY_NETWORK), upstream CONTENEUR:port, secrets SSH d’environment production.

Cloud managé — remplacez le job Deploy SSH par le rollout natif (ECS task definition, Cloud Run revision, Helm/Argo, etc.) en gardant cosign verify avant le basculement.

Kubernetes — image par digest dans le manifeste, admission éventuelle (Kyverno/Gatekeeper) + verify CI ; le smoke devient un probe cluster plutôt qu’un curl sur le réseau Docker d’un VPS.

Peu importe la cible : prod = digest, jamais latest ; verify avant exposition ; health / rollback avec preuve.

1. Environment GitHub production (branches main only) si vous déployez depuis Actions.
2. Branch protection : checks CI summary + Security summary.
3. Optionnel : Sonar (SONAR_*), Slack, ZAP schedule.
4. Feature branch → CI ; merge main → Release → Deploy.

# VPS / SSH — example
ssh-keyscan -p "$PORT" "$HOST"
# coller la sortie complète dans DEPLOY_SSH_KNOWN_HOSTS

• Image registry taguée + digest signé Cosign
• Runtime healthy (conteneur, tâche ou pods)
• /health (ou probe équivalent) OK en interne
• Rollback testé au moins une fois
• Badges CI / Security / Release sur votre README
• Personne ne déploie latest à la main