Supportende über SBOMs, Container-Images und Softwareinventare hinweg automatisch erkennen

Ziel

Stand: 25. Oktober 2026. Dieses vorgeschlagene Verfahren erkennt wiederkehrend Risiken durch das Supportende in einer Systemlandschaft, einschliesslich Anwendungslaufzeiten, Distributionspaketen und Containerinhalten. Es erzeugt eine Liste von Behebungsaufgaben mit zugewiesenen Verantwortlichen und eine separate Liste für unsichere Nachweise. Bei jeder Aktualisierung der Nachweise das API-Schema, die Lebenszyklusseiten der Anbieter und die vor Ort bestehenden Supportansprüche erneut prüfen. Weder ein erfolgreiches Deployment noch eine Messung der Erkennungsleistung wird behauptet.

Voraussetzungen

Ein autorisiertes Systeminventar, Deployment-Aufzeichnungen, Imagekennungen, verfügbare Softwarestücklisten und verantwortliche Personen nutzen, die Supportvereinbarungen bestätigen können. Das zulässige Alter von Inventardaten, die Aktualisierungshäufigkeit der Quellen, die Vorlaufzeit für Migrationen und einen Eskalationsweg festlegen. Anbieter-URLs, Abrufzeitpunkte und etwaige veröffentlichte Revisionsdaten zusammen mit den Entscheidungen speichern.

Das Projekt endoflife.date dokumentiert seine eigene API; es sammelt die Lebenszyklusdaten anderer Produkte. Seinen Feed als Hinweisquelle behandeln; für Entscheidungen über Fristen ist der Anbieter massgeblich. Das Schema unterscheidet zwischen dem Ende des aktiven Supports, dem Supportende und dem Ende des erweiterten Supports. API-Definition.

Schritte

1. Beobachtete Versionen aus bereitgestellten Workloads erfassen und einer verantwortlichen Stelle sowie einer Deployment-Kennung zuordnen. Auch ungenutzte Vorlagen und Build-Stufen einbeziehen. Für jede Komponente Ökosystem, Produkt, Edition, Versionszweig, Distributor und Paketherkunft erhalten. Bei mehrdeutigen Namen eine manuelle Prüfung verlangen, statt nur anhand einer Versionszeichenfolge zuzuordnen.
2. Jeden bereitgestellten Image-Digest mit seiner SBOM und dem Herkunftsnachweis des Basisimages verknüpfen. Wo Docker Scout bereits verfügbar ist, erzeugt docker scout sbom --format spdx local://IMAGE eine SBOM aus einem lokalen Image; IMAGE durch die vorgesehene lokale Imagereferenz ersetzen. Die analysierte Plattform und den Digest festhalten. Nicht stillschweigend einfach das zuletzt gebaute Image scannen. SBOM-Befehl.
3. Komponenten geprüften Produkt- und Veröffentlichungszykluskennungen zuordnen. Den dokumentierten Endpunkt /api/v1/products/{product} oder dessen Endpunkt für den Veröffentlichungszyklus abfragen. Antworten cachen, Weiterleitungen beachten und Ratenbegrenzungen behandeln. isEol, eolFrom, eoasFrom und eoesFrom erhalten, sofern sie geliefert werden. Ein Nullwert für eolFrom bedeutet, dass das Datum unbekannt ist; fehlende Felder zum erweiterten Support können bedeuten, dass diese Phase nicht zutrifft. Keiner der beiden Fälle begründet unbegrenzten Support.
4. Wesentliche Fristen auf den Anbieterseiten bestätigen und festhalten, welche Supportphase und welcher Anspruch gelten. Entscheidungen des Ursprungsprojekts und des Distributors getrennt halten. Der Ubuntu-Lebenszyklus unterscheidet die Standardwartung von Main-Paketen von abonnementgestützter Versorgung und anderen Paketkategorien; nicht allein aus dem Betriebssystemnamen auf identischen Support für jedes Paket schliessen. Supportumfang der Distribution.
5. Lebenszyklus und Aktualität des Images unabhängig voneinander bewerten. Die Docker-Richtlinie für veraltete Basisimages vergleicht den aktuellen Digest des Basisimage-Tags mit dem beim Image-Build verwendeten Digest und erfordert einen Herkunftsnachweis. Ein bestandener Vergleich belegt nicht, dass die zugrunde liegende Version weiterhin unterstützt wird. Einen expliziten Status «unbekannt» beibehalten, wenn Lebenszyklusnachweise, Paketzuordnung oder Herkunftsnachweise fehlen. Bedeutung der Image-Richtlinie.
6. Warnschwellen aus dem Arbeitsaufwand ableiten: Die Migration beginnen, wenn die verbleibende Zeit höchstens der vereinbarten Migrationsvorlaufzeit zuzüglich des Zeitpuffers für Freigabe und Wiederherstellung entspricht. Eskalieren, wenn nur noch das erprobte Zeitfenster für Umstellung und Wiederherstellung bleibt; abgelaufenen Support sofort melden. Dies sind Vorschläge für lokale Richtlinien, keine Anbieterfristen. Meldungen nach verantwortlicher Stelle und Komponente deduplizieren und Ausnahmen zur erneuten Prüfung automatisch auslaufen lassen.
7. Den Entscheidungsprozess anhand von Fällen mit bestehendem oder abgelaufenem Support, unbekanntem Supportstatus, veralteten Feeds sowie dokumentiertem erweitertem Support testen. Ein Image einbeziehen, dessen Digest aktuell ist, dessen Version aber nicht mehr unterstützt wird. Nach der Behebung sowohl die Beobachtung des Systems als auch die Lebenszyklusnachweise aktualisieren, bevor ein Befund geschlossen wird.

Erwartetes Ergebnis

Jeder Befund nennt den betroffenen Workload, die Komponente, die Supportphase, den Anbieternachweis, die verantwortliche Stelle und die nächste Massnahme. Fehlende Daten bleiben sichtbar, statt als unterstützter Zustand gezählt zu werden.

Grenzen und Prüfbasis

Eine SBOM allein kann weder einen vertraglichen Supportanspruch belegen noch jede Änderung zur Laufzeit erfassen. Dies ist eine Zusammenführung dokumentierter Schnittstellen und ein vorgeschlagenes Bewertungsverfahren; seine Tests sind Abnahmekriterien, keine berichteten Ergebnisse. Lebenszyklusüberwachung ergänzt die Erkennung von Schwachstellen und Kompromittierungen, weist aber selbst weder Schwachstellen noch Kompromittierungen nach.