Notifications

The bell, chat, and email surfaces that carry advisories and other security-relevant events out of Cygent — and how to route them.

Overview

Cygent has two notification surfaces, and they're independent on purpose.

Surface	Where it shows up	What it's for
In-app bell	The bell icon in the top nav	Lightweight, always-on log of every notable event on your instance. Org-scoped — everyone in your org sees the same inbox.
Chat + email dispatch	Slack, Discord, Telegram channels and email inboxes you've configured	Outbound delivery, gated by per-channel routing rules. This is the surface you tune for "page the team" vs. "log it quietly."

The bell always receives every event. The chat/email channels only receive what your notification routing says they should.

Today, the main consumer is dependency advisories (see Dependencies). The dispatch system is generic, so the same surfaces carry other kinds of events as they're added (audit completions, PR review summaries, pentest results).

For advisories specifically, the dispatcher emits one event per lifecycle transition that matters:

Event	When
New	A scan matched an advisory that wasn't on the repo before
Re-detected	An open advisory matched again after a path change or short suppression — confirms it's still live
Reopened	A previously resolved or dismissed advisory matched again. Always notifies, because the prior closed state was a deliberate decision
Severity upgraded	Upstream raised the severity on an advisory you already have
Resolved	The affected version disappeared from your manifests and the advisory auto-closed
Withdrawn	Upstream withdrew the CVE itself — the row stays, the message tells you it's no longer real

The Notifications tab

The Notifications tab on an instance has two sub-pages: the inbox and the settings.

Inbox

A filterable feed of every notification that has fired on this instance. You'll typically use:

Filter	Default	Notes
Status	Unread	`Unread` is your work queue. `Open` includes acknowledged but not yet resolved. `Resolved` and `All` are for history.
Severity	(any)	Critical / High / Medium / Low — pulled from the underlying event
Kind	(any)	Filter to one event type, e.g. advisory-new
Search	—	Free-text match on title and body

Click any row for the full payload — for advisory notifications, that's the same denormalized snapshot the chat and email dispatchers use (title, severity, suggested fix, affected repos with manifest paths, deep link to the source advisory).

Settings

The settings sub-page is where you configure routing. Three sections:

Sources — read-only strip listing what kinds of events this instance currently emits. Mostly informational today.
Security contacts — per-channel destinations (email addresses, Slack channel ID, Discord channel ID, Telegram chat ID). Add at least one contact per channel before enabling that channel in routing.
Notification routing — the matrix: one row per channel, columns for the message types it gets, and a severity threshold per channel.

Routing matrix

Each channel — email, Slack, Discord, Telegram — has its own row with three knobs:

Knob	What it does
Enabled	Master switch for that channel. Disabled = nothing goes out, regardless of other settings
Severity threshold	The minimum severity that passes through. Set to `High` and Medium / Low advisories don't reach this channel — they still hit the bell
Message types	Which event categories this channel receives: `attack` (active threats — new criticals, supply-chain attacks), `critical` (everyday advisory signal), `resolved` (close-out events)

Click a column header to toggle that message type across all channels at once — useful for "turn off resolved notifications everywhere."

💡

A common setup: email gets everything at High and above (durable record); Slack gets everything at Medium and above for the team's eyes; Telegram gets only attack at Critical, which is the page-the-oncall channel. You can preview each template before saving — click the Preview button at the top of the matrix.

The critical-route guardrail

If you disable every channel that handles critical messages, Cygent shows a confirmation dialog before letting the change save. The reasoning: silent muting of critical advisories is almost always a mistake, and most teams that hit this case meant to lower a threshold, not turn it off entirely.

You can still confirm and save — it's a guardrail, not a lock.

Testing a channel

Each enabled row in the routing matrix has a Test button. It sends a synthetic notification of the chosen message type to that channel using the real template, so you can verify destinations work before relying on them in an incident.

Use Preview to inspect what each template looks like without actually sending it.

Permissions

Role	What they can do
Organization owner	Edit routing, security contacts, and run test sends
Member	Read-only access to the settings page; full access to the inbox

The settings page shows a lock banner when you're viewing it without edit permission.

Good to know

Routing is per-instance. If you run multiple instances, configure each one separately.
Disabling a channel doesn't silence the bell. The bell inbox always receives every event — the routing matrix only controls outbound dispatch to chat and email.
Severity thresholds are per-channel. If you want one threshold across the board, set the same value on every row.