Trois familles d'analyse, trois angles morts

Jour 1 · SAST — lire le code sans l'exécuter · 25 min

Vous avez passé trois jours à fabriquer une chaîne de livraison qui refuse un secret en clair et une requête SQL concaténée. Deux outils, deux portes. La question de ce module est celle qui vient juste après, et c'est celle qu'on pose en entretien d'architecte sécurité : que reste-t-il que ces portes ne voient pas ?

La réponse tient en trois familles d'analyse. Elles ne se remplacent pas, elles ne se classent pas, et chacune est aveugle exactement là où les deux autres regardent.

Ce que chacune fait, en une phrase

Le mot qui change tout est preuve. Le SAST vous donne un emplacement — app.py, ligne 126 — et une suspicion. Le DAST vous donne une preuve — la charge envoyée, la réponse reçue — et aucun emplacement. Un rapport professionnel a besoin des deux : sans l'emplacement, le développeur ne sait pas quoi corriger ; sans la preuve, il n'est pas convaincu qu'il y a quelque chose à corriger.

La prédiction que vous allez vérifier

Voici les dix vulnérabilités de devsecops-lab, et ce que chaque famille devrait en dire. Ce tableau est une hypothèse, pas une vérité. Vous allez le confronter à la réalité pendant trois jours, et vous en corrigerez au moins une case.

Les deux mots qu'il faut employer correctement dès aujourd'hui

• Faux positif — l'outil signale, le problème n'existe pas. Coût : votre temps, et à la longue votre confiance. Un outil à 40 % de faux positifs finit désactivé, c'est empiriquement ce qui arrive.
• Faux négatif — l'outil se tait, le problème existe. Coût : un incident. C'est le plus grave et le moins visible : personne ne se plaint jamais d'un faux négatif.

Toute la configuration d'un outil d'analyse est un arbitrage entre les deux. Serrer les règles fait monter les faux positifs ; les desserrer fait monter les faux négatifs. Il n'existe pas de réglage qui annule les deux — et c'est pour cela qu'on cumule trois familles plutôt que d'en perfectionner une.

Ce qu'un moteur SAST voit — et ce qu'il ne verra jamais

Jour 1 · SAST — lire le code sans l'exécuter · 25 min

Un moteur SAST ne lit pas votre code comme vous. Il en fait un arbre syntaxique — la structure grammaticale du programme — puis il cherche des formes dans cet arbre. Il n'exécute rien, ne connaît aucune valeur, et ne sait pas ce que votre application fait.

Premier mécanisme : le motif à métavariables

Une règle Semgrep décrit un bout de code avec des trous. Les trous sont des métavariables, écrites $QUELQUECHOSE, qui capturent n'importe quel sous-arbre. L'ellipse ... capture n'importe quelle suite d'éléments.

Ce mécanisme est robuste à la mise en forme — retours à la ligne, espaces, ordre des arguments nommés — là où une expression régulière casse au premier saut de ligne. C'est précisément ce qui distingue un moteur SAST d'un grep bien écrit.

Mais il a une limite dure : il décrit un point du programme. La troisième ligne du tableau le montre — hashlib.md5 sur un mot de passe est une faille, hashlib.md5 sur le chemin d'un fichier de cache n'en est pas une, et le motif ne peut pas les distinguer. Vous rencontrerez ce cas exact ce matin.

Second mécanisme : le suivi de teinte

Pour distinguer les deux cas précédents, il faut suivre d'où vient la donnée. C'est le suivi de teinte : on déclare des sources (les entrées non fiables), des puits (les endroits dangereux) et des assainisseurs (ce qui rend la donnée sûre). Le moteur signale un chemin qui va d'une source à un puits sans passer par un assainisseur.

Sur VULN-03, cela donne exactement trois éléments :

• source — request.args.get("host", "127.0.0.1") : la valeur vient du client, elle est teintée ;
• puits — subprocess.check_output(..., shell=True) : le premier argument est interprété par un interpréteur de commandes ;
• assainisseur — shlex.quote(), ou une validation stricte du format, retirerait la teinte.

Une règle de teinte ne signale donc pas shell=True en soi. C'est ce qui la rend beaucoup plus précise qu'un motif — et beaucoup plus longue à écrire correctement.

Ce que le moteur ne verra jamais

Quiz — SAST : portée et limites

Jour 1 · SAST — lire le code sans l'exécuter · 10 min

TP 1 — Première passe Semgrep sur devsecops-lab

Jour 1 · SAST — lire le code sans l'exécuter · 1 h

Obtenir un inventaire SAST complet de votre application, au format lisible puis au format machine, et le confronter à la prédiction de la première leçon.

1. Placez-vous dans le dépôt, créez le dossier d'artefacts et assurez-vous qu'il n'est pas versionné. Les sorties d'outils ne se committent pas : elles se régénèrent, et elles vieillissent mal dans un historique Git.
   copier

   cd ~/devsecops-lab
   mkdir -p artefacts
   grep -q '^artefacts/' .gitignore || echo 'artefacts/' >> .gitignore
   
   docker run --rm -v "$(pwd)":/src -w /src semgrep/semgrep:1.85.0 \
     semgrep scan --metrics=off \
       --config p/python --config p/flask --config p/security-audit \
       .

2. Lisez la sortie du haut vers le bas, sans la trier. Chaque bloc donne le nom de la règle, le fichier, la ligne, un extrait de code et un message. Notez à la main, sur papier ou dans un fichier, le nombre total de résultats — vous en aurez besoin dans quinze minutes.
3. Relancez la même analyse en produisant du SARIF. C'est le format que vous exploiterez partout ensuite : dans le pipeline, dans l'onglet Security de GitHub, et dans vos rapports.
   copier

   docker run --rm -v "$(pwd)":/src -w /src semgrep/semgrep:1.85.0 \
     semgrep scan --metrics=off \
       --config p/python --config p/flask --config p/security-audit \
       --sarif --output artefacts/semgrep-2026-08-06.sarif .

4. Comptez par règle, avec un script — jamais à l'œil. Ce décompte est votre première mesure de bruit : beaucoup de résultats pour peu de règles distinctes signale une règle qui se déclenche en boucle, et non un code particulièrement mauvais.
   copier

   python3 - <<'PY'
   import collections
   import json
   
   d = json.load(open("artefacts/semgrep-2026-08-06.sarif"))
   run = d["runs"][0]
   niveau = {r["id"]: r.get("defaultConfiguration", {}).get("level", "?")
             for r in run["tool"]["driver"].get("rules", [])}
   c = collections.Counter(r["ruleId"] for r in run["results"])
   for regle, n in c.most_common():
       lieu = run["results"][0]["locations"][0]["physicalLocation"]["artifactLocation"]["uri"]
       print(f"{n:3}  {niveau.get(regle, '?'):8}  {regle}")
   print("---")
   print("total :", sum(c.values()), "resultats,", len(c), "regles distinctes")
   PY

5. Sortez maintenant la liste des emplacements, une ligne par résultat. C'est cette liste que vous allez trier au TP suivant.
   copier

   python3 - <<'PY'
   import json
   
   d = json.load(open("artefacts/semgrep-2026-08-06.sarif"))
   for r in d["runs"][0]["results"]:
       p = r["locations"][0]["physicalLocation"]
       print(f'{p["artifactLocation"]["uri"]}:{p["region"]["startLine"]:<4} '
             f'{r["ruleId"].split(".")[-1]}')
   PY

6. Ouvrez app.py à côté de cette liste et faites la confrontation, vulnérabilité par vulnérabilité. Pour chacune des dix VULN-NN, répondez par oui ou non : Semgrep l'a-t-il trouvée ? Écrivez la réponse, ne la gardez pas en tête.
7. Dernière étape, et c'est celle qui compte pour le pipeline : relancez en mode bloquant. --error fait sortir Semgrep en code 1 dès qu'une règle correspond, et --severity ERROR restreint aux règles de haute confiance. Comparez le nombre de résultats avec celui de l'étape 2.
   copier

   docker run --rm -v "$(pwd)":/src -w /src semgrep/semgrep:1.85.0 \
     semgrep scan --metrics=off --error --severity ERROR \
       --config p/python --config p/flask .
   echo "code de sortie : $?" 

8. Notez les deux chiffres côte à côte : tous jeux de règles, toutes gravités contre deux jeux de règles, gravité ERROR. L'écart entre les deux est exactement la marge de manœuvre dont vous disposez pour régler un seuil de blocage. Vous vous en servirez lundi.

TP 2 — Trier : vrai positif, faux positif, angle mort

Jour 1 · SAST — lire le code sans l'exécuter · 1 h

Rendre un verdict argumenté sur chaque résultat de la passe précédente, et produire la liste de ce que le SAST n'a pas vu.

1. Créez un faux positif authentique — pas une simulation. Ce petit module de cache est du code que vous pourriez écrire demain, et il emploie md5 pour une raison parfaitement légitime : nommer un fichier de manière déterministe.
   copier

   mkdir -p outils
   # Collez le contenu ci-dessous dans outils/cache.py
   

2. Voici le fichier. Recopiez-le tel quel dans outils/cache.py.
   copier

   #!/usr/bin/env python3
   """Petit cache disque pour les reponses de /fetch. Rien de cryptographique ici."""
   import hashlib
   import pathlib
   
   CACHE = pathlib.Path("/tmp/dso-cache")
   
   
   def clef(url: str) -> str:
       """Nom de fichier deterministe pour une URL. Le condense ne protege aucun secret."""
       return hashlib.md5(url.encode()).hexdigest()
   
   
   def lire(url: str):
       f = CACHE / clef(url)
       return f.read_text() if f.exists() else None
   
   
   def ecrire(url: str, contenu: str) -> None:
       CACHE.mkdir(parents=True, exist_ok=True)
       (CACHE / clef(url)).write_text(contenu)

