Shift-Left : détecter les problèmes au plus tôt

En 2017, Equifax laisse passer une faille connue dans une dépendance Apache Struts. Le correctif existait depuis deux mois : la fuite expose les données de 147 millions de personnes et coûte jusqu'à 700 millions de dollars de pénalités. Un simple scan de dépendances dans la CI l'aurait signalée. Quatre ans plus tard, Log4Shell (CVE-2021-44228) touche des millions d'applications Java : les équipes qui scannaient déjà leurs dépendances identifient et corrigent en quelques heures, les autres auditent à la main pendant des semaines.

Cette leçon explique le principe du shift-left : pourquoi un problème coûte d'autant plus cher qu'il est découvert tard, et comment déplacer progressivement tests, sécurité et validation d'infrastructure vers le début du cycle. Elle s'adresse aux développeurs, aux ops et aux responsables qualité ou sécurité qui découvrent le DevSecOps et veulent comprendre ce principe avant de choisir des outils.

Ce que vous allez apprendre

• Définir le principe du shift-left et retracer son origine
• Expliquer pourquoi le coût de correction croît avec le temps
• Distinguer les trois dimensions du shift-left : tests, sécurité, infrastructure
• Associer les gestes humains (threat modeling, checklist de revue, security champions) aux outils
• Mettre en œuvre une démarche progressive, des hooks pre-commit au scan d'IaC
• Éviter les pièges classiques : fatigue d'alerte, blocage excessif, absence de shift-right

Qu'est-ce que le shift-left ?

Le shift-left consiste à détecter un problème le plus tôt possible dans le cycle de développement, parce qu'il y coûte moins cher à corriger. Au lieu d'attendre la fin du projet pour tester et auditer, on déplace (« shift ») ces activités vers le début (« left ») du processus. C'est le principe fondateur du DevSecOps.

Concrètement, on écrit les tests avant ou pendant le développement, on scanne le code à chaque commit plutôt qu'une fois par mois, on vérifie les dépendances automatiquement plutôt qu'à la main avant la release, et on valide l'infrastructure avant de la provisionner plutôt qu'en production.

Le shift-left n'est pas une nouveauté absolue : le Test-Driven Development (TDD, écrire le test avant le code) date des années 2000. Ce qui a changé, c'est l'application systématique du principe à tous les aspects du développement : fonctionnel, sécurité, infrastructure, conformité.

Pourquoi « left » ?

Le terme vient de la représentation du cycle de développement sur une ligne de temps horizontale, où le temps s'écoule de gauche à droite. Dans l'approche héritée du modèle en cascade, les tests de sécurité arrivent juste avant la release : une équipe dédiée audite sous la pression du calendrier, et ce qu'elle trouve coûte cher à réécrire comme à reporter.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Le shift-left inverse cette logique en déplaçant les contrôles vers la phase de code, voire de conception. Il ne supprime pas les contrôles finaux : il réduit drastiquement ce qu'ils trouvent, parce que les vérifications ont eu lieu plus tôt. Le terme a été popularisé par Larry Smith en 2001 dans le Dr. Dobb's Journal, à propos des tests fonctionnels ; son extension à la sécurité accompagne l'essor du DevSecOps à partir de 2015.

Pourquoi une correction tardive coûte-t-elle plus cher ?

Un problème découvert tard coûte plus cher à corriger, et l'écart se creuse à chaque étape franchie. Le tableau donne des ordres de grandeur couramment cités, à lire comme une tendance et non comme une mesure : les multiplicateurs historiques, souvent attribués à un « IBM Systems Sciences Institute », n'ont jamais été retracés à une étude vérifiable, mais le sens de l'écart fait consensus.

Phase de détection	Ordre de grandeur	Pourquoi	Exemple concret
IDE, pre-commit	1	Le développeur corrige immédiatement, contexte frais	5 minutes pour retirer un secret écrit en dur
CI, pull request	Quelques fois plus	Relecture, tests à relancer	30 minutes : comprendre l'alerte, corriger, repousser
Recette	Dix fois plus	Cycle de test complet, retour arrière possible	2 heures : investigation, correction, nouveau cycle
Production	Cent fois plus	Incident, retour arrière, communication, post-mortem	1 à 2 jours d'équipe mobilisée
Après compromission	Sans commune mesure	Investigation, amendes, réputation, juridique	Semaines à mois : Equifax, jusqu'à 700 M$

