doc-locale/fr-fr/user/application_security/policies/scan_execution_policies.md
{{< details >}}
{{< /details >}}
{{< history >}}
scan_execution_policy_pipelines. Feature flag scan_execution_policy_pipelines supprimé dans GitLab 16.5.allow_restricted_variables_at_policy_level. Activé par défaut. Feature flag allow_restricted_variables_at_policy_level supprimé dans GitLab 17.5.{{< /history >}}
Les politiques d'exécution de scan appliquent les scans de sécurité GitLab sur la base des templates CI/CD de sécurité par défaut ou les plus récents. Vous pouvez déployer des politiques d'exécution de scan dans le cadre du pipeline ou selon une planification définie.
Les politiques d'exécution de scan appliquent des scans de sécurité sur tous les projets liés au projet de politique de sécurité. Pour les projets sans fichier .gitlab-ci.yml, ou les projets pour lesquels AutoDevOps est désactivé, les politiques de sécurité créent implicitement le fichier .gitlab-ci.yml. Le fichier .gitlab-ci.yml garantit que les politiques qui exécutent la détection des secrets, l'analyse statique ou d'autres scanners ne nécessitant pas de build dans le projet peuvent toujours s'exécuter et être appliquées.
Les politiques d'exécution de scan et les politiques d'exécution de pipeline peuvent toutes deux configurer des scans de sécurité GitLab sur plusieurs projets pour gérer la sécurité et la conformité. Les politiques d'exécution de scan sont plus rapides à configurer, mais ne sont pas personnalisables. Si l'un des cas suivants s'applique, utilisez plutôt les politiques d'exécution de pipeline :
Pour créer une politique d'exécution de scan, vous pouvez utiliser l'une des ressources suivantes :
type: schedule) s'exécutent uniquement selon leur cadence planifié. La mise à jour d'une politique ne déclenche pas un scan immédiat.Les scans DAST s'exécutent toujours dans l'étape dast. Si l'étape dast n'existe pas, GitLab injecte une étape dast à la fin du pipeline.
Les jobs de politique pour tous les autres scans s'exécutent dans l'étape test du pipeline. Si vous supprimez l'étape test du pipeline par défaut, les jobs s'exécutent dans l'étape scan-policies à la place, selon ces règles :
scan-policies n'existe pas encore, GitLab injecte l'étape dans le pipeline CI/CD au moment de l'évaluation.build existe, GitLab injecte scan-policies immédiatement après l'étape build.build n'existe pas, GitLab injecte scan-policies au début du pipeline.Pour éviter les conflits de noms de jobs, un trait d'union et un numéro sont ajoutés au nom du job. Chaque numéro est une valeur unique pour chaque action de politique. Par exemple, secret-detection devient secret-detection-1.
{{< history >}}
Merge Request Security Template :
flexible_scan_execution. Désactivé par défaut.flexible_scan_execution a été supprimé.{{< /history >}}
Utilisez l'éditeur de politiques d'exécution de scan pour créer ou modifier une politique d'exécution de scan.
Prérequis :
Lorsque vous créez vos premières politiques d'exécution de scan, choisissez parmi ces modèles pour les cas d'utilisation courants :
main ou de release.Si les modèles disponibles ne répondent pas à vos besoins, ou si vous avez besoin de politiques d'exécution de scan plus personnalisées, vous pouvez :
Une fois votre politique complète, enregistrez-la en sélectionnant Configurer avec une requête de fusion en bas de l'éditeur. Vous êtes redirigé vers la merge request sur le projet de politique de sécurité configuré du projet. Si aucun projet de politique de sécurité n'est lié à votre projet, GitLab en crée un automatiquement. Vous pouvez supprimer des politiques existantes depuis l'interface de l'éditeur en sélectionnant Supprimer une politique en bas de l'éditeur. Cette action crée une merge request pour supprimer la politique de votre fichier policy.yml.
La plupart des modifications de politique prennent effet dès que la merge request est fusionnée. Toute modification commitée directement sur la branche par défaut plutôt que via une merge request peut nécessiter jusqu'à 10 minutes avant que les modifications de politique prennent effet.
[!note] Pour les politiques d'exécution DAST, la manière dont vous appliquez les profils de site et de scanner dans l'éditeur en mode règle dépend de l'endroit où la politique est définie :
- Pour les politiques dans les projets, dans l'éditeur en mode règle, choisissez parmi une liste de profils déjà définis dans le projet.
- Pour les politiques dans les groupes, vous devez saisir les noms des profils à utiliser. Pour éviter les erreurs de pipeline, des profils avec des noms correspondants doivent exister dans tous les projets du groupe.
Une configuration YAML avec des politiques d'exécution de scan consiste en un tableau d'objets correspondant au schéma de politique d'exécution de scan. Les objets sont imbriqués sous la clé scan_execution_policy. Vous pouvez configurer un maximum de cinq politiques sous la clé scan_execution_policy. Toutes les autres politiques configurées après les cinq premières ne sont pas appliquées.
Lorsque vous enregistrez une nouvelle politique, GitLab valide le contenu de la politique par rapport à ce schéma JSON. Si vous n'êtes pas familier avec les schémas JSON, les sections et tableaux suivants constituent une alternative.
| Champ | Type | Obligatoire | Valeurs possibles | Description |
|---|---|---|---|---|
scan_execution_policy | array de politique d'exécution de scan | true | Liste des politiques d'exécution de scan (maximum 5) |
{{< history >}}
scan_execution_policy_action_limit (pour les projets) et scan_execution_policy_action_limit_group (pour les groupes). Désactivé par défaut.scan_execution_policy_action_limit (pour les projets) et scan_execution_policy_action_limit_group (pour les groupes) supprimés.{{< /history >}}
| Champ | Type | Obligatoire | Description |
|---|---|---|---|
name | string | true | Nom de la politique. Maximum 255 caractères. |
description | string | false | Description de la politique. |
enabled | boolean | true | Flag pour activer (true) ou désactiver (false) la politique. |
rules | array de règles | true | Liste des règles que la politique applique. |
actions | array d'actions | true | Liste des actions que la politique applique. Limité à un maximum de 10 dans GitLab 18.0 et versions ultérieures. |
policy_scope | object de policy_scope | false | Définit la portée de la politique en fonction des projets, groupes ou labels de framework de conformité que vous spécifiez. |
skip_ci | object de skip_ci | false | Définit si les utilisateurs peuvent appliquer la directive skip-ci. |
no_pipeline | object de no_pipeline | false | Définit si les utilisateurs peuvent appliquer la directive no_pipeline. |
skip_ci {#skip_ci-type}{{< history >}}
{{< /history >}}
Les politiques d'exécution de scan offrent un contrôle sur les utilisateurs autorisés à utiliser la directive [skip ci]. Vous pouvez spécifier certains utilisateurs ou comptes de service autorisés à utiliser [skip ci] tout en garantissant que les vérifications critiques de sécurité et de conformité sont effectuées.
Utilisez le mot-clé skip_ci pour spécifier si les utilisateurs sont autorisés à appliquer la directive skip_ci pour ignorer les pipelines. Lorsque le mot-clé n'est pas spécifié, la directive skip_ci est ignorée, empêchant tous les utilisateurs de contourner les politiques d'exécution de pipeline.
| Champ | Type | Valeurs possibles | Description |
|---|---|---|---|
allowed | boolean | true, false | Flag pour autoriser (true) ou empêcher (false) l'utilisation de la directive skip-ci pour les pipelines avec des politiques d'exécution de pipeline appliquées. |
allowlist | object | users | Spécifiez les utilisateurs toujours autorisés à utiliser la directive skip-ci, indépendamment du flag allowed. Utilisez users: suivi d'un tableau d'objets avec des clés id représentant les identifiants des utilisateurs. |
[!note] Les politiques d'exécution de scan ayant le type de règle
scheduleignorent toujours l'optionskip_ci. Les scans planifiés s'exécutent aux heures configurées, indépendamment du fait que[skip ci](ou l'une de ses variantes) apparaisse dans le dernier message de commit. Cela garantit que les scans de sécurité s'effectuent selon un calendrier prévisible, même lorsque les pipelines CI/CD sont ignorés.
no_pipeline {#no_pipeline-type}Les politiques d'exécution de scan offrent un contrôle sur les utilisateurs autorisés à utiliser la directive [no_pipeline]. Vous pouvez spécifier certains utilisateurs ou comptes de service autorisés à utiliser [no_pipeline] tout en garantissant que les vérifications critiques de sécurité et de conformité sont effectuées.
Utilisez le mot-clé no_pipeline pour spécifier si les utilisateurs sont autorisés à appliquer la directive no_pipeline pour ne pas créer de pipeline lors d'un push. Lorsque le mot-clé n'est pas spécifié, la directive no_pipeline est ignorée, empêchant tous les utilisateurs de contourner les politiques d'exécution de pipeline.
| Champ | Type | Valeurs possibles | Description |
|---|---|---|---|
allowed | boolean | true, false | Flag pour autoriser (true) ou empêcher (false) l'utilisation de la directive no_pipeline pour les pipelines avec des politiques d'exécution de pipeline appliquées. |
allowlist | object | users | Spécifiez les utilisateurs toujours autorisés à utiliser la directive no_pipeline, indépendamment du flag allowed. Utilisez users: suivi d'un tableau d'objets avec des clés id représentant les identifiants des utilisateurs. |
[!note] Les politiques d'exécution de scan ayant le type de règle
scheduleignorent toujours l'optionno_pipeline. Les scans planifiés s'exécutent aux heures configurées, indépendamment du fait que[no_pipeline](ou l'une de ses variantes) apparaisse dans le dernier message de commit. Cela garantit que les scans de sécurité s'effectuent selon un calendrier prévisible, même lorsque les pipelines CI/CD ne sont pas créés.
pipeline {#pipeline-rule-type}{{< history >}}
branch_type :
security_policies_branch_type.security_policies_branch_type a été supprimé.branch_exceptions :
security_policies_branch_exceptions.security_policies_branch_exceptions a été supprimé.pipeline_sources et les options branch_type target_default et target_protected :
flexible_scan_execution.flexible_scan_execution a été supprimé.{{< /history >}}
Cette règle applique les actions définies chaque fois que le pipeline s'exécute pour une branche sélectionnée.
| Champ | Type | Obligatoire | Valeurs possibles | Description |
|---|---|---|---|---|
type | string | true | pipeline | Type de la règle. |
branches <sup>1</sup> | array de string | true si le champ branch_type n'existe pas | * ou le nom de la branche | La branche à laquelle s'applique la politique donnée (prend en charge les caractères génériques). Pour la compatibilité avec les politiques d'approbation des merge requests, vous devez cibler toutes les branches pour inclure les scans dans la branche de fonctionnalité et la branche par défaut |
branch_type <sup>1</sup> | string | true si le champ branches n'existe pas | default, protected, all, target_default <sup>2</sup>, ou target_protected <sup>2</sup> | Les types de branches auxquels s'applique la politique donnée. |
branch_exceptions | array de string | false | Noms des branches | Branches à exclure de cette règle. |
pipeline_sources <sup>2</sup> | array de string | false | api, chat, external, external_pull_request_event, merge_request_event <sup>3</sup>, pipeline, push <sup>3</sup>, schedule, trigger, unknown, web | La source du pipeline qui détermine le moment où le job d'exécution de scan se déclenche. Consultez la documentation pour plus d'informations. |
branches soit branch_type, mais pas les deux.flexible_scan_execution activé. Consultez l'historique pour plus de détails.target_default ou target_protected de branch_type sont spécifiées, le champ pipeline_sources ne prend en charge que les champs merge_request_event et push.schedule {#schedule-rule-type}{{< history >}}
branch_type :
security_policies_branch_type.branch_exceptions :
security_policies_branch_exceptions.scan_execution_pipeline_worker pour les scans planifiés afin de créer des pipelines :
scan_execution_pipeline_worker a été supprimé.security_policy_scheduled_scans_max_concurrency :
scan_execution_pipeline_worker et scan_execution_pipeline_concurrency_control sont tous les deux activés.security_policy_scheduled_scans_max_concurrency dans GitLab 17.11.scan_execution_pipeline_concurrency_control.scan_execution_pipeline_concurrency_control a été supprimé.{{< /history >}}
[!warning] Dans GitLab 16.1 et versions antérieures, vous ne devez pas utiliser le transfert direct avec des politiques d'exécution de scan planifiées. Si vous devez utiliser le transfert direct, mettez d'abord à niveau vers GitLab 16.2 et assurez-vous que les bots de politique de sécurité sont activés dans les projets que vous appliquez.
Utilisez le type de règle schedule pour exécuter des scanners de sécurité selon une planification.
Un pipeline planifié :
.gitlab-ci.yml du projet.cadence.security_policy_bot dans le projet, avec le rôle Invité et les permissions pour créer des pipelines et lire le contenu du dépôt depuis un job CI/CD. Ce compte est créé lorsque la politique est liée à un groupe ou à un projet.schedule d'une politique d'exécution de scan sont appliquées. Les règles dépassant la limite n'ont aucun effet.| Champ | Type | Obligatoire | Valeurs possibles | Description |
|---|---|---|---|---|
type | string | true | schedule | Type de la règle. |
branches <sup>1</sup> | array de string | true si le champ branch_type ou agents n'existe pas | * ou le nom de la branche | La branche à laquelle s'applique la politique donnée (prend en charge les caractères génériques). |
branch_type <sup>1</sup> | string | true si le champ branches ou agents n'existe pas | default, protected ou all | Les types de branches auxquels s'applique la politique donnée. |
branch_exceptions | array de string | false | Noms des branches | Branches à exclure de cette règle. |
cadence | string | true | Expression cron avec des options limitées. Par exemple, 0 0 * * * crée une planification pour s'exécuter chaque jour à minuit (00 h 00). | Chaîne séparée par des espaces contenant cinq champs représentant l'heure planifiée. |
timezone | string | false | Identifiant de fuseau horaire (par exemple, America/New_York) | Fuseau horaire à appliquer à la cadence. La valeur doit être un identifiant de base de données de fuseaux horaires IANA. |
time_window | object | false | Paramètres de distribution et de durée pour les scans de sécurité planifiés. | |
agents <sup>1</sup> | object | true si le champ branch_type ou branches n'existe pas | Le nom des agents GitLab pour Kubernetes où le scan de conteneurs opérationnel s'exécute. La clé d'objet est le nom de l'agent Kubernetes configuré pour votre projet dans GitLab. |
branches, branch_type ou agents.Utilisez le champ cadence pour planifier le moment où vous souhaitez que les actions de la politique s'exécutent. Le champ cadence utilise la syntaxe cron, mais avec certaines restrictions :
0 18 * * *0 13 * * 0Tenez compte des points suivants lors du choix d'une valeur pour le champ cadence :
Lors de l'utilisation du type de règle schedule avec le champ agents :
cadence définie.Lors de l'utilisation du type de règle schedule avec le champ branches :
agent {#agent-schema}Utilisez ce schéma pour définir les objets agents dans le type de règle schedule.
| Champ | Type | Obligatoire | Description |
|---|---|---|---|
namespaces | array de string | true | L'espace de nommage qui est scanné. Si vide, tous les espaces de nommage sont scannés. |
agent {#agent-example}- name: Enforce container scanning in cluster connected through my-gitlab-agent for default and kube-system namespaces
enabled: true
rules:
- type: schedule
cadence: '0 10 * * *'
agents:
<agent-name>:
namespaces:
- 'default'
- 'kube-system'
actions:
- scan: container_scanning
Les clés d'une règle de planification sont :
cadence (obligatoire) : une expression Cron indiquant quand les scans s'exécutent.agents:<agent-name> (obligatoire) : Le nom de l'agent à utiliser pour le scan.agents:<agent-name>:namespaces (facultatif) : Les espaces de nommage Kubernetes à scanner. Si omis, tous les espaces de nommage sont scannés.time_window {#time_window-schema}Définissez la distribution des scans planifiés dans le temps avec l'objet time_window dans le type de règle schedule. Vous pouvez configurer time_window uniquement en mode YAML de l'éditeur de politique.
| Champ | Type | Obligatoire | Description |
|---|---|---|---|
distribution | string | true | Modèle de distribution pour les scans planifiés. Ne prend en charge que random, où les scans sont distribués aléatoirement dans l'intervalle défini par la clé value de time_window. |
value | integer | true | La fenêtre temporelle en secondes pendant laquelle les scans planifiés doivent s'exécuter. Saisissez une valeur comprise entre 3600 (1 heure) et 2629746 (environ 30 jours). |
time_window {#time_window-example}- name: Enforce container scanning with a time window of 1 hour
enabled: true
rules:
- type: schedule
cadence: '0 10 * * *'
time_window:
value: 3600
distribution: random
actions:
- scan: container_scanning
Lorsqu'une politique applique des pipelines planifiés sur plusieurs projets et branches, les pipelines s'exécutent simultanément. La première exécution d'un pipeline planifié dans chaque projet crée un utilisateur bot de sécurité chargé d'exécuter les planifications pour ce projet.
Pour optimiser les performances des projets à grande échelle :
tag spécifié. Envisagez de configurer un runner dédié dans chaque projet pour gérer les planifications appliquées par une politique afin de réduire l'impact sur les autres runners.Les politiques d'exécution de scan planifiées prennent en charge la planification mensuelle en utilisant le champ cadence avec des expressions cron. Vous pouvez configurer time_window jusqu'à 2629746 secondes (environ 30 jours) pour distribuer aléatoirement les scans sur cette période.
Par exemple, pour planifier des scans mensuels avec une fenêtre de distribution de 30 jours :
rules:
- type: schedule
cadence: '0 0 1 * *' # Run on the first day of each month
time_window:
value: 2592000 # 30 days in seconds
distribution: random
Les scans planifiés conservent la trace de leur prochaine heure d'exécution. Après un scan réussi, le système met à jour la date à laquelle le prochain scan doit s'exécuter. Si l'instance GitLab est indisponible pendant une heure de scan planifiée (en raison d'une maintenance, d'une panne ou d'un redémarrage), le système identifie les scans qui auraient dû déjà s'exécuter mais ne l'ont pas fait, et crée des pipelines lorsque l'instance redevient disponible.
Lorsque vous supprimez un projet, tous les scans planifiés associés sont également supprimés. Aucun pipeline ne s'exécute pour les projets supprimés.
Pour annuler un scan planifié, vous disposez de deux options :
enabled: false dans l'éditeur de politique pour désactiver la politique d'exécution de scan. Les scans déjà en cours d'exécution ou dont l'exécution est planifiée dans les 15 prochaines minutes (environ) peuvent tout de même s'exécuter.Lorsque vous déployez des politiques d'exécution de scan planifiées sur de nombreux projets, tenez compte des recommandations suivantes :
time_window : Définissez toujours le paramètre time_window dans vos politiques planifiées. Sans cela, tous les pipelines sont planifiés au même moment, ce qui peut entraîner des problèmes de performances et une contention des ressources.Pour plus d'informations sur l'optimisation des scans planifiés, voir optimiser les pipelines planifiés pour les projets à grande échelle.
GitLab applique le contrôle de la concurrence lorsque vous définissez la propriété time_window.
Le contrôle de la concurrence distribue les pipelines planifiés selon les paramètres time_window définis dans la politique.
scan {#scan-action-type}{{< history >}}
security_policies_variables_precedence. Activé par défaut.security_policies_variables_precedence a été supprimé.scan_execution_policies_with_latest_templates. Désactivé par défaut.scan_execution_policies_with_latest_templates_group. Désactivé par défaut.scan_execution_policies_with_latest_templates et scan_execution_policies_with_latest_templates_group ont été supprimés.v2 pour dependency_scanning introduite dans GitLab 18.4.dependency_scanning modifié en v2 pour les nouvelles politiques dans GitLab 19.1.{{< /history >}}
Cette action exécute le scan sélectionné avec des paramètres supplémentaires lorsque les conditions d'au moins une règle dans la politique définie sont remplies.
| Champ | Type | Valeurs possibles | Description |
|---|---|---|---|
scan | string | sast, sast_iac, dast, secret_detection, container_scanning, dependency_scanning | Type de l'action. |
site_profile | string | Nom du profil de site DAST sélectionné. | Le profil de site DAST pour exécuter le scan DAST. Ce champ ne doit être défini que si le type scan est dast. |
scanner_profile | string ou null | Nom du profil de scanner DAST sélectionné. | Le profil de scanner DAST pour exécuter le scan DAST. Ce champ ne doit être défini que si le type scan est dast. |
variables | object | Un ensemble de variables CI/CD, fourni sous la forme d'un tableau de paires key: value, à appliquer et à appliquer pour le scan sélectionné. La key est le nom de la variable, sa value étant fournie sous forme de chaîne. Ce paramètre prend en charge toute variable que le job GitLab CI/CD prend en charge pour le scan spécifié. | |
tags | array de string | Une liste de tags de runner pour la politique. Les jobs de politique sont exécutés par un runner avec les tags spécifiés. | |
template | string | default, latest ou une version spécifique au scanner | Version du template CI/CD à appliquer. default utilise le template stable. latest utilise le template expérimental, qui peut inclure des modifications incompatibles — il ne s'agit pas de la version recommandée la plus récente. Certains scanners prennent également en charge des templates versionnés représentant la configuration recommandée. Le template latest ne prend en charge que pipeline_sources lié aux merge requests. Pour les versions disponibles par scanner, voir Versions des templates de scanner. |
scan_settings | object | Un ensemble de paramètres de scan, fourni sous la forme d'un tableau de paires key: value, à appliquer et à appliquer pour le scan sélectionné. La key est le nom du paramètre, sa value étant fournie sous forme de booléen ou de chaîne. Ce paramètre prend en charge les paramètres définis dans les paramètres de scan. |
[!note] Si des pipelines de merge request sont activés pour votre projet, vous devez définir la variable CI/CD
AST_ENABLE_MR_PIPELINESà"true"dans votre politique pour chaque scan appliqué. Pour plus d'informations sur l'utilisation des outils de scan de sécurité avec les pipelines de merge request, consultez la documentation sur le scan de sécurité.
Le champ template accepte default et latest pour tous les types de scanners. Certains scanners prennent en charge des templates versionnés supplémentaires. La valeur par défaut recommandée varie selon le scanner — consultez la documentation du scanner avant de définir ce champ.
| Scanner | Templates pris en charge | Documentation |
|---|---|---|
sast | default, latest | Templates SAST stables vs. les plus récents |
sast_iac | default, latest | Éditions de templates |
secret_detection | default, latest | Éditions de templates |
container_scanning | default, latest | Éditions de templates |
dependency_scanning | default, latest, v2 | Analyse des dépendances à l'aide de SBOM |
Certains scanners se comportent différemment dans une action scan par rapport à un scan de pipeline CI/CD ordinaire :
SECRET_DETECTION_RULESET_GIT_REFERENCE. Par défaut, cela pointe vers un fichier de configuration distant qui ne remplace ou ne désactive que les règles de l'ensemble de règles par défaut. L'utilisation de cette seule variable ne prend pas en charge l'extension ou le remplacement de l'ensemble de règles de règles par défaut.SECRET_DETECTION_RULESET_GIT_REFERENCE et un fichier de configuration distant utilisant un passthrough Git pour étendre ou remplacer l'ensemble de règles par défaut. Pour un guide détaillé, consultez Comment configurer une configuration centralisée de détection des secrets dans un pipeline.scheduled, la détection des secrets s'exécute par défaut en premier en mode historic (SECRET_DETECTION_HISTORIC_SCAN = true). Tous les scans planifiés suivants s'exécutent en mode par défaut avec SECRET_DETECTION_LOG_OPTIONS défini sur la plage de commits entre la dernière exécution et le SHA actuel. Vous pouvez remplacer ce comportement en spécifiant des variables CI/CD dans la politique d'exécution de scan. Pour plus d'informations, voir Détection des secrets dans un pipeline avec historique complet.triggered, la détection des secrets fonctionne exactement comme un scan ordinaire configuré manuellement dans le .gitlab-ci.yml.pipeline ignore l'agent défini dans l'objet agents. L'objet agents n'est pris en compte que pour les types de règle schedule. Un agent dont le nom est fourni dans l'objet agents doit être créé et configuré pour le projet.Les exigences suivantes s'appliquent lors de l'application du test dynamique de sécurité des applications (DAST) :
enabled: false en mode YAML.Les paramètres suivants sont pris en charge par le paramètre scan_settings :
| Paramètre | Type | Obligatoire | Valeurs possibles | Valeur par défaut | Description |
|---|---|---|---|---|---|
ignore_default_before_after_script | boolean | false | true, false | false | Indique si les définitions before_script et after_script par défaut dans la configuration du pipeline doivent être exclues du job de scan. |
[!warning] Ne stockez pas d'informations sensibles ou d'identifiants dans des variables, car ils sont stockés dans le cadre de la configuration de politique en texte clair dans un dépôt Git.
Les variables définies dans une politique d'exécution de scan suivent la priorité des variables CI/CD standard.
Des valeurs préconfigurées sont utilisées pour les variables CI/CD suivantes dans tout projet sur lequel une politique d'exécution de scan est appliquée. Seules les politiques peuvent remplacer ces valeurs. Les variables CI/CD de groupe ou de projet ne peuvent pas remplacer ces variables :
DS_EXCLUDED_PATHS: spec, test, tests, tmp
SAST_EXCLUDED_PATHS: spec, test, tests, tmp
SECRET_DETECTION_EXCLUDED_PATHS: ''
SECRET_DETECTION_HISTORIC_SCAN: false
SAST_EXCLUDED_ANALYZERS: ''
DEFAULT_SAST_EXCLUDED_PATHS: spec, test, tests, tmp
DS_EXCLUDED_ANALYZERS: ''
SECURE_ENABLE_LOCAL_CONFIGURATION: true
Dans GitLab 16.9 et versions antérieures :
_EXCLUDED_PATHS étaient déclarées dans une politique, leurs valeurs pouvaient être remplacées par les variables CI/CD d'un groupe ou d'un projet._EXCLUDED_ANALYZERS étaient déclarées dans une politique, leurs valeurs étaient ignorées, indépendamment de l'endroit où elles étaient définies : politique, groupe ou projet.Pour personnaliser l'application des politiques, vous pouvez définir la portée d'une politique afin d'inclure ou d'exclure des projets, groupes ou labels de framework de conformité spécifiques. Pour plus de détails, voir Portée.
[!note] Définir un champ
policy_scopesur une collection vide (par exemple,including: []) est traité de la même manière que l'omission du champ, de sorte que la politique s'applique à tous les projets pour cette dimension de portée. Pour désactiver entièrement une politique, utilisezenabled: false. Pour plus de détails, voir Collections vides danspolicy_scope.
Lorsque vous mettez à jour une politique, les modifications se propagent différemment selon la méthode de mise à jour :
.gitlab/security-policies/policy.yml : Les modifications peuvent prendre jusqu'à 10 minutes pour prendre effet.Les mises à jour des politiques basées sur un pipeline (type: pipeline) ne déclenchent pas de pipelines immédiats et n'affectent pas les pipelines déjà en cours. Les modifications de politique s'appliquent aux futures exécutions de pipeline.
Vous ne pouvez pas déclencher manuellement les règles d'une politique planifiée en dehors de leur cadence planifiée.
Vous pouvez utiliser cet exemple dans un fichier .gitlab/security-policies/policy.yml stocké dans un projet de politique de sécurité :
---
scan_execution_policy:
- name: Enforce DAST in every release pipeline
description: This policy enforces pipeline configuration to have a job with DAST scan for release branches
enabled: true
rules:
- type: pipeline
branches:
- release/*
actions:
- scan: dast
scanner_profile: Scanner Profile A
site_profile: Site Profile B
- name: Enforce DAST and secret detection scans every 10 minutes
description: This policy enforces DAST and secret detection scans to run every 10 minutes
enabled: true
rules:
- type: schedule
branches:
- main
cadence: "*/10 * * * *"
actions:
- scan: dast
scanner_profile: Scanner Profile C
site_profile: Site Profile D
- scan: secret_detection
scan_settings:
ignore_default_before_after_script: true
- name: Enforce secret detection and container scanning in every default branch pipeline
description: This policy enforces pipeline configuration to have a job with secret detection and container scanning scans for the default branch
enabled: true
rules:
- type: pipeline
branches:
- main
actions:
- scan: secret_detection
- scan: sast
variables:
SAST_EXCLUDED_ANALYZERS: brakeman
- scan: container_scanning
Dans cet exemple :
release/* (par exemple, la branche release/v1.2.1)
Scanner Profile A et Site Profile B.Scanner Profile C et Site Profile D.main. Le scan SAST s'exécute avec la variable SAST_EXCLUDED_ANALYZER définie sur "brakeman".Vous pouvez utiliser cet exemple en mode YAML de l'éditeur de politiques d'exécution de scan. Il correspond à un seul objet de l'exemple précédent.
name: Enforce secret detection and container scanning in every default branch pipeline
description: This policy enforces pipeline configuration to have a job with secret detection and container scanning scans for the default branch
enabled: true
rules:
- type: pipeline
branches:
- main
actions:
- scan: secret_detection
- scan: container_scanning
Les politiques d'exécution de scan peuvent amener le même type de scanner à s'exécuter plus d'une fois si vous incluez des jobs de scan dans le fichier .gitlab-ci.yml de votre projet.
Les scans en double s'exécutent intentionnellement, car les scanners peuvent s'exécuter plusieurs fois avec des variables et des paramètres différents. Par exemple, vous pourriez exécuter un scan SAST avec des variables différentes de celles appliquées par vos politiques. Dans ce scénario, deux jobs SAST s'exécutent dans le pipeline :
Pour éviter les scans en double, vous pouvez soit supprimer l'un des scans du fichier .gitlab-ci.yml du projet, soit ignorer les jobs locaux à l'aide de variables. L'omission de jobs n'empêche pas les jobs de sécurité définis par les politiques d'exécution de scan de s'exécuter.
Pour ignorer les jobs de scan à l'aide de variables, vous pouvez utiliser :
SAST_DISABLED: "true" pour ignorer les jobs SAST.DAST_DISABLED: "true" pour ignorer les jobs DAST.CONTAINER_SCANNING_DISABLED: "true" pour ignorer les jobs de scan de conteneurs.SECRET_DETECTION_DISABLED: "true" pour ignorer les jobs de détection des secrets.DEPENDENCY_SCANNING_DISABLED: "true" pour ignorer les jobs d'analyse des dépendances.Pour un aperçu de toutes les variables pouvant ignorer des jobs, voir la documentation sur les variables CI/CD
Lorsque vous travaillez avec des politiques d'exécution de scan, vous pouvez rencontrer les problèmes suivants.
Si une politique d'exécution de scan ne crée pas de pipeline défini dans type: pipeline comme prévu, il se peut que vous ayez workflow:rules dans le fichier .gitlab-ci.yml du projet qui empêche la politique de créer le pipeline.
Les politiques d'exécution de scan avec des règles type: pipeline s'appuient sur la configuration CI/CD fusionnée pour créer des pipelines. Si le workflow:rules du projet filtre entièrement le pipeline, la politique d'exécution de scan ne peut pas créer de pipelines.
Par exemple, la configuration workflow:rules suivante empêche la création de tous les pipelines :
# .gitlab-ci.yml
workflow:
rules:
- if: $CI_PIPELINE_SOURCE == "push"
when: never
Résolution :
Pour résoudre ce problème, vous pouvez utiliser l'une des options suivantes :
Modifiez le workflow:rules dans le fichier .gitlab-ci.yml de votre projet pour autoriser les politiques d'exécution de scan à créer des pipelines. Vous pouvez utiliser la variable $CI_PIPELINE_SOURCE pour identifier les pipelines déclenchés par des politiques :
workflow:
rules:
- if: $CI_PIPELINE_SOURCE == "security_orchestration_policy"
- if: $CI_PIPELINE_SOURCE == "push"
when: never
Utilisez des règles type: schedule plutôt que des règles type: pipeline. Les politiques d'exécution de scan planifiées ne sont pas affectées par workflow:rules et créent des pipelines selon leur planification définie.
Utilisez les politiques d'exécution de pipeline pour plus de contrôle sur le moment et la manière dont les scans de sécurité sont exécutés dans vos pipelines CI/CD.