AppSec Shift-Left: SAST, SCA et Secrets Scanning sans Bloquer l Equipe

Chaque fois qu un CISO annonce shift-left un jeudi, une equipe plateforme passe le week-end a retirer des gates du pipeline. La promesse d attraper les vulnerabilites avant le merge est reelle, mais l execution finit souvent en SAST avec 4 000 findings, en SCA hurlant sur une CVE de 2017 dans une lib de test, et en scanner de secrets qui plante parce que quelqu un a commit un .env.example. Le resultat est previsible: PRs ignorees, builds casses, devs frustres et securite reduite a de la bureaucratie. Chez Basilisk OffSec nous traitons l AppSec comme un produit interne, avec SLA, metriques de friction et un deploiement par etapes qui demarre en warning-only et termine en blocage chirurgical. Ce guide parcourt tout le chemin: definir la criticite, cabler SAST, SCA et scan de secrets pour qu ils gagnent la confiance, durcir le pipeline lui-meme et mesurer si l equipe respecte vraiment le resultat.

Ce que 'critique' veut vraiment dire: severite par contexte

Avant d installer le moindre outil, definis ce que tu appelles critique. Sans cette definition, Semgrep, Snyk et CodeQL vont se battre pour savoir qui alarme le plus, et chaque alerte portera le meme poids visuel quel que soit le rayon d impact. Prends le threat model du service comme base et classe les actifs en trois tiers. Un microservice tier-1 qui traite des PII ou de l argent n est pas la meme surface de risque qu un job batch interne qui lit une replica en lecture seule. Pour un service tier-1, toute CWE-89 (injection SQL) ou CWE-78 (injection de commande OS) detectee par SAST doit casser le build immediatement. Pour un job batch interne, un rapport hebdomadaire suffit peut-etre. Ce mapping severite-par-contexte reduit de 60 a 80 pour cent les faux positifs pertinents, selon les mesures de notre pilote a 12 squads en 2025. Le mapping n est pas un tableur que tu ecris une fois, mais un artefact de policy-as-code qui vit a cote du service et se revoit quand la classification des donnees change.

SAST sans fatigue d alerte

Le SAST seul ne resout rien. Combine Semgrep (regles YAML custom, peu cheres a maintenir, rapides sur les diffs) avec CodeQL pour les flux de donnees interproceduraux plus profonds en Java, C# et Go. Fais tourner Semgrep uniquement sur les fichiers modifies dans le check de PR et garde un scan d arbre complet chaque nuit, pour que la latence cote dev reste basse et la couverture complete. Demarre chaque nouvelle regle en mode comment-only sur GitHub: le bot poste le finding sur la PR sans faire echouer le check. Mesure deux choses pendant 30 jours: temps median entre commentaire et fix, et le taux de wont-fix. Si wont-fix depasse 40 pour cent, c est ta baseline de regles qui est fausse, pas l equipe. Apres cette fenetre, ne promeus en gate bloquant que les regles dont la precision depasse 85 pour cent. La precision se mesure, elle ne se suppose pas: prends 30 findings, fais qu un ingenieur etiquette chacun comme vrai ou faux positif et calcule le ratio avant de passer le gate au rouge.

Configuration concrete a copier

Un gate Semgrep minimal ressemble a semgrep ci --config auto --baseline-commit $(git merge-base origin/main HEAD), qui ne scanne que ce que la branche introduit et supprime la dette preexistante pour ne pas bloquer une PR pour des peches de l an dernier. Une regle custom, c est quelques lignes de YAML: un pattern comme pattern: exec.Command($CMD, ...) avec un metavariable-pattern qui marque un input tainte atteignant l argument, tague severity: ERROR et mappe a CWE-78. Pour CodeQL, cable l action officielle avec languages: java et laisse-la publier dans l onglet code-scanning, pour que les findings se dedupliquent contre Semgrep au lieu de doubler le bruit. Garde chaque regle dans un depot versionne avec une entree CODEOWNERS, pour qu un changement de regle soit lui-meme une PR revue et jamais un basculement silencieux de politique qui surprend un squad le lundi matin.

SCA et le probleme de reachability

