Bestand abgrenzen
Relevante Releases und die dazugehörigen SBOMs eindeutig festlegen.
Open Source & SBOM
OSS-Schwachstellenbericht
Arbeitsstruktur für einen prüfbaren Bericht über erkannte Open-Source-Schwachstellen, ihre Relevanz und die getroffenen Behandlungsentscheidungen.
Status dieser Seite
Strukturvorlage, kein Nachweis eines durchgeführten Scans und kein aktueller Plattformbericht.
Keine pauschale Bewertung
Prioritäten und Fristen müssen anhand des konkreten Instituts, Assets und Risikos festgelegt werden.
Datenstand sichtbar machen
Jede Kennzahl benötigt Quelle, Geltungsbereich und Zeitpunkt der Erhebung.
Mindestinhalt des Berichts
Ein belastbarer Bericht trennt technische Fundstelle, institutsspezifische Relevanz, Behandlungsentscheidung und Verifikationsnachweis.
| Berichtsfeld | Erforderlicher Inhalt |
|---|---|
| Berichtsidentität | Berichtszeitraum, Erstellungszeitpunkt, Version, verantwortliche Stelle und Freigabestatus |
| Prüfumfang | Anwendungen, Releases, Umgebungen, SBOM-Versionen und bewusst ausgeschlossene Bereiche |
| Datenherkunft | Scanner oder Datenquelle, Datenbankstand, Scanzeitpunkt, Regeln und bekannte Einschränkungen |
| Komponente | Paketname, Version, Ecosystem, direkte oder transitive Abhängigkeit und betroffener Release |
| Schwachstelle | CVE, GHSA oder Herstellerkennung sowie Quelle und Veröffentlichungsdatum |
| Bewertung | CVSS inklusive Vektor und Quelle; zusätzliche Signale wie KEV oder EPSS nur mit Abrufstand |
| Institutsauswirkung | Betroffenes IKT-Asset, Geschäftsfunktion, Exponierung, Ausnutzbarkeit und vorhandene Kontrollen |
| Behandlung | Update, Entfernung, Kompensationskontrolle oder Risikoakzeptanz mit Owner und Zieltermin |
| Verifikation | Nachscan, Testnachweis, Release-Nachweis und dokumentiertes Schlussergebnis |
Bearbeitungs- und Freigabefluss
Fundstellen normalisieren
Duplikate zusammenführen und Komponenten-, Versions- und Schwachstellenkennungen vereinheitlichen.
Technisch triagieren
Betroffenheit, Erreichbarkeit, Exponierung und verfügbare Abhilfen nachvollziehbar prüfen.
Geschäftsrelevanz bewerten
Fundstellen mit IKT-Assets, unterstützten Funktionen und Kritikalität verknüpfen.
Behandlung entscheiden
Maßnahme, Verantwortliche, Termin und gegebenenfalls formale Risikoakzeptanz festhalten.
Umsetzung verifizieren
Wirksamkeit durch Nachscan, Test oder überprüfbaren Release-Nachweis bestätigen.
Berichten und freigeben
Restbestand, überfällige Entscheidungen und wesentliche Risiken adressatengerecht freigeben.
Qualitätssicherung vor Freigabe
- Prüfumfang und ausgeschlossene Bereiche sind vollständig benannt.
- Jede offene Fundstelle besitzt Assetbezug, Owner, Entscheidung und Zieltermin.
- CVSS, KEV oder EPSS werden nicht ohne Quelle und Abrufstand verwendet.
- Risikoakzeptanzen enthalten Begründung, Gültigkeit und zuständige Freigabe.
- Geschlossene Fundstellen besitzen einen überprüfbaren Verifikationsnachweis.
- Managementkennzahlen lassen sich auf Einzelfundstellen zurückführen.
Verknüpfte Arbeitsbereiche
Rückfragen zur Plattform: amspeak@amartens.com