Sift Secrets

Triagem de exposição de credenciais e dados sensíveis para compartilhamentos de arquivos.

Quando um compartilhamento aberto aparece, a pergunta nunca é "esse repositório tem uma chave vazada". É "o que exatamente foi exposto, e o que preciso rotacionar antes do fim do expediente." o sift foi feito para essa pergunta: alta revocação, uma fila de revisão rápida, e um ciclo de feedback para que qualquer coisa que você identifique a olho nu vire uma regra que encontra as outras duzentas cópias.

Python 3.11+, apenas biblioteca padrão. Sem pip install, sem internet, sem etapa de build. Ele roda em um laptop de IR isolado, que é onde você precisa.```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

A verificação no local também funciona. Experimente primeiro em um compartilhamento de credenciais fabricadas:```bash
sift demo C:\temp\demoshare

sift.cmd é um launcher que funciona a partir de qualquer diretório. Para digitar sift em vez do caminho completo, adicione C:\Dev\sift ao PATH:```bash setx PATH "%PATH%;C:\Dev\sift"

Para uma máquina sem Python algum, `python build_portable.py` gera
`dist/sift-secrets-<version>-portable-win64.zip`: o runtime embutível oficial do python.org
mais esta árvore de origem, basta descompactar e executar via o `sift.cmd` incluso.
~11 MB, sem instalação, sem direitos de administrador, e nada nele é compilado ou
reempacotado — veja o docstring em `build_portable.py` para entender por que isso
supera um .exe congelado em um laptop de IR bloqueado.

---

## Por que não apenas gitleaks ou trufflehog

Ambas são boas ferramentas que resolvem um problema diferente.

São ferramentas de **precisão** criadas para CI, onde um falso positivo custa a
tarde de um desenvolvedor, então disparam principalmente em coisas com formato de uma
chave de API de fornecedor conhecida. o trufflehog vai além e prefere segredos que consegue *verificar* ao
chamar a API do fornecedor, o que é um sinal genuinamente excelente que regex
não consegue reproduzir.

A triagem de compartilhamento inverte a economia. Um humano já está lendo cada ocorrência, então um
falso positivo custa três segundos. O que te custa é uma **falha**.

Chaves de API de fornecedores definitivamente vazam em compartilhamentos - um backup da raiz da web, um
script de implantação, a pasta de projeto de alguém copiada para o drive departamental, e há
um `.env` com uma chave Stripe viva dentro. Esses casos valem a pena detectar, e o sift
os detecta. Mas eles também são a parte que gitleaks e trufflehog já lidam
bem. A lacuna é todo o resto, e em um compartilhamento de arquivos isso é a maior parte:

| O que os scanners de CI deixam passar | Por que eles passam por cima |
|---|---|
| `web.config` com uma string de conexão SQL | Não é um formato de chave conhecido, não há fornecedor para verificar |
| `Map-Drives.ps1` com `net use ... /user:` | Apenas um comando de shell com uma palavra depois |
| `New Hire Setup Guide.docx` | Arquivo do Office, lido como binário, ignorado completamente |
| `unattend.xml`, GPP `Groups.xml` | Artefatos de implantação do Windows para os quais ninguém escreveu um detector |
| `confCons.xml`, `.rdg`, WinSCP.ini | Senhas armazenadas de forma reversível, mas não um "formato de segredo" |
| `passwords.xlsx` | É um ZIP. Scanners de texto simples veem binário e seguem em frente |
| `.kdbx`, `.pfx`, `id_rsa` | Bytes opacos - o *nome do arquivo* é a descoberta |
| Um `.bak` com uma string de conexão dentro | Binário, então nunca é lido |

o sift cobre esses casos, traz suas próprias regras de chave de fornecedor e **importa
pacotes de regras e descobertas de outras ferramentas** - TOML do gitleaks, YAML do Kingfisher/Titus e
JSON do trufflehog - para que você não esteja escolhendo entre ferramentas.

O trabalho anterior mais próximo é o [Snaffler](https://github.com/SnaffCon/Snaffler), que é
excelente na metade de nomes de arquivo e classificação disso e é a
inspiração direta para as regras de nomes de arquivo. O que ele não tem - e o que acaba
sendo o gargalo real quando você tem 400 ocorrências - é um ciclo de revisão.

---

## O ciclo

1. **Escanee** o compartilhamento.
2. **Trabalhe na fila.** Cada descoberta mostra suas linhas ao redor com a correspondência
   destacada. As setas do teclado ampliam o contexto; um clique abre o arquivo inteiro no
   VS Code naquela linha, ou no Notepad.
3. **Perceba uma falha.** Você vai. Destaque-a na pré-visualização e pressione `r`.
4. **o sift propõe padrões** e informa ao vivo quantas vezes cada um corresponderia
   em tudo que já foi lido.
5. **Salve.** O novo escaneamento em cache leva cerca de um segundo, e as novas ocorrências aparecem
   na fila com suas decisões de triagem existentes intactas.

O passo 5 é a parte que faz o resto valer a pena. As descobertas têm como chave
`(path, rule, line, value-hash)`, então um novo escaneamento re-insere as mesmas linhas e seus
status, notas e responsável seguem junto. Sem isso, você teria que revisar as mesmas
300 ocorrências em cada iteração e desistiria na terceira.

---

## Comandos```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

Em qualquer lugar onde sift aparece, você pode usar python -m sift no lugar, a partir do diretório C:\Dev\sift.

Opções que vale a pena conhecer