Die im Census II dargestellten Abhängigkeiten begegnen mir ebenfalls seit längerem immer häufiger.
Ich bin sehr froh um diesen Bericht, da er gefühlte Tatsachen und Probleme formaler beschreibt als ich es vermag. Trotzdem habe ich jetzt eine Quelle mit großer Glaubwürdigkeit an der Hand, um die dargestellten Probleme im Arbeitsalltag besser adressieren und meine Argumente zu begründen.
Beim Blättern durch die langen Anhänge habe ich etliche Produkte wiedergefunden, die mir seit Jahren Kopfschmerzen bereiten. Vor allem die transitiven Abhängigkeiten werden meines Erachtens regelmäßig unterschätzt. Mir begegnen häufig Probleme mehrfach, weil bei der Nutzung von frei verfügbarer Software, die wiederum auf anderer Software basiert eine praktisch nicht zu überblickende Tiefe von Abhängigkeiten entsteht.
Wie das ganze sinnvoll adressiert werden kann, steht aber leider auf einem anderen Blatt geschrieben. Die Verringerung von Abhängigkeiten ist ein erstrebenswertes Ziel auf der einen Seite aber Software selbst zu entwickeln und potenziell mehr/schlimmere Fehler zu fabrizieren ist ja auch keine Option. Ein Tool-basierter Ansatz ist sicherlich eine Option, aber es gibt viele Entwicklungen, die das einfach nicht leisten können. Vor allem nicht, wenn bei transitiven Abhängigkeiten Probleme aufgezeigt werden, die man nicht trivial beeinflussen kann.
Nicht zuletzt bei Log4J war ich froh um Partner, die hier proaktiv Lösungen gefunden haben, um Abhängigkeiten zu finden und zu beseitigen. Häufig erlebe ich andererseits, dass Priorität und vor allem das Fachwissen fehlen, um nicht nur die offensichtlichen Probleme zu adressieren und zu lösen, sondern alle relevanten potenziellen Probleme. Die Hartnäckigkeit ist schwer umzusetzen, wenn es auch genügend andere Herausforderungen gibt, die leichter zu verstehen und zu lösen sind.
Durch die Zunahme von Supply Chain Angriffen in den letzten beide Jahren denke ich, dass hier noch viel Verbesserungspotential besteht. Nicht zuletzt durch Arbeiten wie Census II bin ich aber zuversichtlich, dass es zukünftig bessere Möglichkeiten zum Bau von sicherer Software, welche auf viel FOSS basiert geben wird. Die Möglichkeiten durch Tools sind auch etwas besser geworden, soweit ich das bewerten kann. Weiteren Bedarf sehe ich in der konsequenten Anwendung von Regulatorik und Compliance, die ja selten eine Tiefe und Stringenz einfordert, um Verwundbarkeiten in abhängigen Komponenten zu finden. Eine Governance, die dafür sorgt, dass zumindest nur Software eingebunden wird, die auch gepflegt und gepatcht wird, ist leider auch nicht überall vorhanden.
Um nur saubere Software zu haben, sollte wohl eher weniger und dafür gute (hier sicher) Software entwickelt werden, aber die Tendenz geht in eine andere Richtung. Ich selbst kann mich da leider auch nicht ausnehmen.
Allein beim Betreiben dieses Blogs aktuell mit dem AWS LightSail Bitnami Stack kenne ich einige Abhängigkeiten zu verwundbaren Bibliotheken, die ich aber selbst nicht stopfen kann, da ich nicht Herr des Stacks bin. Das wird dann wohl ein zukünftiger Beitrag (nach dem Umbau zu einer Lösung, die ich besser kontrollieren kann).
Quellen: