Das Blatt für die Frage, wo in einer Lieferkette eigentlich etwas schiefgehen kann und welche Regel das jeweils schließt — vom Commit bis zur gehärteten Pipeline. Maßgeblich sind die Originalquellen: der NIST SSDF, die OWASP Top 10:2025, das SLSA-Bedrohungsmodell und die OpenSSF Scorecard. Hier steht die Auswahl, die im Alltag wirklich gebraucht wird.
Die zweite Hälfte des Seminars — SBOM, Signaturen, Provenance, SLSA-Stufen, Meldepflichten — liegt auf dem Blatt Lieferkette: Nachweise und Pflichten.
Stationen und wer an ihnen schreibt
Die Kette beginnt nicht beim Build und endet nicht beim Artefakt: Die Entwicklungsumgebung gehört dazu, und jedes Update geht denselben Weg noch einmal.
| Station | Wer schreibt | Was entsteht |
|---|---|---|
| Entwicklungsumgebung | Team, Erweiterungen | Commit |
| Repository | Team, Automatisierung | Quellstand |
| Build | Runner, Paketmanager | Artefakt |
| Registry | Pipeline, Betrieb | veröffentlichtes Image |
| Deployment | Betrieb, Automatisierung | laufender Dienst |
Die mittlere Spalte ist zugleich die Liste der Konten, die ein Angreifer übernehmen möchte — Menschen stehen dort ebenso wie Automatisierung.
Modul: Die moderne Software-Lieferkette
Vier Angriffspfade und ihr Ansatzpunkt
| Pfad | Ansatzpunkt | Was der Angreifer erreicht |
|---|---|---|
| Konto übernommen | Repository | Änderung mit gültiger Signatur |
| Paket untergeschoben | Paketquelle | Code im Build aller Nutzer |
| Build manipuliert | Runner, Cache | Artefakt weicht vom Quellcode ab |
| Artefakt ersetzt | Registry | Auslieferung ohne Codeänderung |
Nur der erste Pfad hinterlässt eine Spur im Quellcode. Die übrigen drei findet keine Codeanalyse — sie schaut an der falschen Stelle. Die OWASP Top 10:2025 führen diese Kategorie als A03 mit der höchsten durchschnittlichen Auftretensrate aller zehn.
Modul: Die moderne Software-Lieferkette
Was SLSA abdeckt — und was nicht
| Bedrohung | Adressiert | Gegenmittel |
|---|---|---|
| Änderung ohne Freigabe | ja | Freigabe vor Übernahme erzwingen |
| Verlauf oder Tag manipuliert | ja | Force-Push und Tags sperren |
| Review nur abgenickt | nein | mehr oder erfahrenere Reviewer |
| Schwachstelle in der Plattform | nein | Plattformwahl und Protokollierung |
| Typosquatting | nein | Prüfung vor der Aufnahme |
| Verfügbarkeit (Löschung, De-Listing) | nein | eigene Spiegelung |
Ein Modell ist auch dort nützlich, wo es Grenzen zieht: Kollusion beim Review bleibt ein Personalthema, keine Konfigurationsfrage.
Modul: Bedrohungsmodell für die Lieferkette
NIST SSDF: die Praktiken, die hier tragen
| Kürzel | Praxis | Bedeutung hier |
|---|---|---|
| PO.5 | Sichere Entwicklungsumgebungen | Umgebungen trennen und härten |
| PS.1 | Code vor Zugriff und Manipulation schützen | Repository-Härtung |
| PS.2 | Integrität eines Release nachweisbar machen | Hashes, Signaturen, Provenance |
| PS.3 | Jedes Release archivieren | Grundlage jeder Untersuchung |
| PW.6 | Build-Prozess sicher konfigurieren | reproduzierbare Builds |
| RV.2 | Schwachstellen bewerten und beheben | Priorisierung nach Risiko |
| RV.3 | Ursachen analysieren | verhindert die Wiederholung |
Das Rahmenwerk schreibt nicht vor, wie eine Praxis umzusetzen ist, und ist ausdrücklich keine Checkliste — die Auswahl erfolgt risikobasiert.
Modul: DevSecOps, Secure by Design und NIST SSDF
Wer entscheidet worüber
| Rolle | Entscheidet | Entscheidet nicht |
|---|---|---|
| Entwicklung | Umsetzung im Code | Risikoakzeptanz |
| Plattformteam | erlaubte Werkzeuge | fachliche Priorität |
| Product Security | Bewertung, Meldung | Termin der Auslieferung |
| Leitung | Risikoakzeptanz | technische Lösung |
Streit entsteht selten über die mittlere Spalte, fast immer über die rechte.
Modul: DevSecOps, Secure by Design und NIST SSDF
Schutzregeln fürs Repository
Rulesets kennen unter anderem: Restrict creations, Restrict updates, Restrict deletions, Block force pushes, Require linear history, Require signed commits, Require a pull request before merging, Require status checks to pass. Restrict deletions und Block force pushes sind standardmäßig aktiv.
| Option des Pull-Request-Zwangs | Wirkung |
|---|---|
| Required approvals | Mindestzahl genehmigender Reviews, 0 bis 10 |
| Dismiss stale reviews | Genehmigung verfällt, wenn sich der Diff ändert |
| Require review from Code Owners | Die betroffenen Eigentümer müssen zustimmen |
| Require approval of most recent push | Wer zuletzt gepusht hat, genehmigt nicht allein |
Erst die letzten beiden schließen die Lücke, durch die nach der Freigabe noch nachgeschoben wird. Release-Tags brauchen eigene Regeln — der Hauptzweig allein genügt nicht. Bypass-Berechtigungen wirken im gesamten Fork-Netzwerk.
# .github/CODEOWNERS — die Dateien, an denen die Lieferkette hängt
/pom.xml @org/plattform
/Dockerfile @org/plattform
/.github/workflows/ @org/plattform
/deploy/policy.yaml @org/securityDie Datei wirkt erst zusammen mit der Option, die eine Zustimmung der Eigentümer verlangt.
Modul: Repository und Entwicklungsprozess absichern
Abhängigkeiten: drei Stufen der Festlegung
| Stufe | Was festliegt | Was noch wandern kann |
|---|---|---|
| Versionsbereich | ungefähr | Version und Inhalt |
| feste Version | die Version | der Inhalt hinter ihr |
| Version plus Hash | Version und Inhalt | nichts |
Erst der Hash beantwortet, ob hinter der Versionsnummer noch dasselbe liegt wie gestern. Gegen Dependency Confusion hilft ein eigener Namensraum für interne Pakete plus die Festlegung, welche Quelle welche Namen überhaupt beantworten darf — die Reihenfolge der Quellen allein genügt nicht.
mvn dependency:tree -Dverbose # was wirklich im Build landet
mvn dependency:tree -Dincludes=<gruppe>:<artefakt>Modul: Abhängigkeiten und Paketquellen kontrollieren
OpenSSF Scorecard: die Prüfungen mit Lieferkettenbezug
| Prüfung | Frage | Warum wichtig |
|---|---|---|
| Maintained | Wird das Projekt gepflegt? | Ein totes Projekt bekommt keinen Patch |
| Branch-Protection | Ist der Hauptzweig geschützt? | Direkter Push wäre möglich |
| Code-Review | Wird gegengelesen? | Vier-Augen-Prinzip beim Zulieferer |
| Pinned-Dependencies | Sind Abhängigkeiten fest? | Der Zulieferer erbt fremdes Risiko |
| Signed-Releases | Sind Releases signiert? | Herkunft prüfbar statt geglaubt |
| Token-Permissions | Minimale Rechte im Build? | Übernahme durch einen Pull Request |
| Dangerous-Workflow | Riskante Muster im Build? | Einschleusung über Kontextwerte |
| Vulnerabilities | Offene bekannte Lücken? | vorhandenes Risiko übernommen |
Achtzehn Prüfungen insgesamt, je zehn Punkte und ein Risikoniveau als Gewicht. Der Wert ist ein Entscheidungshinweis, kein Sicherheitsnachweis — geprüft wird, was maschinell prüfbar ist, und er altert.
Modul: Abhängigkeiten und Paketquellen kontrollieren
Scanverfahren und ihre Reichweite
| Verfahren | Sieht | Sieht nicht |
|---|---|---|
| SAST | Muster im eigenen Quellcode | Laufzeit und Konfiguration |
| SCA | bekannte Lücken in Abhängigkeiten | unbekannte und eigene Fehler |
| Secret Scanning | Zugangsdaten in Code und Historie | Geheimnisse außerhalb des Repos |
| IaC-Scanning | riskante Infrastrukturangaben | den laufenden Zustand |
| Container-Scanning | Pakete im Image | Anwendungslogik im Image |
| DAST | Fehler der laufenden Anwendung | braucht eine Umgebung |
Der Container-Scan gehört auf das gebaute Image, nicht auf das Basis-Image.
OWASP SAMM teilt Sicherheitstests in zwei Stränge, die einander bedingen:
| Skalierbare Grundlage | Tiefes Verständnis |
|---|---|
| Automatisierte Werkzeuge | Manuelle Prüfung |
| Läuft bei jeder Änderung | Läuft für Risikoteile |
| Findet bekannte Muster | Findet Geschäftslogikfehler |
| Skaliert über alle Projekte | Skaliert nicht, wiegt schwerer |
Die Automatisierung räumt das leicht Erreichbare ab und macht damit Fachleute für die schwierigen Angriffswege frei.
Modul: Security Scanning in der Pipeline
Befunde: drei Fälle, drei Wege
| Fall | Antwort | Was dokumentiert wird |
|---|---|---|
| echter Befund | beheben | Änderung und Prüfung |
| Fehlalarm | Regel anpassen | Begründung am Werkzeug |
| akzeptiert | befristete Ausnahme | Frist, Grund, Verantwortliche |
Eine Ausnahme ohne Frist ist keine Ausnahme, sondern eine stillschweigende Änderung der Regel. Fehlt der dritte Fall ganz, wird beim ersten Termindruck das Quality Gate abgeschaltet statt der Befund behoben.
Modul: Security Scanning in der Pipeline
Pipeline: wer welche Rechte braucht
| Schritt | Braucht | Braucht nicht |
|---|---|---|
| Bauen und Testen | Quellcode lesen | Schreibrechte |
| Prüfen und Melden | Befunde schreiben | Registry-Zugriff |
| Veröffentlichen | Registry schreiben, Token ausstellen | Quellcode ändern |
| Ausrollen | Zielumgebung | Registry schreiben |
Die rechte Spalte ist der eigentliche Gewinn: Sie beschreibt, was im Schadensfall nicht möglich ist. Rechte gelten je Job — solange Bauen, Prüfen und Veröffentlichen in einem Job stecken, trägt dieser die Summe aller Rechte.
permissions:
contents: read # Vorgabe für alle Jobs
jobs:
veroeffentlichen:
permissions: # ersetzt die Vorgabe, ergänzt sie nicht
contents: read
packages: write
id-token: writeExterne Actions über den vollständigen Commit-SHA einbinden — das ist die einzige unveränderliche Form. Fremde Eingaben (Titel, Branchnamen) nie direkt in ein Kommando setzen, sondern über eine Umgebungsvariable lesen.
Modul: Pipelines härten und Berechtigungen reduzieren
Typische Fallen
- Der Hauptzweig ist geschützt, die Release-Tags nicht. Damit bleibt genau der Stand beweglich, der ausgeliefert wird.
- Automatisierungskonten umgehen den Freigabezwang. Das hebt das Vier-Augen-Prinzip nicht ab, sondern vollständig auf.
- Bypass-Rechte werden für den Notfall vergeben und nie entzogen. Sie wirken im gesamten Fork-Netzwerk.
- Ein geleaktes Secret wird aus der Datei entfernt, aber nicht rotiert. Aus der Historie verschwindet es nicht — es bleibt gültig, bis es ersetzt wurde.
- Die öffentliche Paketquelle steht als Rückfallebene bereit. Damit beantwortet sie auch interne Namen.
- Build-Werkzeuge tauchen in keiner Abhängigkeitsliste auf. Dabei laufen sie mit den Rechten des Builds, nicht der Anwendung.
- Fünf Scanner gleichzeitig eingeführt, keiner ausgewertet. Ohne datierte Baseline steht die Pipeline am ersten Tag rot und wird am zweiten abgeschaltet.
- Der Container-Scan läuft auf dem Basis-Image. Dann sieht er die eigene Anwendung überhaupt nicht.
- Ein Pull Request aus einem fremden Fork startet einen Build mit Zugriff auf Secrets. Ungeprüfter Fremdcode gehört nie in einen privilegierten Ablauf.
- Eine Action hängt an einem beweglichen Tag. Den kann der Herausgeber jederzeit umhängen.
- Die Workflow-Datei darf jeder ändern, während der Anwendungscode ein Review braucht — dabei hat die Pipeline mehr Rechte als jeder Mensch im Team.