Analyses de sécurité dans GitLab CI : SAST, SCA, secrets et images Docker¶

Le DevOps est une culture qui a bouleversé pas mal de chose, notamment sur la sécurité, avec la notion de ShiftLeft.
On souhaite responsabiliser d'avantage le développeur sur cette problématique de produire du code le plus sûr possible. Je te montre ici quelques job qui pourrait t'aider pour améliorer tout cela. Pour aller plus loin, vois aussi Trivy pour l'Infra as Code et l'analyse dynamique avec ZAP en DAST.

Chaque outil couvre une famille d'analyse différente :

Tous ces jobs vivent dans le stage security. Seul le scan d'image attend le build (needs: sur le job qui pousse l'image) : les autres n'ont besoin que du code source et démarrent immédiatement avec needs: [].

Exemple avec NodeJS¶

Analyse du code source (SAST) - Semgrep¶

Semgrep analyse ton code source à la recherche de patterns dangereux : injection, XSS, eval() sur une donnée utilisateur, etc. C'est le seul outil de cette page qui fait du SAST au sens strict.

Exemple de code en CI/CD :

1
2
3
4
5
6

semgrep:
    stage: security
    needs: []
    image: semgrep/semgrep:1.183.0
    script:
        - semgrep scan --config p/javascript --error .

--config p/javascript charge les règles JavaScript du registry Semgrep, et --error fait échouer le job dès qu'une faille est trouvée. Sur un petit serveur Express qui passe req.query.expr à eval(), Semgrep remonte par exemple javascript.lang.security.audit.code-string-concat.code-string-concat (une donnée de requête Express qui atteint eval) et javascript.express.security.audit.xss.direct-response-write (une réponse écrite directement à partir d'une entrée utilisateur).

Audit des packages (SCA) - NPM¶

NodeJS te permet te faciliter ton développement avec des modules NPM. Ce package manager à des fonctions built-in pour te permetre d'analyser la présence d'eventuel CVE en comparant les dépendances de ton modules avec des bases de données autour de la sécurité.

Exemple de code en CI/CD :

1
2
3
4
5
6

audit: 
    stage: security
    needs: []
    image: node:24-alpine
    script:
        - npm audit

Analyse d'image Docker (container scanning) - Trivy¶

Aqua Security propose un super outil open source, Trivy, qui te permet en plus d'analyser tes modules, ton image Docker. Ainsi il va pouvoir analyser les CVE que peut potentiellement contenir ta base-image.

Exemple de code en CI/CD :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

trivy:
    stage: security
    needs:
        - kaniko # le job du stage build qui pousse l'image
    variables:
        TRIVY_USERNAME: $MOMO_REGISTRY_USERNAME
        TRIVY_PASSWORD: $MOMO_REGISTRY_TOKEN
    image: 
        name: aquasec/trivy:0.76.1
        entrypoint: [""]
    script:
        - trivy image momotoculteur/simple-test:${CI_COMMIT_SHA}

Exemple d'analyse effectuée par Trivy :

Tu n'as nullement besoin d'installer Docker pour pull l'image. Tu dois néanmoins setter les 2 variables d'environnements pour Trivy.

Trivy peut aussi analyser les leaks, secrets et autre credentials sensible que tu pourrais leaks, lorsqu'il analyse une image Dockerfile si celui-ci est présent dans ton code source:

Leaks & Secrets Detections¶

Repository analysis - GitLeaks¶

GitLeaks va te permettre de détecter si par mégarde tu as pu faire fuiter un secret, token, et autres credentials et données sensible dont tu ne devrais pas commiter sur le répo.

Tu peux l'utiliser pour scanner le repository Git dans tout ses commits via la commande gitleaks git, ou scanner ce que tu as indexé en local mais pas encore commité avec gitleaks git --pre-commit --staged. Les anciennes commandes detect et protect sont dépréciées depuis la v8.19.0.

Exemple de code en CI/CD :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

gitleaks:
    stage: security
    needs: []
    variables:
        GIT_DEPTH: "0" # Historique Git complet, pour scanner tous les commits
    image: 
        name: zricethezav/gitleaks:v8.30.1
        entrypoint: [""]
    script:
        - gitleaks git -v .

Exemple d'output lors de la détection d'un potentiel leak :

Helm Chart analysis (misconfiguration) - Trivy¶

Trivy peut aussi t'analyser un helm chart que cela soit pour de la misconfiguration et autres best-practices, ou encore du secrets leaks aussi.

Exemple de code en CI/CD :

1
2
3
4
5
6
7
8

trivy-helm:
    stage: security
    needs: []
    image: 
        name: aquasec/trivy:0.76.1
        entrypoint: [""]
    script:
        - trivy config --helm-values simple-project/values.yaml ./simple-project

Exemple de best-practices pour creer un Helm Chart évitant des problèmes de sécurité :

Dockerfile analysis (misconfiguration) - Trivy¶

Trivy peut aussi analyser un Dockerfile afin d'y detecter toute sorte de leaks, mais aussi te propose des best-practices !

Exemple de code en CI/CD :

1
2
3
4
5
6
7
8

trivy-docker:
    stage: security
    needs: []
    image: 
        name: aquasec/trivy:0.76.1
        entrypoint: [""]
    script:
        - trivy config ./Dockerfile

Exemple ici de sécurité sur un Dockerfile qui ne défini pas un USER spécifique et donc potentiellement être lancé avec un utilisteur root:

Mais Trivy peut aussi te donner des best-practices comme par exemple de définir un tag bien précis quand tu spécifies une base image. Tu pourrais potentiellement sur un futur build avoir une update d'image majeur et avoir des API non-compatibles qui te casse ton application

Pour aller plus loin¶

• Slides : DevSecOps et méthodologie Shift Left
• Slides : analyse de vulnérabilités des images Docker avec Trivy et son TP : analyse d'images et de projet avec Trivy
• TP : détection de secrets avec Gitleaks
• Builder des images dans Kubernetes : le job kaniko dont dépend le scan d'image