
Anteater - Framework di controllo dei gate CI/CD
Anteater è un framework aperto per prevenire l'unione indesiderata di stringhe nominate, nomi di file, binari, funzioni deprecate, codice/credenziali di ambienti di staging, ecc. Qualsiasi cosa possa essere specificata con la sintassi delle espressioni regolari può essere scoperta da anteater.
Dici ad anteater esattamente cosa non vuoi venga unito, e anteater si occupa del resto.
Se anteater trova qualcosa, esce con un codice diverso da zero che a sua volta fa fallire la build del tuo strumento CI, con l'idea di impedire l'unione di una pull request. Eventuali falsi positivi sono facilmente negati utilizzando lo stesso framework RegExp per annullare la corrispondenza falsa.
Possono essere scansionati anche interi progetti, utilizzando una camminata ricorsiva delle directory.
Con pochi semplici passaggi può essere facilmente implementato in un workflow CI/CD con strumenti come Travis CI, CircleCI, Gitlab CI/CD e Jenkins.
È attualmente utilizzato nel progetto della Linux Foundation 'OPNFV' come mezzo per fornire controlli di sicurezza automatizzati al gate, ma come mostrato negli esempi seguenti, può essere utilizzato per altri scenari.
Anteater fornisce anche integrazioni con l'API Virus Total, quindi qualsiasi binario, indirizzo IP pubblico o URL trovato da anteater verrà inviato all'API Virus Total e verrà restituito un rapporto. Se un oggetto viene segnalato come dannoso, farà fallire il job di build CI.
Viene fornito un contenuto di esempio per coloro che non sono sicuri da dove iniziare, ed è incoraggiato e gradito condividere qualsiasi stringa di filtro di Anteater che trovi utile.
Anteater ha molti usi e può essere facilmente adattato per coprire le tue esigenze specifiche.
Innanzitutto, come accennato, può essere configurato per bloccare stringhe e file con un potenziale impatto o rischio di sicurezza. Questo potrebbe includere chiavi private, una cronologia della shell, credenziali AWS, ecc.
È particolarmente utile per garantire che gli elementi utilizzati in un ambiente di staging/sviluppo non finiscano in un ambiente di produzione.
Diamo un'occhiata ad alcuni esempi:
apprun:
regex: app\.run\s*\(.*debug.*=.*True.*\)
desc: "Running flask in debug mode could potentially leak sensitive data"
Il codice sopra corrisponderà a codice in cui un server flask è impostato per essere
eseguito in modalità debug app.run(host='0.0.0.0' port=80 debug=true), che può
essere tipico dell'ambiente di uno sviluppatore e essere erroneamente inserito in
produzione.
Per un'app rails, questo potrebbe essere:
regex: \<%=.*debug.*%>
Ancora più semplice, cerca il seguente nella maggior parte dei framework di logging:
regex: log\.debug
Hai bisogno di impedire agli sviluppatori di aggiungere erroneamente una chiave privata?
private_key:
regex: -----BEGIN\sRSA\sPRIVATE\sKEY----
desc: "This looks like it could be a private key"
Che dire dei file di credenziali che causerebbero la perdita del lavoro se mai trapelassero in produzione? Anteater funziona anche con i nomi dei file.
Per esempio:
jenkins\.plugins\.publish_over_ssh\.BapSshPublisherPlugin\.xml
O anche..
- \.pypirc
- \.gem\/credentials
- aws_access_key_id
- aws_secret_access_key
- LocalSettings\.php
Se la tua app ha i suoi file personalizzati di segreti/configurazione, allora è molto facile aggiungere le tue espressioni regolari. Tutto è impostato usando la formattazione YAML, quindi non è necessario modificare il codice di anteater.
Un altro uso è quando un progetto depreca una vecchia funzione, ma gli sviluppatori potrebbero ancora fare pull request usando la vecchia denominazione della funzione:
depreciated_function:``
regex: depreciated_function\(.*\)
desc: This function was depreciated in release X, use Y function.
O forse impedire alle persone di usare versioni 1.x di un framework:
<script.src.*="https:\/\/ajax\.googleapis\.com\/ajax\/libs\/angularjs\/1.*<\/script>
Facile, imposti una RegExp per fermare la corrispondenza, una specie di RegExp'ception.
Diciamo che vogliamo impedire l'uso di MD5:
md245:
regex: md[245]
desc: "Insecure hashing algorithm"
Questo poi viene erroneamente abbinato al seguente:
mystring = int(amd500) * 4
Impostiamo una RegExp di ignore specifica, in modo che corrisponda e poi venga annullata dalla voce di ignore.
mystring.=.int\(amd500\).*
Tuttavia, altre istanze di MD5 continuano a essere segnalate.
Con anteater, se passi l'argomento --binaries, qualsiasi binario trovato causa
un fallimento della build sulla pull request originale. Fino a quando non viene
impostato un checksum sha256 nei file YAML di ignore di anteater, la build non può
passare.
Ciò significa che puoi impedire alle persone di fare il check-in di oggetti compilati, immagini, PDF ecc. che potrebbero avere un'origine sconosciuta o manomissione dei file binari esistenti.
Un esempio:
$ anteater --binaries --project myproj --patchset /tmp/patch
Non Whitelisted Binary file: /folder/to/repo/images/pal.png
Please submit patch with this hash: 3aeae9c71e82942e2f34341e9185b14b7cca9142d53f8724bb8e9531a73de8b2
Inseriamo l'hash::
binaries:
images/pal.png:
- 3aeae9c71e82942e2f34341e9185b14b7cca9142d53f8724bb8e9531a73de8b2
Esegui di nuovo il job::
$ anteater --binaries --project myproj --patchset /tmp/patch
Found matching file hash for: /folder/to/repo/images/pal.png
In questo modo possiamo essere sicuri che i binari non vengano manomessi tramite una firma crittografica/checksum fallita.
Qualsiasi binario che non abbia un checksum sha256 verrà anche inviato all'API Virus Total per la scansione.
Se vengono utilizzati i seguenti flag (combinati o singolarmente) --ips,
-urls, --binaries, anteater eseguirà una ricerca nell'API Virus Total.
Gli indirizzi IP avranno la loro cronologia DNS controllata per eventuali connessioni precedenti o attuali con domini noti in blacklist contrassegnati come dannosi o contenenti malware.
Gli URL verranno controllati per eventuali connessioni precedenti o attuali con domini noti in blacklist contrassegnati come dannosi o contenenti malware.
Come accennato, i binari verranno inviati a Virus Total e verificati come puliti/infetti.
Per maggiori dettagli e documentazione approfondita, visita readthedocs
Ultima cosa, se usi anteater, mi piacerebbe saperlo (twitter: @decodebytes) e pull request / issues sono benvenute!
I contributi sono benvenuti.
Per favore fai una pull request in un nuovo ramo, non su master.
git checkout -b mypatch
git push origin mypatch
I test unitari e i controlli PEP8 sono in tox, quindi esegui semplicemente il comando
tox prima di inviare il tuo codice.
Se la tua patch corregge un problema, incolla l'URL del problema nel messaggio di commit.