Vier operationelle Risiken, die Sie im Griff haben sollten

Nicht alle erkennbaren Risiken in Ihrer Software-Lieferkette lassen sich anhand der Liste der CVEs (Common Vulnerabilities and Exposures = häufige Schwachstellen und Risiken) identifizieren. Schwachstellen schleichen sich oft unbemerkt durch etwas so Simples wie etwa veraltete oder inaktive Komponenten ein. Diese können zu einer ernsthaften Bedrohung werden.

Sicherheitsteams und Entwickler müssen daher auch die von Komponenten ausgehenden operationellen Risiken identifizieren und bewerten können. Diese sind zwar vielleicht nicht in den CVEs aufgeführt, können aber dennoch zur Gefahr für Ihr Unternehmen werden.

Die wichtigsten vier operationellen Risikofaktoren

Für den sicheren Schutz Ihrer Software-Lieferkette sollten Sie unbedingt die folgenden vier operationellen Risikofaktoren berücksichtigen, wenn Sie Open-Source-Komponenten verwenden.

Ende der Lebensdauer

Wenn ein Entwickler angibt, dass eine Komponente das Ende ihrer Lebensdauer erreicht hat, sollten Sie diese aufgrund des damit verbundenen hohen Risikos nicht verwenden. 

Gleiches gilt für veraltete Komponenten. Diese Open-Source-Software würde zwar vielleicht weiterhin gute Dienste leisten, sie wird aber nicht mehr auf Schwachstellen überwacht. Und selbst wenn Sicherheitslücken erkannt würden, gäbe es keine aktualisierte Version.

Alter der Version

Älterer Code ist in der Regel weniger sicher. Liegt die Veröffentlichung einer Komponente bereits eine Weile zurück – selbst, wenn es sich um die neueste verfügbare Version handelt –, ist sie nicht mehr auf dem aktuellen Stand der Bedrohungen. Zudem nutzt sie vermutlich andere ältere Komponenten, die genauso risikobehaftet sind.

Je älter der Code, desto höher das Risiko. Bei JFrog wird das Risiko bei Versionen, die zwischen 10 und 20 Monate alt sind, als gering eingestuft. Ab einem Alter von drei Jahren (40 Monaten) gelten Versionen als hochriskant.

Aktualität der Version

Von wenigen Ausnahmen abgesehen, sollten Sie stets die aktuelle Komponentenversion verwenden, um von den neuesten Verbesserungen zu profitieren. Sie vermeiden dadurch auch bekannte Schwachstellen älterer Releases.

Komponentenversionen, die einen oder zwei Releases hinter der aktuellen Version zurückliegen, stellen noch kein wirkliches Risiko dar – solange sie nicht älter als 10 bis 20 Monate sind. Bei älteren Versionen steigt das Risiko jedoch proportional. Einer Komponente, für die es bereits vier neuere Versionen gibt, wird ein mittleres Risiko zugeschrieben. Als hochriskant gelten Komponenten, für die es bereits sechs oder mehr neue Releases gibt.

Projektstatus

Ein intaktes Open-Source-Projekt ist das Resultat einer intakten Community. Ein Indiz dafür sind rege Beiträge unterschiedlicher Mitglieder. Komponenten, die von einer einzelnen Person verwaltet und selten aktualisiert werden, profitieren nicht im gleichen Umfang von Verbesserungen, Kontrolle oder Wachsamkeit. Noch riskanter ist Open-Source-Software, um die sich scheinbar niemand mehr kümmert.

Sichere Open-Source-Software bedarf einer aktiven, engagierten Entwickler-Community, die diese kontinuierlich nutzt und verbessert. Die Kubernetes-Software wird beispielsweise von mehr als 3.100 Mitwirkenden gepflegt. Neben zahlreichen Patches gibt es hierfür auch drei Point-Releases pro Jahr.

Die folgenden Indikatoren sollten Sie bei der Bewertung des Projektstatus unbedingt berücksichtigen:

• Release-Frequenz: Um den Mindeststatus an Sicherheit zu wahren, sollte es jährlich mindestens zwei General-Availability- bzw. GA-Releases (Point oder Patch) geben. Software mit nur einem – oder gar keinem – Release – pro Jahr, sollte als unsicher betrachtet werden.

• Commit-Frequenz: Damit Software als sicher gilt, sollten dafür in den vergangenen 12 Monaten mehr als 100 Commits erfolgt sein. Meiden Sie Software mit weniger Commits.

• Anzahl der Beitragenden pro Jahr: Die Commits der vergangenen 12 Monate sollten von mindestens fünf verschiedenen Beitragenden stammen, um einen Mindeststatus an Sicherheit zu gewährleisten. Auch hier gilt: Verwenden Sie keine Software, bei der es weniger sind.

Erhöhen Sie die Sicherheit

Die oben genannten operationellen Risiken in Ihrer Software-Lieferkette zu erkennen, sollte Teil Ihrer DevSecOps-Maßnahmen sein. Es reicht jedoch nicht, lediglich bekannte Schwachstellen zu identifizieren und die Einhaltung von Lizenzrichtlinien sicherzustellen. Nur, wenn Sie Ihre SBOM (Software Bill of Materials), also die Komponentenliste Ihrer Software, zusätzlich regelmäßig auf die genannten operationellen Risiken überprüfen, können Sie einen umfassenden Sicherheitsstatus erzielen.

Mit der SCA (Software Composition Analysis) von JFrog Xray wird dies zum Kinderspiel. Neben Ihren Sicherheits- und Lizenzrichtlinien können Sie auch die operationellen Risikorichtlinien konfigurieren, um gezielt nach unerkannten Risiken zu suchen.

Die von JFrog veröffentlichten Mindeststandards für Risiken ermöglichen es Ihnen, den Schweregrad anhand der operationellen Risikofaktoren zu berechnen oder eigene Schwellenwerte festlegen.

Wenn Sie für wichtige Repositorys Watch-Richtlinien konfigurieren, ermittelt Xray für Sie, bei welchen Komponenten aufgrund von Richtlinienverstößen Maßnahmen zu ergreifen sind.

Sie möchten mehr erfahren? Fordern Sie eine Xray-Demo an.