Catégories de Règles de Politique¶

Lors de la création d'une nouvelle politique ou de la mise à jour d'une précédente, il existe des catégories de règles que vous pouvez définir lorsque vous ajoutez des règles à la politique. Les actions vous aident à définir des déclencheurs et des réponses pour les résultats sous cette règle.

Note

Une politique sans règles revient à l'action par défaut. Vous pouvez ajouter des règles à la politique pour définir des règles personnalisées avec des conditions de filtrage avancées pour les résultats.

Ces catégories pour votre politique incluent :

Score OpenSSF : Cette action vérifie l'OpenSSF. Le score OpenSSF est une collection de métriques de santé de sécurité pour le logiciel open source, permettant aux utilisateurs d'évaluer les pratiques de sécurité d'un paquet open source dans votre code.
Score EPSS : Cela peut être utilisé pour cibler l'EPSS dans votre code. EPSS (Exploit Prediction Scoring System) mesure la probabilité qu'une vulnérabilité particulière soit exploitée.
Score CVSS : Le CVSS génère un score de 0 à 10 basé sur la gravité d'une vulnérabilité.
Confiance : Cette action vérifiera les scénarios où le niveau de confiance d'une vulnérabilité est élevé, moyen ou faible.
Gravité : Cette action vérifie la gravité des résultats dans des états Critique, Avertissement ou Mineur.
Accessibilité Internet : Vérifie si un composant ou une ressource est accessible depuis Internet. Sa valeur est représentée comme Accessible.
Expositions de Code : Cette action examine la composition de votre code d'application, qu'il expose des composants clés tels que des APIs, ou l'utilisation de bibliothèques tierces risquées qui peuvent entraîner des violations de sécurité.
Problèmes de Risque Critique : Cette action cible les problèmes qui posent un risque critique pour votre environnement ou application. Cela inclut des vulnérabilités à haute gravité ou des configurations incorrectes qui nécessitent une attention immédiate.
Tags Manuels : Cette action évalue les ressources basées sur des tags manuels personnalisés assignés dans votre environnement.
Dépendance de Développement : Cette action détermine si une dépendance est uniquement utilisée lors du développement. Ses valeurs correspondantes sont Oui, Exécution, ou Inconnu.
Cluster Kubernetes : Cette action vérifie la configuration et la sécurité de vos clusters Kubernetes, s'assurant qu'ils sont configurés de manière sécurisée et selon les meilleures pratiques.
Service Kubernetes : Cette action évalue la configuration et la sécurité de vos services Kubernetes, garantissant qu'ils sont correctement configurés et sécurisés.
Classe de Vulnérabilité : Vérifie la classe ou la catégorie d'une vulnérabilité, aidant à regrouper et appliquer des règles en fonction de la nature du problème de sécurité (par ex., XSS, Injection, etc.).
Informations Personnelles : Cette action scanne pour des informations personnelles dans votre code, s'assurant que des données sensibles ne sont pas exposées par inadvertance.
Code Vulnérable Accessible : Cette action vérifie si la portion vulnérable du code est réellement accessible en temps d'exécution.
Drapeau de Dépôt : Cette action vérifie s'il existe des drapeaux spécifiques dans vos dépôts, ce qui peut indiquer certaines conditions ou états à traiter.
Étiquettes de Dépôt : Cette action examine les étiquettes assignées à vos dépôts, s'assurant qu'elles sont correctement étiquetées pour l'application et la gestion de la politique.
Langages de Dépôt : Cette action identifie les langages de programmation utilisés dans vos dépôts, aidant à faire respecter des politiques de sécurité spécifiques à chaque langage.
Visibilité de Dépôt : Cette action examine les paramètres de visibilité de vos dépôts, s'assurant qu'ils sont correctement réglés en public ou privé selon vos politiques de sécurité.
Accès Root : Cette action identifie les cas où des codes, scripts ou conteneurs s'exécutent avec des permissions de niveau root, ce qui pourrait introduire des risques de sécurité sérieux si non contrôlés.
Dépôt Forké : Cette action détermine si un dépôt est un fork d'un autre, ce qui peut influencer le niveau de confiance ou les processus de révision.
Accessibilité des Données Sensibles : Cette action évalue si des données sensibles dans votre système sont accessibles basé sur l'analyse du flux de code. Cela aide à identifier les cheminements potentiels qui pourraient exposer des informations confidentielles à un accès non autorisé.
Scanner : Cette action identifie les analyseurs utilisés pour vérifier votre code pour des vulnérabilités, s'assurant que les outils de scan appropriés sont en place et configurés correctement.
Type de Secret : Cette action spécifie le type de secret que la règle vérifie.
Validité du Secret : Cette action vérifie la validité d'un secret s'il est Valide, Invalide ou Inconnu.
États : Cette action examine les divers états des résultats et des vulnérabilités dans votre code, tels qu'ouvert, corrigé ou ignoré.
Vulnérabilité Transitive : Cette action vérifie les vulnérabilités héritées des dépendances de vos dépendances, garantissant une évaluation approfondie de la sécurité de votre code.
Identifiants de Vulnérabilité : Cette action examine les identifiants spécifiques associés aux vulnérabilités dans votre code, s'assurant que tous les problèmes connus sont suivis et traités.
Utilisateur Privilégié : Cette action cible les résultats associés aux utilisateurs ou comptes de service ayant des privilèges élevés. Elle permet de vérifier les politiques concernant les risques de contrôle d'accès ou d'attribution de permissions incorrectes.

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é, source ou 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 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 cohérent qui peut être évalué 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 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'intègrent 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 quelles constatations sont dans le périmètre
Actions de Politique – Appliquent des conditions à ces constatations
Réponse – Détermine ce qui se passe lorsque les conditions sont remplies

