Sécurité & modèle de confiance

Cette page décrit ce à quoi haw fait confiance et ce qu’il exécute, afin que vous puissiez évaluer le rayon d’impact de son exécution sur un dépôt donné. Pour signaler une vulnérabilité et connaître les versions prises en charge, voir le SECURITY.md à la racine du dépôt.

En une ligne : haw exécute du code écrit dans le manifeste et du code présent dans votre PATH. Considérez les deux comme des entrées de confiance.

Le manifeste est du code de confiance

Un espace de travail est défini par un manifeste haw.toml. Ce manifeste peut déclarer des commandes build, test, run et exec, ainsi que des hooks de cycle de vie. Lorsque vous exécutez une opération sur la flotte, haw exécute ces commandes via votre shell, avec votre environnement et votre arbre de travail :

haw build / haw test exécutent les commandes build / test du manifeste.
haw run <cmd> / haw exec <cmd> exécutent des commandes arbitraires sur toute la flotte.
haw sync peut déclencher des hooks et des étapes post-checkout déclarées dans le manifeste.

Par conséquent, exécuter haw build, haw run, haw exec ou haw sync sur un checkout non fiable équivaut à exécuter le Makefile de ce dépôt. Un haw.toml malveillant peut faire tout ce que votre shell peut faire.

Règle générale : traitez haw.toml exactement comme un Makefile ou le bloc scripts d’un package.json. N’exécutez de commandes de cycle de vie que sur des manifestes que vous avez relus ou en lesquels vous avez confiance. Les commandes d’inspection en lecture seule (haw status, haw tree, haw verify) n’exécutent pas les commandes du manifeste et peuvent être exécutées en toute sécurité sur un manifeste non fiable.

Les plugins sont des binaires de confiance

haw suit le schéma d’extension de git / cargo / kubectl : toute sous-commande que haw ne reconnaît pas est déléguée à un exécutable haw-<name> trouvé dans votre PATH. Par exemple, haw jira sync exécute haw-jira.

Deux propriétés comptent pour la sécurité :

Les plugins sont des exécutables ordinaires résolus depuis le PATH. C’est le haw-<name> vers lequel votre PATH pointe qui s’exécute. Un PATH falsifié (ou un binaire haw-* déposé dans l’un de ses répertoires) peut détourner une sous-commande.
Les plugins héritent de la totalité de votre environnement, y compris tout token de forge (GITHUB_TOKEN, GITLAB_TOKEN, HAW_*, …) exporté dans le shell qui a lancé haw.

Par conséquent : n’installez que des plugins de confiance et gardez votre PATH propre — préférez des emplacements d’installation absolus et connus, et évitez de placer des répertoires non fiables ou modifiables par tous en tête des chemins système.

Les plugins s’exécutent bien comme des processus séparés, de sorte qu’un plugin défectueux ou bloqué ne peut pas faire planter haw — mais l’isolation des processus n’est pas ici une frontière de sécurité : un plugin s’exécute avec vos privilèges et vos secrets.

Tokens et identifiants

Les tokens de forge sont lus uniquement depuis les variables d’environnement et utilisés exclusivement pour les requêtes API (ouvrir des PR, lire l’état de la CI). Ils ne sont jamais écrits sur le disque ni jamais journalisés par haw.
L’authentification du transport Git n’est pas gérée par haw — elle reste du ressort de vos clés SSH existantes ou de votre credential helper git.
La composition en lecture seule (haw sync, status, tree, verify) ne nécessite aucun token ; seules les fonctionnalités de forge en ont besoin.

Voir la section Secrets & tokens du README pour l’ordre de priorité exact par forge.

Renforcement de la chaîne d’approvisionnement (ce dépôt)

Le projet haw lui-même applique des contrôles standard de chaîne d’approvisionnement :

Les GitHub Actions sont épinglées à des SHA de commit complets (avec le tag lisible par un humain dans un commentaire de fin) dans chaque workflow, de sorte qu’un tag d’action compromis ou repointé ne puisse pas altérer les artefacts de release avant leur signature.
Les artefacts de release sont signés avec cosign (sans clé / OIDC).
cargo audit et cargo deny s’exécutent à chaque push/PR et selon une planification hebdomadaire (voir .github/workflows/audit.yml et deny.toml) pour bloquer les avis de sécurité connus, les licences interdites et les sources de dépendances inattendues.

Signalement

Pour signaler une vulnérabilité, suivez la procédure du SECURITY.md à la racine du dépôt : utilisez le signalement privé de vulnérabilité de GitHub ou envoyez un e-mail au mainteneur. N’ouvrez pas de ticket public pour les problèmes de sécurité.