AI Services Market
AI Services Market › Fabrique de compétences › Documents › Incident Disclosure Communicator
$4.99 · Sans inscriptionv1.0.0– vues

Incident Disclosure Communicator

Transformez une chronologie de divulgation de vulnérabilité en un avis clair sur lequel vos utilisateurs peuvent vraiment agir.

Un workflow guidé par template pour rédiger des avis de sécurité — chronologie, périmètre affecté, impact et actions utilisateur — en utilisant l'arc de divulgation de CVE-2026-98432 (CVE publié le 15 octobre, escalade Red Hat le 30 octobre, correctifs RHEL le 1er novembre) comme chronologie de référence.

Aperçu de Incident Disclosure Communicator
Idéal pour
Rédacteurs docs, developer relations, fondateurs, et toute personne devant informer les utilisateurs d'un problème de sécurité.
Temps nécessaire
Environ 45 à 60 minutes par avis, une fois les faits rassemblés.
Niveau
Intermédiaire

Installez-la en 3 étapes

Sans inscription. Sans outils en ligne de commande. Choisissez votre IA, copiez une ligne, collez-la.

Pro — les 531 compétences

Vous préférez le faire vous-même ? Achetez la compétence ($4.99), téléchargez le ZIP depuis votre confirmation d'achat, décompressez-le dans le répertoire indiqué ci-dessus, redémarrez votre session IA — même résultat. Vous l'avez déjà achetée ? Votre assistant IA peut la télécharger pour vous.

Contenu du pack

Un fichier SKILL.md (le guide pratique) + un modèle de départ. Aperçu :

Incident Disclosure Communicator

The idea in one paragraph

Most security advisories fail in the same way: they bury the timeline, hedge the affected scope, and leave users guessing what to do before lunch. Good disclosure communication is a writing discipline, not a PR exercise. This skill walks you through assembling a verified timeline, stating exactly who is affected, describing impact without hype, and giving users a short list of actions ordered by urgency. The reference case is CVE-2026-98432: a kernel CVE published October 15, escalated by Red Hat to Critical on October 30 with an interim nftables rule, and followed by RHEL fixes on November 1 — while Ubuntu remained listed as vulnerable. That arc shows what users need at each stage: what happened, whether it touches them, and what to do right now.

What it is built on

Only verified facts from the public record are used as the reference timeline:

  • The kernel team published CVE-2026-98432 on October 15 (fix written by Eric Dumazet on October 1, flaw reported by researcher Xinyang Ge).
  • Fixed kernels (5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3) were released between October 11 and October 18.
  • Red Hat raised the severity to Critical on October 30, published an nftables interim filtering rule, and pushed RHEL 8/9/10 fixes on November 1.
  • Ubuntu was still listed as "Vulnerable" as of November 1; Debian, Oracle, Amazon, and SUSE were partially patched.
  • As of November 1 there was no confirmed exploitation in the wild, and the CVE was not in CISA KEV.
  • Per Anthropic's October 27 blog post, an unreleased research model had written a working remote-root exploit (53 minutes, no credentials), which is why prompt, clear communication mattered even before any wild exploitation.

Workflow

  1. Assemble the verified timeline (input: vendor advisories, CVE record, distro notices -> output: dated timeline with sources). Collect every date from primary sources only: when the flaw was reported, when the fix was written, when the CVE was published, when each distro acted. For the reference case that means October 1 (fix), October 11-18 (fixed kernels), October 15 (CVE published), October 27 (Anthropic blog post), October 30 (Red Hat escalation and interim rule), November 1 (RHEL fixes; Ubuntu still vulnerable). Every entry gets its source link. If a date is unconfirmed, mark it as such instead of smoothing the story.
  2. Define the affected scope in plain terms (input: timeline plus technical details -> output: "you are affected if" checklist). Translate the technical scope into conditions a user can check in a minute: kernel since 4.4 without the fix, specific distro releases and their patch states, configurations that widen exposure (such as MPTCP listeners, which Go 1.24+ enables by default). Name who is not affected too — that sentence saves your support queue.
  3. Write the user action section first (input: scope checklist -> output: ordered action list). Before drafting the narrative, write what users should do, in order: check their kernel version, check their distro advisory, apply the patch or the interim mitigation, verify afterward. Each action gets the exact command or link. If no fix exists yet for some users, say so and give them the interim step plus when to check back.
  4. Draft, review, and publish (input: timeline, scope, actions -> output: published advisory plus update log). Write the advisory in this order: what happened (two sentences), who is affected (the checklist), what to do (the action list), then the timeline and links. Have someone technical review it for accuracy and someone non-technical review it for clarity. Publish with a visible "last updated" stamp, and log every revision — advisories are living documents while patches roll out.

Aperçu du modèle

Incident Disclosure Advisory Worksheet

Draft the advisory here, then publish. Keep every source link.

1. Verified timeline

Reference arc (CVE-2026-98432): Oct 1 fix written / Oct 11-18 fixed kernels released / Oct 15 CVE published / Oct 27 research-model exploit disclosed / Oct 30 Red Hat escalation + interim rule / Nov 1 RHEL fixes, Ubuntu still vulnerable.

2. Affected scope — "you are affected if" checklist

  • [ ] Condition a user can check in a minute:
  • [ ] Condition a user can check in a minute:
  • [ ] Condition a user can check in a minute:

Who is NOT affected (write this sentence; it saves the support queue):

3. User actions, in order

Le pack de compétence lui-même (SKILL.md + modèle) est rédigé en anglais.

Pro — les 531 compétences

Vous aimerez aussi