Slack Report Threads

Why It Matters

A vulnerability report lives for weeks and moves a dozen times. If every one of those moves is its own Slack post, a busy program buries its own channel — and a muted #vdp is an SLA clock running somewhere nobody is looking.

So Kit posts one card per report and hangs everything else in that card’s thread. However many times a report moves, the channel body still shows one line for it.

The Card and the Thread

The first thing Kit does with a new report is post its card. That card is the thread root, and it stays put for the life of the report.

• The card is redrawn in place. Kit rebuilds it from the report and edits the same message. It never posts a second one, and it never posts a “status changed” card of its own.
• The thread is the record. Anything a teammate might need to reconstruct later posts as a short reply underneath.

The split is deliberate. Slack workspaces can set a message-edit window, and a card edit can start failing permanently once a message is old enough. When that happens you lose a convenience, never a fact — the fact is already in the thread.

What the Card Shows

An open report renders the same five zones at every stage, so the channel always reads the same shape.

Header — a severity emoji and the report title. Titles are researcher-written, so they are escaped: a title containing <!channel> lands as text, not as a room ping.

Six fixed fields, in this order. A field with no answer yet shows an em dash (—) rather than disappearing.

Field	What it shows
Severity	The severity tier, with the CVSS score once the report is assessed. Before assessment it shows the researcher’s own claim, explicitly labelled as “researcher’s own rating, not yet assessed” — a stranger’s self-rated “Critical” never sits unmarked in your team’s Severity slot.
Status	The report’s current status.
Type	The vulnerability type.
Assignee	The current owner’s name, or Unassigned.
SLA	The absolute acknowledgment deadline, in UTC — not a countdown. A live countdown would rewrite the card every minute.
Bounty	The formatted bounty amount, once there is one.

Trust line — the submitter’s country (when known), the researcher’s credited name with their karma tier, and how many valid reports they have on this program. A researcher’s standing in another company’s program never leaks into yours. Segments with no data are dropped rather than rendered empty.

Provenance line — the report ID, the submission time in UTC, and the program name.

Buttons — Reply to researcher ↗ (only when the report has a researcher account) and Open in Kit ↗, always last. Both are plain Kit URLs: clicking one signs you in and re-checks your access on arrival. No button carries a token, a share link, or a pre-signed attachment URL.

Once a report reaches Paid or Dismissed, the card collapses to a header, a single outcome line (💸 Paid · $250 USD, or 🚫 Dismissed with the dismissal reason), and Open in Kit ↗. A settled report shouldn’t hold a screenful of channel space forever. Fix Verified is not a collapse — it is still awaiting payout, so it keeps the full card.

What Posts a Reply, and What Only Redraws the Card

The rule: a thread reply exists when something happened that a human may need to reconstruct later. Everything else just redraws the card.

Event	Thread reply	Card
New report submitted	— this is the card	Posted
Any status change	Yes	Redrawn
SLA breached	Yes	Redrawn
Bounty approved	Yes	Redrawn
Disbursement completed	Yes	Redrawn
Appeal received	Yes	Redrawn
Escalation — a report assessed at an escalating severity, or a stalled report its admins had to be told about	Yes	Redrawn
Assignment or re-assignment	No	Redrawn

Replies are deliberately plain text, not cards. They are read in a thread under a card that already carries the title, severity, status and links — repeating that structure would just make the thread unreadable. A status reply carries the transition (Submitted → Validated), who made it, and their comment if they left one, trimmed so a pasted stack trace can’t become a wall.

Kit keys each reply to the record that caused it — the status transition, the appeal, the approved bounty, the completed payout — so a job that retries finds the reply already there rather than posting it twice.

Restricted Reports Never Reach Slack

A restricted report gets no card and no thread at all — not a redacted one.

If a report is restricted after its thread was already posted, Kit retracts it:

• The root card is edited down to a neutral tombstone — no title, no severity, no ID, no link. The channel is told the conversation moved to Kit, not what it was about.
• Kit’s own replies in the thread are deleted.
• The root message itself is never deleted, because deleting it would orphan the thread.
• Replies your teammates typed are not deleted. Those are their own words, not data Kit put there — Kit cannot and does not remove them.