Glissez pour voir

Ce qui fait grimper le coût

Cinq facteurs expliquent cette croissance, et les connaître aide à justifier le shift-left auprès d'une direction qui raisonne en délais et en budget. La perte de contexte d'abord : plus le temps passe, plus le développeur doit reconstituer ce qu'il avait en tête. L'effet domino ensuite : du code écrit par-dessus le bogue en dépend, et le corriger peut casser ce qui suit.

La coordination s'ajoute en production, où la correction mobilise développement, exploitation, sécurité et communication. Puis viennent l'impact métier sur les utilisateurs et le chiffre d'affaires, et les obligations légales : une fuite de données déclenche une notification à la CNIL et aux personnes concernées, dans des délais stricts.

Ce que mesure DORA

Le rapport State of DevOps 2024 de DORA chiffre l'écart entre équipes : les plus performantes déploient jusqu'à 182 fois plus souvent que les moins performantes, et se rétablissent d'un incident jusqu'à 2 293 fois plus vite. DORA range le « shifting left on security » parmi les capacités techniques qui expliquent cet écart ; dès 2016, son rapport relevait que les équipes les plus performantes passaient 50 % de temps en moins à corriger des problèmes de sécurité. Le shift-left n'est pas un frein, c'est un accélérateur mesuré.

Combien coûte une fuite de données ?

Le rapport Cost of a Data Breach 2026 d'IBM, mené avec le Ponemon Institute auprès de 602 organisations victimes d'une fuite, chiffre le coût moyen d'une violation de données à 4,99 millions de dollars, un record en hausse de 12 % sur un an. Le même rapport relève que les organisations qui recourent largement à l'automatisation et à l'IA dans leur sécurité économisent en moyenne 1,93 million de dollars par incident. Le shift-left n'est qu'une partie de cette automatisation, mais il en est le premier maillon : un contrôle qui tourne à chaque commit ne dépend pas de la vigilance d'un auditeur.

Les trois dimensions du shift-left

Le shift-left s'applique à trois domaines complémentaires : les tests fonctionnels, la sécurité et l'infrastructure. Chacun apporte des bénéfices propres, et c'est leur combinaison qui produit les meilleurs résultats.

Les tests fonctionnels

C'est le shift-left « classique », celui qui a donné son nom au concept. Historiquement, une équipe QA dédiée testait l'application une fois le développement « terminé » : les développeurs avaient changé de contexte, chaque bogue imposait un retour en arrière, et la QA devenait un goulot d'étranglement. Le shift-left rapproche chaque type de test du moment où le code est écrit.

Pratique	Description	Bénéfice	Retour
TDD	Écrire le test avant le code	Conception émergente, couverture garantie	Secondes
Tests unitaires	Tester chaque fonction isolément	Retour rapide, maintenance facile	Secondes
Tests d'intégration	Tester les interactions entre composants	Problèmes d'interface détectés	Minutes
Tests de contrat	Valider les API entre services	Régressions d'interface évitées	Minutes

Glissez pour voir

Le principe clé : chaque test s'exécute le plus tôt possible. Un test unitaire de 10 ms dans l'IDE vaut mieux qu'un test de bout en bout de cinq minutes dans la CI. La leçon Stratégies de tests approfondit la pyramide des tests.

La sécurité

C'est le cœur du DevSecOps : intégrer les contrôles de sécurité dès le développement au lieu de les reléguer à un audit final. Traditionnellement, la sécurité fonctionnait en mode gardien : une équipe dédiée validait ou rejetait les releases juste avant la production, était perçue comme un frein, et découvrait des failles devenues coûteuses. Le shift-left distribue les contrôles sur tout le cycle.

Phase	Contrôles	Outils	Ce qu'on détecte
IDE	Linters de sécurité, secrets en temps réel	Extensions Semgrep, Snyk	Motifs dangereux pendant l'écriture
Pre-commit	Scan de secrets, validation de format	Gitleaks, hooks pre-commit	Secrets avant qu'ils atteignent le dépôt
CI/CD	SAST, SCA, scan d'IaC	Semgrep, Trivy, Checkov	Vulnérabilités du code et des dépendances
Build	Scan d'images, signature	Trivy, Cosign	Vulnérabilités des images, intégrité

