Alerts: newly reachable or known exploited

A new high or critical finding already sends the security alert. This alert is for the findings you already have: it tells you when one of them changes in a way that should move it up the queue today.

What triggers it

Open dependency findings on a repository’s default branch. Pull request findings come and go with every pull request and never alert.

Transition	When
Became reachable	The finding’s reachability verdict was unknown or not reachable (`unreachable`), and a later analysis found it reachable: for example a Go module whose verdict was unknown until an image built from the commit was read. A finding that is reachable the first time it is seen is a new finding, which the security alert covers, so it does not alert here.
Became known exploited	One of the finding’s CVE ids (its own id, or a CVE alias of its advisory) was listed as exploited in the wild by ENISA’s EU Vulnerability Database or CISA’s Known Exploited Vulnerabilities catalogue since fremforge last looked, or a new finding was already listed. Known exploited alerts whatever the severity.

Container image findings do not alert here. Their verdicts and known-exploited badges are in the console, the findings API and the SIEM finding events.

fremforge checks every hour. The first check for an organisation records what is already reachable and listed and sends nothing, so turning this on never mails your backlog.

Who receives it

The organisation’s security contacts: every current member whose own Security alerts notification setting is on, the same people who receive the security alert. Each person can turn it off for themselves in their notification settings. Someone who has left the organisation receives nothing. Bot accounts never receive mail.

At once, or in the daily alert summary. A transition to known exploited, and a finding that became reachable at HIGH or CRITICAL severity, are mailed at once. A finding that became reachable at MEDIUM or LOW severity goes into the recipient’s daily alert summary, which is on by default; a person who has switched the summary off gets it at once, as before. The audit event is written at once either way (see SIEM).

Owners get the list: repository, package, version, advisory, severity and what changed, with links to the findings.
Members get the counts only, because the security console is owner-only.

The mail is in the recipient’s language (English, Danish, German, French, Dutch or Swedish).

Once per finding, and at most hourly

One alert per finding per transition, ever. A finding that becomes reachable alerts once. If its verdict goes back to not reachable and then to reachable again, it does not alert again. The same holds for known exploited. This holds per person across both emails: a transition listed in your daily alert summary is not mailed again, and one already mailed at once is not listed in a later summary, whichever way you switch the summary. Switching the summary off sends new items at once from then on; items already set aside for the summary are not re-sent, though they stay in the console and the audit log.
One mail per batch. All transitions found in one check go out in one mail, known exploited first, then by severity. A mail lists up to 20 and says how many more there are.
Rate limit per organisation. At most one alert mail an hour, and at most four in 24 hours. A transition found in between waits and goes in the next mail. One that has waited 7 days is no longer mailed; the weekly digest still counts it.

SIEM

Each transition is also written to the audit log, and so reaches your SIEM endpoints like every audit event:

Action	Fields
`code-security.finding.became_reachable`	`alert_id`, `finding_key`, `repo`, `ecosystem`, `package`, `version`, `vulnerability_id`, `severity`, `reason` (`unknown` or `unreachable`: the verdict before)
`code-security.finding.became_known_exploited`	the same, `reason` (`listed` or `new`), `cve_ids`, `sources` (`euvd`, `cisa_kev`)

finding_key is the identity the SIEM finding events use: dep:<repo>:<advisory>:<ecosystem>:<package>@<version>. Audit events are not rate-limited, and they are written for every transition when it is detected, whatever anyone’s email setting and whether or not the organisation has the alert email switched off.

Turning it off

The alert is on by default. An owner switches it off, or on again, for the whole organisation on Security › Reports › Notifications, which also shows how many findings became reachable or known exploited in the last 7 days, or in the setup checklist item Alerts: newly reachable or known exploited on Security › Overview. The change is audited as code-security.transition_alerts.updated, with the previous and the new value.

While it is off, transitions are still recorded, so the weekly digest still counts them, and each one is still written to the audit log (and so reaches your SIEM), but nothing is mailed, neither at once nor in a daily alert summary. Turning it on again does not send what happened while it was off.

API

GET /_app/api/v1/orgs/{org}/security/transition-alerts (policy:read) returns the setting and the transitions detected since since whose finding is still open, most important first, at most 50 of each kind. since is an ISO 8601 date or date-time, at most 90 days ago; the default is 7 days ago.

curl -sS -H "Authorization: Bearer $TOKEN" \
  "https://frem.sh/_app/api/v1/orgs/acme/security/transition-alerts?since=2026-10-01"

{
  "enabled": true,
  "since": "2026-10-01T00:00:00.000Z",
  "became_reachable": { "count": 1, "items": [{ "transition": "reachable", "repo": "acme/web", "package": "lodash", "version": "4.17.20", "vulnerability_id": "GHSA-35jh-r3h4-6jhm", "severity": "high", "reason": "…", "sources": [] }] },
  "became_known_exploited": { "count": 0, "items": [] }
}

PUT with {"enabled": false} (policy:write) switches it off, audited like the console’s switch with via: api.