Automated alerts and tickets should carry identifiers and links, not credentials, customer data, full logs or exploit detail. Chat and ticket systems have wide audiences, long retention and search, so anything pasted there is hard to take back. Send a pointer to the detail, held somewhere with access control.
Why alerts leak
Automation is fast and literal. If a failing step prints an environment dump and the notifier forwards the last 50 log lines, a token can reach a channel with 400 members. Chat history is searchable, often exported, and retained by policy. Tickets are copied into other systems and shared with contractors. Our post on what to do when a secret appears in chat or a ticket covers cleanup, but prevention is cheaper.
Do and do not
| Include | Leave out |
|---|---|
| Repository, workflow name, run link | Raw log excerpts |
| Package name, affected and fixed versions | Environment variable values |
| Severity and advisory id | Tokens, keys, connection strings |
| Owner or team | Customer names and records |
| Short plain description | Working exploit steps for unfixed issues |
| Deadline or policy reference | Internal hostnames and network layouts, if the audience is wide |
Build messages from fixed templates
The safest message is composed of fixed text plus a few validated fields. Do not forward free text from scan output, pull request titles or issue bodies, because outsiders control it. They can insert misleading links or formatting that makes a fake alert look real. Validate package names and versions against a pattern before including them.
The webhook URL is itself sensitive
Slack's documentation says an incoming webhook URL contains a secret and should not be shared online, and that leaked ones are revoked. Keep it in your CI secret store, never in the workflow file or in a message. See post CI alerts to Slack with an incoming webhook.
Choose the audience deliberately
Put routine alerts in a small channel. Reserve a wider channel for events that need many eyes. For a public repository, remember that job summaries, issues and comments are public. Keep details of unfixed vulnerabilities in a private advisory or a restricted ticket until a fix ships.
Add a safety net
- Reduce the data at the source: configure scan output to omit values, not only mask them.
- Add a redaction step before notification that drops anything matching your own token formats.
- Limit retention in the alert channel where your policy allows. See Slack message retention settings by plan.
- Review a sample of automated messages each quarter.
This does not make your alerts a secret detection system. It only reduces what your own automation pushes out. If a credential does reach a channel, treat it as exposed and rotate it.
Quick check
Is masking in CI logs enough to protect a secret in an alert?
No. Masking is a convenience, not a guarantee. Keep secrets out of notification text at the source.
Should alerts include the full stack trace?
Usually not. Link to the run, where access is controlled, and quote only a short validated summary.
Sources
Safeguard offers compliance and evidence automation and policy controls for software supply chain findings. Try the free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
