SEDATED

Scopo

Con la miriade di modifiche al codice richieste nell'ambiente CICD odierno, gli sviluppatori eseguono continuamente push di codice che potrebbe contenere involontariamente informazioni sensibili. Questa potenziale esposizione di dati sensibili rappresenta un enorme rischio per le organizzazioni (2017 OWASP Top Ten #3 - Sensitive Data Exposure). SEDATED® affronta questo problema rivedendo automaticamente tutte le modifiche in arrivo e fornendo un feedback immediato allo sviluppatore. Se identifica dati sensibili, impedisce che i commit vengano inviati tramite push al server Git.

**NOTA: SOLO le righe aggiunte o modificate (che iniziano con + nel file patch) nei push di commit vengono scansionate da SEDATED®. Le righe che vengono rimosse (che iniziano con - nel file patch) nei push di commit NON vengono scansionate da SEDATED®.

Configurazione

1. Clona SEDATED®

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

cd SEDATED/

2. Aggiorna i file .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. Personalizza variabili e funzioni in /config/custom_configs.sh (a piacere)

4. Esegui il push di SEDATED® con l'implementazione specifica dell'organizzazione

Esegui il push dell'implementazione specifica dell'organizzazione di SEDATED® nel repository Git desiderato dall'organizzazione (GitHub, GitLab, Git, ecc...).

5. Punta l'hook pre-receive al file pre-receive.sh di SEDATED®

Le istruzioni per farlo su un'istanza GitHub Enterprise sono disponibili in GitHub_Enterprise_Setup.md.

Test Locali

• GitHub Docker Setup - Istruzioni generali per configurare un container Docker GitHub che funga da server Git con un hook pre-receive abilitato per i test locali.
  • Saranno necessarie alcune modifiche per consentire a SEDATED® di funzionare come previsto.
    • always_reject.sh dovrà essere sostituito con lo script pre-receive.sh di SEDATED®.
    • I file/la struttura di cartelle associati a SEDATED® dovranno essere inclusi nella stessa directory / accessibili dallo script pre-receive.sh.
    • Potrebbero essere necessarie anche alcune modifiche aggiuntive, ma le istruzioni linkate sopra sono un buon punto di partenza per i test locali.

Descrizione dei File

pre-receive.sh

• Il cuore e l'anima di SEDATED®.
• Lo script hook Git pre-receive di SEDATED®, utilizzato insieme alle regex di SEDATED® (config/regexes.json), identifica le righe di codice aggiunte o modificate inviate tramite push a un'istanza Git che contengono credenziali/dati sensibili hard-coded (come identificati in config/regexes.json) e impedisce il push SE vengono trovate righe contenenti credenziali/dati sensibili hard-coded.

/config/custom_configs.sh

• Il file di configurazione personalizzata di SEDATED®, usato insieme a pre-receive.sh, consente alle organizzazioni di personalizzare la propria implementazione di SEDATED® senza dover modificare alcun codice sorgente all'interno del file pre-receive.sh di SEDATED®, fornendo variabili e funzioni personalizzabili integrate che vengono caricate da pre-receive.sh.

/config/enforced_repos_list.txt

• Utilizzato quando il flag use_enforced_repo_check_custom di SEDATED® (hook pre-receive) in config/custom_configs.sh è impostato su "True".
• Consente a SEDATED® di essere "abilitato" globalmente all'interno dell'organizzazione, ma "applicato" selettivamente solo ai repository elencati in questo file.
• L'applicazione per tutti i repository sotto una specifica organizzazione o nome utente può essere ottenuta aggiungendo /* alla fine dell'organizzazione o del nome utente in cui si desidera l'applicazione.
• Se SEDATED® è abilitato globalmente in un'organizzazione e non compare nel file /config/enforced_repos_list.txt, chi esegue il push (se da riga di comando) vedrà un messaggio personalizzabile (personalizzabile tramite il file /config/custom_configs.sh) e SEDATED® NON scansionerà alcun codice incluso nel push.
• Il flag per abilitare/disabilitare questa funzionalità si trova in /config/custom_configs.sh e può essere impostato su "True" o "False".
  • "False" - Ogni repository con SEDATED® "abilitato" avrà anche SEDATED® "applicato" su di esso.
  • "True" - Solo i repository con SEDATED® "abilitato" E elencati in /config/enforced_repos_list.txt avranno SEDATED® "applicato" su di essi. Tutti gli altri repository con SEDATED® "abilitato" ma non elencati nel file /config/enforced_repos_list.txt vedranno solo un messaggio personalizzato; nessun codice verrà scansionato per i push da quei repository.
• Questo file può essere vuoto; deve solo esistere se il flag use_enforced_repo_check_custom in config/custom_configs.sh è impostato su "True".

/config/regexes.json

