SEDATED

Le projet SEDATED® (Sensitive Enterprise Data Analyzer To Eliminate Disclosure) se concentre sur la prévention des fuites de données sensibles, telles que les identifiants utilisateur et les jetons, vers Git.

Table des matières

• Objectif
• Configuration
  • Cloner SEDATED®
  • Mettre à jour les fichiers .example
  • Personnaliser les variables et fonctions de /config/custom_configs.sh (au besoin)
  • Pousser SEDATED® avec une implémentation propre à l'organisation
  • Pointer le hook pre-receive vers le fichier pre-receive.sh de SEDATED®
• Tests locaux
• Descriptions des fichiers
  • pre-receive.sh
  • /config/custom_configs.sh
  • /config/enforced_repos_list.txt
  • /config/regexes.json
  • /config/whitelists/commit_whitelist.txt
  • /config/whitelists/repo_whitelist.txt
  • /testing/regex_testing/regex_test_script.sh
  • /testing/regex_testing/test_cases.txt
• Personnalisation
  • Variables personnalisées
  • Fonctions personnalisées
• Compatibilité
  • GitHub
  • GitLab
  • Git
  • Tout autre outil Git SCM
• Contribuer
• Auteurs
• Licence

Objectif

Avec la myriade de modifications de code nécessaires dans l'environnement CICD actuel, les développeurs poussent constamment du code qui pourrait involontairement contenir des informations sensibles. Cette exposition potentielle de données sensibles représente un risque énorme pour les organisations (2017 OWASP Top Ten #3 - Sensitive Data Exposure). SEDATED® répond à ce problème en examinant automatiquement toutes les modifications de code entrantes et en fournissant un retour instantané au développeur. S'il identifie des données sensibles, il empêche l'envoi du ou des commits vers le serveur Git.

**REMARQUE : Seules les lignes ajoutées ou modifiées (commençant par + dans le fichier de correctif) dans les pushes de commits sont analysées par SEDATED®. Les lignes supprimées (commençant par - dans le fichier de correctif) dans les pushes de commits NE sont PAS analysées par SEDATED®.

Configuration

1. Cloner SEDATED®

git clone https://github.com/OWASP/SEDATED.git

cd SEDATED/

2. Mettre à jour les fichiers .example

cp /config/whitelists/commit_whitelist.txt.example /config/whitelists/commit_whitelist.txt

cp /config/whitelists/repo_whitelist.txt.example /config/whitelists/repo_whitelist.txt

cp /config/enforced_repos_list.txt.example /config/enforced_repos_list.txt

3. Personnaliser les variables et fonctions de /config/custom_configs.sh (au besoin)

4. Pousser SEDATED® avec une implémentation propre à l'organisation

Pousser l'implémentation spécifique à l'organisation de SEDATED® vers le dépôt Git souhaité par l'organisation (GitHub, GitLab, Git, etc.).

5. Pointer le hook pre-receive vers le fichier pre-receive.sh de SEDATED®

Les instructions pour y parvenir sur une instance GitHub Enterprise se trouvent dans GitHub_Enterprise_Setup.md.

Tests locaux

• Configuration Docker GitHub - Instructions générales pour configurer un conteneur Docker GitHub agissant comme serveur Git avec un hook pre-receive activé pour les tests locaux.
  • Certaines modifications devront être apportées pour permettre à SEDATED® de fonctionner comme prévu.
    • always_reject.sh devra être remplacé par le script pre-receive.sh de SEDATED®.
    • Les fichiers et la structure de dossiers accompagnant SEDATED® devront être inclus dans le même répertoire / accessibles par le script pre-receive.sh.
    • Des ajustements supplémentaires peuvent également être nécessaires, mais les instructions liées ci-dessus sont un bon point de départ pour les tests locaux.

Descriptions des fichiers

pre-receive.sh

