Safeguard alerts in Slack, Microsoft Teams and Discord: setup, routing and noise control

Safeguard can post new findings, scan results and alerts into a Slack channel, a Microsoft Teams channel or a Discord channel, so security signal lands where engineers already talk. You connect each one from the Notification tab under Integrations, choose a bot token or a webhook, and pick one default channel. Know the current limits before you plan: routing is one channel per connection today, and there is no per channel severity filter in the setup screens.

This post walks through the setup for each platform exactly as Safeguard's docs describe it, explains which credential to choose and why, and is blunt about what the integrations do not do yet, because noise control is where most chat alerting projects fail.

Key takeaways

• Chat notifications for Slack, Microsoft Teams and Discord are available (GA). The offering files list Slack, Teams, Google Chat and Discord as notification channels.
• Setup is the same shape on all three: choose an authentication type, paste a credential, let Safeguard validate it, then choose a default channel. Find the cards on the Notification tab under Integrations.
• Each connection sends to one default channel. The data model has per event channel mappings with a minimum severity field, but Safeguard's docs say no screen exposes them yet. Do not plan around per channel severity routing today.
• Bot or webhook: a bot credential gives you a channel picker; a webhook is the least privilege option and posts to the one channel it was created for.
• Teams is a supported channel too. You connect it from the Teams card in Settings and follow the current steps on Safeguard's Teams docs page.
• These are outbound notifications. The Slack and Discord data models carry a slash command flag, but nothing in Settings turns it on. Teams is send only. An @-mention style "Safeguard Tag" is roadmap.
• Noise control happens upstream of the chat tool: prioritisation with reachability, EPSS and CISA KEV (GA), policies and gates (GA), and a dedicated channel per connection.
• Remediation from the alert: autonomous remediation and fix pull requests are GA and ship switched off, with every category set to Manual.

What problem chat alerts solve, and the one they create

A vulnerability that nobody sees is a vulnerability that nobody fixes. Most security teams have learned that dashboards alone do not move work: engineers do not log into a separate console every morning to check for new findings, and email digests sink below the fold by lunchtime. Chat is where incidents are coordinated, where on call engineers already watch, and where a short message with a link can turn into a thread, an owner and a fix in minutes.

That is the case for chat alerts. The case against them is just as real. A channel that receives every scan completion and every low severity finding becomes wallpaper within a week. People mute it, and the one message that mattered scrolls past with the others. The goal is not "send everything to chat". It is "send the right things to the right people in a place they will act on".

Why standards care about the signal path

Several public frameworks expect you to move vulnerability information to the people who can act on it, quickly and in a way you can show later.

• NIST SP 800-218, the Secure Software Development Framework (SSDF). Its Respond to Vulnerabilities practice group asks producers to identify and confirm vulnerabilities on an ongoing basis, then assess, prioritise and remediate them. A chat alert is one of the mechanisms that closes the loop between "identified" and "someone is working on it". The SSDF does not prescribe a tool; it prescribes the outcome.
• NIST SP 800-40 Revision 4, enterprise patch management. NIST frames patch management as identifying, prioritising, acquiring, installing and verifying updates, and treats patching as preventive maintenance rather than an exceptional event. Notifications feed the first two steps.
• NIST SP 800-61 Revision 3, incident response. The current revision ties incident response to the NIST Cybersecurity Framework 2.0 and stresses preparation and efficient detection and response. Knowing where alerts go, who sees them, and how quickly they are acknowledged is part of that preparation.
• CISA Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk". CISA's directives page says it supersedes and revokes BOD 19-02 and BOD 22-01 and consolidates remediation guidance for federal agencies around risk. Federal or not, many teams copy its logic: risk, including known exploitation, should change how loudly you alert. BOD 22-01's fixed deadlines are history.

None of these documents tell you to use Slack, Teams or Discord. They tell you that vulnerability information must reach an owner and be acted on in a reasonable time. Chat integration is a delivery mechanism for that duty, and like any mechanism it can be done well or badly.

The three failure modes of chat alerting

Chat alerting usually fails in one of three ways: too much (every event in one busy channel, so people mute it), too little (a weekly digest, so known exploited issues sit for days), or the wrong place (a channel the owning team does not watch, or one with members who should not see vulnerability detail).