Le SCA est l endroit ou la plupart des equipes trebuchent. Trivy, Grype et osv-scanner sont solides, mais chacun va remonter des centaines de CVE transitives dans des dependances que tu n appelles jamais. La seule metrique qui compte est la reachability. Une CVE dans un chemin de code que ton service n execute jamais est un item de backlog, pas un casse-build. Utilise Endor Labs, Socket ou osv-scanner avec le flag --experimental-call-analysis pour filtrer les CVE sur des fonctions non invoquees, et ne mets en gate que les findings atteignables, corrigeables et de severite haute ou critique. Combine avec un SBOM signe au build (syft ou trivy sbom) et une politique de quarantaine qui bloque une version fraichement publiee pendant 48 heures, ce qui neutralise la plupart des attaques de release malveillante sur la supply chain. N oublie pas le typosquatting et le namespace hijacking: un proxy interne comme Artifactory ou Nexus avec allowlist resout 90 pour cent du risque de dependency confusion en refusant de resoudre des noms internes inconnus contre le registre public.

Scan de secrets et le reflexe de rotation

Le scan de secrets est la victoire rapide que beaucoup ratent. Gitleaks et TruffleHog sur un hook de pre-commit attrapent la fuite avant le push, mais un hook local est consultatif et facilement contourne avec --no-verify, il te faut donc un second scanner cote serveur: GitHub Advanced Security push protection, ou Gitleaks en Action requise. Le modele mental critique: des qu un secret atterrit sur un commit pushe, considere-le comme public, point. Force la rotation; ne reecris pas l historique en pretendant que c est corrige. En 2025 nous avons vu 3 incidents ou des equipes ont brule des heures sur git filter-repo pendant que la cle AWS exposee servait deja a lancer des instances de minage. Garde un runbook automatise qui revoque la credential en moins de 5 minutes, invalide les sessions dependantes et ouvre un ticket de post-mortem. Le mode secrets verifies de TruffleHog, qui teste si une cle trouvee est vivante, vaut la minute supplementaire car il permet de trier par exposition reelle plutot que par nombre de correspondances regex.

Durcir le pipeline lui-meme

Un scanner n est fiable que si le runner sur lequel il s execute l est. Utilise des runners ephemeres a usage unique, pour qu un job compromis ne persiste pas dans le build suivant. Remplace les credentials cloud a longue duree par une federation OIDC a courte duree: le job CI echange son token d identite signe contre un role cloud scope de quelques minutes, si bien qu il n y a aucun AWS_SECRET_ACCESS_KEY statique a fuir. Epingle les actions tierces sur un SHA de commit complet plutot que sur un tag flottant, car un tag peut etre repointe vers du code malveillant apres ton audit. Definis explicitement des permissions de token a moindre privilege (permissions: contents: read) au lieu d heriter de defauts larges. Signe les artefacts de build et les images de conteneur avec Sigstore cosign et verifie la signature a l admission, pour que le pipeline qui a scanne le code prouve aussi ce qui a ete livre. L outillage de securite ne doit pas devenir la cible la plus molle sur le chemin de la production.

Deploiement par etapes: de warning a blocking

Ne bascule pas tout en bloquant le jour un. Phase un: observer. Chaque outil tourne, rien ne casse le build, et tu collectes des baselines de volume de findings, de precision et de latence de fix. Phase deux: avertir sur le neuf, ignorer le vieux. L astuce du baseline-commit fait que seuls les problemes fraichement introduits emergent, alignant le signal sur ce que le dev vient d ecrire. Phase trois: bloquer uniquement l ensemble etroit de findings a haute precision, haute severite et atteignables, et rien d autre. Publie ouvertement les criteres de promotion, pour qu un squad puisse predire exactement ce qui va commencer a echouer et quand. Donne a chaque gate une sortie de secours avec piste d audit: une exception documentee et expirante approuvee par l owner du service, pas un bypass silencieux. Une exception visible, limitee dans le temps et revue est une feature; un bypass que personne ne voit est la maniere dont les gates pourrissent vers l etat qui a fait annoncer shift-left au CISO au depart.

Metriques de friction et SLA interne

