Auf den Punkt: Klassisches Code-Signing schützt nicht vor Manipulation während des Build-Prozesses; ephemere Umgebungen mit kurzlebigen Schlüsseln und Sigstore bieten effektivere Sicherheit.
Angreifer manipulieren Software nicht mehr im Quellcode, sondern während des Kompilierens. Klassisches Code-Signing versagt hier, weil Angreifer mit kompromittierten Build-Servern auch die echten Herstellerschlüssel missbrauchen können.
Die Angriffsvektoren auf Softwarelieferketten haben sich grundlegend verschoben. Während historisch direkte Schwachstellen in Quellcode oder produktiven Systemen im Visier standen, konzentrieren sich staatliche und kriminelle Akteure heute auf die automatisierte Build-Infrastruktur. Der kritische Punkt liegt im Moment des Kompilierens — der Transformation von Quellcode in ausführbare Binärdateien.
Hochentwickelte Angreifer umgehen traditionelle Schutzmaßnahmen wie Code-Reviews, statische Analysen und Branch-Protections im Git-Repository, weil diese nur den statischen Quellcode erfassen. Stattdessen injizieren sie Schadcode während des laufenden Build-Prozesses direkt im Arbeitsspeicher des Build-Runners oder manipulieren temporäre Abhängigkeiten. Der SolarWinds-Angriff mit der Schadsoftware Sunburst demonstrierte diese Methodik: Die Malware wurde direkt während der Kompilierung in das produktive Update eingeschleust, ohne Spuren im Quellcode-Archiv zu hinterlassen.
Klassisches Code-Signing mit Public Key Infrastructure (PKI) zeigt in Cloud-Native-Umgebungen strukturelle Mängel. Das Modell erfordert langlebige private Schlüssel in Pipeline-Geheimnissen oder auf Hardware-Sicherheitsmodulen. Wenn ein Angreifer administrative Kontrolle über den Build-Server erhält, kann er seine manipulierte Software mit dem echten Herstellerschlüssel vollkommen legitim signieren. Das regelmäßige Rotieren statischer Zertifikate ist fehleranfällig; bei Schlüsselabfluss verzögern sich Widerrufe über Certificate Revocation Lists erheblich, in denen kompromittierte Software weiterhin als vertrauenswürdig gilt.
Als Gegenmittel etabliert sich das Paradigma ephemerer Build-Umgebungen. Dabei wird ein Build-Runner nicht mehr als permanent laufender Server betrieben, sondern für jeden Build-Schritt isoliert und vollständig neu initialisiert — typischerweise durch flüchtige Container-Instanzen in Kubernetes-Clustern oder dedizierte Micro-Virtuelle-Maschinen. Kurzlebige Schlüssel, die nur für einen einzelnen Build existieren, und kryptografische Nachweise via Sigstore reduzieren die Angriffsfläche erheblich.
Quelle: www.it-daily.net · Erschienen 19. Juli 2026
Lumi AI News — KI-assistierte Kuratierung gemaess Art. 50 EU AI Act. Paraphrase und Klassifikation durch Lumi News Pipeline v1.7.3.