Sift Secrets

Tri des expositions d'identifiants et de données sensibles dans les partages de fichiers.

Lorsqu'un partage ouvert apparaît, la question n'est jamais « est-ce que ce dépôt contient une clé divulguée ? ». C'est « qu'est-ce qui vient d'être exposé, et que dois-je révoquer avant la fermeture des bureaux ? ». sift est conçu pour cette question : rappel élevé, file d'examen rapide, et une boucle de rétroaction pour que tout ce que vous repérez à l'œil nu devienne une règle qui trouve les deux cents autres copies.

Python 3.11+, bibliothèque standard uniquement. Pas de pip install, pas d'internet, aucune étape de compilation. Il fonctionne sur un ordinateur portable d'IR durci, là où vous en avez besoin.```bash sift survey \fileserver\openshare # how big is this thing sift copy \fileserver\openshare C:\IR\case-4471 # take a throttled copy sift scan C:\IR\case-4471 # scan it, opens the triage UI

L'analyse sur place fonctionne aussi. Essayez-la d'abord sur un partage d'identifiants factices :```bash
sift demo C:\temp\demoshare

sift.cmd est un lanceur qui fonctionne depuis n'importe quel répertoire. Pour taper sift au lieu du chemin complet, ajoutez C:\Dev\sift à PATH :```bash setx PATH "%PATH%;C:\Dev\sift"

Pour une machine sans Python du tout, `python build_portable.py` construit
`dist/sift-secrets-<version>-portable-win64.zip` : le runtime embarquable officiel de python.org
plus cette arborescence source, à décompresser et exécuter via le
`sift.cmd` fourni. ~11 Mo, pas d'installation, pas de droits administrateur, et rien n'y est
compilé ni réemballé — voir la docstring dans `build_portable.py` pour comprendre pourquoi
c'est mieux qu'un .exe figé sur un ordinateur portable IR verrouillé.

---

## Pourquoi pas simplement gitleaks ou trufflehog

Ce sont tous deux de bons outils qui résolvent un problème différent.

Ce sont des outils de **précision** conçus pour la CI, où un faux positif coûte à un
développeur son après-midi, alors ils ne se déclenchent principalement que sur des éléments ressemblant à une
clé API de fournisseur connue. trufflehog va plus loin et privilégie les secrets qu'il peut *vérifier* en
appelant l'API du fournisseur, ce qui est un signal vraiment excellent que la regex
ne peut pas reproduire.

Le tri des partages inverse l'économie. Un humain lit déjà chaque résultat, donc un
faux positif coûte trois secondes. Ce qui vous coûte, c'est un **faux négatif**.

Les clés API de fournisseurs fuient bel et bien sur les partages - une sauvegarde de la racine web, un script
de déploiement, le dossier de projet de quelqu'un copié sur le lecteur du département, et il y a
un `.env` avec une clé Stripe active dedans. Elles valent la peine d'être détectées, et sift
les détecte. Mais c'est aussi la partie que gitleaks et trufflehog gèrent déjà
bien. La lacune, c'est tout le reste, et sur un partage de fichiers c'en est la majeure partie :

| Ce que les scanners CI manquent | Pourquoi ils passent à côté |
|---|---|
| `web.config` avec une chaîne de connexion SQL | Pas un format de clé connu, aucun fournisseur pour vérifier |
| `Map-Drives.ps1` avec `net use ... /user:` | Juste une commande shell avec un mot après |
| `New Hire Setup Guide.docx` | Fichier Office, lu comme binaire, entièrement ignoré |
| `unattend.xml`, GPP `Groups.xml` | Artefacts de déploiement Windows pour lesquels personne n'a écrit de détecteur |
| `confCons.xml`, `.rdg`, WinSCP.ini | Mots de passe stockés de manière réversible, mais pas un « format secret » |
| `passwords.xlsx` | C'est un ZIP. Les scanners de texte brut voient du binaire et passent à autre chose |
| `.kdbx`, `.pfx`, `id_rsa` | Octets opaques - le *nom de fichier* est la trouvaille |
| Un `.bak` avec une chaîne de connexion à l'intérieur | Binaire, donc jamais lu |

sift couvre tout cela, fournit ses propres règles de clés de fournisseur, et **importe les packs de règles
et les résultats d'autres outils** - gitleaks TOML, Kingfisher/Titus YAML, et
trufflehog JSON - donc vous n'avez pas à choisir entre les outils.

L'art antérieur le plus proche est [Snaffler](https://github.com/SnaffCon/Snaffler), qui est
excellent dans la moitié nom-de-fichier-et-classification de ce problème et est l'inspiration
directe pour les règles de noms de fichiers. Ce qu'il n'a pas - et ce qui s'avère
être le véritable goulot d'étranglement une fois que vous avez 400 résultats - c'est une boucle de revue.

---

## La boucle

1. **Scannez** le partage.
2. **Traitez la file d'attente.** Chaque résultat montre les lignes environnantes avec la correspondance
   surlignée. Les touches fléchées élargissent le contexte ; un clic ouvre le fichier entier dans
   VS Code à cette ligne, ou dans Notepad.
3. **Repérez un oubli.** Vous en trouverez. Surlignez-le dans l'aperçu et appuyez sur `r`.
4. **sift propose des motifs** et vous indique en direct combien de fois chacun correspondrait
   sur tout ce qui a déjà été lu.
5. **Enregistrez-le.** La renumérisation en cache prend environ une seconde, et les nouveaux résultats apparaissent
   dans la file d'attente sans que vos décisions de tri existantes soient modifiées.

L'étape 5 est ce qui rend le reste digne d'intérêt. Les résultats sont indexés sur
`(path, rule, line, value-hash)`, donc une renumérisation réinsère les mêmes lignes et vos
statut, notes et propriétaire suivent. Sans cela, vous réexamineriez les mêmes
300 résultats à chaque itération et abandonneriez à la troisième.

---

## Commandes```bash
# size it up first: file count, total bytes, biggest folders, transfer estimates
sift survey \\fileserver\share

# take a rate-limited local copy (resumable; gentle = 5 MB/s by default)
sift copy \\fileserver\share C:\IR\case-4471 --speed gentle

# scan a share and open the triage UI
sift scan \\fileserver\share

# maximum recall: more noise, but a human is reading anyway
sift scan D:\dfs\dept --tier 3

# re-open the UI over the most recent scan
sift ui

# build a share of fabricated credentials, scan it, open the UI
sift demo C:\temp\demoshare

# inherit other tools' vendor-key rules, then use them in the live rescan loop
sift import-rules gitleaks.toml                    # gitleaks TOML
sift import-rules path/to/kingfisher/data/rules    # a directory of YAML

# pull in what the other scanners found, into the same queue
trufflehog filesystem \\fileserver\share --json > th.json
sift import-findings th.json

# hand off to the incident record (redacted unless you say otherwise)
sift export --fmt pdf --status confirmed --out ir-4471.pdf
sift export --fmt csv --out ir-4471.csv
sift export --fmt pdf --no-redact       # plaintext; handle as evidence

sift rules                              # what is loaded
sift selftest                           # detection tests against a synthetic share

# ask vendors whether confirmed findings are still live. NETWORK. Opt-in.
sift validate --status confirmed

Partout où sift apparaît, vous pouvez utiliser python -m sift à la place, depuis le répertoire C:\Dev\sift.

Options à connaître