dragon-lady/push-guardCrochet Git local pre-push et scanner de système de fichiers qui détecte les fuites de secrets probables, masque les valeurs correspondantes et bloque les push sans télémétrie ni accès réseau.
Push Guard est un garde pre-push Git local pour les fuites de secrets probables.
Il analyse le contenu en cours de push, signale les motifs de secrets probables, masque toutes les valeurs correspondantes et se termine avec un code non nul afin que Git bloque le push.
Développé et maintenu par Dragon Lady - github.com/Dragon-Lady - X : @answerislove2
La version 0.4.3 supprime l'exception en ligne # push-guard: ignore. Une mise à niveau peut commencer à bloquer des pushs et des paquets qui passaient auparavant. Avant de mettre à niveau des hooks partagés ou des installations CI, inspectez chaque dépôt consommateur :
git grep -n -i 'push-guard:[[:space:]]*ignore'
Examinez chaque correspondance. Supprimez les secrets et les éléments privés ; ni les uns ni les autres ne peuvent faire l'objet d'une exemption.
Pour les fixtures légitimes de workflow/IOC, ajoutez uniquement le chemin exact du dépôt examiné et les ID de règle workflow.* exacts à .push-guard-allow. Les marqueurs en ligne sont désormais du texte ordinaire, y compris ceux présents dans les tests ou la documentation. Ne convertissez pas automatiquement toutes les lignes de marqueur en autorisations. Examinez toute nouvelle autorisation comme une modification sensible du point de vue de la sécurité.
Le hook pre-push lit les exceptions à partir du commit de base annoncé par la destination, jamais depuis la copie de travail ni les commits candidats. Une autorisation nouvelle ou élargie doit être examinée et établie séparément avant de pouvoir exempter un push ultérieur. Pour un push multi-ref, seules les exceptions partagées par toutes les bases de destination s'appliquent. Les nouvelles refs sans base annoncée ne reçoivent aucune exception.
scan lit de même la politique depuis --base. Lors de l'audit d'une plage historique plus large par rapport à un instantané de politique examiné séparément, passez explicitement --allow-list-ref <reviewed-40-character-commit-SHA>. Il s'agit d'une décision de confiance explicite de la part de l'appelant ; ne substituez jamais la politique du candidat non examiné. scan-package continue d'utiliser la politique --repo choisie par l'appelant, en dehors de l'artefact. Fournissez un répertoire de politique examiné lors de l'analyse de builds non fiables.
Exécutez push-guard scan --base <trusted-base> --head HEAD et push-guard scan-package dist/* de la nouvelle version sur les modifications sortantes réelles et les artefacts construits avant de mettre à niveau le hook installé. Les chemins des membres d'archive peuvent différer des chemins source ; examinez ces chemins exacts séparément. Conservez la version installée existante jusqu'à ce que les dépôts concernés aient terminé cette migration.
Page d'accueil publique : push-guard.netlify.app
La page d'accueil statique du projet se trouve dans docs/ et n'a aucune dépendance d'exécution, script externe, outil d'analyse ni ressource distante. Elle peut être servie avec GitHub Pages depuis le répertoire docs/ ou déployée sur Netlify à l'aide du fichier netlify.toml inclus (aucune commande de build ; répertoire de publication docs).
Le projet Netlify actuel utilise des déploiements manuels. Un simple push Git ne met pas à jour la page publique : publiez le contenu de docs/ après chaque version et vérifiez la version en ligne, l'image sociale et les en-têtes de réponse. Le fichier docs/_headers conserve les en-têtes de sécurité lors du déploiement direct de ce répertoire.
--send de Sweep active l'envoi d'alertes agrégées vers les destinations configurées ; le guard Git reste hors ligne.git uniquement pour lire les diffs de commit, les arbres poussés, les chemins de hook configurés et les métadonnées d'ignore. Le point d'entrée du hook existant est préservé, avec une inspection du contenu brut et de l'historique sortant renforcée.$HOME, et n'exécute aucun processus enfant, y compris Git.$XDG_STATE_HOME/push-guard-sweep/fp.key (par défaut ~/.local/state/push-guard-sweep/fp.key) pour des empreintes stables et non devinables. Cette clé constitue l'exception explicite à « aucune donnée stockée par défaut ». Elle ne contient aucune donnée analysée. Le répertoire d'état est en 0700 et les fichiers sont créés en 0600.--baseline et --output de Sweep contiennent des métadonnées locales expurgées ; --send stocke des reçus de déduplication à clé, jamais des identifiants d'alerte ni des secrets.Le blocage d'un push est la réponse de Git à l'avertissement. Push Guard reste en lecture seule et ne modifie aucun fichier. Le contournement est disponible avec git push --no-verify lorsque la valeur correspondante est connue comme n'étant pas un secret.
La commande push-guard sweep et l'alias push-guard-sweep offrent la même inspection locale. Ils nécessitent le Python 3.11 ou supérieur du paquet existant et n'ont aucune dépendance d'exécution supplémentaire. Les tests de développement utilisent l'extra optionnel test (python -m pip install ".[test]", puis PYTHONPATH=src python -m pytest -q depuis la racine du dépôt). La version 0.4.0 ajoute Sweep. La CI installe cet extra de développement et exécute l'intégralité de la suite pytest, y compris les cas unittest hérités. Les tests de version s'exécutent dans une tâche séparée ; cette tâche ne fournit jamais d'artefacts de distribution à la publication. La tâche de construction d'artefacts n'installe pas les dépendances de test. Sweep n'installe ni n'active de planificateur.
push-guard sweep --list-targets
push-guard sweep --roots ~/projects --class stray
push-guard-sweep --format json --output ~/sweep-report.json
push-guard-sweep --baseline ~/sweep-baseline.json
push-guard-sweep report --format html --output ~/sweep-report.html
push-guard-sweep print-timer --interval 7d
Chaque analyse prend également en compte l'historique par défaut, les dotfiles, les configurations et les emplacements de journaux ci-dessous. --roots modifie les racines de recherche des .env* et des inclusions personnalisées ; utilisez --exclude pour restreindre les autres ensembles par défaut. La répétition de --include GLOB ajoute des fichiers dans les recherches bornées existantes, et la répétition de --exclude GLOB supprime des chemins. Les globs correspondent aux noms de base, aux chemins relatifs à HOME ou aux chemins absolus. Les exclusions l'emportent ; les inclusions ne peuvent pas contourner les exclusions de sécurité ni les limites de profondeur. Le ~ dans les arguments de chemin en ligne de commande est développé. Les chemins analysés doivent rester à l'intérieur de $HOME.