Alertes : nouvellement atteignables ou connues comme exploitées

Un nouveau résultat de gravité élevée ou critique déclenche déjà l’alerte de sécurité. Cette alerte-ci concerne les résultats que vous avez déjà : elle vous prévient lorsque l’un d’eux change d’une manière qui doit le faire remonter dans la file dès aujourd’hui.

Ce qui la déclenche

Les résultats de dépendances ouverts sur la branche par défaut d’un dépôt. Les résultats de pull request apparaissent et disparaissent avec chaque pull request et ne déclenchent jamais d’alerte.

Transition Quand

Devenu atteignable Le verdict d’atteignabilité du résultat était inconnu ou non atteignable (unreachable), et une analyse ultérieure l’a trouvé atteignable : par exemple un module Go dont le verdict est resté inconnu jusqu’à la lecture d’une image construite à partir du commit. Un résultat atteignable dès sa première détection est un nouveau résultat, couvert par l’alerte de sécurité ; il ne déclenche donc pas d’alerte ici.

Devenu connu comme exploité L’un des identifiants CVE du résultat (son propre identifiant, ou un alias CVE de son avis) a été répertorié comme exploité dans la nature par la base de données européenne des vulnérabilités (EUVD) de l’ENISA ou par le catalogue Known Exploited Vulnerabilities de la CISA depuis la dernière vérification de fremforge, ou un nouveau résultat y figurait déjà. Les résultats connus comme exploités déclenchent une alerte quelle que soit leur gravité.

Transition	Quand
Devenu atteignable	Le verdict d’atteignabilité du résultat était inconnu ou non atteignable (`unreachable`), et une analyse ultérieure l’a trouvé atteignable : par exemple un module Go dont le verdict est resté inconnu jusqu’à la lecture d’une image construite à partir du commit. Un résultat atteignable dès sa première détection est un nouveau résultat, couvert par l’alerte de sécurité ; il ne déclenche donc pas d’alerte ici.
Devenu connu comme exploité	L’un des identifiants CVE du résultat (son propre identifiant, ou un alias CVE de son avis) a été répertorié comme exploité dans la nature par la base de données européenne des vulnérabilités (EUVD) de l’ENISA ou par le catalogue Known Exploited Vulnerabilities de la CISA depuis la dernière vérification de fremforge, ou un nouveau résultat y figurait déjà. Les résultats connus comme exploités déclenchent une alerte quelle que soit leur gravité.

Les résultats des images de conteneurs ne déclenchent pas d’alerte ici. Leurs verdicts et leurs badges « connu comme exploité » figurent dans la console, dans l’API des résultats et dans les événements de résultats SIEM.

fremforge vérifie toutes les heures. La première vérification pour une organisation enregistre ce qui est déjà atteignable et répertorié, sans rien envoyer : activer l’alerte ne vous envoie donc jamais tout votre arriéré par e-mail.

Qui la reçoit

Les contacts sécurité de l’organisation : chaque membre actuel dont le paramètre de notification personnel Alertes de sécurité est activé, c’est-à-dire les mêmes personnes que celles qui reçoivent l’alerte de sécurité. Chacun peut la désactiver pour lui-même dans ses paramètres de notification. Une personne qui a quitté l’organisation ne reçoit rien. Les comptes de bot ne reçoivent jamais d’e-mail.

Immédiatement, ou dans le récapitulatif quotidien des alertes. Une transition vers « connu comme exploité », et un résultat devenu atteignable de gravité HIGH ou CRITICAL, sont envoyés immédiatement. Un résultat devenu atteignable de gravité MEDIUM ou LOW est intégré au récapitulatif quotidien des alertes du destinataire, activé par défaut ; une personne qui a désactivé le récapitulatif le reçoit immédiatement, comme auparavant. Dans tous les cas, l’événement d’audit est écrit immédiatement (voir SIEM).

Les propriétaires reçoivent la liste : dépôt, paquet, version, avis, gravité et ce qui a changé, avec des liens vers les résultats.
Les membres ne reçoivent que les totaux, car la console de sécurité est réservée aux propriétaires.

