Software-Lieferketten absichern, Teil 3 Tools und Handlungsweisen für die Software Supply Chain

Anbieter zum Thema

Windhoff Group

Technologien zum Absichern der Software-Lieferkette stecken noch in den Kinderschuhen. Die Landschaft ist ein Flickenteppich aus Nischenlösungen und schnellen Behelfsmitteln, die sich rasant weiterentwickeln.

Innovative Werkzeuge und bewährte Handlungsweisen können dennoch bereits helfen, die Sicherheit der Software-Lieferkette zu verbessern. Die Aufgabe ist breit gefächert. Sie umfasst Secrets Management, Dependency Mapping und Management, Absichern der CI/CD-Pipeline, effektives Repository-Management und vieles mehr.

Open Source in der Software-Lieferkette

Moderne Anwendungen stützen sich im großen Umfang auf wiederverwendbaren Code, darunter allgemein verfügbare Open-Source-Bibliotheken aus öffentlichen Repositories. Bei ihren Attacken auf die Softwarelieferkette machen sich Cyber-Täter eben diese wachsende Interdependenz von Softwareprojekten zu Nutze

Sonatype hat im Jahr 2021 einen Anstieg der Angriffe auf die Software-Lieferkette von Unternehmen aus vorgelagerten Open-Source-Ökosystemen heraus um astronomische 650% festgestellt. Die gleiche Statistik im Jahr davor lag bei 430%. Zu den wirkungsvollsten Angriffsmethoden zählen zum Beispiel:

• Namensraum-Verwechslung (a.k.a. Dependency Confusion): Cybertäter vertreiben gefälschte Bibliotheken in einer neueren Version als die offiziell veröffentlichte über frei zugängliche Repos wie npmjs; bestimmte Build-Tools holen sich dann ungefragt die neuere, absichtlich bösartige Version der betreffenden Bibliothek und schon sind die resultierenden Softwareprojekte kompromittiert;

• Typosquatting: Dieser indirekte Angriffsvektor macht sich unscheinbare Tippfehler zu Nutze, die Entwickler/innen bei der Suche nach beliebten Komponenten aufgrund von Unachtsamkeit gerne unterlaufen; bösartige Bibliotheken ersetzen so unbemerkt ihre legitimen Varianten;

• Brandjacking ist die unbefugte Nachahmung des Branding einer Organisation mit dem Ziel, Entwickler darauf aufbauender Projekte hinter den Ofen zu locken.

Mit weit verbreiteten Tricks können Cybertäter gelegentlich sogar sehr erfahrene Entwickler hinters Licht führen. Um diesen und anderen Machenschaften einen Riegel vorzuschieben, setzen immer mehr Unternehmen auf SCA-Werkzeuge (engl. Software Composition Analysis, also Tools für die Analyse der Softwarezusammensetzung), um eine standardisierte Code-Bestandsliste, die so genannte SBOM, zu berechnen.

Aufgrund ihrer Fähigkeiten zum Zurückverfolgen der Abhängigkeiten bilden SCA-Tools das Rückgrat des Stacks zum Absichern der Software-Lieferkette. Um eine vertrauenswürdige Software-Lieferkette zu schaffen, sollten SBOMs in Verbindung mit dem SLSA-Framework Einsatz finden.

Das SLSA-Framework (kurz für Supply Chain Levels for Software Artifacts) entstand durch eine gemeinsame Initiative von Google, der Linux Foundation und einigen Branchenvertretungen. Es hält eine Reihe von Empfehlungen und Anforderungen fest, die darauf abzielen, die Sicherheit und Vertrauenswürdigkeit der Software-Produkte in allen ihren Phasen zu gewährleisten.

Das Framework legt einen hohen Wert auf bewährte Handlungsweisen, darunter die Erstellung von SBOMs, die Überprüfung der Integrität von Komponenten, die Verwendung von sicheren Lieferkettenpraktiken und die Implementierung von kontinuierlicher Überwachung und Verbesserung.

Analyse der Softwarezusammensetzung mit SCA-Tools

Die Analyse der Softwarezusammensetzung (kurz SCA für Software Composition Analysis) ist eine Methode zur Gewährleistung der Anwendungssicherheit, die sich besonders in der Verwaltung von Open-Source-Komponenten bewährt hat. Mit SCA können Entwicklungsteams schnell alle bekannten (Open-Source-)Abhängigkeiten in einem Projekt verfolgen und analysieren.