Vous pouvez concevoir les catégories comme la limite extérieure d'une règle.¶

Catégories vs Règles vs Actions¶

Il est important de faire la distinction entre 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 dans lesquelles la règle s'applique
Réponse	Définit ce qui se passe lorsque la règle se déclenche

Une catégorie n'impose pas de comportement par elle-même ; elle définit uniquement le champ d'application.¶

Catégories de règles de politique courantes¶

Les catégories de règles de politique s'alignent généralement avec le domaine de sécurité dans lequel une découverte existe. Des exemples incluent :

Tests de sécurité des applications statiques (SAST) - Découvertes liées aux vulnérabilités dans le code source de l'application.
Analyse de la composition logicielle (SCA) - Découvertes liées aux dépendances tierces et open-source.
Secrets - Découvertes liées aux identifiants, jetons ou clés exposés.
Infrastructure en tant que code (IaC) - Découvertes liées à des configurations cloud ou d'infrastructure non sécurisées.
Kubernetes - Découvertes liées à la sécurité des clusters, services ou charges de travail.

* Méthadonnées du dépôt et des actifs - Découvertes dérivées de la configuration du dépôt, de la visibilité, des étiquettes ou des indicateurs.¶

Mappage des catégories de règles de politique aux actions prises en charge¶

Chaque catégorie de règles de politique expose uniquement les actions qui sont sémantiquement et techniquement pertinentes pour le type de résultats qu'elle évalue.

Ce design garantit que les règles restent valides, prévisibles et alignées avec les données de sécurité sous-jacentes.

SAST (Test de Sécurité d'Application Statique)¶

Les règles SAST évaluent les vulnérabilités dans le code source de l'application.

Les actions généralement supportées incluent :

Gravité
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 la composition des logiciels)¶

Les règles SCA évaluent les risques introduits par les dépendances tierces et open-source.

Les actions généralement supportées incluent :

Gravité
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 d'origine

Secrets¶

Les règles de secrets évaluent l'exposition des informations d'identification sensibles dans le code et la configuration.

Les actions couramment prises en charge incluent :

Type de secret
Validité du secret
Gravité
Confiance
Informations personnelles
Analyseur
États
ID de règle d'origine

Kubernetes¶

Les règles Kubernetes évaluent la sécurité des clusters, des services et des workloads.

Les actions couramment prises en charge incluent :

Cluster Kubernetes
Service Kubernetes
Gravité
Confiance
Accessibilité Internet
Accès root
Problèmes de risque critique
Scanner
États
ID de règle original

Métadonnées du dépôt et des actifs¶

Les règles au niveau du dépôt évaluent les attributs contextuels et liés à la gouvernance.

Les actions couramment prises en charge incluent :

Visibilité du dépôt
Étiquettes du dépôt
Langages du dépôt
Drapeaux du dépôt
Dépôt forké
Étiquettes manuelles
Utilisateur privilégié

Sélectionner la bonne catégorie¶

Lorsque vous définissez 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.

Demandez-vous :

Ciblez-vous le code de l'application, les dépendances ou l'infrastructure ?
Ces constatations proviennent-elles d'un type de scanner spécifique ?
Ai-je besoin de contexte de vulnérabilité, de portée d'exécution ou de métadonnées du référentiel ?

Commencez par une large catégorie correcte, puis affinez le comportement en utilisant les actions de politique.¶

Meilleures Pratiques¶

Une intention par règle : Évitez de surcharger une seule règle avec des catégories non liées.
Utiliser des catégories pour séparer les préoccupations : Par exemple, traitez l'Orchestration Zero Touch et le SAST différemment même si les seuils de gravité sont similaires.
Aligner les catégories avec la propriété : Différentes équipes possèdent souvent différentes catégories (AppSec, Plateforme, DevOps).

* Garder les règles prévisibles : Une sélection claire des catégories rend les résultats de la politique plus faciles à expliquer et à défendre.¶

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 périmètre d'une règle
Assurent que seuls les résultats pertinents sont évalués
Permettent une application de politique cohérente et évolutive

Choisir la bonne catégorie est la fondation d'un design de politique efficace. Une fois la catégorie définie, les actions et réponses de politique peuvent être utilisées pour exprimer un comportement d'application précis.