OSV-Empfehlungen

Das Abhängigkeits-Scanning meldet einzelne CVEs. Der Tab Empfehlungen unter Sicherheit › Befunde › Abhängigkeiten (/<org>/_admin/security/findings/dependencies?view=recommendations) macht aus dieser Liste eine Korrekturliste: Jeder offene Befund mit veröffentlichter Korrektur wird zu einer Karte, repo + package + current → fix + die CVEs, die dieses eine Upgrade behebt.

Wie Empfehlungen berechnet werden

Der Gruppierungsschlüssel ist (repo_full_name, ecosystem, package_name, current_version, fixed_version). Befunde, die in allen fünf übereinstimmen, werden zu einer Karte zusammengefasst.

Die Sortierung erfolgt in drei Stufen:

1. Erreichbarkeit: Eine Karte übernimmt das am stärksten erreichbare Erreichbarkeits-Urteil der Befunde, die sie behebt: zuerst erreichbar, dann unbekannt (einschließlich nicht analysiert), dann nicht erreichbar.
2. Schweregrad (innerhalb eines Urteils): kritisch → hoch → mittel → niedrig.
3. EPSS-Score (innerhalb des Schweregrads): Der höchste EPSS-Score unter den gebündelten Schwachstellen gewinnt.

Eine Advisory mit niedrigem Schweregrad, die dein Code erreicht, steht also über einer kritischen, die nicht erreichbar ist, und innerhalb desselben Urteils und Schweregrads steht eine Advisory, die aktiv ausgenutzt wird, über einer theoretischen. Eine nicht erreichbare Karte wird trotzdem aufgeführt; sie rutscht nur nach unten. Die Top-Empfehlungen in der Übersicht und der wöchentliche Digest verwenden dieselbe Reihenfolge.

Was die Karte zeigt

acme/api                                              critical
  npm:lodash 4.17.20 → 4.17.21
  3 vulns fixed · EPSS 23.4% · CVE-2021-23337, CVE-2020-8203 +1

Eine Karte mit dem Urteil erreichbar oder nicht erreichbar zeigt neben ihrem Schweregrad außerdem Erreichbar bzw. Nicht erreichbar.

• Manifest-Pfade: Ist dasselbe Paket in package-lock.json und pnpm-lock.yaml festgelegt, werden beide aufgeführt.
• EPSS: die höchste Wahrscheinlichkeit aus der Exploit-Vorhersage unter den gebündelten CVEs (0–100 %). Der tägliche Aktualisierungsjob holt die EPSS-Daten von FIRST.org.
• Schwachstellen-IDs: Die ersten drei werden direkt angezeigt, der Rest in einer Zusammenfassung +N.

Den Upgrade-PR bekommen

Jede Karte hat eine Schaltfläche Korrektur-PR öffnen für Pakete in den Ökosystemen, die Sicherheitskorrekturen erhalten (siehe Unterstützte Ökosysteme). Sie öffnet einen Pull Request, der dieses Paket in diesem Repository anhebt, als Abhängigkeits-Bot deiner Organisation, und er wartet auf ein Review oder wird gemergt, sobald seine Checks bestanden sind, je nachdem, was deine Organisation gewählt hat; siehe Mergen. Nach der Anforderung zeigt die Karte Fix vorgeschlagen: #N mit dem Zustand des Pull Requests.

Weitere Wege zum Upgrade:

