Comment empêcher l’exposition de credentials / secrets dans les dépôts et les outils de collaboration

Bonjour à tous sur GeekNews !

Nous avons été ravis de voir sur GeekNews, que toute notre équipe lit attentivement, un article qui traite justement du problème que nous cherchons à résoudre.
https://fr.news.hada.io/topic?id=13442
Comme quelqu’un a demandé dans les commentaires du fil qu’on présente cela, nous vous présentons le produit que nous avons développé avec beaucoup d’efforts.

1. Présentation du projet

• Nous proposons un service de détection pour les Secret API Keys utilisées afin de s’intégrer à divers services SaaS.
• Il existe de nombreux outils comme TruffleHog ou GitLeaks, mais ils sont très orientés outils DevSecOps. Nous cherchons à corriger leur inconvénient principal : du point de vue des équipes sécurité et des équipes d’administration d’infrastructure, leur utilisation entraîne souvent un coût d’ingénierie élevé.
• Au-delà de GitHub et GitLab, nous pouvons actuellement étendre l’intégration à Confluence, Jira, Notion, etc.
• Nous aidons à construire une sécurité centrée sur les credentials (Secrets, PII) et, grâce à des fonctions de gestion des menaces, à identifier les menaces pesant sur la sécurité des credentials au sein de l’organisation.
• Nous proposons des fonctionnalités permettant l’intégration avec divers IDP, notamment via SAML / OIDC.

2. Présentation des fonctionnalités

• Nous proposons une fonction de détection de Secrets. Nous identifions aussi l’état des Secret keys, ce qui permet d’échapper aux faux positifs grâce à des statuts comme Active / Inactive.
• Nous proposons une fonction de détection de PII. Comme elle inclut du NLP, elle permet d’identifier plus précisément l’exposition de données personnelles en comprenant le contexte, au-delà d’un simple Regex.
• Nous proposons une fonction Threat Policy. Par exemple, un AWS Active Key dans un état actif peut être défini comme une menace élevée afin d’en établir la priorité.
• Nous proposons une fonction Dashboard.
• Le périmètre d’intégration se divise globalement en deux catégories.
  **Target - vous pouvez ajouter un GitHub public, etc., pour le surveiller.
  **Integration - pour un usage interne (Private), vous pouvez intégrer Github, GitLab, Confluence, Jira, Notion, etc.

3. Gestion des membres

• Les permissions sont globalement réparties entre Administrator, Writer et Reader, ce qui permet une gestion organisationnelle à grande échelle par organisation.
• L’intégration avec l’IDP utilisé par l’organisation est possible via SAML / OIDC.

4. Liens de référence

• Support Center - https://support.cremit.io - vous pouvez obtenir de l’aide via le système de tickets et la documentation.
• Status Page - https://status.cremit.io - vous pouvez consulter l’état du service.
• Security Center - https://security.cremit.io - vous pouvez vérifier le niveau de sécurité maintenu par Cremit.

5. Roadmap - https://releases.cremit.io

• Extension continue du périmètre d’intégration - des incidents de fuite continus et une gestion non maîtrisée des données personnelles existent aussi sur AWS S3, GCS, Azure Storage, etc. L’équipe Cremit les a donc ajoutés à la roadmap d’extension.
• Extension continue des fonctions de gestion
• En lien avec la fonctionnalité Threat, les fonctions de gestion permettant la gestion des incidents continueront à être étendues.
• Extension continue du périmètre de détection des Secrets - les outils SaaS continuent encore aujourd’hui d’être mis à jour et connectés par dizaines chaque semaine. L’équipe Cremit met donc à jour en continu les Secret Pattern / Validation Pattern via un suivi régulier.
• Ajout de fonctions de gestion par l’utilisateur pour les données PII - l’utilisateur peut directement ajouter les patterns PII actuellement gérés de manière managée par Cremit.
• Ajout d’une fonction de validation pour les informations d’authentification gérées directement par l’utilisateur
• Nous prévoyons d’ajouter une fonction permettant de relier des Secrets à des informations de connexion comme celles des systèmes d’administration internes, back-offices, etc.

5. Autres informations complémentaires

• Cremit est une entreprise extrêmement jeune, fondée en mai 2023. Heureusement, nous avons pu recevoir un investissement d’amorçage initial de Primer en août de l’année de création.
• Si vous souhaitez échanger avec notre équipe, n’hésitez pas à demander un rendez-vous via notre site web !
• Il existe actuellement une période d’utilisation gratuite ainsi qu’un Free Plan. Veuillez noter qu’il y a quelques limitations fonctionnelles.

URL d’inscription au service - https://register.cremit.io

[00001]

La plupart de ces outils de détection semblent se limiter aux dépôts ou au code, donc c’est appréciable que celui-ci détecte aussi dans des outils comme Notion ou Jira.

[cremit]

Oui, tout à fait ! Les outils existants sont plutôt axés sur le DevSecOps.
De notre côté, nous visons à détecter tous les emplacements où des identifiants peuvent être exposés, notamment les outils de collaboration, les drives et les dépôts.
Merci de votre intérêt !