Seminar Secure SDLC – Software Supply Chain, SBOM und Artefaktsignierung

Seminarbeschreibung

Moderne Anwendungen enthalten zahlreiche direkte und indirekte Abhängigkeiten. Deren bloße Erfassung beantwortet noch nicht, ob ein ausgeliefertes Produkt betroffen ist oder ob ein Artefakt aus einem vertrauenswürdigen Build stammt. Das Seminar trennt deshalb Komponentenübersicht, Schwachstellenbewertung, Integrität, Herausgeberidentität und Herkunftsnachweis als unterschiedliche Prüfaufgaben.

Ein vorbereitetes Softwareprojekt mit Containerartefakt dient als roter Faden. Komponenten werden identifiziert, eine SBOM erzeugt und Abweichungen zwischen Quellprojekt und ausgeliefertem Artefakt untersucht. Anschließend werden Signierung und Verifikation praktisch durchgeführt. SLSA und standardisierte Nachweisformate helfen, die Reichweite der vorhandenen Belege einzuordnen; eine Signatur oder SBOM wird dabei nicht als pauschaler Sicherheitsnachweis behandelt.

In der Fallstudie stehen eine Anwendungsversion, ihr gebautes Containerimage und mehrere vorbereitete Nachweise zur Verfügung. Nicht alle Unterlagen passen zwangsläufig zum selben Softwarestand. Die Untersuchung richtet sich daher auch auf veraltete Komponentenlisten, abweichende Digests und Signaturen einer nicht erwarteten Identität. Ein technisch gültiger Nachweis wird erst durch seine Bindung an das erwartete Produkt und eine festgelegte Vertrauensrichtlinie für die Annahme nutzbar. Fehlende Informationen führen zu einer begründeten Rückfrage oder Zurückweisung statt zu einer unbelegten Freigabe.

Inhaltsübersicht

1. Lieferkette und Vertrauensentscheidungen
2. Komponenten und SBOM
3. Betroffenheit und Abhängigkeitsrisiken
4. Build-Provenienz und Integrität
5. Signieren und Verifizieren
6. Annahme und kontinuierliche Pflege

Seminarinhalte

Lieferkette und Vertrauensentscheidungen

• Quellpakete, Paketregister, Build-Werkzeuge und Artefaktverteilung als Abhängigkeiten erfassen.
• Verwechslung von Paketnamen, ungewollte Paketquellen und veränderliche Versionen berücksichtigen.
• Freigabekriterien für neue Komponenten und Aktualisierungen definieren.

Komponenten und SBOM

• Direkte und transitive Abhängigkeiten sowie enthaltene Laufzeitkomponenten unterscheiden.
• Eine SBOM im CycloneDX-Format erzeugen und wesentliche Felder mit SPDX-Konzepten vergleichen.
• Komponentenidentität, Version, Abhängigkeitsbeziehungen und Bezug zum Artefakt prüfen.

Betroffenheit und Abhängigkeitsrisiken

• Gemeldete Schwachstellen anhand von Version, Konfiguration und tatsächlichem Einsatz bewerten.
• VEX-Aussagen mit Begründung, Geltungsbereich und Aktualität einordnen.
• Fehlende Pflege, Unterstützungsende und unvollständige Inventarisierung in Entscheidungen einbeziehen.

Build-Provenienz und Integrität

• Quellstand, Build-Verfahren, Parameter und Artefaktdigest in einem Herkunftsnachweis verbinden.
• SLSA-Anforderungen an Source- und Build-Prozesse nach ihrer Aussagekraft unterscheiden.
• Grenzen von Provenienz, Reproduzierbarkeit und bloßer Prüfsummenkontrolle erkennen.

Signieren und Verifizieren

• Ein Übungsartefakt mit einem bereitgestellten Signierverfahren signieren.
• Signatur, erwartete Identität und Artefaktdigest getrennt überprüfen.
• Vertrauensrichtlinien, Schlüsselschutz und Reaktionen auf kompromittierte Signieridentitäten planen.

Annahme und kontinuierliche Pflege

• SBOM, Prüfberichte, Provenienz und Signatur für eine Annahmeentscheidung zusammenführen.
• Neue Schwachstellen bestehenden Artefakten und unterstützten Produktständen zuordnen.
• Aktualisierung, Austausch von Komponenten und Lieferantenrückfragen nachvollziehbar organisieren.

Praxisübungen

1. Direkte und transitive Abhängigkeiten des Beispielprojekts erfassen.
2. Eine SBOM erzeugen und gegen das tatsächlich gebaute Artefakt prüfen.
3. Eine Schwachstellenmeldung anhand des konkreten Einsatzzwecks bewerten.
4. Einen vorbereiteten Provenienznachweis auf erwartete Herkunft und Artefaktbindung untersuchen.
5. Ein Artefakt signieren, erfolgreich verifizieren und nach einer gezielten Veränderung erneut prüfen.
6. Eine begründete Annahme- oder Rückweisungsentscheidung für das bereitgestellte Release dokumentieren.