sandbaseai/awesome-workbuddy

Audit de sécurité des compétences

Évaluer le projet fourni à l'aide du contenu du dépôt et de la documentation principale. L'audit par défaut est en lecture seule : n'installez pas de dépendances, n'exécutez pas de code du projet, ne vous connectez pas, ne fournissez pas d'identifiants et ne connectez pas le projet à un agent ou compte réel.

Audit

1. Enregistrez le dépôt exact, la révision ou la version, la licence, le statut d'archivage, la dernière mise à jour significative et les fichiers examinés. Si la révision auditée n'est pas claire, mentionnez cette limitation.
2. Lisez l'intégralité du fichier SKILL.md ou des instructions équivalentes ainsi que tous les fichiers qu'il invoque directement. Suivez les références aux scripts, hooks, manifestes, étapes d'installation de paquets, binaires, URLs distantes, variables d'environnement et ressources incluses.
3. Établissez un inventaire des capacités : accès aux fichiers locaux, exécution de commandes, accès réseau, contrôle du navigateur, actions sur les comptes, publication, messagerie, suppression, paiement, accès aux identifiants, persistance et comportement de mise à jour automatique.
4. Tracez les données sensibles depuis leur source jusqu'à chaque stockage local, sous-processus, journal, modèle, API, serveur MCP, service d'analyse ou autre destination réseau. L'absence de documentation est une question non résolue, pas une preuve que les données restent locales.
5. Inspectez les manifestes de dépendances, les fichiers de verrouillage, les scripts d'installation et la provenance des versions. Notez toute exécution distante non épinglée, binaire opaque, dépendances transitives larges, ou discordance entre la source et les artefacts distribués.
6. Appliquez le modèle de signaux de risque et de sévérité. Une capacité risquée peut être légitime si elle est nécessaire, divulguée, limitée dans sa portée, réversible et soumise à confirmation.
7. Séparez les conclusions confirmées des risques contextuels et des questions sans réponse. Citez les chemins de fichiers, lignes, champs de configuration, commandes ou documentation principale pour chaque affirmation matérielle.

Résultat

Commencez par l'identité auditée et un verdict :

• Risque observé plus faible : aucun problème matériel n'a été trouvé dans le périmètre examiné, mais cela ne constitue pas une garantie.
• Examen requis : le comportement important, la provenance, les permissions ou le flux de données restent flous.
• Risque observé élevé : un comportement confirmé pourrait exposer des données sensibles, affaiblir la sécurité du compte ou de l'appareil, provoquer une action irréversible ou contourner le contrôle éclairé.

Fournissez les sections suivantes :

1. Périmètre et limitations.
2. Tableau des capacités et permissions.
3. Tableau des flux de données.
4. Résultats classés par sévérité, avec pour chacun des preuves, l'impact et les mesures d'atténuation.
5. Questions sans réponse.
6. Un plan de test avec permissions minimales utilisant des données ou comptes jetables.

N'étiquetez pas un projet comme sûr, malveillant, officiel ou conforme sans preuves suffisantes pour cette affirmation spécifique. L'analyse statique ne peut pas prouver le comportement à l'exécution ni le contenu d'un service distant opaque.