Email notifications | Cefense docs

Six kinds of email, each one its own switch. Five of them are yours to turn off. The sixth tells you that somebody granted a credential for your account, which is exactly the message whose value depends on arriving when it is not wanted.

The six kinds

Kind	Sent when	What it carries	Default
`connection`	A GitHub, GitLab, or Bitbucket credential is granted to your workspace	Which host, which account, what scopes, where the grant came from, and what is already connected	Always on
`scan_report`	A scan finishes having found something	Counts by severity, the repository, the branch, the commit, and how long it took	On, at High and above
`scan_failed`	A scan stops without a usable result	The reason, how many times in a row it has now failed, and when the repository was last covered properly	On
`advisory`	A CVE is published against a package one of your scans recorded	The advisory, the package and version, the fixed version, and how many repositories are affected	Off
`fix_pr_opened`	Cefense opens a pull request carrying a patch	The pull request, the branch, and the finding it closes	On
`immunity`	A threat becomes exposed or closed between two scans, new research reaches a package a scan recorded, or a Hyper sandbox run finishes	Threat names, tiers and counts, the package and version for research, and for Hyper the result or why it did not run, with missing environment variable names but never their values	On, at High and above

A scan report says how many, not which

Counts by severity, and nothing more. No titles, no file paths, no code. The finding belongs in the workspace behind a sign-in, not in a mailbox and a mail provider's logs. A scan that found nothing sends no email at all, because an all-clear every six hours is how a sending address gets filtered.

Severity floors

Three kinds carry findings, and those three carry a floor: a scan report, an advisory, and an Immunity change. Anything below the floor does not send, and the email says how many were held back so a small number is never mistaken for the whole picture.

Kind	Floor	Default
`scan_report`	`critical`, `high`, `watch`, or `info`	`high`
`advisory`	`critical`, `high`, `watch`, or `info`	`critical`
`immunity`	`critical`, `high`, `watch`, or `info`	`high`
`connection`, `scan_failed`, `fix_pr_opened`	None. They are single events, not findings.	n/a

Setting a floor on one of the last three is refused rather than accepted, because a control with nothing behind it is worse than no control.

Cadence

Only the scan report repeats often enough for a cadence to mean anything. every sends one email per qualifying scan. daily sends the first qualifying one and nothing else for a day.

One repository behaving differently

Any repository can be given its own exception: a different severity floor, or silence altogether. An exception is stored only when it actually differs, so the list stays a list of exceptions rather than a copy of every repository you have.

From the terminalbash

cf notifications
cf notifications set scan_report --severity critical --cadence daily
cf notifications set advisory --on
cf notifications mute acme/legacy-api
cf notifications repo acme/payments --severity watch
cf notifications repo acme/legacy-api --reset

cf notify is the same command. The workspace has the same controls under the account menu.

Behaviour	What it does
A repository's floor	Replaces the kind's floor for that repository. It does not widen it or narrow it, it stands in for it.
Muting a repository	Stops every repository-scoped email about it: reports, failures, advisories, and pull requests.
`--reset`	Removes the exception, so the repository goes back to following your ordinary settings.

Whose settings these are

Yours, and yours in this organization. Two people on the same team can set completely different floors, and the same person on two teams has two independent sets. Nothing you leave alone is written down: a person who never opens the screen is simply on the defaults.

Everyone in the organization is a candidate for every organization-scoped email, and each is evaluated against their own settings. The person who published a pull request is left off the email announcing it, on the grounds that they know.

The workspaceWhere the notification controls live, and what else is there.Scan triggers and scheduleHow often a scan finishes is how often a report can arrive.Organizations and rolesWho is on the list, and why it is per organization.

Have a correction or need help?

Email the docs team