Credactor

Trouvez le secret. Corrigez-le. Commitez proprement.

Les scanners de secrets sont doués pour tirer la sonnette d'alarme, mais beaucoup moins pour éteindre l'incendie. Ils vous remettent une liste de credentials fuités et vous laissent le nettoyage. Credactor boucle la boucle : il trouve un secret codé en dur et le réécrit sur place, pour qu'une fuite passe de la détection à la correction en une seule commande.

Garder les credentials hors du code source est une pratique de sécurité de base, pas une option. Credactor rend cette base facile à tenir, sur votre machine avant un commit ou en CI avant un merge. Utilisez-le seul, ou aux côtés des scanners auxquels vous faites déjà confiance.

# Credactor trouve ceci :
db_password = "h8Tq2vKp9mRz4Wd"

# Par défaut, il réécrit le secret comme un sentinelle qui échoue bruyamment à l'exécution :
db_password = "REDACTED_BY_CREDACTOR"

# Avec --replace-with env, il écrit une référence qui lit depuis l'environnement :
db_password = os.environ["DB_PASSWORD"]

Le masquage réécrit les fichiers dans votre arbre de travail. Si un secret a déjà été commité, faites pivoter la clé et nettoyez aussi l'historique (par exemple avec git filter-repo). Réécrire un fichier ne remplace pas la révocation d'un credential fuité.

Pourquoi Credactor

• Masquage, pas seulement détection. La plupart des scanners s'arrêtent à la découverte. Credactor remplace le secret sur place : une sentinelle bruyante REDACTED_BY_CREDACTOR qui échoue à l'exécution par défaut, ou une référence de variable d'environnement adaptée au langage (Python, JavaScript/TypeScript, Go, Java/Kotlin, Ruby, PHP et shell) comme os.environ["KEY"]. Le remplacement est du code valide. Si le fichier n'inclut pas déjà l'import correspondant (par exemple import os), ajoutez-le.
• Sûr par défaut. Écritures atomiques, sauvegardes automatiques .bak, garde-fous sur les liens symboliques et les permissions de fichiers, et masquage complet des secrets dans toutes les sorties. Si une sauvegarde sûre ne peut pas être écrite, Credactor ignore le fichier plutôt que de le réécrire à l'aveugle, et un crash en cours d'écriture laisse l'original intact.
• Zéro dépendance à l'exécution. Bibliothèque standard Python 3.11+ pure, plus un extra optionnel pour les encodages non UTF-8.
• Conçu pour le pipeline. Sortie SARIF pour GitHub Code Scanning, un garde-fou --ci en lecture seule avec des codes de sortie précis, un hook pre-commit (bêta), et l'ingestion de rapports Gitleaks ou TruffleHog. Détectez avec Gitleaks ou TruffleHog, corrigez avec Credactor.

Installation

pip install credactor

Nécessite Python 3.11+. Aucune autre dépendance. Fonctionne sur Linux, macOS et Windows (testé en CI sur Linux et Windows).

Depuis les sources :

git clone https://github.com/rxb06/credactor.git
cd credactor
pip install -e .

credactor fonctionne ensuite depuis n'importe quel répertoire.

Démarrage rapide

Lancez --dry-run d'abord et examinez les résultats avant de masquer. Les faux positifs sont possibles, et avec --fix-all, un faux positif est réécrit. Supprimez les valeurs connues comme sûres avec # credactor:ignore ou une entrée .credactorignore.

credactor --dry-run .                 # scannez, ne changez rien
credactor .                           # scannez, puis masquez de manière interactive (o/n par résultat)
credactor --fix-all .                 # masquez tout après une seule confirmation
credactor --fix-all --yes .           # masquez de manière non interactive (CI / scripts)
credactor --ci .                      # garde-fou en lecture seule : code de sortie 1 en cas de résultats
credactor --replace-with env .        # masquez vers des références de variables d'environnement au lieu de la sentinelle

Hook pre-commit (bêta)

L'intégration du hook est en bêta. Lancez credactor --dry-run . manuellement avant de vous y fier seul.

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/rxb06/credactor
    rev: v2.6.0   # épinglez au dernier tag de version
    hooks:
      - id: credactor

Détection

Credactor détecte les types de credentials qui fuient le plus souvent, et attribue à chacun une sévérité pour que vous puissiez trier d'un coup d'œil.