Safeguard's current chat integrations give you good control over the third problem and over the security of the connection itself. The first two are solved mostly by what you alert on and how you prioritise inside Safeguard, not by the chat integration.

What Safeguard's chat integrations are

Safeguard's docs describe dedicated ChatOps integrations for Slack, Microsoft Teams and Discord, each with its own connection setup, a credential validation step and default channel routing. They are available across Safeguard's supply chain manager (ESSCM), Portal and third party risk (TPRM) products. Google Chat has a similar card that is switched on per workspace.

What each card sends, in the docs' words, is notifications about "new findings, scan results and alerts" to the channel you chose. Safeguard posts when events you subscribed to happen, for example a scan finishing or a new critical finding.

Each card is outbound only. The Slack, Teams and Discord pages each state that the card sends messages to the chat platform and does not receive that platform's events.

Maturity labels used in this post

Which platform and which credential

Every card offers two kinds of credential. One is a bot or app identity that can list channels so you can pick one. The other is a webhook URL that is already bound to one channel and can only post there.

Choose a webhook when you want one fixed channel and the smallest possible grant. Safeguard's Slack and Discord pages both call the webhook the least privilege option. A webhook cannot read anything, cannot list channels and cannot post anywhere else.

Choose a bot when you want to pick the channel from a list inside Safeguard, or you expect to move the destination later without minting a new credential. A bot needs a few more scopes and has to be invited to the channel.

Neither path gives you per event routing today. That choice is about credential scope and convenience, not about filtering.

Step by step: connect Slack

Safeguard's Slack page is specific about scopes. Safeguard only posts messages and lists channels. It never reads messages, files or users through this card, and never changes channels.

Bot token scopes

The token is checked with Slack's auth.test method, which needs no scope. The docs' least privilege recommendation is your own Slack app with chat:write and channels:read only, invited to the one notification channel. Safeguard never needs admin scopes, channels:history, users:read, files:write or any user token scope for this card.

One detail is easy to miss. The dialog has an "Install the Safeguard app" button that installs Safeguard's own Slack app. Safeguard's docs say that app asks for more scopes than the notification card uses, because other Safeguard Slack features use them. If you only want notifications, the docs recommend creating your own app with the scopes above, or using an incoming webhook.

Create the credential in Slack

1. Go to the Slack app management site, choose Create New App, then From scratch, name it and pick your workspace.
2. Under OAuth and Permissions, add the bot token scopes chat:write and channels:read. Add groups:read if the notification channel is private.
3. Click Install to Workspace and allow it.
4. Copy the Bot User OAuth Token. It starts with xoxb-.
5. In Slack, invite the app to the notification channel with /invite @your-app-name.

For a webhook instead:

1. In your app's settings, open Incoming Webhooks and switch on Activate Incoming Webhooks.
2. Click Add New Webhook to Workspace, choose the channel and allow it.
3. Copy the URL. Slack's own documentation treats this URL as a secret, and Safeguard's docs say the same: anyone with it can post to that channel.

Slack's command line tool does not mint bot tokens for an existing app, but you can check a token before pasting it into Safeguard. This is the check Safeguard's docs show:

curl -s -H "Authorization: Bearer $SLACK_BOT_TOKEN" https://slack.com/api/auth.test

Connect it in Safeguard

1. Open Integrations and choose the Notification tab.
2. Click Connect on the Slack card.
3. Enter an Integration Name (it must be unique across your integrations) and, optionally, a description.
4. Choose the Authentication Type.
   • Bot Token (Full Access): paste the token. Safeguard validates it, shows "Connected to workspace:" and loads the channel list. Choose the Default Channel.
   • Incoming Webhook (Send Only): paste the webhook URL. There is no channel to pick; you can type a display name for the channel if you like.
5. Click Connect.

Token types that do and do not work

Bot tokens and webhook URLs do not expire unless your app uses token rotation, which this card does not support. Plan to reinstall or revoke them when people leave or if a token leaks.

What Safeguard stores