Removing the restriction refills the same root card in place. Nothing is replayed: the replies deleted on restriction stay gone.

Researcher Identity in the Channel

The card reads the researcher’s recognition preference — the same setting that governs your public Hall of Fame — before it names anyone.

A researcher’s email address is never shown on the card, whatever their preference. The same rule applies to Kit’s Slack link previews when a teammate pastes a report URL into a channel, and to what KitBot is given to work with.

Which Channel the Card Lives In

The card goes to the channel your account routes New vulnerability report submitted to, resolved by the usual precedence: that exact purpose, then All VDP notifications, then All notifications. Configure this under Integrations → Slack.

Two consequences worth knowing:

• A thread can only be in one place. If several channels are routed to the same purpose, the card lands in one of them, not all.
• Once the card exists, its channel wins. Re-routing the purpose later moves where new reports land; it never migrates a live thread.

Money keeps a separate lane. If you route Bounty approved or Disbursement completed to a different channel — a #finance that shouldn’t see the whole security feed — that channel still gets its own standalone post, on top of the thread reply. If it’s routed to the same channel the card lives in, the thread reply is the only post: no duplicate.

Asking KitBot in the Thread

Because the thread root is the report, mentioning @KitBot anywhere in it resolves to that report with no guessing — status, timeline, SLA state, duplicate checks, severity context, bounty comparisons. See Using @KitBot in Slack.

The One Thing It Can Write

Ask KitBot to summarise the discussion, record a decision, or take a note, and it saves what it wrote as an internal note on that report — filed under your name, because you’re the one who asked. It confirms in the thread with a link straight to the note in Kit. If it didn’t say “saved” with a link, nothing was saved.

Mention it anywhere in the thread and say what you want written:

@KitBot summarise this discussion as an internal note
@KitBot note that we're waiting on the researcher's PoC video
@KitBot record the decision: duplicate of the March report, not paying twice
@KitBot save a note with the repro steps we agreed on above

Plain questions still work the same way — @KitBot what's the SLA on this?. KitBot only writes when you ask it to write.

Two more things it cannot do:

• It cannot choose which report to write to. The destination is the report whose card roots the thread, resolved before KitBot reads a word. Text in the thread — including text a researcher wrote — cannot point the note at some other report.
• It cannot write outside a report thread. Mention KitBot in a general channel and it has no note tool at all; it will tell you to ask again in the report’s own thread.

Notes KitBot saves are ordinary internal notes: they appear on the report’s Conversation tab, and anyone with access can edit or delete them.

One thing KitBot deliberately garbles: a peer share link. Anyone holding that URL can start the peer flow for a report they were never granted, so if one turns up in the thread KitBot will not repeat it — in its reply or in a note, the token comes back as …. The link still works for whoever was sent it; KitBot just refuses to be the one who spreads it.

What It Still Cannot Do

Everything else stays read-only. KitBot cannot triage, assess, assign, or dismiss a report; it cannot message or email a researcher; it cannot approve or adjust a bounty; it cannot change your program’s settings. Ask for any of those and it points you at the report page in Kit.

Saving a note also follows your own access level — if your Kit account is not a CSiRT admin, KitBot will say so and tell you who can raise it, rather than failing quietly.

If you mention KitBot in a thread for a report you’re not allowed to see, it quietly answers program-wide questions instead — it never confirms the report exists, and it is handed no way to write to it.

Quick Checklist

• Route New vulnerability report submitted (or All VDP notifications) to the one channel your security team actually reads
• Follow a report’s thread if you need to be notified when it moves — card edits are silent
• Try @KitBot summarise this discussion as an internal note in a report thread — the confirmation links straight to the note in Kit
• Route Bounty approved to #finance only if you want a separate post there
• Restrict a sensitive report as early as you can — restricting one that has already been posted leaves a tombstone in the channel rather than nothing
• Check who is actually in your VDP channel: guests and Slack Connect members see every card in it