Où scanner les secrets dans le SDLC ?
Nous vous recommandons d'ajouter le scan automatisé des secrets partout où c'est possible, à chaque étape du SDLC. Multiplier les filets crée une défense en profondeur et évite le risque d'un point de failure unique. Nous pensons que toute organisation qui cherche à réduire l'exposition de ses secrets devrait adopter cette stratégie. Contre-intuitivement, cette approche en couches ajoute peu de friction et peut favoriser une adoption large par les développeurs.
Commencez par la surveillance continue de vos instances VCS (côté serveur) : les résultats sont plus informatifs et non bloquants. Une fois à l'aise avec le traitement de ces résultats, vous pouvez augmenter progressivement le niveau de contrôle jusqu'à ce qu'il corresponde à votre organisation. Avec GitGuardian, vous pourrez faire remonter le scan des secrets vers les environnements développeur (côté client) par étapes.
-
Commencez par le scan continu de vos dépôts distants grâce aux intégrations VCS natives disponibles. La mise en place est simple et offre à votre (vos) équipe(s) sécurité une visibilité totale sur un périmètre en évolution, les dépôt étant créés et supprimés chaque jour.
-
Ajoutez des jobs de scan automatisés dans les environnements CI pour tester les branches de support (feature, release, hotfix) avant fusion dans la branche principale.
-
Configurez les postes développeurs pour scanner les changements locaux via le hook git pre-commit et l'interface en ligne de commande ggshield. Cela empêche les secrets de quitter le poste du développeur.
-
Si vous hébergez vos propres instances VCS, vous pouvez utiliser un hook git pre-receive configuré globalement pour bloquer les secrets avant qu'ils n'entrent dans les dépôts centralisés.