3. Analysez ce seul fichier. Semgrep signale l'usage de md5, exactement comme il le signale sur /hash dans app.py.
   copier

   docker run --rm -v "$(pwd)":/src -w /src semgrep/semgrep:1.85.0 \
     semgrep scan --metrics=off --config p/python outils/cache.py

4. Arrêtez-vous une minute sur ce résultat. La même règle, deux verdicts opposés : sur app.py c'est VULN-06, un mot de passe haché avec un algorithme cassé ; sur outils/cache.py c'est un index de cache, où md5 est adapté et rapide. Aucun réglage de l'outil ne fera cette distinction à votre place — parce qu'elle dépend de ce que la valeur protège.
5. Corrigez le faux positif de la bonne manière : en rendant l'intention explicite dans le code. usedforsecurity=False existe depuis Python 3.9 ; Semgrep et Bandit le respectent tous les deux, parce que le code dit désormais la vérité.
   copier

   def clef(url: str) -> str:
       """Nom de fichier deterministe pour une URL.
   
       usedforsecurity=False declare l'intention au lecteur ET a l'outil : ce condense
       sert d'index de cache, il ne protege aucun secret. Sans ce drapeau, la meme
       ligne est indiscernable de VULN-06, qui hache un mot de passe.
       """
       return hashlib.md5(url.encode(), usedforsecurity=False).hexdigest()

6. Relancez l'analyse du fichier : l'alerte a disparu, et vous n'avez rien désactivé.
   copier

   docker run --rm -v "$(pwd)":/src -w /src semgrep/semgrep:1.85.0 \
     semgrep scan --metrics=off --config p/python outils/cache.py

7. Posez maintenant le .semgrepignore du dépôt. Attention au sens de ce fichier : il retire des chemins de l'analyse, il ne fait pas taire des règles. Les fixtures que vous écrirez cet après-midi doivent en faire partie — elles contiennent du code volontairement vulnérable.
   copier

   # .semgrepignore — ce que l'analyse ne doit pas parcourir.
   # Attention : ce fichier retire des FICHIERS de l'analyse, pas des regles.
   # On n'y met jamais du code applicatif pour faire taire une alerte.
   
   .git/
   artefacts/
   rapports/
   __pycache__/
   *.pyc
   venv/
   .venv/
   
   # Les fixtures de test des regles maison contiennent du code volontairement
   # vulnerable : elles doivent etre analysees par --test, jamais par le scan normal.
   .semgrep/tests/

8. Reprenez maintenant la liste complète du TP 1 et rendez un verdict pour chaque ligne. Écrivez-la dans rapports/sast-devsecops-lab.md sous forme de tableau à quatre colonnes : règle · emplacement · verdict · justification. Trois verdicts possibles, et trois seulement : vrai positif, faux positif, à discuter. Pas de quatrième catégorie, pas de ligne sautée.
9. Écrivez ensuite la section qui compte le plus, et qu'aucun outil ne produira jamais pour vous : « Ce que le SAST n'a pas vu ». Pour chaque vulnérabilité absente de la sortie, donnez la cause — logique métier, dépendance, configuration d'exécution — et le moyen par lequel vous comptez la trouver. Vous vérifierez cette prévision demain et lundi.
10. Committez le tout sur une branche dédiée, avec un message qui dit ce qui a été fait.
    copier

    git switch -c feat/triage-sast
    git add outils/cache.py .semgrepignore rapports/sast-devsecops-lab.md
    git commit -m "docs(sast): triage de la premiere passe semgrep et faux positif md5"

Anatomie d'une règle Semgrep

Jour 1 · SAST — lire le code sans l'exécuter · 25 min

Une règle Semgrep est un document YAML. Elle se lit, elle se relit en revue de code, elle se teste, elle se versionne. C'est la différence entre configurer un outil et écrire de la sécurité.

La structure minimale

rules:
  - id: exemple-minimal
    languages: [python]
    severity: WARNING
    message: >-
      Message affiche au developpeur. Il doit dire QUOI faire, pas seulement
      ce qui ne va pas.
    metadata:
      cwe: "CWE-000: exemple"
      owasp: "A00:2021 - exemple"
      confidence: HIGH
    patterns:
      - pattern: dangereux($ARG, ...)
      - pattern-not: dangereux("...", ...)
    fix: sur($ARG)

Le mode teinte

Quand la règle doit suivre un chemin plutôt que reconnaître un point, on passe en mode: taint. Trois clés remplacent alors patterns :