• Le cœur et l'âme de SEDATED®.
• Le script de hook Git pre-receive de SEDATED® utilisé conjointement avec ses expressions régulières (config/regexes.json) identifie les lignes de code ajoutées ou modifiées poussées vers une instance Git qui contiennent des informations d'identification codées en dur / des données sensibles (telles qu'identifiées dans config/regexes.json) et empêche le push SI des lignes contenant de telles informations sont trouvées.

/config/custom_configs.sh

• Le fichier de configurations personnalisées de SEDATED® utilisé conjointement avec pre-receive.sh permet aux organisations de personnaliser leur implémentation de SEDATED® sans avoir à modifier le code source du fichier pre-receive.sh de SEDATED®, grâce à des variables et fonctions personnalisables intégrées qui sont sourcées depuis pre-receive.sh.

/config/enforced_repos_list.txt

• Utilisé lorsque le drapeau use_enforced_repo_check_custom de SEDATED® (hook pre-receive) dans config/custom_configs.sh est défini sur "True".
• Permet à SEDATED® d'être "activé" globalement dans l'entreprise, mais "appliqué" sélectivement uniquement aux dépôts listés dans ce fichier.
• L'application de la règle pour tous les dépôts sous une organisation ou un nom d'utilisateur spécifique peut être réalisée en ajoutant /* à la fin du nom de l'organisation ou de l'utilisateur concerné.
• Si SEDATED® est activé globalement dans une organisation et n'apparaît pas dans le fichier /config/enforced_repos_list.txt, le pousseur (s'il pousse depuis la ligne de commande) verra un message personnalisable (personnalisable via le fichier /config/custom_configs.sh) et SEDATED® NE scrutera AUCUN code inclus dans le push.
• Le drapeau pour activer/désactiver cette fonctionnalité se trouve dans /config/custom_configs.sh et peut être défini sur "True" ou "False".
  • "False" - Chaque dépôt avec SEDATED® "activé" aura également SEDATED® "appliqué" sur lui.
  • "True" - Seuls les dépôts avec SEDATED® "activé" ET listés dans /config/enforced_repos_list.txt verront SEDATED® "appliqué" sur eux. Tous les autres dépôts avec SEDATED® "activé" mais non listés dans le fichier /config/enforced_repos_list.txt verront seulement un message personnalisé affiché, aucun code ne sera scanné pour les pushes en provenance de ces dépôts.

/config/regexes.json

• Contient les expressions régulières (regexes) utilisées pour signaler les données sensibles / informations d'identification codées en dur.
• Ces regexes sont consommées par GNU grep (dans pre-receive.sh) avec le drapeau -P, ce qui en fait des expressions régulières compatibles Perl (PCRE).
• Les regexes peuvent être ajoutées ou supprimées de ce fichier selon les besoins, cependant si vous utilisez le script /testing/regex_testing/regex_test_script.sh, le fichier /testing/regex_testing/test_cases.txt devra être mis à jour en ajoutant ou supprimant les cas de test correspondant aux regexes mises à jour afin que les résultats du script /testing/regex_testing/regex_test_script.sh soient précis.
• Si vous ajoutez/modifiez des regexes dans ce fichier, des caractères d'échappement supplémentaires \ peuvent être nécessaires selon les regexes souhaitées car ce fichier est au format JSON.

/config/whitelists/commit_whitelist.txt

• Utilisé en cas de faux positif : un ou plusieurs commits peuvent être exclus du processus d'analyse si leurs identifiants de commit sont inclus dans ce fichier.
• Les identifiants de commit doivent être séparés par un retour chariot dans ce fichier, comme indiqué dans le fichier /config/whitelists/commit_whitelist.txt.example.
• Ce fichier peut être vide, mais il doit exister.

Optionnel : Demandez aux développeurs de soumettre des pull requests vers ce fichier (commit_whitelist.txt) lorsqu'ils rencontrent des faux positifs afin qu'ils puissent être examinés.

/config/whitelists/repo_whitelist.txt

• Les dépôts (organisation/utilisateur) inclus dans ce fichier seront entièrement exclus de l'analyse des données sensibles / informations d'identification codées en dur jusqu'à ce qu'ils soient retirés de cette liste.
• Utilisé en cas de push massif (par exemple, migration de dépôt) où SEDATED® ne peut pas analyser le code nouveau/modifié inclus dans le push dans la fenêtre de 5 secondes (la fenêtre de 5 secondes est spécifique à GitHub et peut être différente sur d'autres instances Git).
• Les noms de dépôts (organisation/utilisateur) doivent être séparés par un retour chariot dans ce fichier, comme indiqué dans le fichier /config/whitelists/repo_whitelist.txt.example.
• Ce fichier peut être vide, mais il doit exister.

/testing/regex_testing/regex_test_script.sh

• Le script de test des expressions régulières de SEDATED® utilisé conjointement avec testing/regex_testing/test_cases.txt est un moyen simple et rapide hors ligne de tester/valider que les expressions régulières dans config/regexes.json sont valides et correspondent aux motifs souhaités tout en excluant/ne correspondant pas comme souhaité.
  • Teste les regexes contre une liste de cas de test (/testing/regex_testing/test_cases.txt) pour vérifier qu'elles fonctionnent comme attendu.
  • Inclut des tests pour les cas de test positifs et négatifs (/testing/regex_testing/test_cases.txt).
  • DOIT utiliser GNU grep lors de l'exécution du script, sinon le script échouera (BSD grep ne possède pas le drapeau -P).
  • Les cas de test utilisés dans ce script sont importés depuis /testing/regex_testing/test_cases.txt.

/testing/regex_testing/test_cases.txt

• Liste de cas de test à transmettre à /testing/regex_testing/regex_test_script.sh pour consommation.
• Chaque cas de test a >>pass ou >>fail ajouté à sa suite ; cela permet au script /testing/regex_testing/regex_test_script.sh de connaître l'attente pour les regexes.
  • >>pass signifie qu'un push contenant la chaîne précédente sera accepté par SEDATED® (c'est-à-dire que les regexes ne signaleront PAS la chaîne précédente).
  • >>fail signifie qu'un push contenant la chaîne précédente sera rejeté par SEDATED® (c'est-à-dire que les regexes signaleront la chaîne précédente).

Personnalisation

Les variables et fonctions personnalisées sont conçues pour permettre aux organisations de personnaliser facilement leur propre implémentation de SEDATED® sans modifier le fichier principal du hook pre-receive qui effectue tout le travail. Toutes les variables et fonctions personnalisées se trouvent dans /config/custom_configs.sh et les explications des variables contenues dans ce fichier sont listées ci-dessous.

Variables personnalisées

• show_SEDATED_link_custom - "True" pour afficher le lien vers le dépôt GitHub OWASP/SEDATED (sensible à la casse), sinon "False".
• documentation_link_custom - Ajouter un lien vers la documentation spécifique à l'organisation sur la manière dont l'organisation souhaite que les développeurs gèrent les pushes rejetés et/ou des informations générales spécifiques à l'organisation concernant SEDATED®.
  • Affiché au développeur lorsqu'un push est rejeté.
  • Affiché au développeur lorsque la vérification du dépôt appliqué est activée et que le dépôt n'est pas inclus dans le fichier enforced_repos_list.txt.
• use_enforced_repo_check_custom - "True" ou "False" (sensible à la casse).
  • Voir la description du fichier ci-dessus pour /config/enforced_repos_list.txt pour plus de détails sur la signification de ce drapeau.
• enforced_repo_check_true_message_custom avec un message personnalisé (nécessaire uniquement si use_enforced_repo_check_custom est défini sur "True").
• obfuscate_output_custom - "True" ou "False" (sensible à la casse). Utilisez cette option pour masquer les données sensibles affichées dans la sortie de SEDATED®.

Fonctions personnalisées

• SET_USER_REPO_NAME_CUSTOM
  • Définit le nom de l'utilisateur/organisation/groupe et du dépôt.
  • Définit le nom de l'utilisateur/organisation/groupe et du dépôt en utilisant la variable GITHUB_REPO_NAME si vous utilisez GitHub.
  • Si vous n'utilisez pas GitHub, des variables personnalisées peuvent être définies pour obtenir ces noms.
  • Les noms non-GitHub fournis sont configurés pour obtenir simplement les noms dans Git standard, mais peuvent nécessiter des ajustements en fonction des différentes implémentations (Git SCM).
• PRINT_ERROR_MESSAGE_CUSTOM
  • Permet d'afficher un message d'erreur personnalisé lorsque des erreurs sont rencontrées.
• EXIT_SEDATED_CUSTOM
  • Effectuer une action personnalisée supplémentaire lors de la sortie de SEDATED® (par exemple, journaliser, envoyer des métriques, etc.).
  • Par défaut, : "ne rien faire" comme action supplémentaire, et il n'est pas nécessaire de le changer.
• UNABLE_TO_ACCESS_REPO_WHITELIST_CUSTOM
  • Effectuer une action personnalisée supplémentaire lorsque SEDATED® ne peut pas accéder au fichier de liste blanche des dépôts (par exemple, afficher un message d'erreur, journaliser, envoyer une métrique, etc.).
  • Par défaut, : "ne rien faire" comme action supplémentaire, et il n'est pas nécessaire de le changer.
• PUSH_ACCEPTED_CUSTOM

Compatibilité

Uniquement compatible avec les outils SCM qui utilisent le système de contrôle de version Git.

• GitHub
  • Testé complètement (Enterprise v2.15.3).
  • SEDATED® Configuration GitHub Enterprise.
• GitLab
  • Testé préliminairement.
  • Des modifications à SET_USER_REPO_NAME_CUSTOM seront nécessaires pour définir le nom d'utilisateur/org et le nom du dépôt.
• Git
  • Testé préliminairement.
  • Tous les fichiers/dossiers de SEDATED® devront être placés dans le répertoire .git/hooks/ (sauf le dossier/les fichiers de documentation).
  • Supprimer .sample de pre-receive.sample et copier le code du fichier pre-receive.sh de SEDATED® dans le fichier pre-receive que nous venons de créer à partir du fichier .sample.
  • Selon l'implémentation, on peut vouloir utiliser git-template ou quelque chose de similaire.
• Tout autre outil Git SCM
  • Non testé.
  • Des modifications à SET_USER_REPO_NAME_CUSTOM seront probablement nécessaires pour définir le nom d'utilisateur/org et le nom du dépôt.

Contribuer

Les contributions à ce projet sont les bienvenues !

Vous pouvez contribuer de l'une des manières suivantes :

• Soumettez vos idées d'amélioration à nous (ou à n'importe qui dans la communauté qui pourrait souhaiter relever le défi de transformer votre idée en réalité au sein de la base de code de SEDATED®) en créant un ticket avec une bonne explication de ce qui, selon vous, pourrait améliorer SEDATED® et comment vous pensez que cela pourrait se produire concrètement dans la base de code.
• Soumettez une pull request avec vos modifications de code pour améliorer SEDATED® et nous examinerons, testerons et fusionnerons. :)

Auteurs

• Dennis Kennedy
• Simeon Cloutier

Licence

SEDATED® est sous licence BSD 3-Clause "New" or "Revised" License.

---

**SEDATED® ne garantit pas de signaler chaque instance d'identifiants, clés, secrets, etc. codés en dur ; il utilise la correspondance de motifs par expressions régulières et bien qu'il soit devenu assez bon pour attraper la plupart des instances, il n'est pas parfait, mais nous sommes toujours ouverts aux idées et/ou pull requests pour aider à rendre SEDATED® encore meilleur.