Seite 3: Wie geht es weiter?

Inhaltsverzeichnis

Alle Systeme melden nun ihre Zutatenliste (SBOM) an eine zentrale Stelle. Deren Analyse liefert einen Überblick über die gesamte Anwendungslandschaft. Darauf aufbauend lassen sich im Build-Prozess Quality Gates setzen, die im Ernstfall einen Abbruch auslösen. Aus den Alarmierungen ließen sich zudem Issues ableiten und in das zugehörige Trackingsystem einbinden.

Im Sinne von Shift Security Left lassen sich Sicherheitsüberprüfungen weiter vorne im Entwicklungsprozess integrieren, beispielsweise über statische Codeanalysen (SAST) mit FindSecurityBugs oder dynamische (DAST) mit dem Zed Attack Proxy. Werkzeuge wie Dependabot oder Renovate helfen, kleinere Komponentenupdates zu automatisieren, indem sie das Update als Merge- beziehungsweise Pull-Request einstellen, der im Anschluss lediglich zu mergen ist.

Sind neue Sicherheitslücken offiziell bestätigt, kann schnelles Handeln häufig entscheidend sein. Dabei helfen Konzepte wie Continuous Delivery respektive Continuous Deployment, mit denen sich neue Versionen der eigenen Software schneller für den Produktivbetrieb bereitstellen lassen.

Neben dem Einsatz minimalisierter Basis-Images für die Ausführungsschicht bieten sich viele weitere Best Practices an, um sichere oder gehärtete Container zu betreiben – etwa durch Verwenden nicht privilegierter Benutzer, das Begrenzen der für den Container zur Verfügung stehenden Ressourcen oder das Einschränken der Fähigkeiten (Capabilitites) auf die zwingend notwendigen.

Auf dem Weg zu einem Zero-Trust-Network leisten Service Meshes wertvolle Dienste. In der Regel starten diese zu jedem Service Sidecar-Container, die im Anschluss die gesamte Kommunikation steuern. Über Regeln (Intentions) lässt sich festlegen, wer mit wem überhaupt sprechen darf. Das trägt zu einer Mikrosegmentierung und damit zu erhöhter Sicherheit bei. Darüber hinaus lässt sich die Kommunikation mit Mutual TLS (Clientzertifikaten) verschlüsseln und absichern. Diese wiederum können und sollten Entwicklerinnen und Entwickler mit Secrets-Management-Tools wie HashiCorp Vault automatisch erzeugen und in kurzen Abständen rotieren.

Abbildung 6 stellt die Funktionsweise des Service Mesh vereinfacht dar. Für die Services A und B wird ein Proxy vorgeschaltet, der sämtliche Kommunikation übernimmt. Intentions legen fest, dass Service A mit Service B kommunizieren darf, jedoch nicht umgekehrt.

Was tun mit zugekaufter Software?

Da die Anwendungslandschaft einer Organisation meist nicht nur aus eigenentwickelter Software besteht, sondern im Gegenteil häufig sogar der Anteil zugekaufter Software deutlich größer ist, besteht hier Handlungsbedarf. Dabei stellt sich erneut die Frage, welche Produkte tatsächlich von Schwachstellen betroffen sind und wo man diese Information herbekommt. Steht ein Softwarearchiv zur Verfügung, etwa in Form einer JAR- oder WAR-Datei, und ist die Runtime bekannt (beispielsweise JBoss Wildfly in Version x.y), lässt sich beides per Syft analysieren, um wiederum eine SBOM zu erzeugen. Diese lässt sich anschließend in Dependency-Track importieren, um Analysen durchzuführen.

Empfehlenswert ist es, in Ausschreibungen die Anforderung aufzunehmen, dass der Softwarehersteller bei jeder ausgelieferten Version eine SBOM mitliefern muss. Darüber hinaus sollten Unternehmen Service-Level-Agreements (SLAs) vereinbaren, die den Anbieter im Falle einer kritischen Sicherheitslücke zum zeitnahen Liefern von Patches verpflichten.