Skill : auditing-hackerone-vulns
Ce skill fait partie du plugin bitwarden-security-engineer disponible dans le marketplace bitwarden/ai-plugins. Il s'agit d'un skill pleinement défini et opérationnel, conçu pour assister un ingénieur sécurité Bitwarden dans le suivi quotidien des vulnérabilités provenant de HackerOne.
Ce que fait ce skill
Le skill orchestre une séquence d'étapes structurées : interrogation des tickets ouverts dans le projet Jira VULN (filtrés sur la source HackerOne), récupération des items enfants liés dans d'autres projets Jira, recherche des pull requests GitHub associées via gh, et détermination de l'inclusion dans une release Bitwarden. À partir de ces données, chaque ticket se voit attribuer un token d'action coloré (🔴 🟡 🟢 🔵 ⚪ ➖) selon un arbre de décision précis.
Le résultat final est un rapport Markdown structuré daté, comprenant un tableau de synthèse par catégorie et des sections détaillées pour chaque groupe d'action. Les tickets nécessitant une intervention immédiate (mise à jour de statut, marquage comme remédié, vérification en production) apparaissent en tête ; les éléments en surveillance ou en attente sont repliés dans des blocs <details>.
Quand l'utiliser
Ce skill est à invoquer chaque fois que l'utilisateur souhaite : faire un point sur ses tickets VULN ouverts, identifier les findings HackerOne prêts à être vérifiés ou clôturés, obtenir une vue priorisée des remédiations en cours, ou répondre à la question « que dois-je faire sur mes tickets VULN aujourd'hui ? ». Le frontmatter du skill indique explicitement de toujours le préférer à une approche ad hoc pour ce type de tâche.
Points techniques notables
Le skill intègre des règles précises adaptées à l'infrastructure Bitwarden : gestion des cherry-picks sur les branches de release (les SHA divergent entre main et la branche release), traitement du monorepo bitwarden/clients avec ses tags par type de client (web-, browser-, desktop-, cli-), et règle stricte d'utiliser --jq de gh plutôt que python3 pour parser le JSON (Python n'étant pas dans les allowed-tools du skill). Ces détails évitent des erreurs silencieuses lors de la détermination de l'inclusion d'un correctif dans une version déployée en production.