Sicherheit von Abhängigkeiten und der Lieferkette (SCA)

Moderne Anwendungen bestehen größtenteils aus Abhängigkeiten von Drittanbietern. Ein einzelnes verwundbares Paket tief in Ihrem Abhängigkeitsbaum kann die gesamte Anwendung gefährden.

Dieses Risiko wird als Risiko der Software-Lieferkette bezeichnet. Ihre Absicherung ist ein zentraler Bestandteil von DevSecOps.

Software Composition Analysis (SCA) untersucht die Abhängigkeiten Ihres Projekts und vergleicht sie mit Datenbanken bekannter Schwachstellen (CVEs).

Im Gegensatz zu SAST, das Ihren Code untersucht, konzentriert sich SCA auf die von Ihnen importierten Bibliotheken.

• Erkennt bekannte verwundbare Versionen
• Weist auf riskante oder inkompatible Lizenzen hin
• Schlägt sichere Upgrade-Versionen vor

GitHub stellt Dependabot bereit. Dieser überprüft kontinuierlich Ihre Manifestdateien und erzeugt Warnungen, wenn eine Abhängigkeit eine bekannte Schwachstelle aufweist.

Sie aktivieren ihn unter Settings > Code security and analysis. Die Warnungen erscheinen mit Bewertungen des Schweregrads auf der Registerkarte „Security“.

Dependabot kann außerdem automatisch Pull Requests erstellen, die verwundbare Abhängigkeiten aktualisieren. Konfigurieren Sie ihn mit einer Datei dependabot.yml.

Die dependency-review-action wird bei Pull Requests ausgeführt und verhindert den Merge, wenn ein PR eine Abhängigkeit mit einer bekannten Schwachstelle einführt.

Dadurch wird Sicherheit nach links verschoben: Riskante Pakete werden erkannt, bevor sie den Main-Branch erreichen.

Die Actions, die Sie in einem Workflow aufrufen, sind selbst Abhängigkeiten. Wenn Sie auf @v4 verweisen, vertrauen Sie der Person oder Organisation, die dieses Tag kontrolliert.

Für maximale Sicherheit pinnen Sie Actions auf eine vollständige Commit-SHA, die unveränderlich ist.

Ein Lockfile wie package-lock.json oder poetry.lock legt die exakten Versionen und Hashes der Abhängigkeiten fest.

Verwenden Sie in CI einen deterministischen Installationsbefehl, damit Builds reproduzierbar sind und nicht unbemerkt eine manipulierte Version beziehen können.

Eine Software Bill of Materials (SBOM) ist ein vollständiges Verzeichnis aller Komponenten in Ihrem Build. Sie wird für die Compliance zunehmend vorausgesetzt.

GitHub kann eine SBOM im SPDX-Format exportieren, und Tools wie Syft können eine solche innerhalb von CI erstellen.

SCA deckt auch Lizenzrisiken ab. Die Einbindung einer GPL-lizenzierten Bibliothek in ein proprietäres Produkt kann rechtliche Verpflichtungen nach sich ziehen.

Konfigurieren Sie Ihren Scanner so, dass er nicht zulässige Lizenzen markiert oder ablehnt. So wird das Problem in CI statt erst bei einem Audit sichtbar.

Die Erkennung hilft nur, wenn sie problematischen Code stoppt. Konfigurieren Sie SCA-Gates so, dass sie die Pipeline fehlschlagen lassen, wenn eine kritische Schwachstelle gefunden wird.

Legen Sie einen Schwellenwert für den Schweregrad fest, sodass Funde mit geringem Risiko lediglich warnen, während kritische Funde den Merge oder das Deployment blockieren.

Da täglich neue Schwachstellen veröffentlicht werden, reicht eine einmalige Prüfung nicht aus. Führen Sie SCA zusätzlich zu jedem PR auch nach einem Zeitplan aus.

So erkennen Sie Pakete, die zum Zeitpunkt des Merges sicher waren, später aber verwundbar wurden.

Testen Sie Ihr Verständnis der Sicherheit in der Software-Lieferkette.

Sie haben gelernt, die Software-Lieferkette abzusichern.

• SCA untersucht Abhängigkeiten auf bekannte Schwachstellen
• Dependabot warnt vor riskanten Paketen und aktualisiert sie automatisch
• Die Abhängigkeitsprüfung blockiert riskante PRs
• Pinnen Sie Actions auf SHAs, verwenden Sie Lockfiles und erstellen Sie eine SBOM

Zusammen mit SAST und der Verwaltung von Geheimnissen ergibt sich daraus eine umfassend abgesicherte Pipeline.