Règles Gitleaks¶
Boost Security analyse les dépôts avec une configuration Gitleaks par défaut sélectionnée : l'ensemble de règles intégré de Gitleaks, ainsi que des règles personnalisées gérées par Boost.
Priorité de configuration¶
Le scanner Gitleaks utilise une seule configuration pour un dépôt : la première trouvée, dans l'ordre suivant :
- Un fichier
.gitleaks.tomldans le dépôt. - Une configuration de scanner Gitleaks définie dans Boost Security.
- La configuration par défaut sélectionnée par Boost Security.
La configuration qui s'applique remplace entièrement la configuration par défaut ; les configurations ne sont jamais fusionnées. Par conséquent, une configuration de scanner Gitleaks définie dans Boost Security n'a aucun effet sur un dépôt qui contient son propre fichier .gitleaks.toml.
Warning
Un fichier .gitleaks.toml qui n'est pas un TOML valide, par exemple une liste de chemins écrite comme un fichier d'ignore, ne laisse aucune règle active. L'analyse réussit mais ne signale aucun résultat. Pour exclure des chemins de l'analyse, utilisez plutôt un fichier .boostignore.
Étendre les règles de Gitleaks¶
Lorsque vous configurez un ensemble de règles Gitleaks personnalisé, vous pouvez soit spécifier un ensemble de règles entier, soit utiliser la fonctionnalité d'extension de Gitleaks. Il y a plusieurs raisons pour lesquelles vous pourriez vouloir étendre les règles par défaut de Gitleaks :
- Ajouter de nouvelles règles de détection.
- Étendre une règle existante.
- Rendre une règle plus stricte (c’est-à-dire, éliminer un faux positif).
La documentation de configuration de Gitleaks montre comment étendre la configuration pour répondre à tous ces cas.
title = "Configuration Gitleaks personnalisée"
[extend]
useDefault = true
# Définir des règles ici
Note
[extend] useDefault = true est pris en charge à la fois dans un fichier .gitleaks.toml de dépôt et dans une configuration de scanner Gitleaks définie dans Boost Security. Il démarre à partir des règles intégrées de Gitleaks.
Validité des Secrets¶
Boost Security testera la validité des secrets par rapport à l'un des services publics suivants. Notez que, si les règles Gitleaks correspondantes sont désactivées dans la politique de Boost Security, la validité des secrets ne sera pas vérifiée même s'il s'agit d'un service pris en charge.
| SaaS | Règle Gitleaks |
|---|---|
| Asana | - asana-client-secret |
| Datadog | - datadog-access-token |
| Dropbox | - dropbox-api-token - dropbox-long-lived-api-token - dropbox-short-lived-api-token |
| - facebook-access-token - facebook-page-access-token - facebook-secret |
|
| GitHub | - github-app-token - github-fine-grained-pat - github-pat - github-refresh-token |
| GitLab | - gitlab-pat |
| Heroku | - heroku-api-key |
| Hubspot | - hubspot-api-key |
| Mailgun | - mailgun-private-api-token |
| Sendgrid | - sendgrid-api-token |
| Slack | - slack-app-token - slack-bot-token - slack-config-access-token - slack-config-refresh-token - slack-legacy-bot-token - slack-legacy-token - slack-legacy-workspace-token - slack-user-token - slack-webhook-url |
| Square | - square-access-token |
| Stripe | - stripe-access-token |
| Telegram | - telegram-bot-api-token |
| - twitter-bearer-token - twitter-access-token |