• Contiene le espressioni regolari (regex) utilizzate per segnalare dati sensibili/credenziali hard-coded.
• Queste regex vengono usate da GNU grep (in pre-receive.sh) con il flag -P, rendendole espressioni regolari compatibili con Perl (PCRE).
• Le regex possono essere aggiunte o rimosse da questo file secondo necessità; tuttavia, se si utilizza lo script /testing/regex_testing/regex_test_script.sh, il file /testing/regex_testing/test_cases.txt dovrà essere aggiornato aggiungendo o rimuovendo i casi di test relativi alle regex aggiornate, affinché i risultati di /testing/regex_testing/regex_test_script.sh siano accurati.
• Se si aggiungono/modificano regex in questo file, potrebbero essere necessari caratteri di escape aggiuntivi \ a seconda delle regex desiderate, poiché questo file è in formato JSON.

/config/whitelists/commit_whitelist.txt

• Utilizzato in caso di falso positivo: uno o più commit possono essere esclusi dal processo di scansione se i loro ID di commit sono inclusi in questo file.
• Gli ID di commit dovranno essere separati da ritorni a capo in questo file, come mostrato nel file /config/whitelists/commit_whitelist.txt.example.
• Questo file può essere vuoto, ma deve esistere.

Opzionale: chiedere agli sviluppatori di inviare pull request a questo file (commit_whitelist.txt) quando incontrano falsi positivi, così da poterli esaminare.

/config/whitelists/repo_whitelist.txt

• I repository (organizzazione/nome utente) inclusi in questo file saranno completamente esclusi dalla scansione di dati sensibili/credenziali hard-coded finché non verranno rimossi da questo elenco.
• Utilizzato in caso di push massicci (ad esempio migrazione di repository) in cui SEDATED® non può scansionare il codice nuovo/modificato incluso nel push entro la finestra di 5 secondi (la finestra di 5 secondi è specifica di GitHub e può essere diversa su altre istanze Git).
• I nomi dei repository (organizzazione/nome utente) devono essere separati da ritorni a capo in questo file, come mostrato nel file /config/whitelists/repo_whitelist.txt.example.
• Questo file può essere vuoto, ma deve esistere.

/testing/regex_testing/regex_test_script.sh

• Lo script di test delle espressioni regolari di SEDATED®, utilizzato insieme a testing/regex_testing/test_cases.txt, è un modo semplice, rapido e offline per testare/validare che le espressioni regolari dentro config/regexes.json siano valide, corrispondano ai pattern desiderati ed escludano/non corrispondano come previsto.
  • Testa le regex contro un elenco di casi di test (/testing/regex_testing/test_cases.txt) per verificare che le regex funzionino come previsto.
  • Include test sia per casi positivi che negativi (/testing/regex_testing/test_cases.txt).
  • È OBBLIGATORIO usare GNU grep quando si esegue lo script, altrimenti lo script fallirà (BSD grep non ha il flag -P).
  • I casi di test utilizzati in questo script vengono caricati da /testing/regex_testing/test_cases.txt.

/testing/regex_testing/test_cases.txt

• Elenco di casi di test da passare a /testing/regex_testing/regex_test_script.sh per l'elaborazione.
• A ogni caso di test viene aggiunto >>pass o >>fail; questi indicano allo script /testing/regex_testing/regex_test_script.sh quale sia l'aspettativa per le regex.
  • >>pass significa che un push contenente la stringa precedente sarà accettato da SEDATED® (cioè le regex NON segnaleranno la stringa precedente).
  • >>fail significa che un push contenente la stringa precedente sarà rifiutato da SEDATED® (cioè le regex segnaleranno la stringa precedente).

Personalizzazione

Variabili e funzioni personalizzate sono progettate per consentire alle organizzazioni di personalizzare facilmente la propria implementazione specifica di SEDATED® senza modificare il file hook pre-receive principale che svolge tutto il lavoro pesante. Tutte le variabili e funzioni personalizzate si trovano in /config/custom_configs.sh; di seguito sono elencate le spiegazioni delle variabili contenute in questo file.

Variabili Personalizzate

• show_SEDATED_link_custom - "True" per mostrare il link al repository GitHub OWASP/SEDATED (sensibile alle maiuscole), altrimenti impostare su "False".
• documentation_link_custom - Aggiungi il link alla documentazione specifica dell'organizzazione su come l'organizzazione desidera che gli sviluppatori gestiscano i push rifiutati e/o informazioni generali specifiche dell'organizzazione relative a SEDATED®.
  • Visualizzato allo sviluppatore quando un push viene rifiutato.
  • Visualizzato allo sviluppatore quando il controllo del repository applicato è impostato su true e il repository non è incluso nel file enforced_repos_list.txt.
• use_enforced_repo_check_custom - "True" o "False" (sensibile alle maiuscole).
  • Vedi la descrizione del file /config/enforced_repos_list.txt sopra per maggiori dettagli sul significato di questo flag.
• enforced_repo_check_true_message_custom con messaggio personalizzato (necessario solo se use_enforced_repo_check_custom è impostato su "True").
• obfuscate_output_custom - "True" o "False" (sensibile alle maiuscole). Usa questa opzione per mascherare i dati sensibili visualizzati nell'output di SEDATED®.

Funzioni Personalizzate

