Catégories de Règles de Politique¶
Les catégories de règles de politique définissent le type de résultats de sécurité auquel une règle de politique s'applique. Elles établissent le champ d'évaluation en regroupant les résultats en fonction de leur domaine de sécurité, de leur source ou de leur contexte opérationnel.
Qu'est-ce que les Catégories de Règles de Politique ?¶
Une catégorie de règle de politique représente une classe de résultats produite par les scanners et les intégrations de Boost Security.
Chaque catégorie regroupe des résultats qui partagent :
- Un domaine de sécurité commun (par exemple, code, dépendances, infrastructure)
- Des caractéristiques de risque similaires
- Un ensemble d'attributs constants pouvant être évalués par des actions de politique
En termes simples, une catégorie de règle de politique répond à la question :
Question
À quel type de résultats de sécurité cette règle s'applique-t-elle ?
Pourquoi les Catégories de Règles de Politique Sont-Elles Importantes ?¶
Les catégories de règles de politique fournissent structure et prévisibilité à l'application des politiques.
Pour les utilisateurs, les catégories rendent les politiques plus faciles à comprendre.
Comment les Catégories S'inscrivent Dans le Modèle de Politique¶
Les règles de politique dans Boost Security suivent un modèle d'évaluation en couches :
- Politique – Une collection de règles et une action par défaut
- Catégorie de Règle – Définit quels résultats sont dans le champ d'application
- Actions de Politique – Appliquent des conditions à ces résultats
- Réponse – Détermine ce qui se passe lorsque les conditions sont remplies
Vous pouvez considérer les catégories comme la limite externe d'une règle.
Catégories vs Règles vs Actions¶
Il est important de distinguer ces concepts étroitement liés :
| Concept | Objectif |
|---|---|
| Catégorie de Règle de Politique | Définit quel type de résultats est évalué |
| Règle de Politique | Regroupe une catégorie, des actions et une réponse |
| Actions de Politique | Définissent les conditions sous lesquelles la règle s'applique |
| Réponse | Définit ce qui se passe lorsque la règle est déclenchée |
Une catégorie n'impose pas de comportement par elle-même ; elle définit simplement le champ d'application.
Catégories Courantes de Règles de Politique¶
Les catégories de règles de politique s'alignent généralement avec le domaine de sécurité dans lequel un résultat existe. Des exemples incluent :
-
Tests de Sécurité des Applications Statique (SAST) - Résultats liés aux vulnérabilités dans le code source des applications.
-
Analyse de Composition Logicielle (SCA) - Résultats liés aux dépendances de tiers et aux logiciels en open source.
-
Secrets - Résultats liés aux identifiants exposés, aux tokens ou aux clés.
-
Infrastructure en tant que Code (IaC) - Résultats liés aux configurations cloud ou d'infrastructure non sécurisées.
-
Kubernetes - Résultats liés à la sécurité des clusters, des services ou des charges de travail.
-
Métadonnées de Dépôt et d'Actifs - Résultats dérivés de la configuration, de la visibilité, des étiquettes ou des indicateurs du dépôt.
Mapper les Catégories de Règles de Politique aux Actions Supportées¶
Chaque catégorie de règle de politique expose uniquement les actions qui sont sémantiquement et techniquement pertinentes pour le type de résultats qu'elle évalue.
Conception permet de s'assurer que les règles restent valides, prévisibles et alignées sur les données de sécurité sous-jacentes.
SAST (Tests de Sécurité des Applications Statique)¶
Les règles SAST évaluent les vulnérabilités dans le code source des applications.
Les actions supportées couramment incluent :
- Sévérité
- Confiance
- Score CVSS
- Score EPSS
- Classe de vulnérabilité
- Identifiants de vulnérabilité
- Code vulnérable atteint
- Accessibilité des données
- Scanner
- États
- ID de règle originale
SCA (Analyse de Composition Logicielle)¶
Les règles SCA évaluent les risques introduits par les dépendances de tiers et les logiciels en open source.
Les actions supportées couramment incluent :
- Sévérité
- Score CVSS
- Score EPSS
- Score OpenSSF
- Vulnérabilité transitive
- Dépendance de développement
- Accessibilité Internet
- Identifiants de vulnérabilité
- Scanner
- États
- ID de règle originale
Secrets¶
Les règles Secrets évaluent l'exposition de données sensibles dans le code et les configurations.
Les actions supportées couramment incluent :
- Type de secret
- Validité du secret
- Sévérité
- Confiance
- Information personnelle
- Scanner
- États
- ID de règle originale
Kubernetes¶
Les règles Kubernetes évaluent la sécurité des clusters, des services et des charges de travail.
Les actions supportées couramment incluent :
- Cluster Kubernetes
- Service Kubernetes
- Sévérité
- Confiance
- Accessibilité Internet
- Accès root
- Problèmes de risque critique
- Scanner
- États
- ID de règle originale
Métadonnées de Dépôt et d'Actifs¶
Les règles au niveau du dépôt évaluent des attributs contextuels et liés à la gouvernance.
Les actions supportées couramment incluent :
- Visibilité du dépôt
- Étiquettes du dépôt
- Langages du dépôt
- Indicateurs du dépôt
- Dépôt forké
- Tags manuels
- Utilisateur privilégié
Sélectionner la Bonne Catégorie¶
Lors de la définition d'une règle de politique, choisissez la catégorie en fonction de ce que vous souhaitez contrôler, et non de la manière dont vous souhaitez répondre.
Posez-vous les questions suivantes :
- Cible-je le code des applications, les dépendances ou l'infrastructure ?
- Ces résultats sont-ils produits par un type de scanner spécifique ?
- Ai-je besoin de contexte de vulnérabilité, d'accessibilité d'exécution ou de métadonnées de dépôt ?
Commencez de manière large avec la catégorie correcte, puis affinez le comportement à l'aide des actions de politique.
Meilleures Pratiques¶
-
Une intention par règle : Évitez de surcharger une seule règle avec des catégories non liées.
-
Utilisez des catégories pour séparer les préoccupations : Par exemple, traitez SCA et SAST différemment même si les seuils de sévérité sont similaires.
-
Alignez les catégories avec la propriété : Différentes équipes possèdent souvent différentes catégories (AppSec, Plateforme, DevOps).
-
Gardez les règles prévisibles : Une sélection claire de la catégorie facilite l'explication et la défense des résultats de la politique.
Résumé¶
Les catégories de règles de politique définissent ce qu'une règle évalue, pas comment elle réagit.
Elles :
- Établissent le champ d'application d'une règle
- Garantissent que seuls les résultats pertinents sont évalués
- Permettent une application cohérente et évolutive des politiques
Choisir la bonne catégorie est le fondement d'une conception de politique efficace. Une fois la catégorie définie, les actions de politique et les réponses peuvent être utilisées pour exprimer un comportement d'application précis.