Analyse des Secrets Stockés¶

Les secrets codés en dur dans votre code sont une source très courante de vulnérabilités. Si votre code est hébergé publiquement, les attaquants trouveront ces identifiants et les utiliseront pour essayer de compromettre vos systèmes.

Même si votre code n'est pas hébergé publiquement, les attaquants qui compromettent les machines de vos développeurs et les développeurs malveillants auront accès à ces identifiants. C'est pourquoi il est important de créer des politiques qui traitent de cette vulnérabilité.

Boost permet de scanner votre historique de commits Git à la recherche de secrets potentiels. Bien qu'il soit bénéfique de mettre en œuvre des mesures pour empêcher l'introduction de secrets dans le code dès le départ, il existe encore des raisons valables de revoir l'historique du code pour tout secret existant.

La configuration sur le poste de travail du développeur peut changer de manière inattendue, empêchant l'analyse des secrets stockés.
Les règles de scan de secrets lors des événements de push peuvent être assouplies pour éviter de bloquer trop de ces événements.
Les mécanismes de protection contre les pushes contenant des secrets permettent généralement aux développeurs de sauter la validation d'un push (c'est-à-dire, GitLab, GitHub).
Pour garantir la conformité à votre sécurité applicative, vous devez disposer de preuves que l'analyse des secrets a été effectuée et que tout secret potentiel identifié a été correctement traité.

De plus, il est fortement recommandé de former les développeurs et d'imposer des pratiques de développement sécurisées pour éviter que des secrets ne soient introduits dans votre historique Git. Veuillez consulter la documentation de Gitleaks, section scan pré-engagement, pour des exemples sur la façon de minimiser les chances d'introduire un secret dans l'historique Git.

Analyse Continue¶

Pour commencer à analyser les secrets dans le code avec BoostSecurity, sélectionnez la couverture Secrets dans la fenêtre modale de provisioning de la couverture d'analyse.

À partir de maintenant, chaque nouveau commit sur votre branche par défaut, ainsi que tout commit effectué dans le contexte d'une demande de tirage, sera analysé pour détecter des secrets.

Créer une ligne de base¶

Idéalement, vous auriez activé l'analyse des secrets depuis la création d'un dépôt de code, de sorte que chaque commit soit analysé pour des secrets. Malheureusement, dans de nombreuses situations, ce n'est pas le cas. Par conséquent, lorsque vous activez pour la première fois l'analyse des secrets sur un dépôt de code, il est fortement recommandé de scanner l'ensemble de l'historique git pour détecter la présence de tout secret codé en dur potentiel.

Étant donné que l'analyse d'un historique de commits complet prend du temps, il est conseillé de ne scanner l'intégralité de l'historique qu'une seule fois pour créer une ligne de base des secrets. Pour analyser l'intégralité de l'historique de commits de la branche par défaut, dans l'onglet avancé de la fenêtre modale de provisioning du scanner, cochez le scanner Gitleak Git Scan.

Lors du provisioning, ceci lancera l'exécution du scanner. Une fois le scanner terminé, il est fortement conseillé de déprovisionner le scanner GitLeak Git Scan.

Note

Veuillez éviter de lancer des analyses simultanées de l'historique des commits sur plusieurs projets lors de la création d'une ligne de base. La nature chronophage de ces analyses peut créer des goulets d'étranglement et retarder d'autres pipelines, en fonction de la disponibilité du runner CI/CD.

Comprendre la Validation des Secrets BoostSecurity¶

L'analyse des secrets peut donner lieu à un grand nombre de résultats qui doivent être triés et priorisés. Pour aider à cela, l'analyse des secrets de BoostSecurity inclut une fonctionnalité de validation des secrets.

Lorsque BoostSecurity détecte qu'un secret pourrait être lié à un service public bien connu, il essaiera de contacter le service pour déterminer si le secret est toujours valide ou non. Si c'est le cas, la validité du secret est définie sur Valide dans BoostSecurity.

Ensuite, en utilisant le moteur de politique de BoostSecurity, on peut créer une règle pour agir rapidement sur les secrets valides.

Personnalisation de la Détection des Secrets¶

En plus de la validité des secrets, BoostSecurity propose plusieurs mécanismes pour aider à réduire le nombre de résultats.

Sélection des Règles Gitleaks¶

Dans le moteur de politique de BoostSecurity, les utilisateurs peuvent sélectionner les règles Gitleaks à activer ou à désactiver. Par défaut, il est recommandé d'activer toutes les règles. Ensuite, pour les règles générant trop de faux positifs, vous pouvez décider de désactiver la règle correspondante.

Par exemple, supposons que vous obtenez des faux positifs pour les secrets New Relic. Dans l'onglet des scanners d'une politique BoostSecurity, sous le scanner Gitleaks et la classe Exposition de Secrets à des Acteurs Non Autorisés, vous pouvez désélectionner toutes les règles concernant New Relic.

Règles Gitleaks Personnalisées¶

Il est également possible de personnaliser la définition des règles Gitleaks, qui sont utilisées pour effectuer l'analyse. Cela est particulièrement utile dans deux situations :

Une règle génère trop de faux positifs dans votre contexte, et vous souhaitez exclure certains cas.
Un type particulier de secret n'est pas détecté, et vous souhaitez être en mesure de le détecter.

Pour utiliser des règles Gitleaks personnalisées, vous devez d'abord créer une configuration de scanner Gitleaks.

Ouvrez la fenêtre de configuration du scanner comme décrit ici.
Sélectionnez "Activer" pour le scanner Gitleaks.
Cliquez sur le bouton Ajouter une Configuration.
Ajoutez le Nom, le Chemin et le Contenu. La case à cocher Valider les Secrets est sélectionnée par défaut, et le contenu ici est votre fichier .gitleaks.toml. Le chemin DOIT se terminer par un fichier ayant une extension .toml.
Cliquez sur le bouton Enregistrer pour sauvegarder la configuration.

Une fois qu'une configuration GitLeak a été créée, vous devez indiquer à BoostSecurity sur quels dépôts de code vous souhaitez l'appliquer.

Dans l'onglet avancé de la fenêtre modale de provisioning du scanner, cochez le scanner Gitleak Git et cliquez sur Suivant.
Sélectionnez l'ensemble de règles Gitleaks approprié et cliquez sur Terminer.

Note

Supposons que le scanner Gitleaks ait déjà été provisionné sur un dépôt de code, et que vous souhaitiez appliquer une configuration Gitleaks personnalisée à celui-ci. Dans ce cas, vous devez d'abord déprovisionner le scanner Gitleaks, puis le provisionner tout en sélectionnant la configuration personnalisée appropriée comme ci-dessus.