Glissez pour voir

L'équipe sécurité ne disparaît pas : elle change de rôle. Au lieu de valider chaque release, elle définit les règles, maintient les outils et fait monter les équipes en compétence. L'OWASP Top 10:2025, qui remplace l'édition 2021, ajoute deux catégories, Software Supply Chain Failures et Mishandling of Exceptional Conditions : la chaîne d'approvisionnement doit être surveillée en continu, pas auditée ponctuellement. La leçon OWASP Top 10 appliqué au DevSecOps détaille chaque catégorie.

L'infrastructure

Avec l'Infrastructure as Code (IaC, l'infrastructure décrite dans des fichiers versionnés plutôt que par des clics dans une console), l'infrastructure devient du code, et elle doit être testée avant d'être appliquée. Sans shift-left, une mauvaise configuration se découvre au provisionnement, ou en production quand un attaquant l'exploite : un bucket public, un groupe de sécurité ouvert à tout, un conteneur qui tourne en root.

Quoi	Quand	Comment	Ce qu'on détecte
Terraform	Avant terraform apply	Checkov, OPA	Buckets publics, chiffrement manquant, ports ouverts
Kubernetes	Avant kubectl apply	Kubescape, kube-linter	Conteneurs root, secrets en clair, limites manquantes
Dockerfiles	Avant docker build	Hadolint, Dockle	Images non officielles, utilisateur root, couches inutiles
CloudFormation	Avant déploiement	cfn-lint, Checkov	Configurations AWS non conformes

Glissez pour voir

L'avantage de l'IaC est que les mêmes outils de revue s'appliquent à l'infrastructure : un changement de configuration passe par une pull request et une CI, exactement comme un changement de code applicatif, avec la même traçabilité.

Quelle part du shift-left reste humaine ?

Les outils ne couvrent qu'une partie du shift-left : les contrôles les plus en amont sont humains, et aucun scanner ne les remplace. Trois gestes complètent la chaîne automatique, de la conception à la revue de code, et le dernier s'appuie sur un rôle à part, le security champion.

Modéliser les menaces avant d'écrire le code

Le threat modeling (modélisation des menaces) est le shift-left le plus précoce : il identifie les scénarios d'attaque pendant la conception, quand corriger revient à changer un schéma ou une décision d'architecture. On le pratique à chaque fonctionnalité importante, à l'intégration d'un service externe, ou quand les flux de données changent. La leçon Threat modeling avec STRIDE en donne la méthode.

Former les développeurs

Un développeur qui ne connaît pas une vulnérabilité ne la reconnaît pas dans son propre code : ce n'est pas une question de compétence, mais de connaissances transmises. Des sessions courtes et régulières, sur des exemples tirés de la stack réelle de l'équipe, valent mieux qu'une formation annuelle vite oubliée. La leçon Former les équipes à la sécurité construit ce programme.

Ajouter une checklist de sécurité aux pull requests

Chaque pull request peut porter une courte checklist que n'importe quel relecteur applique, sans attendre un expert : pas de secret dans le diff, entrées utilisateur validées, requêtes SQL paramétrées, authentification vérifiée sur les nouveaux points d'accès, nouvelles dépendances justifiées. Le fichier CODEOWNERS de GitHub ajoute en plus un relecteur désigné dès qu'un fichier sensible change.

Ce relecteur désigné est souvent un security champion : un développeur de l'équipe qui garde son poste et porte en plus une responsabilité de sécurité, en faisant le pont avec l'équipe sécurité. Ce n'est ni un expert à temps plein ni un rôle improvisé : la leçon Créer un programme Security Champions explique comment en faire un programme structuré.

Comment mettre en œuvre le shift-left ?

La mise en œuvre doit être progressive : vouloir tout faire d'un coup est le meilleur moyen de frustrer les équipes et d'abandonner. Les cinq étapes ci-dessous vont du contrôle le plus rentable au plus complet, et chacune s'installe une fois la précédente acceptée par l'équipe.

