Seminar Secure SDLC, SBOM und Supply-Chain-Security für Wallets

Seminarprofil

Sicherheit wird von der Architektur bis zum ausgelieferten Artefakt nachweisbar gemacht. Die Veranstaltung schafft klare Gates, Zuständigkeiten und Evidenz für Entwicklung, Betrieb und Zertifizierung.

Der Schwerpunkt liegt auf hochprivilegierten Build- und Signierpfaden, eingebetteten SDKs sowie der Frage, wie Änderungen und Schwachstellen ohne Verlust der Zertifizierbarkeit beherrscht werden.

Inhaltsverzeichnis

• Seminarprofil
• Zielgruppe
• Voraussetzungen
• Lernziele
• Fachliche Schwerpunkte
• Security Requirements und Definition of Done
• Threat Modeling im Entwicklungsprozess
• Sicherheitsorientiertes Code Review
• SBOM und Software-Supply-Chain-Security
• CI/CD-Sicherheit und Release Gates
• App-Signierung, Provenance und sichere Auslieferung
• Schwachstellen- und Patch-Management
• Zertifikatsaufrechterhaltung und Change Impact
• Praxisaufgaben
• Einordnung in das Seminarprogramm

Zielgruppe

• Product-Security- und DevSecOps-Teams
• Entwicklungs- und Release-Verantwortliche
• Softwarearchitekten
• Qualitäts- und Zertifizierungsteams

Voraussetzungen

Grundkenntnisse in Softwareentwicklung, CI/CD und IT-Sicherheit.

Lernziele

• Prüfbare Security Requirements und Release Gates etablieren.
• Threat Modeling und Code Review in den Entwicklungsprozess integrieren.
• SBOM und Lieferkettenrisiken wirksam steuern.
• Build-, Signier- und Release-Vertrauen absichern.
• Schwachstellen und Änderungen mit Evidenz und Zertifizierung verbinden.

Fachliche Schwerpunkte

Security Requirements und Definition of Done

Sicherheitsziele werden als umsetzbare und prüfbare Anforderungen in Backlog, Architektur und Abnahme verankert.

1. Geschäftsrisiken und Threat-Model-Befunde in konkrete Anforderungen übersetzen.
2. Akzeptanzkriterien, Missbrauchsfälle und Negativtests ergänzen.
3. Anforderungen Komponenten, Verantwortlichen und Release Gates zuordnen.
4. Erfüllung und Abweichungen revisionsfähig nachweisen.

Threat Modeling im Entwicklungsprozess

Threat Modeling wird nicht als einmaliger Workshop behandelt, sondern bei Architektur- und Produktänderungen gezielt aktualisiert.

1. Trigger für neue oder zu aktualisierende Bedrohungsanalysen definieren.
2. Leichtgewichtige Modelle in Produktplanung und Design Review integrieren.
3. Risiken als Entwicklungs- und Testaufgaben nachverfolgen.
4. Modelle bei Vorfällen, Plattformänderungen und neuen Credentials aktualisieren.

Sicherheitsorientiertes Code Review

Reviews konzentrieren sich auf Schlüsselzugriffe, Autorisierung, Serialisierung, kryptografische Prüfung, Fehlerbehandlung und sicherheitskritische Zustandswechsel.

1. Kritische Codebereiche und Review-Checklisten aus dem Threat Model ableiten.
2. Änderungen an Authentisierung, Attestation, Recovery und Kryptografie besonders prüfen.
3. Fehlerpfade, Logging und fail-open Verhalten systematisch analysieren.
4. Befunde priorisieren, testen und bis zur Behebung verfolgen.

SBOM und Software-Supply-Chain-Security

Wallets enthalten SDKs, Bibliotheken, Build-Tools und Plattformdienste. Eine SBOM schafft Transparenz, muss aber mit Herkunfts-, Signatur- und Schwachstellenprozessen verbunden werden.

1. Direkte und transitive Abhängigkeiten sowie eingebettete SDKs erfassen.
2. Herkunft, Integrität, Lizenz und Wartungsstatus bewerten.
3. SBOM automatisiert erzeugen und mit Schwachstelleninformationen abgleichen.
4. Austausch, Ausnahme und End-of-Life kritischer Komponenten steuern.

CI/CD-Sicherheit und Release Gates

Build- und Deployment-Pipelines sind hochprivilegierte Produktionssysteme. Identitäten, Artefakte und Freigaben werden gegen Manipulation abgesichert.

1. Pipeline-Identitäten, Secrets und privilegierte Runner inventarisieren.
2. Quellcode-, Build- und Artefaktintegrität kryptografisch absichern.
3. Security-Tests und Freigabekriterien risikobasiert automatisieren.
4. Produktionssignierung, Rollback und Notfallrelease kontrollieren.

App-Signierung, Provenance und sichere Auslieferung

Nur autorisierte, nachvollziehbar erzeugte Artefakte dürfen als vertrauenswürdige Wallet-Version gelten. Provenance und Signatur werden mit Backend-Policies verbunden.

1. Signierschlüssel, Freigaberollen und erlaubte Build-Umgebungen festlegen.
2. Build-Provenance und Artefakt-Hashes nachvollziehbar erzeugen.
3. App Stores, Enterprise-Verteilung und Backend-Akzeptanz koordinieren.
4. Schlüsselwechsel, kompromittierte Builds und erzwungene Updates vorbereiten.

Schwachstellen- und Patch-Management

Wallet-Schwachstellen betreffen App, Backend, Bibliotheken, Hardware und Partner. Kritikalität wird mit erreichbaren Angriffspfaden und Zertifizierungsfolgen bewertet.

1. Meldekanäle, Triage und Ownership für alle Komponenten definieren.
2. Ausnutzbarkeit, betroffene Population und Geschäftsfolgen bewerten.
3. Mitigation, Patch, Policy-Änderung oder Funktionssperre priorisieren.
4. Regression, Veröffentlichung und Nachweispflege abschließen.

Zertifikatsaufrechterhaltung und Change Impact

Nach der Erstzertifizierung müssen Produktänderungen, Plattformupdates und Schwachstellen hinsichtlich ihrer Zertifizierungswirkung bewertet werden.

1. Änderungsklassen und Schwellenwerte für Re-Evaluation definieren.
2. Security Impact Analysis in das Change- und Release-Management integrieren.
3. Regressionstests und Evidenzupdates automatisieren.
4. Zertifikatsstatus, Auflagen, Ablauf und Nachfolgeversionen überwachen.

Praxisaufgaben

• Definition einer Wallet-spezifischen Security Definition of Done.
• SBOM- und Lieferantenreview für ein eingebettetes SDK.
• Threat Model der Build- und Signierpipeline.
• Release-Gate-Entwurf für kritische Wallet-Änderungen.

Einordnung in das Seminarprogramm

Das Einzelseminar kann eigenständig besucht oder in einen Rollenpfad für Architektur, Entwicklung, Betrieb, Recovery, Testing oder Zertifizierung eingeordnet werden. Die Herstellerseite ordnet alle Angebote nach Einstieg, technischer Vertiefung und Assurance.