SCA-Tools können alle verwandten Komponenten, ihre unterstützenden Bibliotheken sowie ihre direkten und indirekten Dependencies ermitteln. SCA-Tools können auch Softwarelizenzen, veraltete Abhängigkeiten sowie Schwachstellen und potenzielle Exploits erkennen. Der Scan-Prozess generiert ein Software-Inventar in Form eines Materialnachweises (SBOM) mit einer vollständigen Auflistung aller Software-Assets der Codebasis.

Ein SCA-Tool (kurz für Software Composition Analysis) ist ein Werkzeug zur Analyse, Verfolgung und Verwaltung von Komponenten, Bibliotheken, Frameworks und anderen Abhängigkeiten einer Softwareanwendung. SCA-Tools wie Snyk spielen eine entscheidende Rolle bei der Gewährleistung der Sicherheit und Compliance. Sie liefern Berichte und Empfehlungen über bekannte Sicherheitslücken, Lizenzprobleme oder Risiken im Drittanbietercode, selbst wenn dieser tief in der vorgelagerten Software-Lieferkette eingebunden ist.

Viele SCA-Tools haben ihren Ursprung im Lizenzmanagement von Open-Source-Code und haben sicherheitsspezifische Features erst nachträglich integriert. In diese Kategorie fallen unter anderem Mend.io (zuvor als WhiteSource bekannt), FOSSA und Black Duck by Synopsys.

SCA-Tools können bekannte Softwarepakete eigenständig ausfindig machen. Einige Tools erstellen eine SBOM im Rahmen des Software-Build-Prozesses. Sicherheitsexperten raten zum Einsatz von SCA-Werkzeugen an mehreren Stellen im Software-Lebenszyklus: in der IDE, in SCM-Werkzeugen (Source Code Management und Software Configuration Management) sowie nicht zuletzt in CI/CD-Tools wie Jenkins, Tekton Pipelines oder Spinnaker.

Im Rahmen eines Projektes namens Automated Compliance Tooling Project unter der Schirmherrschaft der Linux Foundation entsteht eine Sammlung quelloffener Referenz-Toolchain(s) für die automatische Erstellung und Verwendung einer SBOM zur Unterstützung der Lizenzeinhaltung, des Schwachstellenmanagements und anderer Richtlinien. Die quelloffenen Gemeinden der Projekte Fossology, Tern, OSS Review Toolkit, Reuse Software, Scan Code und SPDX ziehen gemeinsam an einem Strang.

Sicherheitslösungen lassen sich an verschiedenen Stellen im Software-Entwicklungslebenszyklus (SDLC) integrieren: über die CLI-Schnittstelle, durch Git-Integration und durch das Hinzufügen von Snyk als Fehlschlag der CI/CD-Pipeline.

Code- und Konfigurationsmanagement mit SCM-Tools

SCM steht für Software Configuration Management oder Source Code Management. Der Begriff bezieht sich auf die Praktiken, Werkzeuge und Techniken zur Verwaltung des Quellcodes und der Konfiguration einer Softwareanwendung. SCM umfasst die Verwaltung von Änderungen, Versionierung, Verzweigung, Zusammenführung und Freigabe des Quellcodes.

Das SCM ermöglicht es Entwicklern, den gesamten Lebenszyklus des Quellcodes zu kontrollieren und sicherzustellen, dass Änderungen ordnungsgemäß einfließen und dokumentiert werden. Es erleichtert die Zusammenarbeit in Entwicklungsteams auf eine strukturierte Art und Weise.

SCM-Tools wie Git, Subversion (SVN) oder Mercurial bieten Funktionen zur Verfolgung von Code-Aktualisierungen, Verwaltung von Branches, Zusammenführung von Code-Abweichungen und zur Unterstützung der Zusammenarbeit in Entwicklungsteams.

Mit GitOps zu Policy-as-Code für Development-Pipelines

Ein Ansatz namens „Policy as Code“ greift den Gedanken auf, der „Infrastructure-as-Code“ zu Grunde liegt, und wendet diesen auf Sicherheitsrichtlinien an. „Policy as Code“ lässt sich auf die CI/CD-Pipeline anwenden, um zu verhindern, dass kompromittierter Code in die Lieferkette gelangt. Kubernetes-native Pipelines wie beispielsweise Tekton sind bereits darauf ausgerichtet.

