DevSecOps sur Scaleway : intégrer SAST et DAST dans une pipeline qui tient en production

Pourquoi le DevSecOps se pose différemment sur Scaleway

Les équipes qui choisissent Scaleway le font généralement pour deux raisons : la localisation européenne des données et un modèle tarifaire lisible. Elles découvrent ensuite que l'écosystème sécurité y est plus léger que chez les hyperscalers. Pas d'équivalent managé d'Amazon Inspector ou de Security Command Center qui scannerait vos images et vos workloads en tâche de fond. Scaleway fournit d'excellentes briques — IAM avec applications et policies, Secret Manager, Private Networks, Audit Trail, Cockpit pour l'observabilité, Kapsule pour Kubernetes managé — mais l'assemblage vous revient.

Ce n'est pas un défaut. Cela pousse les contrôles de sécurité là où ils devraient être : dans la chaîne de livraison, versionnés à côté du code. Cet article décrit une chaîne DevSecOps concrète articulée autour du SAST, du SCA, du scan IaC et du DAST sur Scaleway, avec les arbitrages qui comptent réellement quand il faut la faire vivre au quotidien.

Les quatre familles de scan, et ce que chacune détecte vraiment

Avant de brancher quoi que ce soit dans la CI, soyez honnête sur le périmètre de chaque outil. La plupart des déploiements DevSecOps qui échouent partent du principe que le SAST trouvera des failles de logique métier, ou que le DAST détectera une dépendance transitive vulnérable.

Regardez la dernière colonne. Une pipeline qui bloque sur tout dès le premier jour est contournée en quinze jours. Commencez par des gates durs sur les secrets et l'IaC — peu coûteux et quasiment sans faux positifs — puis durcissez progressivement le SAST et le SCA en mode différentiel : seules les découvertes introduites par la merge request font échouer le job.

Un SAST que les développeurs ne désactivent pas

Semgrep s'est imposé comme le choix pragmatique sur les bases de code polyglottes : règles lisibles en YAML, ruleset communautaire couvrant la plupart des langages, et semgrep ci effectue nativement un scan différentiel par rapport à la branche cible. SonarQube reste pertinent si vous l'exploitez déjà pour la qualité de code et souhaitez une quality gate unique, mais son instance nécessite une base de données et une Instance Scaleway ou un déploiement Kapsule pour l'héberger — un vrai coût d'exploitation. Sur des stacks plus étroites, les outils natifs au langage (gosec, Bandit, Brakeman) sont plus rapides et moins bruyants.

