Abhängigkeiten und Herkunft sichtbar machen

Zunächst werden Paketquellen, verwendete Versionen und die Verantwortlichen für Aktualisierungen erfasst. Lockdateien und geeignete Komponentenübersichten können helfen, betroffene Abhängigkeiten bei einer Sicherheitsmeldung zuzuordnen. Eine solche Übersicht muss allerdings zum tatsächlich ausgelieferten Stand passen, nicht nur zu einem aktuellen Entwicklungsverzeichnis.

Neue Bibliotheken benötigen eine bewusste Aufnahmeentscheidung. Neben Funktionen und Lizenzfragen zählen Pflegezustand, Herkunft und der geplante Updateweg. Eine grosse Zahl ungeprüfter Erweiterungen erhöht den Aufwand, weil jede zusätzliche Komponente im Betrieb erkannt, bewertet und bei Bedarf ersetzt werden können muss.

Build- und Deploymentrechte begrenzen

CI-Systeme und Deploymentkonten besitzen häufig direkten Einfluss auf produktive Anwendungen. Ihre Rechte, Geheimnisse und ausführbaren Jobs verdienen daher dieselbe Aufmerksamkeit wie klassische Administratorzugänge. Fremde Beiträge oder unkontrollierte Buildskripte dürfen nicht ohne geeignete Trennung auf produktive Zugangsdaten zugreifen.

Freigaben und Prüfschritte werden nachvollziehbar zwischen Entwicklung und Auslieferung angeordnet. Herkunftsnachweise und signierte Artefakte können unterstützen, wenn die Prüfung beim Empfänger tatsächlich stattfindet. Eine vorhandene Signatur ohne verlässliche Zuordnung und Verifikationsregel liefert dagegen nur begrenzte Sicherheit.

Ein Artefakt bis zur Produktion verfolgen

Bei der Abnahme wird eine ausgewählte Version vom Quellstand über den Build bis zum laufenden System verfolgt. Dabei werden verwendete Abhängigkeiten, Freigaben und Deploymentbelege abgeglichen. Das macht sichtbar, ob die produktive Fassung wirklich dem geprüften Ergebnis entspricht oder unterwegs unkontrolliert verändert werden kann.

Für einen Einstieg nennen Sie Repositories, Paketmanager, Buildsysteme und Bereitstellungswege. Daraus lässt sich ein passender Verbesserungsplan entwickeln. Modelle wie SLSA bieten Orientierung für Herkunft und Prozessabsicherung; ein bestimmtes Niveau darf aber nur mit den dafür tatsächlich erfüllten Anforderungen behauptet werden.

Ihre Checkliste für den nächsten Schritt

  • Komponentenübersicht und Paketstände mit der ausgelieferten Version abgleichen.
  • CI- und Deployment-Geheimnisse auf notwendige Rechte und Reichweite begrenzen.
  • Ein produktives Artefakt nachvollziehbar bis zum geprüften Quellstand zurückverfolgen.

Häufige Fragen

Reicht eine SBOM als Schutzmassnahme aus?

Eine Komponentenliste verbessert die Übersicht, behebt aber keine Schwachstellen. Sie braucht aktuelle Zuordnung, Bewertung und einen funktionierenden Prozess für Änderungen.

Verhindert eine Signatur jede schädliche Softwareänderung?

Nein. Sie kann Herkunft und Integrität unterstützen. Ein kompromittierter oder unzureichend kontrollierter Herstellungsprozess kann weiterhin problematische Artefakte erzeugen.

Quellen & weiterführende Informationen

SLSA: Spezifikation Version 1.2 ↗

Fachliche Orientierung, Stand 25.10.2026. Der konkrete Befund erfordert Zugriff auf die betroffene Umgebung und eine abgestimmte Prüfung.