• Lass die Abhängigkeits-Updates die PRs öffnen. Sind Abhängigkeits-Updates aktiviert, öffnet Renovate in seinem nächsten nächtlichen Lauf, nachdem eine Advisory (OSV) für eine Abhängigkeit veröffentlicht wurde, einen Sicherheits-Update-PR und ignoriert dabei deinen schedule und die Wartezeit für das Release-Alter. Wenn ein offener Renovate-PR ein Paket bereits anhebt, verlinkt der Befund im Tab Befunde darauf (Renovate-PR #n).
• Einen Lauf jetzt auslösen. Der Tab Empfehlungen hat eine Schaltfläche Einen Abhängigkeits-Update-Lauf auslösen, die einen außerplanmäßigen Renovate-Lauf für die ganze Organisation startet, höchstens einmal pro Stunde. Sind die Abhängigkeits-Updates nicht aktiviert, verlinkt der Tab auf die Seite, auf der du sie aktivierst.
• Selbst anheben. Jede Karte nennt das Paket, die installierte Version und die vorgeschlagene korrigierte Version, sodass du die Änderung in deinem eigenen Branch vornehmen und den PR-Scan bestätigen lassen kannst, dass die Befunde verschwunden sind.

Der alte Endpunkt Upgrade-PR öffnen bleibt stillgelegt und antwortet mit 410 Gone; die Schaltfläche Korrektur-PR öffnen ersetzt ihn.

Migration nötig: die Korrektur liegt in einem anderen Paket

Manche Advisories haben keine Korrektur für das Paket, das du verwendest, sind aber in einem Nachfolger behoben, den die Advisory selbst nennt: ein neuer Modulpfad oder eine neue Major-Version oder ein umbenanntes Paket. Beispiele aus echten Advisories:

Ein solcher Befund zeigt Migration zu <package> nötig (behoben in <version>) statt „noch keine Korrektur", in den Tabs Befunde und Nach Paket, in der API (needs_migration, siehe Befund-API) und im wöchentlichen Digest. Er erscheint nicht unter Empfehlungen und bekommt keine Schaltfläche Korrektur-PR öffnen: Der Wechsel zu einem anderen Modul oder Paket ändert Imports und oft auch die API, ist also eine Codeänderung, die du selbst vornimmst, und kein Versionssprung.

So wird der Nachfolger bestimmt:

• Die Advisory muss deine installierte Version betreffen und darf für dein Paket keine korrigierte Version darüber nennen. Hat dein eigenes Paket eine Korrektur, bekommt der Befund wie gewohnt diese Korrektur.
• Der Nachfolger ist ein anderes Paket im selben Ökosystem, das die Advisory mit einer korrigierten Version aufführt. Angezeigt wird seine niedrigste Version, die die Advisory nicht betrifft. Die Aliasse einer Advisory (zum Beispiel ein Go-Eintrag GO-… und sein Gegenstück GHSA-…) werden gemeinsam gelesen.
• Werden mehrere aufgeführt, bevorzugt Go dieselbe Major-Version wie deine (go-jose.v2 zu go-jose/go-jose.v2, nicht go-jose/v4), dann die niedrigste höhere Major-Version, und schlägt nie eine niedrigere Major-Version desselben Moduls vor. Andere Ökosysteme bevorzugen einen Namen, der auf deinen endet (request zu @cypress/request).
• Lassen sich die Versionen nicht ordnen oder ist kein anderes Paket korrigiert, behält der Befund „noch keine Korrektur". Eine Advisory, die nirgends behoben ist, etwa golang.org/x/crypto/openpgp (nicht mehr gepflegt), wird nie als Migration angezeigt.

Warum das nicht dasselbe ist wie der Tab Befunde

Der Tab Befunde ist die maßgebliche Quelle, eine Zeile pro (CVE × Manifest). Empfehlungen sind die umsetzbare Zusammenfassung:

• Ein Paket ohne veröffentlichte Korrektur erscheint nie unter Empfehlungen (es ist noch nicht umsetzbar).
• Ein Paket, das sich mit einem einzigen Upgrade beheben lässt, erscheint einmal unter Empfehlungen und N-mal unter Befunde (einmal pro CVE).
• Ein verworfener Befund erscheint in keinem der beiden Tabs.

Verwende Befunde, um einzelne CVEs und Verwerfungen zu sichten; verwende Empfehlungen, um die tatsächliche Korrekturarbeit des Tages zu steuern.

Über die REST-API

GET /_app/api/v1/orgs/:slug/security/recommendations (findings:read) liefert die Empfehlungen selbst, in der Reihenfolge des Tabs: ein Eintrag pro Repository, Paket und aktueller Version, mit fixed_version, highest_severity, vulnerability_count, vulnerability_ids, manifest_paths, max_epss, reachability, known_exploited und finding_id, dem Befund auf dem Standard-Branch, den eine Anforderung einer Sicherheitskorrektur nennt (null, wenn jeder Befund der Gruppe auf einem Pull Request liegt).

Die zugrunde liegenden CVE-Befunde, also die Rohdaten, die Empfehlungen zusammenfassen, sind über die öffentliche API verfügbar. Nutze das, wenn du ein eigenes Dashboard baust, in ein Ticketsystem exportierst oder die Priorisierung von einem KI-Agenten steuern lässt.

• Abhängigkeitsbefunde auflisten GET /_app/api/v1/orgs/:slug/code-security/deps/findings: eine Zeile pro (CVE × Manifest), mit package_name, current_version, fixed_version, severity, vulnerability_id, manifest_path. Gruppiere clientseitig nach (repo_full_name, ecosystem, package_name, current_version, fixed_version), um die Zusammenfassung der Empfehlungen nachzubilden.
• Einen Befund verwerfen POST /_app/api/v1/orgs/:slug/code-security/deps/findings/:id/dismiss Body: { "reason": "..." }

Der Listen-Endpunkt erfordert ein Personal Access Token (PAT) mit dem Scope findings:read; Verwerfungen erfordern findings:write:

curl -H "Authorization: Bearer ${FREMFORGE_PAT}" \
  "https://frem.sh/_app/api/v1/orgs/acme/code-security/deps/findings?include_dismissed=false"

Die vollständige OpenAPI-Spezifikation findest du in der Referenz der öffentlichen REST-API.

Siehe auch

• Behebungsfrist (SLA): wie die SLA-Pill im Tab Befunde berechnet wird.
• Sicherheits-Digest: schickt jeden Montag die 5 wichtigsten behebbaren Befunde per E-Mail, erreichbare zuerst.
• Push-Schutz: Secrets, die schon beim Push blockiert werden, die vorgelagerte Hälfte derselben Lieferketten-Triade.