La politique de sécurité, sous forme de code.
Écrivez votre exigence de sécurité une fois : chaque scan, chaque équipe et chaque pipeline la suivent.
policy.yamlOrganisationAppliquée
- BloquerAlertes SAST critiques
- BloquerInjection SQL sur une branche protégée
- AvertirCVSS 7.0 et plus
- ExcluRapports legacy, risque accepté
Écrite une fois. Appliquée à chaque merge.
policy.yamlévalué à chaque scan
name: Block Critical Vulnerabilitiesscope: ORGANIZATIONpriority: 50enabled: truerules: - name: Block Critical SAST Findings action: block criteria: - scanner_type eq SAST - severity eq CRITICALFixées une fois, héritées partout.
Le socle de votre organisation s'applique à chaque équipe et à chaque projet. Un projet peut le durcir, jamais l'assouplir.
AcmeOrganisation
Block Critical Vulnerabilitiesseverity eq CRITICAL → block- PaymentsÉquipehéritée
payments-apihéritéecheckout-webhéritée+ severity eq HIGH → blockplus stricte, jamais plus souple
- PlatformÉquipehéritée
infrahéritéedocs-sitehéritée
Commencez par un dépôt.
Connectez GitHub, GitLab, Bitbucket ou Azure DevOps, choisissez un dépôt, et le premier scan démarre.
En détail
Ce qu'une règle peut dire
Écrire la règle. Bloquer le merge. Tracer l'exception.
10 types de règles, 8 opérateurs, logique ET / OU. D'un simple seuil CVSS à un CWE précis sur une branche protégée.
policy.yamlOrganisationAppliquée
- BloquerAlertes SAST critiquesscanner_type eq SASTAND severity eq CRITICAL
- BloquerInjection SQL sur une branche protégéeCWE-89AND main
- AvertirCVSS 7.0 et plusCVSS 4.0
- ExcluRapports legacy, risque acceptélegacy/reports/**2026-12-31
10 types de règles, 8 opérateurs, logique ET / OU. D'un simple seuil CVSS à un CWE précis sur une branche protégée.
La gestion des politiques, en bref
Qu'est-ce que la politique de sécurité sous forme de code (policy as code) ?
Vos exigences de sécurité sont écrites en YAML versionné, à côté de votre code. CybeDefend évalue la politique en vigueur à chaque scan (SAST, SCA, secrets, conteneurs, IaC et CI/CD) : les règles suivent le dépôt.
Quelle est la différence entre bloquer et avertir ?
Bloquer arrête le pipeline et enregistre la violation. Avertir l'enregistre sans arrêter le pipeline : c'est la manière prudente de déployer une nouvelle règle avant de la rendre bloquante.
Comment fonctionne la hiérarchie organisation, équipe et projet ?
Les politiques s'appliquent en cascade, du haut vers le bas. L'organisation fixe un socle dont les équipes et les projets héritent et qu'ils ne peuvent que durcir : une exigence de l'entreprise n'est jamais contournée en silence.
L'évaluation des politiques ralentit-elle mon pipeline ?
Non. Les politiques sont évaluées de façon asynchrone, avec un délai d'expiration configurable : les scans et les déploiements n'attendent jamais le point de contrôle.
Puis-je faire une exception pour un fichier ou un risque accepté ?
Oui. Chaque politique accepte des exclusions ciblées par motif glob, avec une date d'expiration facultative, et vous pouvez marquer une alerte comme risque accepté, justification à l'appui. Dans les deux cas, une piste d'audit est conservée.