Behebungskennzahlen
Die Behebungskennzahlen zeigen, ob die Funktionen zum Priorisieren und Beheben für deine Organisation ihren Zweck erfüllen. Die Seite misst die Erfolgskennzahlen von Erreichbarkeit und Sicherheitskorrekturen an deinen eigenen Befunden, über die letzten 30 oder 90 Tage, und vergleicht jeden Zeitraum mit derselben Anzahl Tage unmittelbar davor.
Du findest sie unter Sicherheit › Berichte › Behebungskennzahlen
(/<org>/_admin/security/reports/remediation). Owner der Organisation und
Mitglieder ihres Teams Auditors können sie öffnen. Wähle oben auf der Seite
Letzte 30 Tage oder Letzte 90 Tage.
Jede Zahl betrifft nur deine Organisation. Nichts wird mit anderen Organisationen verglichen oder aus ihnen berechnet.
Auf derselben Seite befindet sich die Karte Anonyme Zahlen beitragen: eine Opt-in-Einstellung, standardmäßig aus, die die Zahlen deiner Organisation anonym zu den Zahlen hinzufügt, die fremforge veröffentlicht. Siehe Anonyme Zahlen.
Was sie zeigt
| Abschnitt | Was er zeigt |
|---|---|
| Erreichbarkeit | Offene Abhängigkeitsbefunde pro Ökosystem, aufgeteilt nach Urteil: erreichbar, nicht erreichbar (unreachable) und unbekannt. Abdeckung ist der Anteil mit einem anderen Urteil als unbekannt. Anteil ohne Aufrufpfad ist der Anteil, bei dem die Engine keinen Pfad von deinem Code zur verwundbaren Funktion gefunden hat. Die Zielwerte sind 60 % Abdeckung für Go und 30 % für npm sowie 30 % nicht erreichbar für Go. Ökosysteme ohne Engine sind gekennzeichnet. |
| Verlauf der Abdeckung | Abdeckung und Anteil nicht erreichbar pro Tag, aus einem täglichen Snapshot der eigenen Befunde deiner Organisation. Der Snapshot begann am 2026-10-14, daher füllt sich das Diagramm ab diesem Datum; bis zwei Tage gespeichert sind, meldet der Bereich, dass er noch Daten sammelt. |
| Pull Requests für Sicherheitskorrekturen | Pro Engine, deterministisch (Abhängigkeits-Upgrades) und KI-gestützt (SAST, mit deinem eigenen Modellschlüssel): im Zeitraum gestellte Anfragen, geöffnete, gemergte, geschlossene und noch auf Review wartende Pull Requests sowie die Merge-Quote (gemergt geteilt durch geöffnet). Die Zielwerte sind 70 % für deterministische und 40 % für KI-gestützte Pull Requests. |
| Durch eine Sicherheitskorrektur behobene Befunde | Befunde, die ein Scan nicht mehr gemeldet hat, nachdem der Pull Request ihrer Sicherheitskorrektur gemergt wurde, pro Typ und pro Tag. Die API liefert zusätzlich findings_fixed_by_renovate: Befunde, deren Paket einer der eigenen Sicherheits-Pull-Requests des gehosteten Renovate angehoben hat, während sie offen waren (gezählt ab 2026-10-14). |
| Behebungsdauer | Der Median der Tage zwischen dem ersten Auftreten eines hohen oder kritischen Abhängigkeitsbefunds und dem Zeitpunkt, an dem ein Scan ihn nicht mehr gemeldet hat. Dieser Zeitraum gegenüber dem vorherigen und innerhalb dieses Zeitraums durch AutoFix behoben gegenüber anders behoben. |
| Behebungsdauer nach Befundtyp | Für Abhängigkeiten, Container-Images, IaC, Secrets und SAST, jeder Schweregrad: der Median der Tage bis zur Behebung der in diesem und im vorherigen Zeitraum behobenen Befunde, die Mediane pro Schweregrad und die in diesem Zeitraum verworfenen Befunde mit ihrem eigenen Median. Siehe die Definitionen unten. |
| Dauer bis zum Merge von Sicherheitskorrekturen | Der Median der Stunden vom Öffnen bis zum Merge der in diesem und im vorherigen Zeitraum gemergten Pull Requests für Sicherheitskorrekturen: deterministisch, KI-gestützt und die eigenen Sicherheits-Pull-Requests des gehosteten Renovate. Renovate-Pull-Requests werden ab dem 24. Oktober 2026 gezählt, seit ihr Öffnungszeitpunkt erfasst wird; die Seite nennt das Datum. |
| Bekanntermaßen ausgenutzt | Offene Befunde in Abhängigkeiten und Container-Images, deren Schwachstelle in der EU Vulnerability Database der ENISA oder im Katalog Known Exploited Vulnerabilities der CISA als ausgenutzt geführt wird, mit Links zu den gefilterten Befundlisten. |
| SLA-Verstöße | Pro Tag die Befunde aller Scanner, die über ihre SLA hinaus offen sind, alle Schweregrade sowie hoch und kritisch, und die neuen Verstöße pro Tag. Summen für diesen und den vorherigen Zeitraum. |
Wie die Zahlen entstehen
- Eindeutige Befunde. Ein Abhängigkeitsbefund zählt einmal pro Repository, Paket und Advisory, gleich wie viele Branches oder Pull Requests ihn melden. Die offenen Abhängigkeitsbefunde werden an jedem Tag des Verlaufs auf dieselbe Weise gezählt.
- Der tägliche Snapshot wird einmal am Tag nur für deine Organisation erstellt, aus derselben Zählung wie die Abdeckungswerte oben, und nie mit Daten anderer Organisationen zusammengeführt. Er wird so lange aufbewahrt wie deine Einstellung für die Befundhistorie, wenn du eine gesetzt hast, andernfalls 18 Monate, und er wird gelöscht, wenn deine Organisation gelöscht wird. Ein Legal Hold bewahrt ihn auf.
- Urteile sind keine Verwerfungen. Ein nicht erreichbarer Befund bleibt offen und wird überall als offen gezählt. Siehe Erreichbarkeit.
- Pull Requests für Sicherheitskorrekturen werden nach dem Datum gezählt, an dem die Korrektur angefordert wurde. Ein Pull Request, der noch auf Review wartet, senkt die Merge-Quote, bis er gemergt oder geschlossen wird.
- Behebungsdauer und SLA-Verstöße stammen aus der Befundhistorie, die mit dem Beginn der Historienerfassung deiner Organisation beginnt (die Seite nennt das Datum). Ein Befund, der an diesem Datum bereits offen war, zählt ab dem Zeitpunkt, an dem er zum ersten Mal gespeichert wurde.
- Was als geöffnet und behoben gilt (Behebungsdauer nach Typ):
- Geöffnet ist der Zeitpunkt, an dem der Befund zum ersten Mal auf dem Standard-Branch gesehen wurde. Ein Befund, den nur ein Pull Request meldet, wird nicht gezählt.
- Behoben ist der erste Scan, der ihn nicht mehr meldet. Bei einem Befund, den sein Scanner als erledigt markiert, ist das exakt; andernfalls ist es die tägliche Aktualisierung der Historie, die ihn als Erste nicht mehr enthielt, also höchstens einen Tag zu spät.
- Eine Verwerfung ist keine Behebung. Verworfene Befunde werden getrennt gezählt, mit dem Median der Tage von geöffnet bis verworfen.
- Ein Befund, der zurückkehrt, beginnt von vorn. Er zählt ab seinem erneuten Auftreten, nicht ab seinem ersten Auftreten.
- IaC-Befunde haben seit dem 24. Oktober 2026 einen eigenen Typ; davor wurden sie mit den Container-Images gezählt. Historie von vor diesem Datum wurde zu IaC verschoben, wo der eigene Datensatz des Scanners zu dem Befund noch existiert.
- Die Dauer bis zum Merge reicht vom Öffnen des Pull Requests bis zu seinem Merge, für Pull Requests, die im Zeitraum gemergt wurden. Noch offene oder ohne Merge geschlossene Pull Requests werden nicht gezählt.
- SLA-Fristen sind dieselben effektiven Fristen wie in den SLA-Markierungen und im Compliance-Bericht, einschließlich einer längeren SLA für nicht erreichbare Befunde, wenn deine SLA-Richtlinie einen Multiplikator festlegt. Ein Befund verletzt seine SLA, wenn die Frist verstreicht, während er weder behoben noch verworfen ist.
API
Dieselben Zahlen stehen über die API mit einem Token zur Verfügung, das den
Scope findings:read hat:
curl -H "Authorization: Bearer $FREMFORGE_TOKEN" \
"https://frem.sh/_app/api/v1/orgs/<org>/code-security/remediation-metrics?days=30"days ist 30 (der Standard) oder 90. Die Antwort enthält die Abschnitte oben
als reachability, autofix, time_to_fix, time_to_fix_by_type,
time_to_merge, known_exploited und sla, dazu window und targets.
Prozentwerte sind Zahlen von 0 bis 100 mit einer Nachkommastelle oder null,
wenn es nichts zu teilen gibt. Das Schema findest du in der
OpenAPI-Spezifikation.