Les jetons déterministes de fournisseurs (les préfixes ci-dessus) sont signalés quelle que soit l'entropie. Les détecteurs heuristiques (JWT, chaînes de connexion, hexadécimal, Base64) doivent franchir un seuil d'entropie. L'hexadécimal ou le Base64 isolé n'est signalé que s'il est entre guillemets. Une valeur à haute entropie sans guillemets n'est détectée que sur une variable au nom de credential, ce qui épargne les SHA git et les sommes de contrôle. Pour les règles complètes de détection et de sévérité, consultez le Manuel.

L'ensemble de règles natif de Credactor est plus restreint que celui d'un scanner dédié, et certains formats de fournisseurs (par exemple SendGrid, Twilio et les webhooks Slack) ne sont pas détectés. Son atout est la correction : associez-le à Gitleaks ou TruffleHog pour la détection la plus large, ou utilisez-le seul.

Associez-le à un autre scanner, masquez le tout

Credactor se suffit à lui-même, et il gagne en force en compagnie. Vous utilisez déjà Gitleaks ou TruffleHog ? Passez leur rapport à Credactor et il masque l'ensemble combiné, dédupliqué par rapport à ses propres résultats (en cas de chevauchement, la sévérité la plus élevée l'emporte). Une seule passe de correction couvre votre scan et le leur :

gitleaks dir . -f json -r gitleaks.json
credactor --from-gitleaks gitleaks.json --fix-all --yes .

--from-gitleaks / --from-trufflehog (ou une table [ingest] dans .credactor.toml) exigent une cible de répertoire — pointez Credactor vers la même racine que celle où le scanner a été exécuté. Les chemins des rapports sont résolus par rapport au répertoire de travail, et un rapport est un instantané : régénérez-le après avoir masqué ou modifié l'arbre. Consultez le guide Intégration CI.

Autres fonctionnalités

• Masquage interactif ou par lots ; une chaîne de remplacement personnalisée via --replacement ; --scan-history pour scanner l'historique des commits git
• Sauvegardes sécurisées : --secure-delete (écrase et supprime le .bak ; élève la barre contre la récupération occasionnelle, pas une garantie forensique) ou --secure-backup-dir pour stocker les sauvegardes hors du dépôt
• Listes blanches en ligne # credactor:ignore et .credactorignore (glob, file:line, littéraux de valeurs)
• Configuration par dépôt via .credactor.toml
• 29 types de fichiers source/config/notes pris en charge par défaut (.txt inclus) ; --scan-json pour inclure le JSON ; --fail-on-error pour échouer lorsqu'un fichier ne peut pas être lu

Types de fichiers scannés

.py .js .ts .jsx .tsx .sh .bash .env .cfg .ini .toml .yaml .yml .rb .go .java .php .cs .kt .tf .hcl .conf .config .properties .xml .pem .key .crt .txt

Plus les variantes .env.* / .env-* (.env.local, .env.production) et les fichiers SSH / clés privées (id_rsa, id_dsa, id_ecdsa, id_ed25519), tous identifiés par nom de fichier plutôt que par extension. Le JSON est exclu par défaut car les réponses d'API produisent un taux de faux positifs élevé ; ajoutez --scan-json pour l'inclure. Un fichier nommé directement en ligne de commande est scanné même si son extension ne figure pas dans cette liste.

Codes de sortie

Durcissement de la chaîne d'approvisionnement

Un outil de sécurité doit être sûr à installer, pas seulement sûr à exécuter. Le pipeline de construction et de publication de Credactor est durci de bout en bout ; tous les détails dans le document Sécurité.

• Zéro dépendance à l'exécution. Un pip install credactor par défaut n'installe aucun paquet tiers (seul l'extra optionnel [encoding]), donc rien à vérifier au moment de l'installation.
• Chaîne d'outils épinglée par hash. Les builds CI et de publication installent depuis un fichier de verrouillage --require-hashes, backend de build inclus (python -m build --no-isolation contre un setuptools épinglé), donc une dépendance falsifiée fait échouer le build.
• Artefacts vérifiés octet par octet contre les sources. À chaque push et avant chaque publication, scripts/audit_wheel.py compare la wheel et le sdist aux sources commitées octet par octet (sha256 vs git HEAD) ; tout fichier ajouté, manquant ou modifié fait échouer le garde-fou, donc une étape de build ne peut pas injecter de code sans être remarquée.
• CI épinglée par SHA, privilèges minimaux. Les GitHub Actions sont épinglées aux SHA de commits, et les jetons de workflows restent étroits — contents: read par défaut, id-token: write uniquement pour le job de publication.

Documentation

Licence

Apache 2.0. Voir LICENSE.