Warnungen: neu erreichbar oder als ausgenutzt bekannt
Ein neuer hoher oder kritischer Befund löst bereits die Sicherheitswarnung aus. Diese Warnung gilt den Befunden, die du schon hast: Sie meldet, wenn sich einer davon so ändert, dass er heute in der Warteschlange nach oben rücken sollte.
Was sie auslöst
Offene Abhängigkeitsbefunde auf dem Standard-Branch eines Repositorys. Befunde aus Pull Requests kommen und gehen mit jedem Pull Request und lösen nie eine Warnung aus.
| Übergang | Wann |
|---|---|
| Wurde erreichbar | Das Erreichbarkeits-Urteil des Befunds war unbekannt oder nicht erreichbar (unreachable), und eine spätere Analyse hat ihn als erreichbar eingestuft: zum Beispiel ein Go-Modul, dessen Urteil unbekannt war, bis ein aus dem Commit gebautes Image gelesen wurde. Ein Befund, der schon beim ersten Auftreten erreichbar ist, ist ein neuer Befund, den die Sicherheitswarnung abdeckt, und löst hier daher keine Warnung aus. |
| Wurde als ausgenutzt bekannt | Eine der CVE-IDs des Befunds (seine eigene ID oder ein CVE-Alias seiner Advisory) wurde, seit fremforge zuletzt nachgesehen hat, in der EU Vulnerability Database der ENISA oder im Katalog Known Exploited Vulnerabilities der CISA als aktiv ausgenutzt gelistet, oder ein neuer Befund war bereits gelistet. Als ausgenutzt bekannte Befunde lösen unabhängig vom Schweregrad eine Warnung aus. |
Befunde in Container-Images lösen hier keine Warnung aus. Ihre Urteile und Markierungen als ausgenutzt bekannt stehen in der Konsole, in der Findings-API und in den SIEM-Befundereignissen.
fremforge prüft jede Stunde. Die erste Prüfung für eine Organisation hält fest, was bereits erreichbar und gelistet ist, und sendet nichts. Das Einschalten verschickt also nie deinen Rückstau per E-Mail.
Wer sie erhält
Die Sicherheitskontakte der Organisation: jedes aktuelle Mitglied, dessen eigene Benachrichtigungseinstellung Sicherheitswarnungen eingeschaltet ist, also dieselben Personen, die die Sicherheitswarnung erhalten. Jede Person kann sie in ihren Benachrichtigungseinstellungen für sich abschalten. Wer die Organisation verlassen hat, erhält nichts. Bot-Konten erhalten nie E-Mails.
Sofort oder in der täglichen Warnungszusammenfassung. Ein Übergang zu als ausgenutzt bekannt und ein Befund, der mit Schweregrad HIGH oder CRITICAL erreichbar wurde, werden sofort gemailt. Ein Befund, der mit Schweregrad MEDIUM oder LOW erreichbar wurde, landet in der täglichen Warnungszusammenfassung des Empfängers, die standardmäßig eingeschaltet ist; wer die Zusammenfassung abgeschaltet hat, erhält ihn wie bisher sofort. Das Audit-Ereignis wird in jedem Fall sofort geschrieben (siehe SIEM).
- Owner erhalten die Liste: Repository, Paket, Version, Advisory, Schweregrad und was sich geändert hat, mit Links zu den Befunden.
- Mitglieder erhalten nur die Zahlen, weil die Sicherheitskonsole Ownern vorbehalten ist.
Die E-Mail ist in der Sprache des Empfängers (Englisch, Dänisch, Deutsch, Französisch, Niederländisch, Norwegisch oder Schwedisch).
Einmal pro Befund und höchstens stündlich
- Eine Warnung pro Befund und Übergang, für immer. Ein Befund, der erreichbar wird, löst einmal eine Warnung aus. Fällt sein Urteil auf nicht erreichbar zurück und wird dann wieder erreichbar, löst er keine weitere aus. Dasselbe gilt für als ausgenutzt bekannt. Das gilt pro Person über beide E-Mails hinweg: Ein Übergang, der in deiner täglichen Warnungszusammenfassung aufgeführt ist, wird nicht noch einmal gemailt, und einer, der bereits sofort gemailt wurde, steht in keiner späteren Zusammenfassung, egal wie du die Zusammenfassung umschaltest. Schaltest du die Zusammenfassung ab, werden neue Einträge ab dann sofort gesendet; Einträge, die bereits für die Zusammenfassung zurückgelegt waren, werden nicht erneut gesendet, bleiben aber in der Konsole und im Audit-Log.
- Eine E-Mail pro Stapel. Alle in einer Prüfung gefundenen Übergänge gehen in einer E-Mail hinaus, als ausgenutzt bekannte zuerst, dann nach Schweregrad. Eine E-Mail listet bis zu 20 auf und sagt, wie viele es darüber hinaus gibt.
- Ratenbegrenzung pro Organisation. Höchstens eine Warnungs-E-Mail pro Stunde und höchstens vier in 24 Stunden. Ein dazwischen gefundener Übergang wartet und kommt in die nächste E-Mail. Einer, der 7 Tage gewartet hat, wird nicht mehr gemailt; der wöchentliche Digest zählt ihn trotzdem.
SIEM
Jeder Übergang wird außerdem ins Audit-Log geschrieben und erreicht so wie jedes Audit-Ereignis deine SIEM-Endpunkte:
| Aktion | Felder |
|---|---|
code-security.finding.became_reachable | alert_id, finding_key, repo, ecosystem, package, version, vulnerability_id, severity, reason (unknown oder unreachable: das vorherige Urteil) |
code-security.finding.became_known_exploited | dieselben, reason (listed oder new), cve_ids, sources (euvd, cisa_kev) |
finding_key ist die Identität, die die SIEM-Befundereignisse verwenden: dep:<repo>:<advisory>:<ecosystem>:<package>@<version>. Audit-Ereignisse sind nicht ratenbegrenzt und werden für jeden Übergang geschrieben, sobald er erkannt wird, unabhängig von den E-Mail-Einstellungen aller Beteiligten und davon, ob die Organisation die Warnungs-E-Mail abgeschaltet hat.
Abschalten
Die Warnung ist standardmäßig eingeschaltet. Ein Owner schaltet sie für die ganze Organisation unter Sicherheit › Berichte › Benachrichtigungen ab oder wieder ein; die Seite zeigt auch, wie viele Befunde in den letzten 7 Tagen erreichbar oder als ausgenutzt bekannt wurden. Alternativ geht das über den Punkt Warnungen: neu erreichbar oder als ausgenutzt bekannt der Einrichtungs-Checkliste unter Sicherheit › Übersicht. Die Änderung wird als code-security.transition_alerts.updated mit dem vorherigen und dem neuen Wert auditiert.
Solange sie abgeschaltet ist, werden Übergänge weiterhin erfasst, sodass der wöchentliche Digest sie weiterhin zählt, und jeder wird weiterhin ins Audit-Log geschrieben (und erreicht so dein SIEM), aber nichts wird gemailt, weder sofort noch in einer täglichen Warnungszusammenfassung. Das Wiedereinschalten sendet nicht nach, was in der Zwischenzeit passiert ist.
API
GET /_app/api/v1/orgs/{org}/security/transition-alerts (policy:read) gibt die Einstellung und die seit since erkannten Übergänge zurück, deren Befund noch offen ist, die wichtigsten zuerst, höchstens 50 pro Art. since ist ein ISO-8601-Datum oder -Zeitpunkt, höchstens 90 Tage zurück; der Standard ist vor 7 Tagen.
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 mit {"enabled": false} (policy:write) schaltet sie ab, auditiert wie der Schalter in der Konsole, mit via: api.
Siehe auch
- Erreichbarkeit: die Urteile.
- Sicherheitskorrekturen: Korrekturen für als ausgenutzt bekannte Befunde werden zuerst geöffnet.
- Wöchentlicher Digest: die in der Woche neu erreichbaren und neu als ausgenutzt bekannten Befunde.