Wissen, was tatsächlich ausgeliefert wird
Eine Software Bill of Materials, kurz SBOM, beschreibt enthaltene Komponenten. Sie hilft, bei einer neu bekannt gewordenen Schwachstelle betroffene Produkte zu finden. Entscheidend ist der Bezug zum wirklich ausgelieferten Artefakt. Eine Liste aus dem Quellrepository kann unvollständig sein, wenn der Build zusätzliche Pakete lädt oder Komponenten austauscht.
Herkunft und Integrität getrennt prüfen
Ein unverändertes Paket kann bereits bösartig sein. Eine Signatur bestätigt deshalb nicht automatisch, dass sein Inhalt sicher ist; sie unterstützt die Prüfung von Herkunft und Unverändertheit. Zusätzlich sind freigegebene Paketquellen, festgelegte Versionen und nachvollziehbare Buildschritte wichtig. Auch kleine Hilfswerkzeuge können im Buildkontext Zugriff auf sensible Schlüssel erhalten.
Auf neue Erkenntnisse reagieren können
Ein Abhängigkeitsinventar wird wertvoll, wenn daraus eine Handlung entsteht: betroffene Version erkennen, Nutzung prüfen, Update testen und kontrolliert verteilen. Für nicht kurzfristig ersetzbare Komponenten braucht es eine begründete Übergangslösung. Veraltete Komponenten still in einer Ausnahmeliste zu belassen, ist keine belastbare Strategie.
Beispiel: Eine Schwachstelle in einer Bibliothek
Das Team kann über die SBOM die betroffenen Releases bestimmen. Es prüft, ob der gefährdete Funktionspfad erreichbar ist, erstellt eine aktualisierte Version und testet deren wichtigste Abläufe. Über nachvollziehbare Artefaktkennungen lässt sich anschließend kontrollieren, ob alle vorgesehenen Umgebungen den korrigierten Stand nutzen.
Womit Sie sinnvoll beginnen können
- Komponentenlisten je ausgeliefertem Release erzeugen und aufbewahren.
- Paketquellen und Buildberechtigungen auf das Notwendige begrenzen.
- Zuständigkeit und Ablauf für dringende Updates praktisch erproben.