• SET_USER_REPO_NAME_CUSTOM
  • Imposta il nome di utente/organizzazione/gruppo e repository.
  • Imposta il nome di utente/organizzazione/gruppo e repository usando la variabile GITHUB_REPO_NAME se si utilizza GitHub.
  • Se non si utilizza GitHub, è possibile impostare variabili personalizzate per ottenere questi nomi.
  • I nomi non-GitHub forniti sono configurati solo per ottenere i nomi in Git puro (vanilla Git), ma potrebbero dover essere adattati in base a diverse implementazioni (Git SCM).
• PRINT_ERROR_MESSAGE_CUSTOM
  • Consente di stampare un messaggio di errore personalizzato quando si verificano errori.
• EXIT_SEDATED_CUSTOM
  • Esegue un'azione personalizzata aggiuntiva quando si esce da SEDATED® (es. log, invio metriche, ecc...).
  • Il default è : "non fare nulla" come azione aggiuntiva e non è necessario modificarlo.
• UNABLE_TO_ACCESS_REPO_WHITELIST_CUSTOM
  • Esegue un'azione personalizzata aggiuntiva quando SEDATED® non riesce ad accedere al file whitelist dei repository (es. stampa messaggio di errore, log, invio metrica, ecc...).
  • Il default è : "non fare nulla" come azione aggiuntiva e non è necessario modificarlo.
• PUSH_ACCEPTED_CUSTOM
  • Esegue un'azione personalizzata aggiuntiva quando un push viene accettato (es. log, invio metriche, ecc...).
  • Il default è : "non fare nulla" come azione aggiuntiva e non è necessario modificarlo.
• UNABLE_TO_ACCESS_REGEXES_CUSTOM
  • Esegue un'azione personalizzata aggiuntiva quando SEDATED® non riesce ad accedere al file regexes.json.
  • Il default è : "non fare nulla" come azione aggiuntiva e non è necessario modificarlo.
  • SEDATED® eseguirà exit 1 e stamperà un messaggio di errore se non riesce ad accedere alle regex; tuttavia, se desiderato, in questi casi può essere eseguita un'azione personalizzata aggiuntiva (es. stampa di un messaggio di errore aggiuntivo, log, invio metrica, ecc...).
• PUSH_REJECTED_WITH_VIOLATIONS_CUSTOM
  • Esegue un'azione personalizzata aggiuntiva quando i push vengono rifiutati perché contengono violazioni (es. log, invio metriche, ecc...).
  • Il default è : "non fare nulla" come azione aggiuntiva e non è necessario modificarlo.
• UNABLE_TO_ACCESS_COMMIT_WHITELIST_CUSTOM
  • Esegue un'azione personalizzata aggiuntiva quando SEDATED® non riesce ad accedere al file whitelist dei commit (es. log, invio metriche, ecc...).
  • Il default è : "non fare nulla" come azione aggiuntiva e non è necessario modificarlo.

Compatibilità

Compatibile solo con strumenti SCM che utilizzano il sistema di controllo versione Git.

• GitHub
  • Testato completamente (Enterprise v2.15.3).
  • SEDATED® GitHub Enterprise Setup.
• GitLab
  • Testato preliminarmente.
  • Saranno necessarie modifiche a SET_USER_REPO_NAME_CUSTOM per impostare utente/org e nome repository.
• Git
  • Testato preliminarmente.
  • Tutti i file/cartelle di SEDATED® dovranno essere inseriti nella directory .git/hooks/ (tranne i file/cartelle di documentazione).
  • Rimuovi .sample da pre-receive.sample e copia il codice dal file pre-receive.sh di SEDATED® nel file pre-receive appena creato dal file .sample.
  • A seconda dell'implementazione, potrebbe essere opportuno utilizzare git-template o qualcosa di simile.
• Qualsiasi Altro Strumento Git SCM
  • Non testato.
  • Saranno probabilmente necessarie modifiche a SET_USER_REPO_NAME_CUSTOM per impostare utente/org e nome repository.
  • Potrebbero essere necessarie ulteriori modifiche per funzionare.

Contribuisci

Contributi a questo progetto benvenuti!

Puoi contribuire in uno dei seguenti modi:

• Inviaci le tue idee per miglioramenti (o a chiunque nella community voglia raccogliere la sfida di trasformare la tua idea in realtà all'interno del codebase di SEDATED®) apri una issue con una buona spiegazione di cosa pensi potrebbe migliorare SEDATED® e come pensi che possa realizzarsi concretamente nel codebase.
• Invia una pull request con le tue modifiche al codice per rendere SEDATED® migliore: la esamineremo, la testeremo e la uniremo. :)

Autori

• Dennis Kennedy
• Simeon Cloutier

Licenza

SEDATED® è distribuito sotto la BSD 3-Clause "New" or "Revised" License.

**SEDATED® non è garantito che segnali ogni istanza di credenziali hard-coded, chiavi, segreti, ecc... utilizza il pattern matching tramite regex e, sebbene sia diventato abbastanza bravo a catturare la maggior parte delle istanze, non è perfetto; siamo comunque sempre aperti a idee e/o pull request per contribuire a rendere SEDATED® ancora migliore.