TL;DR
La règle empirique largement citée — popularisée par Pressman (1987) et les travaux de Boehm sur le coût des défauts — veut que corriger un défaut découvert en développement coûte 1x, en QA 10x, et en production 100x. Le Shift Left Security consiste à déplacer la détection des vulnérabilités aussi près que possible du moment d'écriture du code. Les contrôles bloquants sur les analyses de sécurité automatisées dans le CI constituent le principal mécanisme d'implémentation.
L'expression "shift left" fait référence au cycle de vie du développement logiciel visualisé comme une chronologie de gauche à droite : exigences, conception, développement, tests, staging, production. Déplacer les tests de sécurité vers la gauche signifie les exécuter plus tôt dans cette séquence.
La courbe "1x / 10x / 100x" est le plus souvent attribuée à une étude de l'IBM Systems Sciences Institute, mais les montants exacts en dollars (souvent cités : 80–240 $ en dev, 960–7 600 $ en QA, 7 600–80 000 $ en production) proviennent d'une source fréquemment recyclée qui n'a pas été indépendamment vérifiée — voir l'analyse de Laurent Bossavit dans The Leprechauns of Software Engineering. Le patron directionnel, en revanche, est corroboré par l'étude NIST RTI International (GCR 02-805, 2002) et les enquêtes industrielles de Capers Jones : les défauts coûtent considérablement plus cher lorsqu'ils sont détectés tardivement, et les vulnérabilités de sécurité suivent la même courbe — avec le coût supplémentaire de la réponse à l'incident, des notifications aux clients et de l'exposition réglementaire si la faille est exploitée avant d'être découverte.
Le multiplicateur de 100x n'est pas une abstraction. Une injection SQL découverte lors d'une revue de code prend une heure à un développeur pour être corrigée — une requête paramétrée, un test, une pull request. La même injection SQL découverte après une violation de données impliquant 500 000 enregistrements mobilise une enquête forensique, une révision juridique, une notification aux régulateurs, un prestataire de réponse à incident, des communications clients et probablement un contentieux civil. Le correctif technique représente toujours une heure. Tout le reste est un surcoût dû au délai.
L'implémentation de base est simple : exécuter des vérifications de sécurité dans votre pipeline CI et bloquer sur les résultats.
Une implémentation minimale pour une application web :
# .github/workflows/security.yml
name: Security Gate
on: [push, pull_request]
jobs:
security:
runs-on: ubuntu-latest
permissions:
security-events: write
steps:
- uses: actions/checkout@v4
- name: Dependency audit
run: npm audit --audit-level=high
# Fails the build on HIGH or CRITICAL dependency CVEs
- name: SAST scan
uses: semgrep/semgrep-action@v1
with:
config: p/owasp-top-ten
- name: Upload SARIF results
uses: github/codeql-action/upload-sarif@v4
with:
sarif_file: semgrep.sarifCela intercepte une classe de vulnérabilités au moment de la pull request, avant que le code n'atteigne le staging. L'essentiel est que le build échoue — pas seulement qu'il produise un rapport. Une analyse qui s'exécute sans jamais rien bloquer n'est pas un contrôle bloquant ; c'est un générateur de rapports que personne ne lit.
Tous les résultats de sécurité ne justifient pas l'échec d'un build. Une politique de blocage pragmatique :
| Criticité | Action CI |
|---|---|
| CRITIQUE | Échec immédiat — blocage de la fusion |
| ÉLEVÉE | Échec — blocage de la fusion (avec processus de dérogation pour les exceptions) |
| MOYENNE | Avertissement — ne bloque pas, crée un ticket de suivi |
| FAIBLE / INFO | Journal uniquement — revu trimestriellement |
Le blocage sur les nouvelles découvertes uniquement évite un mode d'échec courant : une base de code avec 200 résultats préexistants de criticité moyenne ferait échouer chaque build si tous les résultats étaient bloquants. La plupart des plateformes CI/CD supportent un mode "nouvelles découvertes uniquement" qui compare par rapport au dernier commit sain. Commencez par là.
Le SAST intégré au CI couvre ce qui est visible dans le code source : patrons d'injection, secrets en dur, fonctions cryptographiques non sécurisées, appels d'API dangereux. Ce qu'il ne couvre pas : le comportement à l'exécution, les failles de logique métier, les échecs d'autorisation, et toute vulnérabilité qui ne se manifeste que lorsque le code s'exécute contre une vraie pile applicative.
C'est là que le DAST et les outils de pentest comblent le manque. La même logique de blocage s'applique — déclenchée sur un environnement de staging déployé, consommant des sorties SARIF, bloquant sur les résultats CRITIQUES.
- name: Trigger BreachVex scan
run: |
SCAN_ID=$(curl -sf -X POST https://api.breachvex.com/v1/scans \
-H "Authorization: Bearer ${{ secrets.BREACHVEX_API_KEY }}" \
-H "Content-Type: application/json" \
-d '{"target": "https://staging.yourapp.com"}' | jq -r '.id')
echo "SCAN_ID=$SCAN_ID" >> $GITHUB_ENV
- name: Wait for scan completion and download SARIF
run: |
# Poll until complete, then download
curl -sf "https://api.breachvex.com/v1/scans/$SCAN_ID/sarif" \
-H "Authorization: Bearer ${{ secrets.BREACHVEX_API_KEY }}" \
-o breachvex.sarif
- name: Upload to GitHub Code Scanning
uses: github/codeql-action/upload-sarif@v4
with:
sarif_file: breachvex.sarifL'implémentation technique est la partie facile. La partie difficile consiste à changer la propriété des défauts de sécurité.
Dans les modèles de sécurité traditionnels, un pentest trimestriel découvre des vulnérabilités, une équipe de sécurité rédige un rapport, et un ticket est créé pour l'équipe ingénierie afin de le corriger — à un moment indéterminé. La responsabilité est diffuse, les délais sont flous, et les résultats se perdent dans le backlog.
Le Shift Left change le modèle de propriété. Lorsqu'une vulnérabilité est découverte dans la pull request d'un développeur, c'est ce développeur qui en est responsable. Le cycle de correction est immédiat. Il n'y a pas de transfert entre sécurité et ingénierie. L'équipe de sécurité passe de la rédaction de rapports à la propriété de la chaîne d'outils : maintien des contrôles CI, calibrage du rapport signal/bruit, construction du processus de dérogation.
Les équipes qui opérationnalisent cela de manière constante constatent que la dette de sécurité cesse de s'accumuler. Le contrôle bloquant empêche l'introduction de nouvelles vulnérabilités en production. Le travail restant consiste à traiter le backlog préexistant — qui est fini et peut être suivi.