La notarisation ne bloque jamais.
La première étape, wisec_notify, collecte, signe et envoie le build, puis rend la main. Votre pipeline continue pendant que Wisec analyse.
Quelles règles un build doit-il respecter pour continuer, et qui en décide ?
Vous écrivez des politiques block ou warn pour votre organisation. Le gate de Wisec les applique dans votre pipeline, après l'analyse, et affiche ce qui a été enfreint.
La première étape, wisec_notify, collecte, signe et envoie le build, puis rend la main. Votre pipeline continue pendant que Wisec analyse.
En fin de pipeline, wisec-agent --gate interroge Wisec jusqu'à la fin de l'analyse, puis lit le résultat de vos politiques.
Un secret en dur, une CVE au-dessus de votre seuil, un fichier critique modifié, un contributeur non approuvé, un score sous votre minimum : le gate sort en erreur et affiche les violations.
Une vulnérabilité déclarée non affectée ou corrigée dans le VEX signé est retirée du gate. Le secret, lui, bloque toujours : il faut le retirer du code.
Chaque politique a une action : block fait échouer le gate, warn est journalisé sans échec. Elles se gèrent par organisation, par un administrateur.
| Politique | Évaluée | Se déclenche sur |
|---|---|---|
| secrets_detected | avant l'analyse | Un secret en dur détecté par gitleaks |
| critical_file_modified | avant l'analyse | La modification d'un fichier critique (configuration CI, Dockerfile…) |
| unapproved_contributor | avant l'analyse | Un auteur de commit absent de votre liste de contributeurs approuvés |
| cve_severity | après l'analyse | Une CVE d'une gravité au moins égale à votre seuil |
| risk_threshold | après l'analyse | Un score de sécurité du build sous votre minimum |
Le gate est le seul endroit où une politique bloque. Sans l'étape wisec_gate, aucune politique block ne fait échouer votre pipeline : le build est notarisé, rien de plus.
./wisec-agent --gate