A security bot should reply only when asked or when a defined event requires it, such as a dismissal needing a reason. Keep replies short and factual, and never argue. Two way chat adds convenience, but an eager bot turns a pull request thread into a second source of noise.
When a reply is justified
There are only a few good reasons for a bot to speak after its first comment:
- A developer issued a command, such as asking for a recheck or an explanation.
- A dismissal needs a missing reason.
- The finding is fixed and a one line confirmation helps close the thread.
- The state changed in a way that matters, such as a new advisory affecting a package already in the change.
Everything else can stay silent.
Design a small command set
Commands let developers act without leaving the page. Keep the set tiny so it can be remembered.
| Command idea | What it does |
|---|---|
| Recheck | Reruns the scan on the current head |
| Explain | Posts a short expansion of the rule, once |
| Dismiss with reason | Records the dismissal and closes the finding |
| Snooze | Hides the finding until a set date, with a reason |
Each command should confirm what it did in one line, and be recorded for audit. A dismissal done through a command should be as traceable as one done in a form.
Reply style
- One or two sentences.
- No apology and no cheerfulness. State the result.
- Include a link only if it adds something.
- Do not repeat the original comment.
An example: "Dismissed as test code by a developer. Recheck scheduled. The dismissal expires in 30 days." That is complete.
Do not argue
If a developer replies "this is a false positive" with a reason, record it. The bot should not respond with a counterargument. A disagreement that matters should go to a human owner of the rule. Provide a path: "To dispute this rule, contact the platform team."
Guard against abuse and injection
Anything a bot reads from a comment thread is untrusted input, especially if the bot uses a language model to interpret requests. A thread comment could contain instructions meant to change its behaviour. Parse commands with strict syntax, check who is allowed to issue each one, and never let free text change a gate result. Our post on whether a code comment can talk an AI reviewer into approving explains the risk.
Permissions matter
Limit who can dismiss or snooze. A contractor on a pull request may be able to comment, but whether they may waive a critical finding is a policy decision. Tie command rights to roles, and log the identity behind each action.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a finding moves through states, and think about which transitions should produce a bot reply.
Safeguard policies and gates keep decisions and their history, which supports traceable dismissals. Try the free scan.
Quick check
Is a conversational bot a good idea?
A small command set is useful. Open ended chat adds risk and noise, so most teams keep it strict.
Who may dismiss a finding through the bot?
Set it by role and severity. Many teams let authors dismiss low severity items and require an approver for high ones.
Last reviewed: 19 October 2026.