Deux règles rendent le SAST tenable dans la durée. D'abord, produire du SARIF et laisser la forge afficher les découvertes directement dans la merge request : un rapport de sécurité que personne n'ouvre ne sert à rien. Ensuite, garder les suppressions dans le code (// nosemgrep: rule-id — raison) plutôt que dans un fichier d'exclusion central, pour que le relecteur voie la justification à côté de la ligne qu'elle protège.

Dépendances, images et Container Registry Scaleway

Le SCA offre le meilleur rapport valeur/minute de CI. Trivy couvre à la fois le scan de système de fichiers (lockfiles, licences) et le scan d'images ; Grype est une alternative solide. Scannez l'image après le build mais avant le push, pour qu'un artefact vulnérable n'atteigne jamais votre namespace de registry sur rg.fr-par.scw.cloud.

Deux pratiques comptent plus que le choix du scanner. Épinglez les images de base par digest et non par tag, pour qu'un rebuild soit reproductible et qu'un résultat de scan reste signifiant. Et générez un SBOM au build, conservez-le en artefact, puis rescannez-le chaque nuit : un conteneur propre lundi ne l'est plus vendredi, et la publication des CVE n'attend pas votre prochaine release.

Terraform et scan IaC des ressources Scaleway

Checkov et le scanner de configuration de Trivy comprennent suffisamment bien le provider Terraform Scaleway pour attraper les erreurs classiques : un scaleway_instance_security_group ouvert en entrée sur 0.0.0.0/0 port 22, un bucket Object Storage laissé public, un pool Kapsule exposé sur un réseau public là où un Private Network suffirait. Complétez par une revue des policies IAM : le modèle Scaleway (applications, groupes, policies) rend le moindre privilège simple à appliquer, mais le réflexe d'attribuer ProjectManager à l'application CI reste tristement répandu. Donnez à l'application de pipeline uniquement ContainerRegistryFullAccess et KubernetesFullAccess sur le bon projet, et faites tourner sa clé API.

Le DAST exige un environnement réel — rendez-le éphémère

C'est là que la plupart des pipelines s'arrêtent, car le DAST suppose une application qui tourne. Sur Scaleway, deux options fonctionnent bien. Pour un service HTTP conteneurisé, les Serverless Containers déploient un environnement par merge request en quelques secondes et redescendent à zéro ensuite, ce qui rend le coût des environnements de revue négligeable. Pour tout ce qui a des dépendances avec état, déployez un namespace par MR sur Kapsule et détruisez-le à la fusion.

Lancez ensuite OWASP ZAP dessus. Le baseline scan est un parcours passif de quelques minutes, sans risque, exécutable sur chaque MR. Le scan actif complet est beaucoup plus long et doit tourner la nuit sur un environnement de staging dédié. Si votre service est une API, utilisez zap-api-scan.py avec votre spécification OpenAPI : vous fournissez à ZAP l'inventaire d'endpoints qu'il ne peut pas découvrir par crawl, ce qui améliore radicalement la couverture. Nuclei complète utilement le dispositif pour des vérifications templatisées sur l'infrastructure exposée : en-têtes mal configurés, panneaux d'administration par défaut, CVE connues en bordure.

La difficulté du DAST, c'est l'authentification. Prévoyez du temps : un fichier de contexte ZAP avec script de login et jeton de session, ou un JWT pré-émis injecté en en-tête. Sans cela, vous scannez votre page de connexion et rien d'autre.

Une pipeline directement réutilisable

stages: [secrets, sast, build, review, dast]

variables:
  REGISTRY: rg.fr-par.scw.cloud/mon-namespace
  IMAGE: $REGISTRY/api:$CI_COMMIT_SHORT_SHA

gitleaks:
  stage: secrets
  image: zricethezav/gitleaks:latest
  script: ["gitleaks detect --source . --redact --exit-code 1"]

semgrep:
  stage: sast
  image: semgrep/semgrep:latest
  script:
    - semgrep ci --sarif --output semgrep.sarif
  artifacts:
    reports: { sast: semgrep.sarif }

checkov:
  stage: sast
  image: bridgecrew/checkov:latest
  script:
    - checkov -d infra/ --framework terraform --compact --hard-fail-on HIGH

build-and-scan:
  stage: build
  image: quay.io/buildah/stable
  script:
    - buildah bud -t $IMAGE .
    - trivy image --severity HIGH,CRITICAL --ignore-unfixed --exit-code 1 $IMAGE
    - trivy image --format cyclonedx -o sbom.json $IMAGE
    - echo "$SCW_SECRET_KEY" | buildah login -u nologin --password-stdin rg.fr-par.scw.cloud
    - buildah push $IMAGE
    - cosign sign --key env://COSIGN_KEY $IMAGE
  artifacts:
    paths: [sbom.json]

deploy-review:
  stage: review
  script:
    - kubectl create ns review-$CI_MERGE_REQUEST_IID --dry-run=client -o yaml | kubectl apply -f -
    - helm upgrade --install api ./chart -n review-$CI_MERGE_REQUEST_IID --set image=$IMAGE
  environment:
    name: review/$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID.review.example.com
    on_stop: stop-review

zap-baseline:
  stage: dast
  image: ghcr.io/zaproxy/zaproxy:stable
  script:
    - zap-api-scan.py -t $CI_ENVIRONMENT_URL/openapi.json -f openapi -r zap.html -I
  artifacts:
    paths: [zap.html]
  allow_failure: true

Le flag -I et le allow_failure: true sur le job DAST sont volontaires : on observe avant de bloquer. Une fois la baseline stabilisée et les faux positifs filtrés dans un fichier de règles ZAP, basculez le job en bloquant.

Refermer la boucle au runtime

Le scan s'arrête au déploiement ; les attaques non. Sur Kapsule, trois contrôles offrent un rapport effort/valeur imbattable. Activez Pod Security Admission en mode restricted sur les namespaces applicatifs, ce qui interdit par défaut les conteneurs privilégiés et les montages hôte. Appliquez des NetworkPolicies en deny par défaut pour qu'un pod compromis ne puisse pas pivoter latéralement — le CNI de Kapsule les supporte nativement. Et faites remonter les logs d'audit et les événements Falco dans Cockpit, où Scaleway agrège déjà vos métriques et logs via des endpoints managés Grafana, Loki et Prometheus.

Complétez avec Secret Manager plutôt que des Secrets Kubernetes en clair dans etcd, Audit Trail pour la traçabilité au niveau API de qui a modifié quoi dans le projet, et des clés API à durée de vie courte pour les applications CI. Rien d'exotique : toute la difficulté est dans la constance.

Ce qui fait vraiment tenir le dispositif

L'assemblage technique ci-dessus se monte en quelques jours. Le faire survivre un an demande trois décisions d'organisation. Définissez un SLA explicite par sévérité — critique corrigé en jours, élevé en semaines — et suivez le backlog comme n'importe quelle dette technique. Donnez aux équipes un processus d'exception documenté avec date d'expiration, sinon elles en inventeront un non documenté. Et mesurez la pipeline elle-même : si les étapes de sécurité ajoutent plus de deux ou trois minutes à une merge request, les développeurs les contourneront, et aucune politique n'y changera quoi que ce soit.

Le DevSecOps sur Scaleway est moins clé en main que chez AWS ou GCP, mais le résultat est plus portable et plus facile à auditer : chaque contrôle vit dans vos dépôts, pas dans la console d'un fournisseur. Pour des équipes qui ont justement choisi Scaleway pour des raisons de souveraineté, c'est exactement le bon compromis.