Gates de politique : stoppez les vulnérabilités avant la production

Pourquoi les alertes ne suffisent pas

La plupart des outils de sécurité signalent après coup. Un résultat arrive dans un tableau de bord, quelqu'un le trie, un ticket part vers l'équipe responsable, et pendant ce temps la release continue d'avancer. Si le résultat a été manqué ou si le scan n'a jamais vu le paquet, la vulnérabilité est en production avant que quiconque n'ait pris de décision.

Les gates de politique peuvent aussi arrêter un build en temps réel, avant que la release n'aille plus loin.

Ce qu'une gate peut arrêter

Règle	Ce qui se passe
Résultats dans le build	Un build dont les résultats sont exclus par votre politique est bloqué.
Une CVE précise	Dès que votre équipe a décidé qu'une CVE ne doit pas être livrée, les builds qui la contiennent sont bloqués.
Une release malveillante connue	Une release malveillante avec une CVE publiée, comme xz, est signalée et peut être bloquée de la même manière.
Une licence	Les règles de politique de licence peuvent bloquer un build qui apporte une licence que vous avez exclue.

Une gate ne vaut que par ce qu'elle voit

Une gate fondée sur un scan de lockfile ne peut bloquer que ce que le lockfile liste. CRACI voit le trafic qui entre dans chaque build, et ses gates travaillent donc à partir de ce que le job a réellement récupéré :

• Les dépendances transitives à tous les niveaux. Voir les dépendances transitives.
• Les dépendances cachées, comme le code téléchargé par les scripts d'installation, les scripts de build Rust qui téléchargent pendant le build et l'image de base d'un build de conteneur.
• Les paquets restaurés depuis un cache CI, qui sont enregistrés et marqués comme mis en cache.

Chaque composant d'une SBOM CRACI était dans le build : une gate ne travaille donc jamais à partir d'un paquet seulement déduit. Pour le raisonnement, voir les SBOM générées au build.

Gates et politique de sortie ne font pas le même travail

Risque	Ce qui l'arrête
Une dépendance avec une CVE connue que vous avez exclue	Gate de politique
Une licence que vous avez exclue	Gate de politique
Une connexion vers un hôte dont le build n'a pas besoin	Politique de sortie, en refus par défaut
Un nouveau paquet malveillant sans avis publié	Non signalé tant qu'aucun avis n'existe. Une politique de sortie réglée en refus par défaut l'empêche tout de même d'envoyer vos secrets vers un hôte dont le build n'a pas besoin.

Quand une nouvelle CVE apparaît

1. CRACI réévalue les SBOM surveillées et signale ce qui est touché.
2. Votre équipe sécurité la trie et la transmet à l'équipe chargée de la correction.
3. L'historique des builds montre quels builds la contenaient, et donc pendant combien de temps vous avez été touché.
4. L'équipe responsable livre le correctif, et une gate de politique garde la CVE hors des builds suivants.

Le correctif reste entre vos mains. La gate s'assure qu'il tient dans la durée. Voir le suivi des vulnérabilités.

Ce que les gates ne font pas

• Pas d'analyse d'atteignabilité. Une gate se fonde sur la présence d'un paquet dans le build, pas sur le fait que votre code appelle ou non la fonction vulnérable.
• Pas de détection de malwares. Ce sont les avis qui pilotent la gate : elle n'intercepte donc pas un paquet malveillant tout nouveau.
• Pas de scan de code. Le SAST et le scan de secrets sont volontairement hors périmètre, et de nombreux excellents outils fonctionnent aux côtés de CRACI.

Gates de politique : questions fréquentes

Qu'est-ce qu'une gate de politique ?

Une règle qui arrête un build lorsqu'il enfreint votre politique. Au lieu de signaler un problème que quelqu'un traitera plus tard, la gate empêche le build d'aller plus loin.

Quelle différence entre une gate de politique et une alerte de scanner ?

Une alerte dépend de quelqu'un qui agit à temps. Une gate agit d'elle-même. Les gates de CRACI travaillent aussi à partir d'un enregistrement de ce que le build a récupéré : elles peuvent donc intercepter des paquets qu'un scan de lockfile ne verrait jamais.

Puis-je bloquer une CVE précise ?

Oui. Une gate de politique peut bloquer les builds qui contiennent une CVE précise, pour qu'une vulnérabilité sur laquelle votre équipe a tranché ne revienne pas dans un build ultérieur.

Une gate peut-elle bloquer une licence ?

Oui. Chaque paquet enregistré porte sa licence déclarée, et les règles de politique de licence peuvent bloquer un build sur une licence.

Une gate arrête-t-elle les nouveaux malwares ?

Pas à elle seule. Une release malveillante connue avec une CVE publiée est signalée comme toute autre vulnérabilité, et une gate peut bloquer les builds qui la contiennent. Un nouveau paquet malveillant n'est pas signalé tant qu'aucun avis n'existe. C'est une politique de sortie réglée en refus par défaut qui limite les dégâts pendant cette période.

Quels systèmes CI fonctionnent avec les gates de politique ?

GitHub Actions, sur les runners CRACI. Les autres systèmes CI figurent sur la roadmap.