IT-Teams müssen Software-Patch-Anstrengungen besser priorisieren

Cybersecurity-Teams müssen besser priorisieren, welche Schwachstellen von Anwendungsentwicklern behoben werden sollen. Eine globale Umfrage unter 1.224 Sicherheits-, Entwicklungs- und IT-Betriebsexperten, die heute von JFrog, einem Anbieter einer CI/CD-Plattform (Continuous Integration/Continuous Delivery) für die Entwicklung von Software, veröffentlicht wurde, ergab, dass 60 % der Befragten in einem bestimmten Monat in der Regel nur vier Tage oder länger damit verbringen, Anwendungsschwachstellen zu beheben.

Das Problem ist, dass die meiste Zeit damit verbracht wird, Schwachstellen zu beheben, die entweder nicht in den Softwarebibliotheken enthalten sind, die tatsächlich ausgeführt werden, oder die Anwendung selbst stellt nie eine Verbindung zum Internet her. Noch beunruhigender ist, dass die Sicherheitsforscher von JFrog 212 Schwachstellen analysiert haben und anschließend den Schweregrad von 85 % der als kritisch und 73 % der als hoch eingestuften Schwachstellen herabgestuft haben.

Dieselben Forscher fanden auch heraus, dass 74 % der gemeldeten Common Vulnerabilities and Exposures (CVES) mit hohen und kritischen Werten des Common Vulnerability Scoring System (CVSS), die den 100 besten Docker-Hub-Community-Images zugewiesen wurden, nicht ausgenutzt werden konnten.

Überlastung durch Schwachstellenberichte

Eines der schmutzigen Geheimnisse der IT ist, dass Anwendungsentwickler die von den Cybersecurity-Teams erstellten Berichte über Sicherheitslücken nicht allzu ernst nehmen. Cybersecurity-Teams geben schon seit Jahren lange Listen von Schwachstellen an Anwendungsentwicklungsteams weiter, aber viele dieser Teams stellen fest, dass es sich bei der Untersuchung dieser Warnungen oft um einen weiteren Fall handelt, in dem ein Cybersecurity-Team ein Problem sieht, wo keines ist.

Natürlich wird es immer wieder vorkommen, dass ein Entwicklungsteam einen Alarm ignoriert, der sich als katastrophal erweist. Wenn Cybersecurity-Teams sicherstellen wollen, dass ihre Warnungen nicht ignoriert werden, müssen sie sich darüber im Klaren sein, dass Anwendungsentwicklungsteams nicht unendlich viel Zeit für die Erstellung und Bereitstellung von Software-Patches zur Verfügung steht. Sie müssen immer noch neuen Code schreiben, egal wie viele Schwachstellen ein Cybersecurity-Team meint, aufgedeckt zu haben. Das Wichtigste für jedes Cybersecurity-Team ist die Priorisierung von Patch-Anfragen, und zwar nicht nur nach der Schwere einer Sicherheitslücke, sondern auch nach dem Grad ihrer Ausnutzbarkeit.

Inkonsistente Codescans

Um dieses Ziel zu erreichen, müssen Sie natürlich im Rahmen eines DevSecOps-Workflows enger mit den Entwicklungsteams zusammenarbeiten, um den Code vor und nach der Bereitstellung einer Anwendung zu scannen. In der JFrog-Umfrage wurde festgestellt, dass Codescans von Unternehmen zu Unternehmen oft uneinheitlich angewendet werden. Insgesamt 42 % gaben an, dass es am besten ist, Sicherheitsscans durchzuführen, während der Code geschrieben wird, während 41 % es vorziehen, neue Softwarepakete vor der Installation zu scannen. Insgesamt 41 % der Befragten gaben an, dass die Laufzeit der am wenigsten geeignete Zeitpunkt zum Ausführen von Scans sei. Mehr als die Hälfte (56 %) gab an, dass ihr Unternehmen Sicherheitsscans sowohl auf der Code- als auch auf der Binärscan-Ebene durchführt.

Es gibt natürlich viele Patches, z. B. für Betriebssysteme, die ein Cybersecurity-Team selbst anwenden können sollte, ohne dass Anwendungen beschädigt werden. Wenn die Anwendung beschädigt wird, sollte es relativ einfach sein, den Patch zurückzusetzen. Das Patchen von Anwendungen ist jedoch eine ganz andere Sache. Cybersecurity-Teams, die versuchen, eine benutzerdefinierte Anwendung zu patchen, übernehmen die Verantwortung für eine Aufgabe, die wahrscheinlich schlecht ausgehen wird.

Natürlich kann der Tag kommen, an dem es keine Schwachstellen mehr in Software gibt, aber solange Software von Menschen geschrieben oder von Maschinen erzeugt wird, die mit von Menschen geschriebener Software trainiert wurden, wird es immer bekannte und unbekannte Schwachstellen geben, die sorgfältig behoben werden müssen.