1. Commencer par les hooks pre-commit

   C'est l'investissement le plus rentable : les hooks pre-commit s'exécutent sur le poste, avant que le code n'atteigne le dépôt. Un secret committé par erreur est bloqué immédiatement.

   pip install pre-commit
   cd mon-projet
   pre-commit install

   Créez ensuite un fichier .pre-commit-config.yaml à la racine :

   .pre-commit-config.yaml

   repos:
     # Détection de secrets
     - repo: https://github.com/gitleaks/gitleaks
       rev: v8.30.1
       hooks:
         - id: gitleaks
   
     # Formatage et contrôles de base
     - repo: https://github.com/pre-commit/pre-commit-hooks
       rev: v6.0.0
       hooks:
         - id: trailing-whitespace
         - id: end-of-file-fixer
         - id: check-yaml
         - id: check-added-large-files

   Ce fichier active Gitleaks et des contrôles de formatage. Un rev est un tag, donc modifiable : pre-commit autoupdate --freeze le remplace par le SHA du commit correspondant. Le guide du framework pre-commit détaille les hooks disponibles.

   Bloquer avant le commit évite un nettoyage bien plus lourd. Un secret committé reste dans l'historique Git même après un git revert, qui ajoute un commit inverse sans effacer l'ancien : il ne reste alors que la révocation du secret, puis la réécriture de l'historique.

   Gardez ces hooks rapides, sous une dizaine de secondes. Au-delà, les développeurs prennent l'habitude de git commit --no-verify, l'option qui ignore tous les hooks pre-commit, et le contrôle ne protège plus rien.

2. Ajouter le SAST dans la CI

   Ajoutez ensuite l'analyse statique (SAST, analyser le code source sans l'exécuter) à chaque pull request. Le job tourne dans l'image officielle de Semgrep, épinglée par digest : un tag peut être réécrit, un digest jamais.

   .github/workflows/security.yml

   name: Security Scan
   on: [pull_request]
   
   permissions: {}  # rien par défaut, chaque job déclare ses besoins
   
   jobs:
     sast:
       runs-on: ubuntu-24.04
       permissions:
         contents: read
         security-events: write  # requis pour publier le rapport SARIF
       container:
         image: semgrep/semgrep:1.178.0@sha256:32e459968daabe7ab86968184a29109b9564aa00392401156f9788452b42786b
       steps:
         - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
           with:
             persist-credentials: false
         - run: semgrep scan --config p/python --config p/owasp-top-ten --error --sarif --output semgrep.sarif
         - name: Publier le rapport SARIF
           if: always()  # publier même quand le scan a fait échouer le job
           uses: github/codeql-action/upload-sarif@2892aa5e19bbd11bc0cff5427e3b750a04d9e3c2 # v4.38.2
           with:
             sarif_file: semgrep.sarif

   Choisissez les règles d'après votre langage : sur une injection SQL Flask évidente, le ruleset générique p/security-audit ne remonte rien, quand p/python et p/owasp-top-ten la détectent. La leçon Tests de sécurité donne la mesure complète. Affinez ensuite selon les faux positifs rencontrés.

3. Analyser les dépendances (SCA)

   L'analyse de composition (SCA) détecte les vulnérabilités connues (CVE, identifiants publics de failles) dans les bibliothèques tierces, qui forment la majorité du code d'une application moderne. Le job ci-dessous lance Trivy depuis son image épinglée par digest : il échoue sur une vulnérabilité critique et se contente de signaler les hautes.

     sca:
       runs-on: ubuntu-24.04
       permissions:
         contents: read
       container:
         image: aquasec/trivy:0.75.0@sha256:af6acf9a6b85dfe389a1941505c0ce9efef52a4719635e1a962f022a3d855daa
       steps:
         - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
           with:
             persist-credentials: false
         - run: trivy fs --severity CRITICAL --exit-code 1 .  # bloque le job
         - run: trivy fs --severity HIGH --exit-code 0 .      # signale sans bloquer

   Cet épinglage n'est pas un excès de prudence. En mars 2026, l'automatisation de publication de Trivy a été compromise (CVE-2026-33634) : une release v0.69.4 piégée a été publiée, puis des images 0.69.5, 0.69.6 et latest sur Docker Hub. Un fichier de sommes de contrôle téléchargé avec la release ne protège pas d'une release compromise ; un digest choisi après vérification fige le binaire exact.