Mit der Implementierung von Policy-as-Code setzt sich das Projekt Open Policy Agent (OPA) im Rahmen der Cloud Native Computing Foundation (CNCF) auseinander. Viele der besten Tools für das Policy-Management, darunter Conftest, nutzen Rego, die Sprache von OPA, für Regeln zur Auswertung von Kubernetes-Konfigurationen, Tekton-Pipeline-Definitionen, Terraform-Code, Serverless-Konfigurationen und andere. Eine Conftest-Richtlinie in Rego (policy/Bereitstellung.rego) könnte zum Beispiel so aussehen:

Kubernetes macht sich die sogenannten Admission Controller zu Nutze, um Richtlinien für Objekte während der Erstellungs-, Aktualisierungs- und Löschvorgänge durchzusetzen. Admission Control ist ein grundlegendes Konzept für die Durchsetzung von Richtlinien in Kubernetes.

OPA-Gatekeeper, eine Integrationskomponente für OPA und Kubernetes, kann sich als ein Admission-Controller einbringen und zum Zeitpunkt der Bereitstellung Rego-Richtlinien anwenden. OPA-Gatekeeper kann so den nativen, in Kubernetes eingebauten, Admission Controller namens Pod Security um komplexere Zulassungsrichtlinien erweitern.

Für Kubernetes gibt es mit Falco (ursprünglich von Sysdig, Inc., heute bei der CNCF beheimatet) und StackRox (Red Hat Advanced Cluster Security for Kubernetes) zwei leistungsstarke Open-Source-Policy-Engines, die sich die Implementierung und Verwaltung von Policy as Code auf die Fahnen schrieben.

StackRox-Richtlinien lassen sich in den Phasen Build, Deploy und Runtime anwenden. Falco konzentriert sich auf die Erkennung von Sicherheitsverletzungen zur Laufzeit. Falco bietet mehrere vorkonfigurierte Tests auf ungewöhnliches Verhalten, das auf eine aktive Sicherheitsbedrohung hinweisen kann, wie z.B. unerwartete Privileg-Eskalationen.

Eine StackRox-Richtlinie kann beispielsweise während des CI/CD-Prozesses zum Tragen kommen, um Images mit bekannten kritischen Schwachstellen zu kennzeichnen und den Build zu warnen oder abzubrechen. Die gleiche Richtlinie kann zur Bereitstellungszeit die Zulassung von Images mit bekannten kritischen Schwachstellen verhindern. Die gleiche Richtlinie kann wiederum auch zur Laufzeit auf neu entdeckte kritische Schwachstellen in bereitgestellten Images hinweisen.

StackRox bietet auch eine CI/CD-Integration, um Sicherheitsprüfungen, beispielsweise das Scannen von Images nach Schwachstellen, zur Build-Zeit zu automatisieren. Die Checks von StackRox zum Zeitpunkt der Bereitstellung können dazu beitragen, die Einhaltung von bewährten Praktiken einer sicheren Konfiguration und Branchenstandards durchzusetzen, während die Bedrohungserkennung zur Laufzeit dazu beiträgt, bereitgestellte Anwendungen im Betrieb zu schützen.

Workflow-Engines wie die quelloffene Ratify können die Überprüfung verschiedener Objekte der Lieferkette gemäß für ein Image gemäß der ORAS Artifact Specification anhand vorgegebener Richtlinien koordinieren.

Handlungsempfehlungen

Sicherheitsexperten empfehlen Unternehmen die einige bewährte Handlungsweisen, darunter:

1. Beschaffen Sie sich ein Schwachstellen-Meldesystem und nutzen Sie es gewissenhaft.

2. Bauen Sie SBOMs mit Tools wie Syft oder Trivy, die die Lieferkette zurückverfolgen und auch externen Code erfassen können.

3. Überprüfen und kontrollieren Sie den Bezug von Open-Source-Paketen. Recherchieren Sie bekannte Verwundbarkeiten der betreffenden Open-Source-Bibliotheken umfassend. Halten Sie Ihre Open-Source-Abhängigkeiten stets auf dem neuesten Stand, um die Gesundheit und die Sicherheit nachgelagerter Anwendungen nicht zu gefährden.