With a bot token, Safeguard reads your workspace name and the channels the bot can see. It stores the connection's name, channel and the token or webhook URL. What goes to Slack is notification text about your Safeguard projects and findings. Safeguard's docs state that no customer data from this integration is sent to third party LLMs.

Step by step: connect Microsoft Teams

Microsoft Teams is a supported notification channel. The Teams card sends the same new findings, scan results and alerts as the Slack and Discord cards, to a channel in your own Microsoft 365 tenant.

You set up the connection from the Teams card in Settings:

1. Open Integrations and choose the Notification tab.
2. Click Connect on the Teams card.
3. Enter an Integration Name and, optionally, a description.
4. Follow the current steps on Safeguard's Microsoft Teams docs page to create the webhook in Teams and paste it into the card.

Microsoft is changing how incoming webhooks work in Teams, so the steps on the Microsoft side depend on what your tenant offers. Rather than copy instructions here that could drift, this post points you to the docs page, which Safeguard keeps current. If the Teams card does not accept the webhook type your tenant gives you, contact Safeguard support with the webhook type you have.

A few points hold whatever the webhook type:

• Safeguard only posts. It never reads channel messages, files or members, and it never needs an administrator role in your Microsoft 365 tenant.
• The webhook URL is a secret. Anyone who has it can post to that channel, so store and rotate it as you would a token.
• You get a test message. When you save a webhook connection, Safeguard posts a test message to the channel, so you know straight away that the connection works.
• Teams is send only. Safeguard's ChatOps page says there is no inbound command field on the Teams configuration at all.

Step by step: connect Discord

Discord is the most straightforward of the three. Safeguard only posts messages and lists servers and channels. It never reads messages, members or roles.

Bot permissions

The token is checked with Discord's GET /users/@me, which needs no permission. Safeguard never needs Administrator, Manage Server, Manage Channels, Manage Roles, Read Message History or any privileged gateway intent.

Create the credential in Discord

For a webhook:

1. Open the channel's settings and go to Integrations, then Webhooks.
2. Create a webhook, name it and copy its URL. Discord's own documentation explains that a webhook can be executed without a bot user or other authentication, which is why the URL itself is the secret.

For a bot token:

1. In the Discord Developer Portal, create an application and open its Bot settings.
2. Copy the bot token (reset it if it is hidden).
3. Build an authorization link with the bot scope and the permissions View Channels and Send Messages, plus Embed Links if you want embeds. Open it to add the bot to your server.
4. Make sure the bot can see the notification channel.

You can check either credential before pasting it, using the commands Safeguard's docs show:

# Bot token
curl -s -H "Authorization: Bot $DISCORD_BOT_TOKEN" https://discord.com/api/v10/users/@me

# Webhook URL (returns the webhook without posting)
curl -s "<webhook-url>"

Connect it in Safeguard

1. Open Integrations and choose the Notification tab.
2. Click Connect on the Discord card.
3. Enter an Integration Name and, optionally, a description.
4. Choose the Authentication Type.
   • Bot Token (Full Access): paste the token. "Connected as bot:" appears. On the Server and Channel step, choose the server, then the channel. Safeguard filters the list down to text channels.
   • Webhook URL (Send Only): paste the URL. Nothing to pick; you can type a display name for the channel.
5. Click Next, then Connect.

One quirk from Safeguard's ChatOps page: if your bot has joined no servers, the Select Server step can sit on "Loading servers..." rather than telling you to invite the bot. If it has not resolved after a few seconds, check that the bot was actually added to a server.

Google Chat, briefly

The offering files list Google Chat alongside the other three. Safeguard's Google Chat card is switched on per workspace, so if you do not see it under Integrations, ask your Safeguard contact. It posts through a space's incoming webhook, which Google offers only to Business and Enterprise Google Workspace accounts, and Workspace admins can turn webhooks off. Add a webhook under the space's Apps and integrations, copy its link and paste it on the Google Chat card. Google documents per space message rate limits, and Safeguard's docs note about one post per second per space, so a burst of notifications can be slowed down.

Credential validation, every time