4. Scanner l'IaC

   Si vous utilisez Terraform, CloudFormation ou Kubernetes, ajoutez un scan des configurations avec Checkov, lui aussi lancé depuis son image épinglée.

     iac:
       runs-on: ubuntu-24.04
       permissions:
         contents: read
       container:
         image: bridgecrew/checkov:3.3.22@sha256:617c76e3f9b1f7907ebca9abb6b9d746844edcb48e9bd775e4692c69c1c6ac47
       steps:
         - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
           with:
             persist-credentials: false
         - run: checkov --directory terraform/ --framework terraform --compact --skip-check CKV_AWS_123,CKV_AWS_456

   Documentez chaque règle exclue par --skip-check dans un commentaire ou un ticket : une exclusion sans justification devient de la dette.

5. Mesurer et itérer

   Le shift-left est une pratique qui s'améliore, pas un projet ponctuel. Suivez quatre métriques chaque mois et ajustez les règles en conséquence ; les cibles du tableau sont des points de départ, pas des normes.

   Métrique	Ce qu'elle indique	Cible de départ
   Vulnérabilités par phase	Efficacité du shift-left	Le plus en pre-commit et CI, le moins en production
   Délai moyen de correction	Réactivité de l'équipe	Moins de 24 h pour le critique
   Taux de faux positifs	Qualité des règles	Moins de 10 %
   Taux de contournement	Adhésion de l'équipe	Moins de 5 %

   Glissez pour voir

Pourquoi avertir avant de bloquer ?

Un contrôle qui bloque dès le premier jour se fait contourner avant d'avoir prouvé sa valeur. Les jobs ci-dessus montrent l'état visé, mais ils s'introduisent en deux temps : le mode avertissement, qui montre les alertes sans arrêter le job, puis le mode bloquant, une fois le bruit éliminé.

Pour Semgrep, tout tient à l'option --error. Sans elle, semgrep scan sort en code 0 même quand il trouve un résultat : le job reste vert et l'équipe voit les alertes sans être bloquée. Avec elle, le scan sort en code 1 dès qu'un résultat subsiste, et le job échoue. Mesuré avec Semgrep 1.178.0 sur une injection SQL Flask volontaire : 0 sans l'option, 1 avec. Commencez sans, et ajoutez-la quand les faux positifs sont traités.

Trivy applique la même logique dans un seul job : --exit-code 1 sur le critique fait échouer le job, --exit-code 0 sur le haut se contente de signaler. Abaissez ensuite ce seuil de blocage à mesure que l'équipe traite ses alertes, plutôt que de tout bloquer dès le départ.

Reste à rendre l'échec lisible. L'envoi du rapport SARIF (format standard de résultats d'analyse) vers l'onglet Security de GitHub porte if: always(). Sans cette condition, l'échec du scan ferait sauter les étapes suivantes, et le développeur verrait un job rouge sans le détail des résultats, précisément quand il en a besoin.

Quels pièges éviter ?

Un shift-left mal introduit peut faire plus de mal que de bien. Le tableau relie chaque piège au symptôme qui le trahit et à sa correction ; le plus fréquent est le premier, tout bloquer dès le départ, qui pousse les équipes au contournement.

Piège	Symptôme	Cause	Solution
Tout bloquer	Pipeline rouge en permanence, développeurs frustrés	Règles trop strictes dès le départ	Bloquer le critique, alerter sur le reste, durcir progressivement
Ignorer les faux positifs	500 alertes par jour, que tout le monde ignore	Outils mal configurés	Des exclusions documentées, chacune justifiée
Outils sans formation	Contournements par --no-verify	Règles imposées sans explication	Former, expliquer le pourquoi, associer les développeurs
Shift-left sans shift-right	Fausse impression de sécurité	Attention portée sur la seule CI	Compléter par du DAST en recette et une surveillance en production
Pas de propriétaire	Alertes qui traînent	Responsabilité floue	Un propriétaire par alerte, dans le flux de tickets
Métriques absentes	Impossible de savoir si ça marche	Aucun suivi	Mesurer vulnérabilités par phase, délais, faux positifs

Glissez pour voir

La fatigue d'alerte

Le piège le plus insidieux est la fatigue d'alerte : quand les développeurs reçoivent des centaines d'alertes par jour, ils finissent par tout ignorer, y compris les vraies failles critiques. Quatre gestes l'évitent : prioriser (seul le critique bloque), contextualiser (une CVE dans une dépendance de test pèse moins qu'en production), dédupliquer, et faire déboucher chaque alerte sur une action claire.

