Un jeton de registre écrit dans bunfig.toml est transmis à toute personne qui peut lire le dépôt, et $`sh -c "convert ${file}"` confie à un vrai shell un nom de fichier issu d'une requête : Bun Shell échappe la valeur pour son propre analyseur, pas pour le shell que vous lancez. Et comme trustedDependencies remplace la liste intégrée de paquets de confiance de Bun, une seule entrée supplémentaire exécute le script d'installation de ce paquet sur chaque machine qui installe. Ce skill repère ces erreurs et les autres erreurs de projet Bun listées ci-dessous avant l'installation ou le déploiement, et vous explique comment corriger chacune.

Votre agent lance un scanner sur bunfig.toml, .npmrc, package.json, bun.lock (et les noms de bun.lockb et d'autres lockfiles), ainsi que sur les fichiers TypeScript et JavaScript qui utilisent Bun. Il suit les données de requête à travers les variables de chaque fichier, sait quelles formes de Bun Shell et de SQL échappent ou lient les valeurs et lesquelles ne le font pas, laisse tranquilles l'arithmétique sur les nombres et les listes de marqueurs ?, compare trustedDependencies à la liste par défaut de Bun, considère les références $VAR et ${VAR} comme configurées, ignore les commentaires, les tests et node_modules, et n'exécute jamais bun ni votre code. Il renvoie BLOCK, REVIEW ou NOT FLAGGED, avec le fichier, la ligne, la raison et une approche plus sûre. Les secrets ne sont jamais affichés.

Ce qui est vérifié

BLOCK (à corriger avant la mise en production)

• B01: registres http:// simples, registres de scope, URL de paquets et URL de lockfile (un registre sur localhost est accepté)
• B02: jetons et mots de passe de registre écrits dans bunfig.toml, .npmrc, les scripts de package.json, des URL, du code ou bun.lock
• B03: données de requête transmises à sh -c, bash -c, bun -e, interpolation brute ou Bun.spawn avec sh -c, ou choix du programme à exécuter
• B04: requêtes bun:sqlite et sql.unsafe() avec des valeurs insérées dans le texte SQL (y compris du SQL construit dans une variable et allongé avec +=)

REVIEW (à vérifier avant la publication)

• B11: entrées trustedDependencies hors de la liste de confiance par défaut de Bun, ou provenant de git, GitHub, de fichiers ou d'URL (non signalées si les scripts d'installation sont désactivés dans bunfig.toml ou .npmrc)
• B12: bun.lock à côté d'un lockfile npm, Yarn ou pnpm
• B13: le bun.lockb binaire, ou des réglages qui désactivent le lockfile texte ou l'enregistrement du lockfile
• B14: contrôles de certificat TLS désactivés (rejectUnauthorized: false, NODE_TLS_REJECT_UNAUTHORIZED=0)
• B15: mode développement de Bun.serve écrit dans le code, ou traces de pile envoyées aux clients
• B16: commandes shell construites à partir de variables, et données de requête passées comme arguments de commande
• B17: noms de tables ou de colonnes et autres parties de SQL issus de variables

Ce qui est inclus

• Le scanner (Python 3.9+, bibliothèque standard uniquement)
• Un guide des règles avec la raison, l'approche plus sûre et le lien vers la documentation officielle de Bun pour chaque règle
• Un projet Bun d'exemple risqué et un projet sûr (bunfig.toml, package.json, lockfiles et TypeScript), ainsi que le vrai rapport produit par le scanner sur le projet risqué

Limites

Il lit chaque fichier séparément : les données de requête sont suivies à travers les variables d'un même fichier, pas d'un module à l'autre, et les options de Bun.serve construites dans une autre variable, les Dockerfile, les fichiers de CI et le NODE_ENV de votre déploiement ne sont pas lus. node:child_process et les clients SQL autres que bun:sqlite et Bun SQL ne sont pas vérifiés. NOT FLAGGED n'est pas une garantie.

Contenu

Un fichier ZIP de 24 fichiers : SKILL.md, le scanner dans scripts/ (10 fichiers Python), references/rules.md (chaque règle avec sa raison et son approche plus sûre) et examples/ (13 fichiers d'exemple plus report.md, la vraie sortie du scanner sur l'exemple risqué).

Mode d'emploi : Il s'agit d'un skill pour agent : un dossier contenant un fichier SKILL.md et des scripts Python qu'un agent de programmation IA comme Claude Code, Cursor ou Codex CLI peut exécuter. Décompressez-le dans le dossier de skills de votre agent (pour Claude Code : ~/.claude/skills/), puis demandez à votre agent de vérifier votre projet. Les scripts fonctionnent aussi seuls avec Python 3.9 ou plus récent, sans rien installer. Ils ne font que lire vos fichiers : aucun accès réseau, et rien n'est envoyé nulle part.