Les metriques de friction separent l AppSec fonctionnelle du theatre de securite. Suis quatre KPI par squad: temps median du pipeline securite (cible sous 4 minutes), taux de rerun cause par des scanners flaky (cible sous 5 pour cent), MTTR des findings critiques (cible sous 7 jours), et NPS interne des equipes produit sur l outillage. Si le NPS passe sous zero, mets en pause l expansion et enquete avant d ajouter un scanner de plus. Traite les propres promesses de l equipe plateforme comme un SLA: temps de reponse de triage pour un nouveau critique, uptime du service de scan et un budget maximal de latence ajoutee au check de PR. Ajoute des sessions purple team mensuelles sur des flux reels pour verifier que ce que le SAST trouve correspond a ce qu un attaquant exploiterait vraiment; un finding de linter sans chemin d exploitation est une regle a retrograder, et une faille exploitee que le linter a ratee est une regle a ecrire.

Pieges frequents

Les echecs recurrents sont d une constance ennuyeuse. Bloquer sur tout le backlog historique au lieu du diff, ce qui punit le mauvais dev. Mettre en gate des CVE non atteignables, ce qui entraine tout le monde a cliquer ignorer par reflexe jusqu a ignorer aussi l atteignable. Stocker des commentaires de suppression sans expiration, si bien qu un waiver temporaire devient une cecite permanente. Faire tourner le scan de secrets uniquement cote client et faire confiance au hook. Laisser le pipeline securite tourner sur un runner avec des credentials de production attaches. Mesurer le volume de findings comme si plus d alertes signifiait plus de securite, alors que le vrai but est un flux bas, fiable et traite. Et le plus humain: livrer l outillage sans un canal ou un dev peut dire cette regle est fausse et obtenir une reponse rapide et respectueuse. Chacun de ces points transforme un controle defendable en ce que les equipes contournent.

Une checklist livrable

Avant de declarer le rollout termine, confirme ce qui suit. Tiers d actifs definis et stockes en policy-as-code. SAST tournant en scope de diff sur les PR avec scan complet nocturne, nouvelles regles demarrant en comment-only. SCA en gate uniquement sur les CVE atteignables, corrigeables et de severite haute ou critique, avec SBOM signe par build et fenetre de quarantaine sur les nouveaux releases. Un proxy interne de paquets avec allowlist contre la dependency confusion. Scan de secrets impose cote serveur avec push protection, plus un runbook automatise revoquer-et-tourner sous 5 minutes. Runners ephemeres, OIDC au lieu de cles cloud statiques, actions epinglees par SHA, tokens a moindre privilege et artefacts signes-et-verifies. Quatre KPI de friction en dashboard par squad avec SLA publie. Exceptions documentees, expirantes et auditees. Si une ligne manque, tu as un deploiement de scanner, pas un programme d AppSec.

FAQ

SAST ou SCA doit-il bloquer en premier? Commence par le SCA sur les critiques atteignables, car les findings de dependances ont souvent un fix clair et peu couteux (monter une version) et une histoire propre de vrai positif, si bien que le premier gate bloquant gagne la confiance plutot que le ressentiment. Le blocage SAST vient apres avoir mesure la precision par regle, car un gate SAST bruyant est le moyen le plus rapide de perdre la salle.

Comment gerer un secret deja dans l historique git? Tourne d abord, toujours, et traite la valeur comme compromise des l instant du push. Reecrire l historique avec git filter-repo est du menage que tu fais apres la rotation pour reduire l exposition future, jamais la reponse a incident elle-meme. Automatise le chemin de revocation pour que le temps moyen de rotation soit en minutes, pas les heures que coute une gymnastique manuelle pendant que la cle est abusee.

Le takeaway pratique est simple: ne bascule pas tout en bloquant le jour un. Commence en warning, definis la criticite par contexte, durcis le pipeline qui scanne, mesure la friction, et ne promeus que les regles a precision prouvee. Six mois plus tard, tu auras un pipeline que les devs respectent parce qu il se trompe rarement, et quand il alarme, ca vaut le coup de regarder. C est ca le vrai shift-left, pas du shift-blame.