On all three main platforms, Safeguard validates credentials in a dedicated step before it lists channels, teams or servers. You cannot reach a channel picker with credentials Safeguard has not confirmed. If validation fails because of a revoked token, wrong scopes, a malformed webhook URL or a wrong tenant, you see an inline error and the flow does not advance.

The same step runs when you edit an existing integration with new credentials. If you edit an integration and leave the token or URL fields blank without changing the authentication type, Safeguard keeps the credential on file and skips revalidation for that step. Fill in a credential field only when you are actually rotating it.

Routing: one default channel per connection

This is the part most readers come for, so here it is plainly.

Every Slack, Teams or Discord integration you set up today sends everything to the single default channel you picked (or, for a webhook, the channel the webhook belongs to). Safeguard's ChatOps page says it checked all three connection drawers and none of them expose any screen to create, view or edit a channel mapping. A newly created integration's mapping list comes back empty, and there is no self service way to fill it.

The data model is clearly designed for more. Each platform's configuration carries a list of channel mappings, and the docs list the fields such a mapping would have:

Safeguard's docs label this section "a data model, not a shipped feature". The intent is easy to read: route critical and high findings to an on call channel, send the rest somewhere quieter, mute a mapping without deleting it, and in Slack mention a group when a mapping fires. None of that is usable from the product today, and you should not design a rollout that depends on it.

Here is the record Safeguard's docs show for a Slack integration created with a bot token. Field names are real; the values are illustrative.

{
  "id": 42,
  "integrationName": "Security Alerts Slack",
  "authType": "BOT_TOKEN",
  "workspaceName": "example-workspace",
  "botUserName": "safeguard-bot",
  "defaultChannelId": "C0123ABCDE",
  "defaultChannelName": "security-alerts",
  "webhookEnabled": false,
  "slashCommandEnabled": false,
  "channelMappings": [],
  "isActive": true
}

Note the empty channelMappings and slashCommandEnabled set to false. Those two fields are the whole story of today's limits.

What about severity filters and notification preferences?

The topic people search for is "can I send only critical alerts to Slack". The honest answer for the chat cards today is no, not from the chat integration setup. Safeguard's ChatOps FAQ says every integration sends everything to its single default channel regardless of event type or severity, and that severity filtering and per event routing happen upstream, if at all.

The Settings area of the product does include a notifications section, according to the offering files, and the chat cards post when "events you subscribed to" happen. The public docs do not yet document which subscription controls exist or how they interact with chat cards, so this post does not describe them. If you need per severity or per category control in chat, ask your Safeguard contact what your tenant has, and test it in a sandbox channel before you announce anything to engineering.

Safeguard also documents a webhooks and events catalogue with filters, but that page carries a banner that its /v1 REST endpoints are not yet available. Do not build a routing layer on it today.

Noise control that works today

If the chat card cannot filter, where does noise control come from? From deciding what Safeguard treats as important before it ever posts, and from how you lay out channels.

1. Prioritise inside Safeguard first

Safeguard's vulnerability management (GA) enriches findings with EPSS scores and CISA KEV status, and reachability analysis (GA) ranks the vulnerable code paths your application actually calls. When your team triages in Safeguard with those signals, the alerts that reach chat are about issues already known to matter. The detail is in our post on reachability, EPSS and KEV.

2. Turn noise into policy

Policies, gates and guardrails (GA), including plain English policy creation, let you decide what blocks a release and what only warns. A policy that blocks on known exploited, reachable, high severity issues produces far fewer and far more meaningful events than "any new CVE". See plain English security policies to release gates.

3. Give each connection its own channel

Because each integration has one default channel, the channel is your routing unit. A common layout:

4. Use the chat platform's own controls

Slack, Teams and Discord all let members set per channel notification levels, keywords and mentions. In a dedicated alerts channel, ask the on call rotation to set notifications for all messages, and everyone else to set mentions only. This is crude compared with severity routing, but it is real and it works today.

5. Respect platform rate limits

Slack publishes rate limits for posting messages, and Google documents limits on webhook posts to a Chat space. A scan that finishes across hundreds of repositories at once can generate a burst. Fewer, better alerts are kinder to the platform as well as to people.

6. Fix from the alert, not just discuss it

