Dependency Security
Konzeptuelle Praxis zur Absicherung von Softwareabhängigkeiten und der Lieferkette durch Governance, Scans und Integritätsmechanismen.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Übergeneralisierte Policies blockieren Releases
- Blindes Vertrauen in Scanning-Tools ohne Review
- Unvollständige SBOMs führen zu falscher Risikoabschätzung
- SBOMs automatisiert bei jedem Build erzeugen
- Signierte Artefakte entlang der gesamten Pipeline verwenden
- Policies iterativ vorgängig testen und feinjustieren
I/O & Ressourcen
- Quellcode, Build-Pipeline und Lockfiles
- Zugriff auf Paketregistries und Artefakt-Feeds
- Security-Policies und Compliance-Anforderungen
- SBOMs, Scan-Berichte und Audit-Logs
- Remediation-Tickets und Policy-Entscheidungen
- Signierte und verifizierte Artefakte
Beschreibung
Dependency Security bezieht sich auf Praktiken, Prozesse und Werkzeuge zum Schutz von Software-Projektabhängigkeiten und der Software-Lieferkette vor kompromittierten Paketen, bösartigem Code und ungepatchten Schwachstellen. Es umfasst Governance, automatisierte Scans, Signaturen und Lieferkettenstandards, um Integrität, Vertrauenswürdigkeit und schnelle Reaktionsfähigkeit zu gewährleisten.
✔Vorteile
- Reduzierte Angriffsfläche durch kompromittierte Abhängigkeiten
- Schnellere Erkennung und Reaktion auf Lieferkettenvorfälle
- Bessere Compliance- und Auditfähigkeit
✖Limitationen
- Nicht alle Schwachstellen sind automatisiert erkennbar
- Falsch-positive können Betriebsaufwand erhöhen
- Abhängigkeit von Drittanbieter-Registries und deren Integrität
Trade-offs
Metriken
- Zeit bis zur Erkennung einer kompromittierten Abhängigkeit
Mittlere Zeit zwischen Erstmeldung und Erkennung im eigenen System.
- Anteil signierter Build-Artefakte
Prozentualer Anteil der Artefakte mit validierbaren Signaturen.
- Vulnerabilities pro Release nach Schwere
Anzahl und Schwereklassen gefundener Schwachstellen je Release.
Beispiele & Implementierungen
Company A: Scans als Gate in CI
Ein SaaS-Anbieter blockiert Builds mit kritischen Dependabot-Funden und erstellt automatische Remediation-Tickets.
Open-Source-Projekt implementiert SBOM-Export
Ein Framework-Projekt liefert für jede Version eine SBOM, um Konsumenten Transparenz zu bieten.
Plattformbetrieb nutzt Signed Artifacts
Die Plattform validiert Signaturen von Artefakten in der Deployment-Phase zur Sicherstellung der Integrität.
Implementierungsschritte
Bestandsaufnahme: Abhängigkeiten, Registries und Prozesse erfassen
Sichtbarkeit schaffen: SBOM-Generierung und Dependency-Graphen einführen
Automatisierung: Scans, Signaturen und Policy-Gates in CI integrieren
⚠️ Technische Schulden & Engpässe
Tech Debt
- Ungepflegte Lockfiles und inkonsistente Versionierung
- Legacy-Builds ohne SBOM- oder Signatur-Unterstützung
- Manuelle Prozesse für Abhängigkeitsprüfungen statt Automatisierung
Bekannte Engpässe
Beispiele für Missbrauch
- Blockieren aller externen Pakete ohne Ausnahme führt zu Stillstand
- SBOMs manuell pflegen und dadurch veraltete Daten verbreiten
- Policies so restriktiv, dass Sicherheitsfixes über Wochen verzögert werden
Typische Fallen
- Annahme, dass Signaturen allein Angriffe verhindern
- Migration zu vielen Tools gleichzeitig ohne klare Ownership
- Ignorieren von Transienten Problemen in Abhängigkeitsgraphen
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Begrenzte Sichtbarkeit in Drittanbieter-Repositories
- • Rechtliche Einschränkungen bei Verteilung von Lizenzdaten
- • Performance-Einfluss durch ausführliche Scans