Politiques de Scanner¶
Une Politique de Scanner est un ensemble nommé et réutilisable de directives qui régissent le comportement des scanners auxquels elle est assignée. Une politique est définie une seule fois et peut ensuite être assignée à un nombre quelconque de scanners sur vos assets.
Actuellement, une directive est disponible : Correspondance de motifs de fichiers, qui restreint un scanner aux fichiers qu'il est censé couvrir. D'autres directives viendront étendre ce qu'une Politique de Scanner peut régir, et s'appliqueront aux politiques existantes sans changer leur mode de création ou d'assignation.
Les Politiques de Scanner permettent aux équipes de garder les scanners bruyants ou lents ciblés sur les fichiers qu'ils couvrent réellement. Par exemple, un scanner Infrastructure-as-Code peut être limité aux manifestes Terraform et Kubernetes, et un scanner SCA aux fichiers de verrouillage de dépendances, afin que les Pull Requests ne touchant ni l'un ni l'autre n'attendent pas une analyse qui n'a rien à analyser.
Les Politiques de Scanner sont gérées depuis la page Scanner Coverage → Scanner Policy.
Note
Les Politiques de Scanner constituent un concept distinct des Policies. Une Policy régit quelles constatations deviennent des violations et ce qui leur arrive ; une Politique de Scanner régit le comportement des scanners auxquels elle est assignée.
La Page des Politiques de Scanner¶
La page des Politiques de Scanner liste les politiques définies par Nom, avec le nombre de scanners que chacune régit sous Assigned Scanners. Le menu d'actions de chaque ligne propose une action Edit et une action Delete, et le bouton New Policy en crée une. Lorsqu'aucune politique n'existe encore, la page affiche « No scanner policies found ».
Une politique se compose d'un nom et des directives activées sur celle-ci. Les noms sont obligatoires et doivent être uniques ; l'enregistrement d'une politique dont le nom est déjà utilisé est rejeté.
Assigned Scanners¶
La colonne Assigned Scanners indique combien de scanners portent actuellement la politique, sous la forme « 1 scanner » ou « 4 scanners ».
Un nombre non nul est un lien, et le suivre ouvre la page Scanner Coverage filtrée sur cette politique. Un nombre égal à zéro reste un simple texte.
Note
La page filtrée peut afficher moins d'assets que le nombre indiqué, voire aucun. Ce nombre peut inclure des scanners sur des assets archivés ou orphelins, que la page Scanner Coverage ne liste pas. Un résultat vide à cet endroit est donc attendu et ne constitue pas une erreur.
Suppression d'une Politique¶
Une politique doit être retirée de tous les scanners auxquels elle est assignée avant de pouvoir être supprimée. Tant que son nombre d'Assigned Scanners est non nul, l'action Delete dans le menu d'actions de la ligne est grisée, et son infobulle en indique la raison :
This policy is still assigned to 13 scanners. Deprovision them in Scanner Coverage before deleting it.
This count can include scanners on archived or orphan assets, which Scanner Coverage does not list.
Ces scanners doivent être déprovisionnés, ou la politique doit en être retirée, avant que celle-ci puisse être supprimée — voir How to Limit a Scanner to Specific Files. L'action Delete devient disponible une fois que le nombre atteint zéro.
Directives¶
Le comportement d'une politique découle des directives activées sur son onglet Directives. Chaque directive est indépendante : elle s'active via une case à cocher, et son activation révèle les paramètres qu'elle nécessite. Une politique sans aucune directive activée n'a aucun effet sur les scanners auxquels elle est assignée.
Correspondance de motifs de fichiers est actuellement la seule directive disponible.
La Directive de Correspondance de Motifs de Fichiers¶
Cette directive restreint un scanner à un ensemble de fichiers. Un scanner régi par elle ne s'exécute que si les fichiers modifiés par l'analyse incluent une correspondance avec l'un de ses motifs — pour une Pull Request, tout fichier modifié par l'un quelconque de ses commits. Si rien ne correspond, l'analyse est ignorée et une vérification réussie est renvoyée au fournisseur de gestion de code source (SCM).
La directive est décrite dans l'onglet Directives comme suit :
Run the scanner only when a changed file's name matches one of the following patterns. Otherwise the scan is skipped (a passing check is still posted).
Son activation révèle le champ File patterns. Chaque ligne contient un motif, et il suffit qu'un fichier corresponde à l'un d'entre eux pour que le scanner s'exécute.
Warning
La désactivation de la directive File pattern matching efface les motifs qui y ont été saisis. Ils doivent être ressaisis si la directive est réactivée ultérieurement.
Syntaxe des Motifs¶
Un motif est comparé au nom de fichier de chaque fichier modifié — et non à son chemin complet — de sorte qu'un motif correspond à n'importe quelle profondeur dans le dépôt. *.tf correspond à main.tf ainsi qu'à infra/prod/eu-west-1/main.tf.
La correspondance est sensible à la casse : Dockerfile ne correspond pas à dockerfile.
Les caractères génériques suivants sont pris en charge :
| Caractère générique | Signification | Exemple | Correspond à |
|---|---|---|---|
* |
Toute séquence de caractères, y compris aucune | *.tf |
main.tf, modules/network/variables.tf |
? |
Exactement un caractère | v?.yaml |
v1.yaml, v2.yaml |
[seq] |
Tout caractère unique de la séquence | [Mm]akefile |
Makefile, makefile |
Une séquence peut également être niée sous la forme [!seq], correspondant à tout caractère unique absent de celle-ci. Les caractères sans signification particulière sont interprétés littéralement, ce qui suffit pour cibler un fichier spécifique par son nom :
| Motif | Correspond à | Ne correspond pas à |
|---|---|---|
Dockerfile |
Dockerfile, services/api/Dockerfile |
dockerfile, Dockerfile.dev |
*.lock |
poetry.lock, backend/Cargo.lock |
lockfile.txt |
package*.json |
package.json, package-lock.json |
packages.config |
requirements*.txt |
requirements.txt, requirements-dev.txt |
requirements.in |
Ce qui suit n'est pas pris en charge :
**n'a pas de signification particulière. C'est inutile, car tout motif correspond déjà à n'importe quelle profondeur.- Un motif contenant un
/ne correspond jamais, puisque les motifs sont comparés à des noms de fichiers plutôt qu'à des chemins. - Les motifs ne sont pas des expressions régulières.
Quand les Motifs Sont Évalués¶
Les motifs de fichiers sont évalués lors des analyses déclenchées par un commit, par rapport aux fichiers modifiés de cette Pull Request ou de cette plage de commits poussée. Les analyses ne disposant d'aucun ensemble de fichiers modifiés à comparer ne sont jamais ignorées.
| Analyse | Résultat |
|---|---|
| Scanner sans politique assignée | S'exécute |
| Analyse de Pull Request, un fichier modifié par l'un des commits correspond | S'exécute |
| Analyse de Pull Request, aucun fichier modifié ne correspond | Ignorée |
| Analyse de push sur une branche surveillée, un fichier modifié correspond | S'exécute |
| Analyse de push sur une branche surveillée, aucun fichier modifié ne correspond | Ignorée |
| Analyse déclenchée manuellement | S'exécute |
| Analyse complète ou première analyse d'un asset | S'exécute |
Analyses Ignorées¶
Une analyse ignorée par la directive File pattern matching reste néanmoins enregistrée, et demeure donc visible sur la page Scans.
Sur la page Scans, l'analyse porte un statut neutre Skipped by rules, et son développement affiche la raison « No files matched this scanner. »
Dans le SCM, Boost Security rapporte une vérification réussie nommée boostsecurity - <scanner> avec le titre Nothing to scan. Sur GitHub, il s'agit d'un check run avec une conclusion success ; sur GitLab, d'un statut de commit avec un état success. Une analyse ignorée ne bloque donc jamais une Pull Request exigeant que la vérification soit réussie.
Disponibilité¶
Les Politiques de Scanner ne sont proposées que pour les scanners provisionnés via l'Orchestration Zero Touch (ZTP). Le Boost Security Scanner n'accepte une politique que lorsque le ZTP est activé pour l'organisation ou l'intégration SCM. Un scanner ne pouvant pas recevoir de politique n'affiche aucun contrôle de politique dans l'assistant de provisionnement ni dans la modale Manage Scanner Policies.
Assignation d'une Politique¶
Les directives d'une politique prennent effet une fois la politique assignée à un scanner sur un asset. Les assignations se font soit à l'étape Scanner policies du provisionnement avancé, soit sans reprovisionnement via la modale Manage Scanner Policies sur la page Scanner Coverage. Consultez How to Limit a Scanner to Specific Files pour la procédure complète.
Les deux interfaces utilisent le même contrôle par scanner à trois états — No change, Apply, qui révèle une liste déroulante de politiques, et Clear, qui supprime l'assignation — accompagné d'un résumé des modifications en attente.
Le nom de la politique assignée s'affiche sous le scanner sur la page Scanner Coverage, aux côtés des autres paramètres de configuration du scanner.