An alert is only useful if it leads to a fix. Autonomous remediation (GA) opens tested, policy gated fix pull requests, singly or in bulk, but ships switched off with every category set to Manual, so a human decides how much runs on its own. The details are in autonomous remediation in Safeguard.

Supplier risk alerts from TPRM

Safeguard's third party risk management (GA) watches what your suppliers ship you. The offering files list its monitoring alerts as new critical vulnerability, KEV addition, risk change and SBOM expiry, with chat among the destinations. The ChatOps page confirms the same chat integrations are available across ESSCM, Portal and TPRM. If you run vendor monitoring, a separate supplier risk channel is a good idea, since the audience (procurement, vendor management, compliance) is usually different from the engineers fixing your own code. Our TPRM post covers the module.

Inbound commands: what is and is not there

ChatOps often implies two way interaction: typing a command in chat and getting an answer or an action. Safeguard's docs are careful here, and so should you be.

• Slack and Discord: both configuration types include a slash command flag, so the platform is built to support inbound interaction. Neither connection drawer exposes a control to turn it on. Safeguard's docs say to treat inbound slash commands as something the platform is designed for, not a feature you can enable today.
• Teams: no inbound command field exists on the Teams configuration at all. It is send only.
• @-mention "Safeguard Tag": listed on Safeguard's roadmap, not shipping.

If you want to ask Safeguard questions conversationally today, the supported routes are the Safeguard CLI (GA), the desktop and mobile apps (GA) and Safeguard in Claude or ChatGPT through each assistant's connector directory, covered in Safeguard in your IDE and in Claude and ChatGPT.

Security of the connection itself

A chat integration is a credential that can post into your company's communication tool. Treat it like any other secret. Prefer webhooks for least privilege, use your own Slack app rather than the broader Safeguard app if you only need notifications, leave chat:write.public off so vulnerability detail stays in a restricted channel, and rotate credentials on a schedule and when people leave, because Slack and Discord bot tokens and webhook URLs do not expire on their own. Deleting the connection in Safeguard is half the job; also remove the webhook, uninstall the app or remove the bot in the chat platform.

Rotation and disconnect, per platform

Troubleshooting

Decision table: what to set up for your situation

What Safeguard does not do

1. It does not route by event type or severity per channel today. The channel mapping and minimum severity fields exist in the data model only. Every integration sends to its one default channel.
2. It does not take commands from chat today. Slack and Discord have a slash command flag with no screen to turn it on; Teams has no inbound field at all. The @-mention Safeguard Tag is roadmap.
3. It does not manage your chat platform's rate limits or retention. Slack, Teams, Discord and Google Chat each apply their own limits and data retention. Messages Safeguard posts are then governed by your chat tool's policies.
4. It does not decide who should act. The integration delivers a message to a channel. Ownership, escalation and on call rotation are your process.
5. It does not rotate credentials for you. Slack token rotation is not supported by the card; bot tokens and webhook URLs do not expire on their own.
6. It does not replace a ticketing system. Chat is for awareness and coordination. Track remediation work in your ticketing tool, which Safeguard also integrates with.
7. The /v1 webhook and events API is not available yet. Do not build a custom router on it until the docs remove the banner.

Common mistakes

Pointing the integration at a busy general channel. It feels inclusive and becomes ignored within days. Use a dedicated alerts channel.

Using the Safeguard Slack app install button for notifications only. It works, but it grants more scopes than the card needs. Create your own app with chat:write and channels:read, or use a webhook.

Forgetting to invite the bot. The most common setup failure, according to Safeguard's docs, is a valid bot token with no channel to see. Run /invite in the channel, then retry.

Expecting severity filters in the chat setup. There are none yet. Do the filtering with triage and policy inside Safeguard.

Posting vulnerability detail into a public Discord or Slack channel. Unfixed vulnerability detail is sensitive. Keep the alerts channel private and leave chat:write.public off.

Leaving old credentials live. Deleting the connection in Safeguard does not revoke the webhook or uninstall the app. Do both.

Treating chat as the system of record. An alert thread is not evidence that a vulnerability was fixed. The record lives in Safeguard and your ticketing tool.

FAQ

Does Safeguard integrate with Slack?