L’e-mail est rédigé dans la langue du destinataire (anglais, danois, allemand, français, néerlandais, norvégien ou suédois).

Une fois par résultat, et au plus une fois par heure

Une seule alerte par résultat et par transition, pour toujours. Un résultat qui devient atteignable déclenche une alerte une fois. Si son verdict repasse à non atteignable puis redevient atteignable, il ne déclenche pas de nouvelle alerte. Il en va de même pour « connu comme exploité ». Cette règle vaut par personne pour les deux e-mails : une transition listée dans votre récapitulatif quotidien des alertes n’est pas renvoyée, et une transition déjà envoyée immédiatement n’est pas listée dans un récapitulatif ultérieur, quelle que soit la façon dont vous basculez le récapitulatif. Désactiver le récapitulatif envoie les nouveaux éléments immédiatement à partir de ce moment ; les éléments déjà mis de côté pour le récapitulatif ne sont pas renvoyés, mais ils restent dans la console et dans le journal d’audit.
Un e-mail par lot. Toutes les transitions détectées lors d’une vérification partent dans un seul e-mail, les résultats connus comme exploités en premier, puis par gravité. Un e-mail en liste jusqu’à 20 et indique combien il en reste.
Limite de fréquence par organisation. Au plus un e-mail d’alerte par heure, et au plus quatre en 24 heures. Une transition détectée entre-temps attend et part dans l’e-mail suivant. Une transition qui attend depuis 7 jours n’est plus envoyée ; le résumé hebdomadaire la compte toujours.

SIEM

Chaque transition est également écrite dans le journal d’audit, et parvient donc à vos points de terminaison SIEM comme tout événement d’audit :

Action	Champs
`code-security.finding.became_reachable`	`alert_id`, `finding_key`, `repo`, `ecosystem`, `package`, `version`, `vulnerability_id`, `severity`, `reason` (`unknown` ou `unreachable` : le verdict précédent)
`code-security.finding.became_known_exploited`	les mêmes, `reason` (`listed` ou `new`), `cve_ids`, `sources` (`euvd`, `cisa_kev`)

finding_key est l’identité qu’utilisent les événements de résultats SIEM : dep:<repo>:<advisory>:<ecosystem>:<package>@<version>. Les événements d’audit ne sont pas limités en fréquence, et ils sont écrits pour chaque transition dès sa détection, quels que soient les paramètres d’e-mail de chacun et que l’organisation ait ou non désactivé l’e-mail d’alerte.

Désactivation

L’alerte est activée par défaut. Un propriétaire la désactive, ou la réactive, pour toute l’organisation dans Sécurité › Rapports › Notifications, qui indique aussi combien de résultats sont devenus atteignables ou connus comme exploités au cours des 7 derniers jours, ou via l’élément Alertes : nouvellement atteignables ou exploitées de la liste de configuration dans Sécurité › Vue d’ensemble. La modification est auditée sous code-security.transition_alerts.updated, avec l’ancienne et la nouvelle valeur.

Tant qu’elle est désactivée, les transitions sont toujours enregistrées, donc le résumé hebdomadaire les compte toujours, et chacune est toujours écrite dans le journal d’audit (et parvient donc à votre SIEM), mais rien n’est envoyé par e-mail, ni immédiatement ni dans un récapitulatif quotidien des alertes. La réactiver n’envoie pas ce qui s’est passé pendant qu’elle était désactivée.

API

GET /_app/api/v1/orgs/{org}/security/transition-alerts (policy:read) renvoie le paramètre et les transitions détectées depuis since dont le résultat est toujours ouvert, les plus importantes en premier, au plus 50 de chaque type. since est une date ou une date-heure ISO 8601, au plus 90 jours en arrière ; par défaut, il y a 7 jours.

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 avec {"enabled": false} (policy:write) la désactive, ce qui est audité comme le bouton de la console, avec via: api.

Voir aussi

Atteignabilité : les verdicts.
Correctifs de sécurité : les correctifs des vulnérabilités connues comme exploitées sont ouverts en premier.
Résumé hebdomadaire : les résultats de la semaine nouvellement atteignables et nouvellement connus comme exploités.

Politiques Correctifs à base de règles