• pattern-sources — d'où vient la donnée non fiable ;
• pattern-sanitizers — ce qui la rend sûre (facultatif, mais c'est lui qui supprime les faux positifs) ;
• pattern-sinks — où elle ne doit pas arriver.

focus-metavariable: $CMD, dans un puits, restreint la teinte à un argument précis : sans lui, une valeur teintée passée en troisième argument déclencherait la règle alors que seul le premier est interprété par l'interpréteur de commandes.

Le test de la règle : la partie qu'on saute et qu'il ne faut pas sauter

Semgrep sait tester ses propres règles. Vous écrivez un fichier de fixture contenant du code annoté, et semgrep --test vérifie que la règle remonte exactement ce qu'elle doit remonter :

• # ruleid: mon-id avant une ligne — la règle doit la signaler ;
• # ok: mon-id avant une ligne — la règle ne doit pas la signaler.

L'appariement entre la règle et sa fixture se fait par nom de fichier : .semgrep/flask-regles.yml se teste avec .semgrep/tests/flask-regles.py. Un nom qui ne correspond pas, et le test passe en ne testant rien.

Où les ranger

Dans .semgrep/, à la racine du dépôt, versionné. Trois conséquences immédiates : les règles fonctionnent hors ligne, elles passent en revue de code comme le reste, et une règle cassée se reverte comme un commit.

TP 3 — Écrire .semgrep/flask-regles.yml

Jour 1 · SAST — lire le code sans l'exécuter · 1 h 15

Produire trois règles maison — un motif, une règle de teinte, une règle avec correction suggérée — les tester, puis les brancher au pipeline.

1. Créez l'arborescence des règles et de leurs tests.
   copier

   mkdir -p .semgrep/tests

2. Écrivez la fixture avant les règles, dans .semgrep/tests/flask-regles.py. Elle décrit ce que vous attendez : quatre cas à signaler, cinq à ne pas signaler.
   copier

   # .semgrep/tests/flask-regles.py
   # Fixture des regles maison. Chaque annotation est une assertion :
   #   ruleid: <id>   la regle DOIT remonter la ligne qui suit
   #   ok: <id>       la regle NE DOIT PAS remonter la ligne qui suit
   # Ce fichier n'est jamais importe : il est lu par « semgrep --test ».
   import ipaddress
   import shlex
   import subprocess
   
   import yaml
   from flask import render_template_string, request
   
   
   def gabarit_ko():
       terme = request.args.get("q", "")
       # ruleid: caplogy-flask-gabarit-dynamique
       return render_template_string("<h1>Resultats pour " + terme + "</h1>")
   
   
   def gabarit_ok():
       # ok: caplogy-flask-gabarit-dynamique
       return render_template_string("<h1>Resultats pour {{ terme }}</h1>",
                                     terme=request.args.get("q", ""))
   
   
   def shell_ko():
       hote = request.args.get("host", "127.0.0.1")
       # ruleid: caplogy-entree-http-vers-shell
       return subprocess.check_output("ping -c1 " + hote, shell=True)
   
   
   def shell_assaini():
       hote = shlex.quote(request.args.get("host", "127.0.0.1"))
       # ok: caplogy-entree-http-vers-shell
       return subprocess.check_output("ping -c1 " + hote, shell=True)
   
   
   def shell_constant():
       # ok: caplogy-entree-http-vers-shell
       return subprocess.check_output("uptime", shell=True)
   
   
   def shell_liste():
       hote = str(ipaddress.ip_address(request.args.get("host", "127.0.0.1")))
       # ok: caplogy-entree-http-vers-shell
       return subprocess.check_output(["ping", "-c1", hote])
   
   
   def yaml_ko(donnee):
       # ruleid: caplogy-yaml-load-non-sur
       return yaml.load(donnee, Loader=yaml.Loader)
   
   
   def yaml_ok(donnee):
       # ok: caplogy-yaml-load-non-sur
       return yaml.safe_load(donnee)

3. Écrivez maintenant les trois règles dans .semgrep/flask-regles.yml. Remarquez la progression : la première est un motif avec exclusion, la deuxième une règle de teinte complète, la troisième un motif assorti d'une correction suggérée.
   copier

   # .semgrep/flask-regles.yml
   # Regles maison de devsecops-lab. Elles vivent dans le depot : elles fonctionnent
   # hors ligne, elles se relisent en revue, et elles evoluent avec le code.
   rules:
   
     # ------------------------------------------------------------------ VULN-02
     # severity WARNING, PAS ERROR, et c'est un choix : le motif a de vrais faux
     # positifs (un gabarit constant defini plus haut declenche la regle). On ne
     # bloque donc pas le pipeline dessus. C'est le DAST du jour 3 qui fera autorite
     # sur le XSS : lui apporte la PREUVE que ce motif ne peut pas donner.
     - id: caplogy-flask-gabarit-dynamique
       languages: [python]
       severity: WARNING
       message: >-
         render_template_string() recoit un gabarit construit dynamiquement. Toute
         entree utilisateur qui y arrive est interpretee par Jinja2 : XSS reflechi
         au minimum, execution de gabarit (SSTI) au pire. Passer un gabarit fixe et
         transmettre la valeur en variable : render_template_string("{{ x }}", x=v).
       metadata:
         cwe: "CWE-79: Improper Neutralization of Input During Web Page Generation"
         owasp: "A03:2021 - Injection"
         vuln: VULN-02
         confidence: MEDIUM
       patterns:
         - pattern-either:
             - pattern: render_template_string($GABARIT, ...)
             - pattern: flask.render_template_string($GABARIT, ...)
         - pattern-not: render_template_string("...", ...)
         - pattern-not: flask.render_template_string("...", ...)
   
     # ------------------------------------------------------------------ VULN-03
     - id: caplogy-entree-http-vers-shell
       languages: [python]
       severity: ERROR
       mode: taint
       message: >-
         Une valeur issue de la requete HTTP atteint un interpreteur de commandes.
         Passer une liste d'arguments sans shell=True, ou valider strictement la
         valeur avant de la concatener.
       metadata:
         cwe: "CWE-78: Improper Neutralization of Special Elements used in an OS Command"
         owasp: "A03:2021 - Injection"
         vuln: VULN-03
         confidence: HIGH
       pattern-sources:
         - pattern-either:
             - pattern: request.args.get(...)
             - pattern: request.form.get(...)
             - pattern: request.args[...]
             - pattern: request.form[...]
             - pattern: flask.request.args.get(...)
       pattern-sanitizers:
         - pattern: shlex.quote(...)
         - pattern: ipaddress.ip_address(...)
       pattern-sinks:
         - patterns:
             - pattern-either:
                 - pattern: subprocess.check_output($CMD, ..., shell=True, ...)
                 - pattern: subprocess.run($CMD, ..., shell=True, ...)
                 - pattern: subprocess.Popen($CMD, ..., shell=True, ...)
                 - pattern: os.system($CMD)
             - focus-metavariable: $CMD
   
     # ------------------------------------------------------------------ VULN-07
     - id: caplogy-yaml-load-non-sur
       languages: [python]
       severity: ERROR
       message: >-
         yaml.load() avec un Loader complet construit des objets Python arbitraires
         (tag !!python/object/apply) : c'est une execution de code a distance des
         que la donnee vient du reseau. Utiliser yaml.safe_load().
       metadata:
         cwe: "CWE-502: Deserialization of Untrusted Data"
         owasp: "A08:2021 - Software and Data Integrity Failures"
         vuln: VULN-07
         confidence: HIGH
       patterns:
         - pattern-either:
             - pattern: yaml.load($D)
             - pattern: yaml.load($D, Loader=yaml.Loader)
             - pattern: yaml.load($D, Loader=yaml.UnsafeLoader)
             - pattern: yaml.load($D, Loader=yaml.FullLoader)
       fix: yaml.safe_load($D)

4. Lancez le test. La sortie doit annoncer un nombre de cas exécuté et aucun échec. Si elle annonce zéro test trouvé, arrêtez-vous : le nom de base de la fixture ne correspond pas à celui du fichier de règles.
   copier

   docker run --rm -v "$(pwd)":/src -w /src semgrep/semgrep:1.85.0 \
     semgrep --test --config .semgrep/ .semgrep/tests/

5. Cassez volontairement une règle et relancez le test. Retirez par exemple la ligne - pattern-not: render_template_string("...", ...) : le cas gabarit_ok doit maintenant échouer. C'est la preuve que votre test teste quelque chose. Remettez la ligne, relancez, revérifiez le vert.
6. Appliquez enfin les règles au code réel. Vous devez voir remonter VULN-02, VULN-03 et VULN-07, et rien d'autre — trois résultats pour trois règles. Notez les gravités : VULN-03 et VULN-07 sortent en ERROR, VULN-02 en WARNING. Ce n'est pas un oubli, c'est une décision — voir l'encadré ci-dessous.
   copier

   docker run --rm -v "$(pwd)":/src -w /src semgrep/semgrep:1.85.0 \
     semgrep scan --metrics=off --config .semgrep/ --error app.py
   echo "code de sortie : $?" 

7. Regardez ce que propose le champ fix:, sans l'appliquer. --dryrun affiche le correctif que --autofix écrirait. Vous corrigerez VULN-07 demain, à la main et sur une branche dédiée.
   copier

   docker run --rm -v "$(pwd)":/src -w /src semgrep/semgrep:1.85.0 \
     semgrep scan --metrics=off --config .semgrep/ --autofix --dryrun app.py

8. Branchez les règles maison au pipeline. Remplacez le job sast de .github/workflows/ci.yml par celui-ci : il ajoute --config /src/.semgrep, restreint le blocage à la gravité ERROR, et publie le SARIF dans l'onglet Security de GitHub.
   copier

     sast:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v4
         - name: semgrep
           run: |
             docker run --rm -v "$PWD:/src" -w /src semgrep/semgrep:1.85.0 \
               semgrep scan --metrics=off --error --severity ERROR \
                 --config p/python --config p/flask --config /src/.semgrep \
                 --sarif --output /src/semgrep.sarif /src
         - name: publier le sarif
           if: always()
           uses: github/codeql-action/upload-sarif@v3
           with:
             sarif_file: semgrep.sarif

9. Notez le changement de doctrine dans ce job : on charge p/python et p/flask, mais plus p/security-audit. Vous avez mesuré son bruit ce matin ; il reste excellent pour un audit lancé à la main, il n'a pas sa place dans une porte bloquante. Écrivez cette phrase dans votre rapport : c'est votre première décision de seuil, et elle sera défendue lundi.
10. Committez, poussez, et vérifiez que le pipeline devient rouge — c'est attendu : VULN-03 et VULN-07 sont toujours dans app.py et vos règles viennent de les déclarer ERROR, donc bloquantes. VULN-02, elle, n'apparaît qu'en avertissement dans l'onglet Security : vous la traiterez lundi, avec le DAST, qui en apportera la preuve.
    copier

    git add .semgrep .github/workflows/ci.yml
    git commit -m "feat(sast): trois regles maison semgrep et leur fixture de test"
    git push -u origin feat/triage-sast

11. Regardez au passage ce que vos annotations du 5 août n'ont pas fait. Les lignes /ping et /config portent encore un # nosemgrep: <règle> posé au module 1, avec échéance au 10 août. Il n'a rien suspendu ici : il nommait une règle de p/security-audit, et vos règles s'appellent caplogy-*. C'est la démonstration exacte de ce qui a été exigé de vous : une exception nommée ne couvre que la règle qu'elle nomme, et elle ne devient jamais un blanc-seing sur la ligne. Un nosemgrep nu, lui, aurait avalé silencieusement vos trois règles neuves. Laissez les annotations en place jusqu'à lundi : vous les lèverez avec les corrections, pas avant.
12. Rangez ce constat dans votre journal — il fait partie de ce que vous défendrez lundi.
    copier

    # ajoutez une ligne a journal-incidents.md :
    # | 2026-08-06 | nosemgrep du 5 aout inoperant sur les regles maison | exception nommee, pas nue | comportement attendu, aucune action | 0 |

TP 4 — SonarQube CE : une découverte, puis on éteint

Jour 1 · SAST — lire le code sans l'exécuter · 45 min

Voir de ses yeux ce qu'apporte une plateforme SAST à serveur — quality gate, security hotspots, dette technique — et savoir dire pourquoi elle n'entre pas dans ce pipeline.

1. Lancez le serveur sur le réseau du parcours. Suivez les journaux et attendez la ligne SonarQube is operational — deux à trois minutes.
   copier

   docker run -d --name sonarqube --network dso-net \
     -p 9000:9000 sonarqube:10.6-community
   
   # Le demarrage prend deux a trois minutes : SonarQube leve un Elasticsearch interne.
   # Attendez la ligne « SonarQube is operational » avant d'ouvrir le navigateur.
   docker logs -f sonarqube

2. Ouvrez http://localhost:9000. Identifiants initiaux admin / admin ; SonarQube impose immédiatement un changement de mot de passe. Créez ensuite un projet local nommé devsecops-lab, puis générez un jeton d'analyse dans My Account → Security. Le jeton n'est affiché qu'une fois.
3. Lancez le scanner. Notez le sonar.host.url : il désigne le conteneur par son nom sur dso-net, pas localhost — depuis l'intérieur d'un conteneur, localhost c'est lui-même.
   copier

   docker run --rm --network dso-net \
     -v "$(pwd)":/usr/src \
     sonarsource/sonar-scanner-cli:11.0 \
     -Dsonar.projectKey=devsecops-lab \
     -Dsonar.sources=. \
     -Dsonar.exclusions=artefacts/**,rapports/**,.semgrep/tests/** \
     -Dsonar.host.url=http://sonarqube:9000 \
     -Dsonar.token=COLLEZ_ICI_VOTRE_JETON

4. Retournez sur l'interface. Trois choses à regarder, et rien d'autre : le Quality Gate (passé ou échoué, et sur quelle condition exactement), l'onglet Security Hotspots, et l'onglet Issues filtré sur Vulnerability.
5. Arrêtez-vous sur la notion de security hotspot : c'est un point du code à faire relire par un humain, pas une vulnérabilité affirmée. SonarQube assume ainsi son incertitude au lieu de la masquer derrière une gravité — c'est une réponse honnête au problème du faux positif, et une idée que vous pouvez reprendre dans votre propre triage. Choisissez-en un, tranchez-le (Safe ou To review) et écrivez le motif.
6. Ouvrez maintenant votre rapport et écrivez la section « SonarQube CE : ce qu'il apporte, ce qu'il coûte ». Trois différences concrètes avec Semgrep, chiffrées quand c'est possible : quelque chose que Sonar a trouvé et pas Semgrep, quelque chose que Semgrep a trouvé et pas Sonar, et le coût d'exploitation du serveur. Interdiction d'écrire « c'est plus visuel ».
7. Éteignez et supprimez. Vérifiez l'espace récupéré : c'est un chiffre que vous défendrez au point de contrôle.
   copier

   docker rm -f sonarqube
   docker image rm sonarqube:10.6-community sonarsource/sonar-scanner-cli:11.0
   docker system df   # verifiez l'espace recupere : environ 2 Go

8. Dernier réflexe, celui qui distingue une découverte d'une accumulation : docker ps -a ne doit plus montrer aucune trace de SonarQube. Un service qu'on essaie et qu'on n'éteint pas devient une dépendance que personne n'a décidée.

TP 5 — Consigner la passe SAST

Jour 1 · SAST — lire le code sans l'exécuter · 45 min

Fermer la journée par un document qu'un tiers peut relire sans vous, et le faire entrer dans le dépôt par une demande de fusion.

1. Relisez rapports/sast-devsecops-lab.md et complétez les sections 1 et 2. La section 1 porte les versions exactes : semgrep/semgrep:1.85.0, les jeux de règles employés, la date. Un rapport sans versions n'est pas rejouable, et un résultat non rejouable n'est pas un résultat.
2. Complétez la section 2 avec les chiffres réels : nombre de résultats tous jeux confondus, nombre de règles distinctes, nombre de résultats en gravité ERROR sur p/python et p/flask seuls. Ces trois nombres sont l'argumentaire de votre futur seuil de blocage.
3. Vérifiez que la section 3 ne laisse aucune ligne sans verdict et sans justification, et que la section 4 liste les angles morts avec la manière de les couvrir. Deux d'entre eux seront traités dès demain.
4. Committez et poussez.
   copier

   git add rapports/sast-devsecops-lab.md
   git commit -m "docs(sast): rapport de la passe statique du 6 aout"
   git push

5. Ouvrez la demande de fusion vers main. Dans la description, écrivez ce qu'un relecteur doit vérifier et ce qui reste ouvert.
   copier

   gh pr create --base main --head feat/triage-sast \
     --title "SAST : regles maison, triage et rapport du 6 aout" \
     --body "Trois regles maison + fixture testee. Rapport de triage complet.
   Le pipeline est ROUGE volontairement : VULN-02, VULN-03 et VULN-07 sont
   detectees par les nouvelles regles et seront corrigees au J2.
   A verifier en relecture : les cas 'ok:' de la fixture, et la decision
   de retirer p/security-audit de la porte bloquante."

6. Ne fusionnez pas. Cette PR reste ouverte jusqu'à demain, pipeline rouge : c'est l'état normal d'une branche qui a découvert des failles mais ne les a pas encore corrigées. Une équipe qui fusionne quand même est une équipe qui a désactivé sa porte sans le dire.

M2 · J1 — Règle Semgrep maison : VULN-02 détectée, faux positif justifié

Jour 1 · SAST — lire le code sans l'exécuter · 30 min

Votre code n'est qu'une fraction de ce que vous livrez

Jour 2 · SCA — la surface qu'on hérite · 25 min

Votre app.py fait cent trente lignes. L'image Docker que vous avez construite lundi pèse près d'un gigaoctet. Entre les deux, il y a tout ce que vous n'avez pas écrit et que vous livrez pourtant : c'est le domaine de la SCA.

Direct et transitif

Votre requirements.txt déclare six paquets. pip install en installe une bonne quinzaine : Flask tire Werkzeug, Jinja2, itsdangerous, click, blinker et MarkupSafe ; requests tire urllib3, certifi, idna et charset-normalizer.

• Les dépendances directes, vous les avez choisies. Vous pouvez en changer.
• Les dépendances transitives, personne ne les a choisies. Elles s'exécutent dans le même processus, avec les mêmes droits, avec le même accès à vos secrets et à votre base.

Historiquement, la grande majorité des vulnérabilités qu'une application subit — par opposition à celles qu'elle contient — viennent de cette troisième ligne. C'est aussi la raison pour laquelle la SCA est le seul domaine où l'outil est réellement plus fort que l'humain : nul ne suit à la main les advisories de quinze paquets.

Le vocabulaire, correctement employé

Le SBOM, et pourquoi ce n'est pas de la paperasse

Un SBOM (Software Bill of Materials) est la nomenclature de votre logiciel : chaque composant, sa version, son PURL, sa licence, et le lien vers son parent. Deux formats dominent — CycloneDX (OWASP, orienté sécurité) et SPDX (Linux Foundation, orienté licences). Vous produirez du CycloneDX.

La chaîne d'approvisionnement, deux menaces à connaître

• Le typosquatting — un paquet malveillant publié sous un nom voisin d'un paquet populaire (reqeusts, python-dateutil contre dateutil). Il s'installe par une faute de frappe et s'exécute à l'installation.
• La confusion de dépendances — un paquet interne, non publié, dont le nom est enregistré sur le dépôt public par un tiers. Le gestionnaire, mal configuré, préfère la version publique, plus récente.

Aucune des deux ne se détecte par un scanner de CVE : ce ne sont pas des failles, ce sont des paquets hostiles. Elles se traitent par un miroir interne et un index verrouillé — hors périmètre de ce parcours, mais à savoir nommer.

Lire une CVE : le score, le vecteur, et la question qui décide

Jour 2 · SCA — la surface qu'on hérite · 25 min

Trivy va vous rendre une liste. Longue. Chaque ligne portera un identifiant, une gravité et un score. La tentation est de trier par score décroissant et de commencer par le haut : c'est la mauvaise méthode, et c'est celle que tout le monde applique.

Le score n'est que le résumé du vecteur

Un score CVSS v3.1 se calcule à partir de huit métriques de base. Le vecteur les donne toutes ; le nombre n'en est que la moyenne pondérée. Lisez le vecteur.

Ainsi CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H se lit en une phrase : depuis le réseau, sans condition particulière, sans compte, sans qu'aucune victime n'ait à cliquer, l'attaquant obtient tout. C'est 9.8, et c'est le pire cas courant.

Les bandes de sévérité — celles du parcours

Ce tableau vaut pour tous vos rapports jusqu'à la soutenance. Le M4 y ajoutera DREAD comme grille de priorisation métier, en complément et jamais en remplacement.

Les deux chiffres que le CVSS ne donne pas

• EPSS — la probabilité, estimée statistiquement, qu'une CVE soit exploitée dans les trente prochains jours. Une CVE à 9.8 avec un EPSS de 0,2 % et une CVE à 7.5 avec un EPSS de 35 % ne se traitent pas dans le même ordre.
• CISA KEV — le catalogue des vulnérabilités effectivement exploitées et observées dans la nature. Y figurer déplace immédiatement une CVE en tête de file, quel que soit son score.

Et la question qui décide vraiment

Les trois décisions possibles, et seulement trois

1. Corriger — monter de version. C'est le cas par défaut, et pour une dépendance c'est souvent gratuit. Quand c'est gratuit, on ne discute pas : on corrige, même si la faille n'est pas atteignable.
2. Compenser — la correction casse quelque chose, ou n'existe pas encore (unfixed). On réduit alors l'exposition autrement : filtrage en amont, désactivation de la fonction, isolation réseau. La CVE reste, le risque baisse.
3. Accepter — le risque est jugé négligeable pour ce déploiement. Cette décision est légitime, à trois conditions : elle est écrite, elle est datée d'une échéance de réexamen, et elle est prise par quelqu'un qui a l'autorité pour la prendre.

Quiz — CVE, CVSS et SBOM

Jour 2 · SCA — la surface qu'on hérite · 10 min

TP 6 — Trivy fs : l'inventaire des CVE de votre application

Jour 2 · SCA — la surface qu'on hérite · 1 h

Obtenir la liste complète des vulnérabilités connues de vos dépendances, comprendre l'arbre qui les porte, et mesurer l'effet de chaque filtre sur le décompte.

1. Créez le volume de cache — une fois pour tout le parcours — puis lancez le premier scan en sortie lisible.
   copier

   cd ~/devsecops-lab
   docker volume create trivy-cache 2>/dev/null
   
   docker run --rm \
     -v "$(pwd)":/src -w /src \
     -v trivy-cache:/root/.cache/trivy \
     aquasec/trivy:0.53.0 \
     fs --scanners vuln --format table .

2. Lisez le tableau colonne par colonne : Library, Vulnerability, Severity, Installed Version, Fixed Version, Title. La colonne qui commande vos actions n'est ni la gravité ni le titre : c'est Fixed Version. Vide, il n'existe pas de correctif et vous devrez compenser.
3. Affichez maintenant l'arbre des dépendances, restreint aux gravités hautes. C'est là que le transitif devient visible : vous verrez apparaître des paquets que vous n'avez jamais déclarés.
   copier

   docker run --rm \
     -v "$(pwd)":/src -w /src \
     -v trivy-cache:/root/.cache/trivy \
     aquasec/trivy:0.53.0 \
     fs --scanners vuln --dependency-tree --severity HIGH,CRITICAL .

4. Relevez deux paquets remontés qui ne figurent pas dans votre requirements.txt. Écrivez-les. Ce sont vos dépendances transitives : personne ne les a choisies, elles tournent avec vos droits.
5. Produisez la version machine, celle qui servira au rapport et au pipeline.
   copier

   docker run --rm \
     -v "$(pwd)":/src -w /src \
     -v trivy-cache:/root/.cache/trivy \
     aquasec/trivy:0.53.0 \
     fs --scanners vuln --format json \
        --output artefacts/trivy-fs-2026-08-07.json .

6. Comptez et triez par script. Notez le premier des quatre nombres de la journée : le décompte brut, toutes gravités confondues.
   copier

   python3 - <<'PY'
   import collections
   import json
   
   d = json.load(open("artefacts/trivy-fs-2026-08-07.json"))
   par_gravite = collections.Counter()
   lignes = []
   for res in d.get("Results", []):
       for v in res.get("Vulnerabilities", []) or []:
           par_gravite[v["Severity"]] += 1
           lignes.append((v["Severity"], v["PkgName"], v["InstalledVersion"],
                          v.get("FixedVersion", "-"), v["VulnerabilityID"],
                          (v.get("CVSS", {}).get("nvd", {}) or {}).get("V3Score", "-")))
   
   ordre = ["CRITICAL", "HIGH", "MEDIUM", "LOW", "UNKNOWN"]
   lignes.sort(key=lambda l: (ordre.index(l[0]) if l[0] in ordre else 9, l[1]))
   for g, paquet, installee, corrigee, cve, score in lignes:
       print(f"{g:9} {paquet:12} {installee:9} -> {corrigee:9} {cve:18} {score}")
   print("---")
   for g in ordre:
       if par_gravite[g]:
           print(f"{g:9} {par_gravite[g]}")
   PY

7. Choisissez maintenant trois CVE dans la liste, de gravités différentes, et allez lire leur advisory : le lien figure dans la sortie JSON, champ PrimaryURL. Pour chacune, recopiez le vecteur CVSS complet dans votre rapport et traduisez-le en une phrase française. Ces trois-là seront le matériau du TP suivant.
8. Appliquez enfin les filtres du futur seuil de blocage, et regardez le code de sortie. --severity HIGH,CRITICAL restreint la gravité, --ignore-unfixed écarte ce qui n'a pas de correctif, --exit-code 1 fait échouer la commande.
   copier

   docker run --rm \
     -v "$(pwd)":/src -w /src \
     -v trivy-cache:/root/.cache/trivy \
     aquasec/trivy:0.53.0 \
     fs --scanners vuln --severity HIGH,CRITICAL --ignore-unfixed --exit-code 1 .
   echo "code de sortie : $?" 

9. Écrivez les quatre nombres côte à côte dans votre rapport : brut, HIGH+CRITICAL, HIGH+CRITICAL corrigeables, et le code de sortie. Cet écart est votre marge de négociation quand une équipe vous dira que la porte est trop stricte. Un seuil se défend avec des chiffres, pas avec une doctrine.

TP 7 — Produire un SBOM CycloneDX et demander un second avis

Jour 2 · SCA — la surface qu'on hérite · 1 h

Générer l'inventaire normalisé de votre application, le relire, puis le soumettre à un second moteur pour mesurer le désaccord entre bases de vulnérabilités.

1. Générez le SBOM au format CycloneDX. C'est Trivy qui le produit — inutile d'ajouter Syft, qui ferait exactement la même chose avec un outil de plus à maintenir.
   copier

   docker run --rm \
     -v "$(pwd)":/src -w /src \
     -v trivy-cache:/root/.cache/trivy \
     aquasec/trivy:0.53.0 \
     fs --format cyclonedx --output artefacts/sbom.cdx.json .

2. Ouvrez-le. Pas dans un éditeur : par script, et regardez la structure. bomFormat, specVersion, l'horodatage, l'outil générateur, puis la liste des composants avec leur purl.
   copier

   python3 - <<'PY'
   import json
   
   d = json.load(open("artefacts/sbom.cdx.json"))
   print("format      :", d.get("bomFormat"), "spec", d.get("specVersion"))
   print("genere le   :", d["metadata"]["timestamp"])
   print("outil       :", d["metadata"]["tools"])
   comps = d.get("components", [])
   print("composants  :", len(comps))
   print()
   for c in comps[:25]:
       print(f'  {c.get("name", "?"):22} {c.get("version", "?"):12} {c.get("purl", "")}')
   PY

3. Comparez deux nombres : le nombre de composants du SBOM et le nombre de lignes de votre requirements.txt. L'écart, c'est l'arbre transitif. Écrivez les deux chiffres — c'est l'illustration la plus directe de la leçon de ce matin.
4. Vérifiez que le SBOM est exploitable : Trivy sait le rescanner directement, sans repasser par le système de fichiers. C'est ainsi qu'on analyse une livraison dont on n'a plus le code source.
   copier

   docker run --rm \
     -v "$(pwd)":/src -w /src \
     -v trivy-cache:/root/.cache/trivy \
     aquasec/trivy:0.53.0 \
     sbom --format table artefacts/sbom.cdx.json

5. Demandez maintenant un second avis à un autre moteur, sur exactement le même inventaire. Grype n'entre pas dans votre outillage permanent — il intervient une fois, ici, pour une démonstration précise.
   copier

   docker run --rm \
     -v "$(pwd)":/src -w /src \
     -v grype-db:/root/.cache/grype \
     anchore/grype:v0.79.2 \
     sbom:/src/artefacts/sbom.cdx.json -o table

6. Produisez la sortie JSON de Grype, puis croisez les deux moteurs par script.
   copier

   docker run --rm \
     -v "$(pwd)":/src -w /src \
     -v grype-db:/root/.cache/grype \
     anchore/grype:v0.79.2 \
     sbom:/src/artefacts/sbom.cdx.json -o json \
     > artefacts/grype-2026-08-07.json
   
   python3 - <<'PY'
   import json
   
   trivy = set()
   d = json.load(open("artefacts/trivy-fs-2026-08-07.json"))
   for res in d.get("Results", []):
       for v in res.get("Vulnerabilities", []) or []:
           trivy.add((v["PkgName"].lower(), v["VulnerabilityID"]))
   
   grype = set()
   g = json.load(open("artefacts/grype-2026-08-07.json"))
   for m in g.get("matches", []):
       grype.add((m["artifact"]["name"].lower(), m["vulnerability"]["id"]))
   
   print(f"Trivy   : {len(trivy)} couples paquet/CVE")
   print(f"Grype   : {len(grype)} couples paquet/CVE")
   print(f"Communs : {len(trivy & grype)}")
   print()
   print("-- vus par Trivy seul --")
   for p, c in sorted(trivy - grype):
       print(f"   {p:16} {c}")
   print("-- vus par Grype seul --")
   for p, c in sorted(grype - trivy):
       print(f"   {p:16} {c}")
   PY

7. Regardez les trois nombres : vus par Trivy seul, vus par Grype seul, communs. Le désaccord n'est pas un défaut. Choisissez une CVE remontée par un seul des deux, allez lire son advisory, et écrivez dans votre rapport pourquoi les deux positions se défendent — intervalle de versions affectées interprété différemment, source primaire distincte, ou correctif rétroporté par une distribution.
8. Écrivez enfin la phrase qui va dans tous vos rapports jusqu'à la soutenance, et remplacez les valeurs par les vôtres : « Aucune vulnérabilité HIGH ou CRITICAL corrigeable n'est connue de Trivy 0.53.0 sur le périmètre analysé au 7 août 2026. » Notez ce qu'elle ne dit pas : elle ne dit pas que l'application est sûre.

TP 8 — Exploitabilité réelle et correction de VULN-10

Jour 2 · SCA — la surface qu'on hérite · 1 h 15

Prouver qu'une CVE de dépendance est réellement exploitable, décider de chaque CVE par l'atteignabilité, corriger VULN-10 en montant les versions, et poser un fichier d'exceptions daté.

1. Écrivez le script de démonstration dans demo/pyyaml-poc.py et lancez-le. Il montre côte à côte l'exécution de code par yaml.load et le refus par yaml.safe_load.
   copier

   mkdir -p demo
   # Collez le contenu ci-dessous dans demo/pyyaml-poc.py, puis :
   python3 demo/pyyaml-poc.py

2. Voici le script. Recopiez-le tel quel.
   copier

   # demo/pyyaml-poc.py — a lancer UNIQUEMENT sur votre poste, jamais ailleurs.
   # Demontre que yaml.load avec un Loader complet execute du code arbitraire.
   # C'est la CVE de PyYAML 5.3.1 (FullLoader contournable) rendue concrete.
   import subprocess
   import sys
   
   import yaml
   
   # Charge utile : un tag !!python/object/apply qui appelle une commande shell.
   CHARGE = """!!python/object/apply:subprocess.check_output
   - ["echo", "code-execute-par-la-deserialisation"]
   """
   
   
   def sans_reseau_via_endpoint():
       """Ce que ferait un attaquant contre /config de devsecops-lab."""
       print(">>> yaml.load(Loader complet) sur une charge hostile :")
       resultat = yaml.load(CHARGE, Loader=yaml.Loader)
       print("    resultat :", resultat)
       print(">>> la commande a bien ete executee cote serveur.")
   
   
   def defense():
       print(">>> yaml.safe_load sur la meme charge :")
       try:
           yaml.safe_load(CHARGE)
       except yaml.YAMLError as e:
           print("    refuse :", type(e).__name__)
   
   
   if __name__ == "__main__":
       sans_reseau_via_endpoint()
       defense()

3. Arrêtez-vous sur ce que vous venez de voir : une chaîne de caractères, désérialisée, a exécuté une commande. C'est la jonction exacte entre VULN-10 (la version de PyYAML est vulnérable) et VULN-07 (votre /config appelle yaml.load sur le corps de la requête). L'une sans l'autre serait inoffensive.
4. Établissez l'atteignabilité, à la main, pour les paquets remontés en HIGH et CRITICAL. Ce grep est grossier — c'est le geste que les plateformes commerciales facturent sous le nom de reachability. Pour chaque paquet : la bibliothèque est-elle seulement importée ?
   copier

   cd ~/devsecops-lab
   
   # Pour chaque paquet remonte HIGH+, la fonction vulnerable est-elle importee ?
   # grep grossier, volontairement : c'est le geste manuel que les plateformes vendent.
   for pkg in werkzeug jinja2 pyyaml requests urllib3; do
     echo "=== $pkg ==="
     grep -rin --include='*.py' "import $pkg\|from $pkg" . || echo "   jamais importe"
   done

5. Écrivez maintenant, dans votre rapport, un verdict par CVE HIGH+ : corriger, compenser ou accepter, avec la raison. L'atteignabilité est votre argument principal : une CVE dans une fonction jamais importée descend dans la file ; une CVE sur un chemin emprunté à chaque requête monte. Interdiction de répondre « je monte tout » : ce n'est pas un tri.
6. Corrigez VULN-10 pour de bon : branche dédiée, montée de version, reconstruction, rescan bloquant. Attendez-vous à ce que l'application casse — c'est la partie instructive.
   copier

   git switch main
   git switch -c fix/vuln-10-deps
   
   # Remplacez requirements.txt par les versions corrigees (etape suivante),
   # puis reconstruisez et rescannez.
   docker build -t devsecops-lab:dev .
   
   docker run --rm \
     -v "$(pwd)":/src -w /src \
     -v trivy-cache:/root/.cache/trivy \
     aquasec/trivy:0.53.0 \
     fs --scanners vuln --severity HIGH,CRITICAL --ignore-unfixed --exit-code 1 .
   echo "code de sortie apres montee de version : $?" 

7. Voici les versions corrigées de requirements.txt. Remplacez le contenu, puis relancez la construction et le scan de l'étape précédente. Si app.py ne démarre plus, lisez la trace : Flask 3 et Werkzeug 3 déplacent certains imports, corrigez-les une erreur à la fois.
   copier

   Flask==3.0.3
   Werkzeug==3.0.3
   Jinja2==3.1.4
   PyYAML==6.0.1
   requests==2.32.3
   urllib3==2.2.2

8. Pour ce qui reste — les CVE non corrigeables (unfixed) ou dont la correction casserait la compatibilité — posez un fichier d'exceptions daté. Chaque entrée porte une expired_at : sans elle, l'exception n'existe pas.
   copier

   # .trivyignore.yaml — exceptions DATEES. Sans expired_at, pas d'exception.
   # Chaque entree dit : quelle CVE, pourquoi on l'accepte, jusqu'a quand.
   vulnerabilities:
     - id: CVE-EXEMPLE-0000
       # Paquet non atteignable : la fonction affectee n'est jamais importee
       # (verifie le 2026-08-07, voir rapports/sca-devsecops-lab.md section 4).
       # Reexamen impose a la date ci-dessous : ensuite, le pipeline redevient rouge.
       statement: "non atteignable sur ce deploiement ; correctif casse la compat 2.x"
       expired_at: 2026-11-07

9. Relancez une dernière fois le scan bloquant avec le fichier d'exceptions en place. Le code de sortie doit être 0, et vous devez pouvoir expliquer, pour chaque ligne du .trivyignore.yaml, pourquoi elle est là et quand elle expire. Une exception que vous ne savez pas justifier est une exception à retirer.
10. Committez la correction et le fichier d'exceptions séparément — deux gestes, deux messages.
    copier

    git add requirements.txt
    git commit -m "fix(VULN-10): montee des dependances hors versions a CVE"
    git add .trivyignore.yaml demo/pyyaml-poc.py
    git commit -m "docs(sca): exceptions datees et POC de deserialisation"

TP 9 — Porte SCA au pipeline et veille Dependabot

Jour 2 · SCA — la surface qu'on hérite · 45 min

Ajouter au pipeline un job qui produit le SBOM et bloque sur les CVE corrigeables, et activer une surveillance automatique des mises à jour de sécurité.

1. Reprenez la branche de correction et ajoutez le job sca à .github/workflows/ci.yml, sous jobs:, au même niveau que les deux autres. Il fait trois choses : produire le SBOM, le publier comme artefact daté du commit, puis bloquer sur les CVE HIGH+ corrigeables.
   copier

     sca:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v4
         - name: sbom cyclonedx
           run: |
             docker run --rm -v "$PWD:/src" -w /src aquasec/trivy:0.53.0 \
               fs --format cyclonedx --output /src/sbom.cdx.json .
         - name: publier le sbom
           uses: actions/upload-artifact@v4
           with:
             name: sbom-cyclonedx
             path: sbom.cdx.json
         - name: scan bloquant des dependances
           run: |
             docker run --rm -v "$PWD:/src" -w /src aquasec/trivy:0.53.0 \
               fs --scanners vuln --severity HIGH,CRITICAL --ignore-unfixed \
                  --exit-code 1 .

2. Lisez la dernière étape du job avant de committer. Les deux filtres --severity HIGH,CRITICAL et --ignore-unfixed sont vos deux décisions de seuil : vous ne bloquez ni sur les Medium ni sur l'incorrigeable. Sachez les défendre — ce sont exactement les questions de lundi.
3. Activez la veille : créez .github/dependabot.yml. Dès qu'un correctif de sécurité existe pour l'une de vos dépendances épinglées, Dependabot ouvrira une PR — que votre pipeline testera avant toute fusion.
   copier

   # .github/dependabot.yml — surveillance des mises a jour de securite.
   # Dependabot ouvre une PR des qu'un correctif de securite existe pour une
   # dependance epinglee : c'est le complement obligatoire de l'epinglage.
   version: 2
   updates:
     - package-ecosystem: pip
       directory: /
       schedule:
         interval: weekly
       open-pull-requests-limit: 5
       commit-message:
         prefix: "fix(deps)"
       labels:
         - securite
         - dependances

4. Committez, poussez, et regardez l'exécution du pipeline dans l'onglet Actions. Le job sca doit maintenant apparaître à côté de secrets et sast.
   copier

   git add .github/workflows/ci.yml .github/dependabot.yml
   git commit -m "feat(ci): job sca avec sbom en artefact et veille dependabot"
   git push

5. Ouvrez l'exécution terminée et vérifiez deux choses : le job sca est vert (vos corrections du TP 8 sont passées), et le SBOM figure bien dans la section Artifacts de l'exécution, nommé d'après le commit. Téléchargez-le : c'est l'inventaire daté de cette version précise.
6. Notez pour lundi : vous avez trois portes sur quatre. Il manque le DAST, et il manque la discussion d'ensemble des seuils. Écrivez la question que vous vous posez déjà — « pourquoi HIGH et pas MEDIUM ? » — vous y répondrez avec des chiffres.

TP 10 — Consigner la passe SCA

Jour 2 · SCA — la surface qu'on hérite · 45 min

Produire le rapport de composition, rejouable et daté, et le faire entrer dans le dépôt par une demande de fusion.

1. Ouvrez rapports/sca-devsecops-lab.md et remplissez les sections 1 et 2 avec les versions exactes et les quatre décomptes du TP 6. Si un chiffre vous manque, relancez la commande — n'estimez pas.
2. Complétez la section 3 avec les trois nombres du croisement Trivy/Grype et la CVE divergente que vous avez commentée. Rappelez la formule prudente : « connu de tel moteur, à telle date ».
3. Rédigez la section 4, celle qui a le plus de valeur : pour chaque CVE HIGH+, le verdict (corriger / compenser / accepter) et l'argument d'atteignabilité qui le fonde. C'est ce raisonnement, et non la liste des CVE, qui distingue votre rapport d'une sortie d'outil.
4. Complétez la section 5 : le contenu de .trivyignore.yaml avec la justification et l'échéance de chaque exception, et la mention de Dependabot comme mécanisme de veille. Une exception sans échéance dans ce document est une erreur à corriger avant de continuer.
5. Committez le rapport et poussez la branche.
   copier

   git add rapports/sca-devsecops-lab.md
   git commit -m "docs(sca): rapport de composition du 7 aout"
   git push

6. Ouvrez — ou mettez à jour — la demande de fusion, mais ne fusionnez pas. Le job sca est vert, mais sast reste rouge : VULN-03 et VULN-07 sont encore dans le code. La fusion consolidée aura lieu lundi, quand les quatre portes seront vertes ensemble.
   copier

   gh pr create --base main --head fix/vuln-10-deps \
     --title "SCA : correction VULN-10 et rapport de composition" \
     --body "Dependances montees hors versions a CVE, exceptions datees,
   SBOM en artefact, veille Dependabot. Job sca au VERT.
   Ne pas fusionner : sast reste rouge (VULN-03, VULN-07 a corriger lundi)."

7. Regardez la PR : secrets vert, sca vert, sast rouge. La protection de main refuse la fusion tant qu'une vérification échoue — et c'est exactement son rôle. Vous fermez la journée SCA avec un dépôt aux dépendances propres, tracées et surveillées, et une porte de plus au pipeline. Lundi, le DAST rejoint la chaîne et vous corrigez les dernières failles de code.

M2 · J2 — CVE tranchée par l'atteignabilité, VULN-10 corrigée, SBOM daté

Jour 2 · SCA — la surface qu'on hérite · 30 min

DAST : l'application attaquée pendant qu'elle tourne

Jour 3 · DAST et intégration des trois au pipeline · 25 min

Le SAST a lu votre code sans l'exécuter. La SCA a lu vos dépendances sans les exécuter. Le DAST fait l'inverse exact des deux : il ne lit rien, il attaque l'application pendant qu'elle tourne et regarde comment elle répond. Il ne sait pas où est le code, ni quelles bibliothèques vous utilisez. Il sait envoyer une requête et lire une réponse — comme un attaquant réel.

Trois temps, et une frontière de droit au milieu

• L'exploration (spider) parcourt l'application et dresse la liste des URL qu'elle atteint. Tout le reste du scan se limite à cette liste : ce qui n'est pas découvert n'est pas testé.
• Le scan passif observe les réponses sans jamais rien attaquer : en-têtes de sécurité absents, cookies sans attribut, bannières de version, message de débogage. Il est sans risque et peut tourner partout, à chaque build.
• Le scan actif fabrique et envoie de vraies charges d'attaque — apostrophes d'injection, balises de script, chemins traversants — et observe si elles prennent. Il modifie l'état de la cible, prend du temps, et ne se lance que sur une cible qu'on a le droit d'attaquer.

Ce que le DAST trouve, et ce qu'il ne verra jamais

C'est le miroir exact du tableau du premier jour. Le DAST voit tout ce qui laisse une trace dans une réponse HTTP, et rien de ce qui n'en laisse pas.

Mettez ce tableau en regard de celui du premier jour. Le SAST voyait VULN-05, VULN-06 et manquait la preuve du XSS ; le DAST prouve le XSS et ne voit ni le secret ni le md5. Aucun des deux n'est meilleur. Ils sont complémentaires, et leur intersection est vide sur la moitié des failles.

L'exploration ne suffit pas : le scan piloté par spécification

Le spider ne découvre que ce qui est relié. Une API n'a pas de liens : ses routes existent, mais aucune page n'y pointe. Pour les tester, on donne à l'outil la carte — une spécification OpenAPI — et il attaque chaque route décrite. C'est le zap-api-scan que vous emploierez tout à l'heure, et c'est aussi ce qui rendra le DAST utilisable dans le pipeline : un scan qui ne dépend pas de ce que le spider a bien voulu trouver est un scan reproductible.

Quiz — DAST et complémentarité

Jour 3 · DAST et intégration des trois au pipeline · 10 min

TP 11 — ZAP en passif sur vos deux cibles

Jour 3 · DAST et intégration des trois au pipeline · 1 h

Lancer un scan passif sur devsecops-lab puis sur Juice Shop, et distinguer ce que l'observation seule révèle — sur une application de 130 lignes et sur une application riche.

1. Vérifiez que vos deux cibles répondent, et relancez celle qui dort. Ces images ont été construites au M1 ; on ne les recrée pas, on les redémarre.
   copier

   cd ~/devsecops-lab
   docker ps --filter name=devsecops-lab --filter name=juice-shop
   
   # Si l'un des deux ne tourne pas, relancez-le (images du M1) :
   docker start devsecops-lab 2>/dev/null || \
     docker run -d --name devsecops-lab --network dso-net -p 5000:5000 devsecops-lab:dev
   docker start juice-shop 2>/dev/null || \
     docker run -d --name juice-shop --network dso-net -p 3000:3000 \
       bkimminich/juice-shop:v17.3.0
   
   # Verifiez que les deux repondent depuis votre poste :
   curl -sf -o /dev/null -w "devsecops-lab %{http_code}\n" http://localhost:5000/
   curl -sf -o /dev/null -w "juice-shop   %{http_code}\n" http://localhost:3000/

2. Lancez le scan passif sur votre application. ZAP explore, puis observe les réponses sans jamais attaquer. Le rapport HTML atterrit dans artefacts/.
   copier

   mkdir -p artefacts
   docker run --rm --network dso-net \
     -v "$(pwd)/artefacts":/zap/wrk:rw \
     ghcr.io/zaproxy/zaproxy:2.15.0 \
     zap-baseline.py -t http://devsecops-lab:5000 \
       -r zap-baseline-devsecops-2026-08-10.html \
       -J zap-baseline-devsecops.json
   echo "code de sortie ZAP : $?" 

3. Ouvrez artefacts/zap-baseline-devsecops-2026-08-10.html dans votre navigateur. Repérez les alertes liées à VULN-09 : en-têtes de sécurité manquants (Content-Security-Policy, X-Content-Type-Options), et surtout la trace du mode débogage. C'est la même faille que Bandit signalait dans le code et que Trivy verra dans l'image au M3 — trois outils, trois angles, une seule cause.
4. Lancez maintenant le même scan passif sur Juice Shop. Même commande, autre cible.
   copier

   docker run --rm --network dso-net \
     -v "$(pwd)/artefacts":/zap/wrk:rw \
     ghcr.io/zaproxy/zaproxy:2.15.0 \
     zap-baseline.py -t http://juice-shop:3000 \
       -r zap-baseline-juice-2026-08-10.html

5. Comparez les deux rapports côte à côte. Votre application de 130 lignes déclenche une poignée d'alertes ; Juice Shop en déclenche beaucoup plus, parce qu'elle a une vraie surface : cookies applicatifs, scripts, stockage côté client, en-têtes multiples. Le passif n'a pourtant rien attaqué dans les deux cas — toute cette matière est simplement lue dans les réponses.
6. Notez dans votre rapport DAST naissant (rapports/dast-devsecops-lab.md) deux choses : l'alerte de devsecops-lab qui correspond à VULN-09, et une phrase sur l'écart de surface entre les deux cibles. Le fond de Juice Shop — l'exploitation réelle — est réservé au M5 ; aujourd'hui, elle sert de point de comparaison.

TP 12 — Scan actif, scan d'API, inspection du trafic

Jour 3 · DAST et intégration des trois au pipeline · 1 h 10

Passer en actif sur devsecops-lab pour obtenir la preuve de VULN-02, scanner l'API par sa spécification, inspecter une requête au proxy, et vérifier la prédiction du premier jour.

1. Lancez le scan actif sur votre application. Il explore, puis attaque chaque point d'entrée trouvé. Comptez quelques minutes, et laissez-le aller au bout.
   copier

   docker run --rm --network dso-net \
     -v "$(pwd)/artefacts":/zap/wrk:rw \
     ghcr.io/zaproxy/zaproxy:2.15.0 \
     zap-full-scan.py -t http://devsecops-lab:5000 \
       -r zap-full-devsecops-2026-08-10.html \
       -J zap-full-devsecops.json
   echo "code de sortie ZAP : $?" 

2. Ouvrez le rapport et trouvez Cross Site Scripting (Reflected) sur /search. Dépliez l'alerte : ZAP vous donne la charge exacte qu'il a envoyée et l'extrait de réponse où elle réapparaît. C'est VULN-02, et c'est une preuve, pas une suspicion — la différence exacte avec ce que votre règle Semgrep produisait hier. Vérifiez aussi, en creux, que la SQLi n'apparaît plus : VULN-01 a été corrigée au M1, et l'actif le confirme.
3. Écrivez la carte de l'API dans openapi.yaml, à la racine du dépôt. Sans elle, /ping, /config et /login resteraient invisibles : aucune page ne pointe vers eux.
   copier

   # openapi.yaml — carte des routes de devsecops-lab pour zap-api-scan.
   # Sans elle, le spider ne trouverait ni /ping ni /config (aucune page n'y mene).
   openapi: 3.0.3
   info:
     title: devsecops-lab
     version: "1.0"
   servers:
     - url: http://devsecops-lab:5000
   paths:
     /search:
       get:
         parameters:
           - name: q
             in: query
             required: true
             schema: { type: string }
         responses:
           "200": { description: resultats }
     /ping:
       get:
         parameters:
           - name: host
             in: query
             schema: { type: string }
         responses:
           "200": { description: sortie de ping }
     /login:
       post:
         requestBody:
           content:
             application/x-www-form-urlencoded:
               schema:
                 type: object
                 properties:
                   user: { type: string }
                   pwd: { type: string }
         responses:
           "200": { description: authentifie }
           "401": { description: refuse }

4. Lancez le scan piloté par la spécification. ZAP lit la carte, puis attaque chaque route décrite — y compris celles que le spider ne trouvait pas.
   copier

   docker run --rm --network dso-net \
     -v "$(pwd)":/zap/wrk:rw \
     ghcr.io/zaproxy/zaproxy:2.15.0 \
     zap-api-scan.py -t /zap/wrk/openapi.yaml -f openapi \
       -r artefacts/zap-api-devsecops-2026-08-10.html

5. Comparez la couverture des deux scans actifs : le scan par exploration a testé ce qui était relié, le scan d'API a testé /ping et /login en plus. C'est la démonstration que dans le pipeline, on pilotera par spécification — c'est reproductible, là où l'exploration dépend de ce que le spider a bien voulu trouver ce jour-là.
6. Inspectez enfin une requête au proxy. mitmproxy se place entre votre client et la cible et journalise tout en clair : la charge XSS que vous envoyez, et la réponse qui la renvoie.
   copier

   # Un proxy d'inspection, le temps d'une requete. On lit le trafic API en clair.
   docker run --rm -d --name dso-mitm --network dso-net -p 8080:8080 \
     mitmproxy/mitmproxy:10.3.1 mitmdump
   
   # Envoyez une requete A TRAVERS le proxy : la charge XSS traverse mitmproxy,
   # qui la journalise avec la reponse.
   curl -s -x http://localhost:8080 \
     "http://devsecops-lab:5000/search?q=<script>alert(1)</script>" -o /dev/null
   
   # Lisez ce que le proxy a intercepte, requete ET reponse :
   docker logs dso-mitm | tail -n 30
   
   # On coupe le proxy : c'etait une inspection, pas un service.
   docker rm -f dso-mitm

7. Regardez ce que mitmproxy a capturé : votre charge <script> dans l'URL, et la réponse HTML qui la contient telle quelle. C'est le même XSS, vu au niveau du fil. Ce geste — intercepter, lire, modifier une requête — est exactement ce que vous feriez à la main dans Burp Community, en interface graphique. ZAP automatise, mitmproxy et Burp inspectent : trois outils, une même famille.
8. Refermez la journée technique sur la vérification qui compte : reprenez le tableau de prédiction du premier jour et cochez chaque case avec ce que vous avez maintenant mesuré. Le DAST a-t-il trouvé VULN-02 ? Oui, avec preuve. VULN-05, VULN-06, VULN-10 ? Non, et vous savez dire pourquoi. VULN-04 ? Aucun des trois. Notez tout écart entre votre prédiction et la réalité : c'est là que vous avez appris quelque chose.

Trois portes, trois seuils : bloquer juste ce qu'il faut

Jour 3 · DAST et intégration des trois au pipeline · 25 min

Vous avez maintenant quatre portes possibles : secrets, sast, sca, dast. La question n'est plus comment les brancher — vous savez le faire — mais à quel seuil chacune doit refuser une fusion. C'est une décision d'architecture, et c'est celle qu'on vous demandera de défendre.

Le principe qui gouverne tous les seuils

Gravité et confiance : deux axes, pas un

On ne bloque pas sur la seule gravité. On bloque sur le croisement de trois propriétés :

• la gravité — combien coûte la faille si elle est exploitée ;
• la confiance — la probabilité que l'alerte soit un vrai positif ;
• la corrigeabilité — existe-t-il un correctif que l'équipe peut appliquer maintenant.

C'est exactement pourquoi votre XSS a voyagé d'un axe à l'autre en trois jours : côté SAST, le motif du gabarit dynamique était grave mais peu sûr (faux positifs sur les gabarits constants), donc en avertissement. Côté DAST, la preuve d'exécution lève le doute : grave et sûr, donc bloquant. La même faille, deux traitements, une seule logique.

Les quatre portes, leur seuil, et le motif de chaque seuil

Ce qui ne bloque pas ne disparaît pas

Bloquer n'est qu'une des actions possibles. Ce qui ne bloque pas doit encore être tracé : le SARIF remonte dans l'onglet Security, les avertissements restent visibles, les Medium se traitent en fenêtre de maintenance, les exceptions portent une date d'expiration. Une porte n'est pas un mur binaire ; c'est le sommet visible d'un dispositif qui, en dessous, garde trace de tout.

TP 13 — DAST au pipeline : rouge sur le XSS, puis vert

Jour 3 · DAST et intégration des trois au pipeline · 1 h

Ajouter la quatrième porte au pipeline, la voir échouer sur VULN-02, corriger les dernières failles de code, lever les exceptions du module 1 à leur échéance, et amener les quatre portes au vert ensemble.

1. Reprenez la branche de correction et ajoutez le job dast à .github/workflows/ci.yml, sous jobs:. Il démarre la cible et ZAP sur un même réseau, puis lance le scan d'API en mode bloquant.
   copier

     dast:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v4
         - name: cible + zap sur un reseau dedie
           run: |
             docker network create dast-net
             docker build -t devsecops-lab:dev .
             docker run -d --name devsecops-lab --network dast-net devsecops-lab:dev
             # attendre que la cible reponde, depuis le meme reseau
             docker run --rm --network dast-net curlimages/curl:8.8.0 \
               sh -c 'for i in $(seq 1 30); do curl -sf http://devsecops-lab:5000/ && exit 0; sleep 2; done; exit 1'
         - name: zap api scan (actif, bloquant sur le XSS)
           run: |
             docker run --rm --network dast-net \
               -v "$PWD:/zap/wrk:rw" \
               ghcr.io/zaproxy/zaproxy:2.15.0 \
               zap-api-scan.py -t /zap/wrk/openapi.yaml -f openapi \
                 -c zap-regles.conf -r zap-dast.html
         - name: publier le rapport zap
           if: always()
           uses: actions/upload-artifact@v4
           with:
             name: rapport-dast
             path: zap-dast.html

2. Ajoutez le fichier de règles zap-regles.conf à la racine. Attention : les colonnes sont séparées par des tabulations. C'est lui qui promeut le XSS réfléchi en FAIL et fait taire le bruit passif.
   copier

   # zap-regles.conf — action par regle pour zap-api-scan.py -c
   # format : <id de regle><TAB>WARN|FAIL|IGNORE<TAB>(commentaire)
   # On echoue le build sur le XSS reflechi, et rien d'autre : c'est la seule
   # regle a haute confiance dont la preuve a ete etablie au TP 12.
   40012	FAIL	(Cross Site Scripting (Reflected) : porte bloquante)
   10015	IGNORE	(Incomplete or No Cache-control : bruit passif, hors porte)
   10096	IGNORE	(Timestamp Disclosure : bruit)
   10027	IGNORE	(Information Disclosure - Suspicious Comments : bruit)
   

3. Committez, poussez, et regardez le pipeline. Le job dast doit être rouge : VULN-02 est toujours dans le code, ZAP en fournit la preuve, et la règle 40012 échoue le build. C'est la boucle rouge→vert, sur la dernière porte.
   copier

   git add .github/workflows/ci.yml zap-regles.conf openapi.yaml
   git commit -m "feat(ci): porte dast (zap-api-scan) bloquante sur le XSS reflechi"
   git push

4. Corrigez VULN-02 dans app.py. Un gabarit fixe, la valeur passée en variable : Jinja l'échappe automatiquement. C'est le geste que votre règle Semgrep recommandait mot pour mot.
   copier

   @app.route("/search")
   def search():
       # F-VULN-02 : gabarit FIXE, la valeur passe en variable et Jinja l'echappe.
       terme = request.args.get("q", "")
       return render_template_string("<h1>Resultats pour {{ terme }}</h1>", terme=terme)

5. Corrigez du même élan VULN-03 : validez que l'entrée est bien une adresse IP, puis passez une liste d'arguments sans interpréteur de commandes. Ajoutez import ipaddress en tête de fichier.
   copier

   @app.route("/ping")
   def ping():
       # F-VULN-03 : on valide que l'entree EST une IP, puis liste d'arguments sans shell.
       hote = request.args.get("host", "127.0.0.1")
       ipaddress.ip_address(hote)  # leve ValueError si ce n'est pas une adresse
       out = subprocess.check_output(["ping", "-c1", hote])
       return out

6. Puis VULN-06 et VULN-07 : sha-256 à la place de md5, safe_load à la place de load.
   copier

   @app.route("/hash")
   def weak_hash():
       # F-VULN-06 : sha-256 a la place de md5 pour un usage de securite.
       return hashlib.sha256(request.args.get("p", "").encode()).hexdigest()
   
   
   @app.route("/config", methods=["POST"])
   def load_config():
       # F-VULN-07 : safe_load ne construit que des types simples, pas d'objets Python.
       return str(yaml.safe_load(request.data))

7. Levez les quatre exceptions du 5 août. Nous sommes le 10 : c'est l'échéance que vous aviez inscrite, et les quatre failles qu'elles couvraient viennent d'être corrigées. Une exception qui survit à sa cause est une dette cachée — supprimez les annotations et leurs trois lignes de commentaire, puis vérifiez qu'il n'en reste aucune.
   copier

   # Supprimez, dans app.py, les blocs :
   #   # nosemgrep: <identifiant>
   #   # VULN-0N — exception acceptee le 2026-08-05, echeance module 2 (2026-08-10).
   #   # Faille pedagogique deliberee. Suivi : README section 5, journal-incidents.
   
   grep -n 'nosemgrep' app.py
   echo "lignes restantes : $(grep -c nosemgrep app.py)"   # attendu : 0

8. Fermez la trace au même endroit que vous l'aviez ouverte : la section 5 du README et le journal. Une exception se clôt par écrit, pas par oubli.
   copier

   # README.md, section 5 : passez les quatre lignes en statut LEVEE, avec la date du jour
   # et le commit de correction. Ne supprimez pas les lignes : l'historique de la dette
   # fait partie du dossier.
   
   # journal-incidents.md, une ligne :
   # | 2026-08-10 | 4 exceptions nosemgrep levees a echeance | VULN-02/03/06/07 corrigees | annotations retirees, README section 5 a jour | 0 |

9. Relisez ce que vous venez de faire dans l'ordre : les exceptions ont été posées nommées et datées, elles n'ont jamais couvert plus que la règle qu'elles nommaient, elles ont tenu exactement jusqu'à leur échéance, et elles sont levées le jour dit avec la trace de leur fermeture. C'est le cycle complet d'une dette de sécurité gérée. La version dégradée — un nosemgrep nu posé un jeudi soir — donne le même vert au pipeline et aucune de ces garanties.
10. Vérifiez localement, avant de pousser, que le XSS a disparu — relancez le scan d'API. Le job doit sortir en code 0 : plus de règle 40012.
    copier

    docker build -t devsecops-lab:dev .
    docker restart devsecops-lab
    docker run --rm --network dso-net -v "$(pwd)":/zap/wrk:rw \
      ghcr.io/zaproxy/zaproxy:2.15.0 \
      zap-api-scan.py -t /zap/wrk/openapi.yaml -f openapi -c zap-regles.conf
    echo "code de sortie ZAP : $?"

11. Committez les corrections et poussez. Cette fois, regardez les quatre jobs : secrets, sast, sca, dast — tous verts. C'est la première fois que le pipeline complet passe.
    copier

    git add app.py README.md journal-incidents.md
    git commit -m "fix(VULN-02,03,06,07): gabarit fixe, ip validee, sha256, safe_load ;
    exceptions nosemgrep du 5 aout levees a echeance"
    git push

12. Prenez la mesure de ce que vous venez de faire : une faille signalée par le SAST en avertissement, prouvée par le DAST, corrigée, et désormais gardée par une porte automatique qui échouera le build si elle revient. C'est cela, la sécurité comme code — et c'est la fin du parcours des trois familles.

TP 14 — Synthèse des trois familles et fusion consolidée

Jour 3 · DAST et intégration des trois au pipeline · 25 min

Écrire la note qui relie les trois jours, fusionner les corrections sur une chaîne verte, et laisser un dépôt dont chaque porte a un seuil défendable.

1. Complétez rapports/dast-devsecops-lab.md : d'abord le tableau vulnérabilité × famille, une ligne par VULN, une colonne par famille (SAST / SCA / DAST), rempli avec ce que vous avez constaté sur trois jours — pas avec la prédiction du premier jour. Signalez toute case où la réalité a démenti la prédiction.
2. Écrivez ensuite, sous le tableau, une phrase par angle mort : VULN-04 (aucune famille), les CVE que le SAST ne voit pas, les secrets et le md5 que le DAST ne voit pas. C'est la démonstration, en trois lignes, qu'aucune famille ne se suffit.
3. Recopiez enfin le tableau des quatre portes — secrets, sast, sca, dast — avec pour chacune son seuil et le motif du seuil. Le motif est ce qui distingue votre note d'une capture d'écran de configuration.
4. Committez la note, puis fusionnez les corrections sur une chaîne verte. Vérifiez d'abord que les quatre checks passent, puis fusionnez la branche de correction.
   copier

   git add rapports/dast-devsecops-lab.md
   git commit -m "docs(dast): synthese des trois familles et seuils du pipeline"
   git push
   
   # apres verification des quatre checks verts sur la PR :
   gh pr merge feat/triage-sast --squash --delete-branch

5. Vérifiez sur main que le pipeline est vert de bout en bout, quatre portes comprises. Vous laissez un dépôt où chaque faille détectable par une machine est gardée par une porte, chaque porte a un seuil écrit, et chaque exception a une date. C'est l'état dans lequel un module de sécurité doit rendre un dépôt.

M2 · J3 — DAST intégré : ZAP échoue le build sur XSS, pipeline vert aux 4 portes

Jour 3 · DAST et intégration des trois au pipeline · 2 h