Yes. Safeguard's Slack card posts new findings, scan results and alerts to a Slack channel. You can connect with a bot token from your own Slack app or with an incoming webhook. Find it on the Notification tab under Integrations.

Can Safeguard send alerts to Microsoft Teams?

Yes. Microsoft Teams is a supported notification channel. Connect it from the Teams card in Settings and follow the current steps on Safeguard's Teams docs page, since Microsoft is changing how Teams incoming webhooks work. If the card does not accept your webhook type, contact Safeguard support.

Does Safeguard support Discord notifications?

Yes. Use a channel webhook for least privilege, or a bot token from your own Discord application with View Channels and Send Messages if you want to pick the server and channel inside Safeguard.

Can I send only critical vulnerabilities to Slack?

Not from the chat integration setup today. Each integration posts to one default channel, and the minimum severity field exists only in the data model. Reduce noise with prioritisation and policies inside Safeguard and a dedicated alerts channel.

Can I route different projects or event types to different channels?

Not through a channel mapping today. Per event routing is designed into the data model but has no screen. Ask your Safeguard contact about timing before you design around it.

Can I run Safeguard commands from Slack or Discord?

No. The slash command flag exists in the data model for Slack and Discord, but nothing in Settings enables it. Teams is send only. For conversational use, run the Safeguard CLI or add Safeguard from the Claude or ChatGPT connector directory.

Is a webhook or a bot token more secure?

A webhook is the least privilege option on Slack and Discord: it can post to one channel and nothing else. A bot token can list channels and needs to be scoped and invited carefully. Both are secrets.

What data does Safeguard send to the chat platform?

Notification text about your Safeguard projects and findings. Safeguard stores the connection name, channel and credential, and its docs state that no customer data from these integrations is sent to third party LLMs.

Why does the Slack channel list show nothing?

The bot has not been invited to any channel, or the token lacks channels:read. Invite the bot with /invite in the channel, add the scope if needed, reinstall the app and retry.

Does Safeguard support Google Chat?

Yes, as a card switched on per workspace. It posts through a space's incoming webhook, which needs a Business or Enterprise Google Workspace account.

You can download Safeguard and follow along with the Safeguard docs. For background on noise, see how to reduce alert fatigue from vulnerability scanners, why alert fatigue, not tool gaps, is the real AppSec bottleneck and what Safeguard does today, every capability labelled.

The alert tells you what is wrong. The next step is closing the gap between the alert and a fix in production, which is what the section below covers for every vulnerability, whichever channel it arrived in.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The chat integration tells a channel that something needs attention. These demos show what happens next, in the tools where the fix gets made and approved.

This demo is a real Safeguard CLI session. You ask it to fix a lodash CVE in a repository; it reads the finding and advisory, asks before any command that changes something, edits the dependency, runs install and tests with approval, and pushes nothing. The same flow applies when a chat alert names a vulnerable dependency in one of your repos.

Click through it at your own pace, or open it full screen.

This demo shows Claude working with Safeguard: you add Safeguard, sign in with OAuth and choose which tools Claude can use. When an alert lands in chat and someone wants to ask follow up questions about affected projects, this is the conversational route that works today, since the chat cards do not take commands.

Click through it at your own pace, or open it full screen.

This demo is a real Android session with the Safeguard mobile app. You send work to a computer running the CLI and approve the command on the phone with Allow once, Allow for turn or Deny. For an on call engineer who sees an alert away from a desk, it shows how approval can happen from the phone.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Safeguard docs: Slack, Teams and Discord (ChatOps integrations)
• Safeguard docs: Slack integration
• Safeguard docs: Microsoft Teams integration
• Safeguard docs: Discord integration
• Safeguard docs: Google Chat integration
• Safeguard docs: Webhooks and events
• Safeguard: Slack app
• Slack: Sending messages using incoming webhooks
• Slack: Rate limits
• Microsoft Learn: Create an incoming webhook
• Discord Developer Docs: Webhook resource
• Google for Developers: Build a Google Chat app as a webhook
• NIST SP 800-218: Secure Software Development Framework
• NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning
• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations
• CISA: Cybersecurity directives

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.