Un scanner n'est adopté que s'il respecte quatre critères, résumés dans le tableau : un outil qui en manque un finit contourné. Le plus décisif est la précision : face à 500 alertes dont 450 sont fausses, l'équipe cesse vite de lire les 50 autres. Mieux vaut moins de règles, mais fiables.

Critère	Objectif	Si non respecté
Rapidité	Quelques secondes dans l'IDE, moins de 5 minutes en CI	Contourné ou désactivé
Précision	Moins de 10 % de faux positifs	Alertes ignorées
Actionnable	Explication claire et correctif suggéré	Frustration, escalade
Contextuel	Dans l'IDE ou la pull request, pas dans un rapport à part	Retour jamais lu

Glissez pour voir

Le shift-left ne remplace pas les contrôles en production

Le shift-left est un complément, pas un remplacement. Les tests dynamiques (DAST), la surveillance de sécurité et la détection d'anomalies restent essentiels : une CI parfaite ne protège pas d'une attaque zero-day en production.

Shift-left ou shift-right ?

Le shift-left a un complément naturel, le shift-right, qui étend les contrôles vers la fin du cycle, c'est-à-dire en production. Certains problèmes n'apparaissent qu'en conditions réelles : la charge réelle, les interactions avec des systèmes tiers, les comportements émergents à grande échelle, ou une attaque zero-day qu'aucun scan ne couvre.

Pratique	Description	Objectif
Feature flags	Activer une fonctionnalité pour une partie des utilisateurs	Limiter l'impact d'un bogue
Canary releases	Déployer sur une petite fraction avant le reste	Détecter avant propagation
Blue/green	Deux environnements identiques, bascule instantanée	Retour arrière immédiat
Chaos engineering	Injecter des pannes volontaires	Valider la résilience
Surveillance de sécurité	Détecter les comportements anormaux en temps réel	Repérer les attaques

Glissez pour voir

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Les deux approches forment un continuum : le shift-left réduit le nombre de problèmes qui atteignent la production, le shift-right détecte ceux qui passent malgré tout et limite leur impact. Les équipes les plus performantes pratiquent les deux.

À retenir

• Le shift-left déplace tests, sécurité et validation d'infrastructure vers le début du cycle.
• Un problème coûte d'autant plus cher qu'il est découvert tard ; les multiplicateurs cités sont des ordres de grandeur.
• Trois dimensions : tests fonctionnels, sécurité, infrastructure.
• Les contrôles les plus en amont sont humains : threat modeling, checklist de revue, security champions.
• Commencez par les hooks pre-commit, le contrôle le plus rentable, et gardez-les sous une dizaine de secondes.
• Lancez le SAST en avertissement, puis ajoutez --error pour bloquer.
• Épinglez les outils de sécurité par digest : Trivy lui-même a été piégé en mars 2026.
• Ne bloquez pas tout : le critique bloque, le reste alerte.
• Complétez par le shift-right : surveillance, déploiements progressifs, chaos engineering.

Contrôle de connaissances

Vérifiez que l'essentiel de cette leçon est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

8 questions

8 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

FAQ : questions fréquentes

Ces réponses courtes reprennent les questions qui reviennent le plus souvent sur le shift-left : son coût, sa mise en place sans bloquer les équipes et les faux positifs. Chacune se lit seule.

Qu'est-ce que le shift-left ?

Quelle est la différence entre shift-left et shift-right ?

Pourquoi le coût de correction d'un bug augmente-t-il avec le temps ?

Comment mettre en place le shift-left dans une équipe ?

Quelle est la différence entre shift-left et DevSecOps ?

Quels sont les pièges les plus courants du shift-left ?

Quelle part du shift-left sécurité reste humaine ?

Comment éviter que les faux positifs fassent échouer le shift-left ?

×

📖 Voir la documentation →