4. Nutzen Sie vertrauenswürdige private Repositories. Verifizieren Sie die Signaturen von Artefakten mit Tools wie Ansible oder mit Content-Signing-Technologien wie Sigstore. Mit dem Bezug von Code sollten automatische Tests ansetzen, darunter auch SCA-Tests, und dann kontinuierlich ablaufen.

5. Legen Sie auf Git nur solchen Code ab, den Sie anhand von nachprüfbaren Tests und Code-Audits als nachvollziehbar vertrauenswürdig einstufen (Stichwort: Audit Trail). Speichern und überprüfen Sie Ihre Sicherheitsrichtlinien in Code – vor jedem Git-Commit.

6. Nutzen Sie GitOps-Werkzeuge wie ArgoCD, um eine einzige Quelle der Wahrheit für Anwendungskonfigurationsdateien zu etablieren.

7. Implementieren Sie richtlinienbasierte Zugriffskontrollen (RBAC), um Zero Trust Security durch deklarativ ausgedrückte Berechtigungen zu ermöglichen.

8. Führen Sie bei der Bereitstellung von Anwendungen Sicherheitstests auf Code-Ebene und Scans von Container-Images und deren Paketen durch. Implementieren Sie Policy-in-Code mit Richtlinien-Engines.

9. Überprüfen Sie Anwendungskonfigurationen mit Lintern, sobald die YAML-Dateien der Bereitstellung und Helm-Charts verfügbar sind.

10. Setzen Sie die Überwachung der Sicherheit im gesamten Lebenszyklus der Bereitstellung fort mit Plattform- und Anwendungsüberwachungslösungen einschließlich Tools zur Analyse des Laufzeitverhaltens. SAST- und Fuzz-Testing in der CI/CD-Pipeline geht in Dynamische Anwendungssicherheitstests (DAST) zur Laufzeit über, vorzugsweise in einer Staging-Umgebung.

11. Verwenden Sie eine Workflow-Engine wie Ratify zur Überprüfung der verschiedenen Bestandselemente der Lieferkette gemäß einer vorgegebenen Richtlinie unter Verwendung von SBOMs und Signaturen.

12. Setzen Sie zu guter Letzt auf die kontinuierliche Weiterbildung aller Entwickler, die sich an Ihren Projekten beteiligen, um eine kontinuierliche Prozessoptimierung im Einklang mit den sich ändernden Bedrohungen und Anforderungen zu ermöglichen.

Fazit

Die Allgegenwärtigkeit von Software versetzt digitalisierte Unternehmen in einen erhöhten Bedrohungszustand. Um ihn zu bewältigen, ist es von entscheidender Bedeutung, proaktiv geeignete Maßnahmen zu ergreifen und bewährte Sicherheitspraktiken anzuwenden.

Die Gewährleistung der Sicherheit entlang der Software-Wertschöpfungskette ist ein kontinuierlicher Wettlauf gegen die Zeit. Während Sicherheitsanbieter ihre Innovationen vorantreiben, entwickeln Angreifer ihre Methoden ebenfalls unaufhörlich weiter.

Softwareentwickler in Unternehmen müssen die Sicherung ihrer Software-Lieferkette selbst in die Hand nehmen. Die Erwartung, eine schlüsselfertige allumfassende Rundum-Glücklich-Lösung von einem einzigen Sicherheitsanbieter zu beziehen, bleibt auf absehbare Zeit für die meisten Organisationen unerfüllt. Den Entwicklern bleibt nichts anderes übrig, außer ihren Sicherheitsstack stückweise aus den innovativsten Lösungen auf dem Markt selbst zusammenzustellen.

Durch die Implementierung eines robusten Sicherheitsrahmens, die Nutzung von Schwachstellenberichtssystemen und SBOMs sowie die regelmäßige Schulung der Entwickler können Unternehmen ihre Widerstandsfähigkeit gegenüber Sicherheitsbedrohungen stärken und eine sicherere Software-Wertschöpfungskette gewährleisten. Dies trägt dazu bei, das Vertrauen der Kunden zu stärken und das Risiko von Sicherheitsvorfällen und Datenverlusten zu minimieren.

(ID:49954932)