Kürzlich wurde die Veröffentlichung von ein neuer Bericht der Entwickler-Sicherheitsfirma Snyk und der Linux Foundation, über ihre gemeinsame Forschung zum Stand der Sicherheit von Open-Source-Software.
In deinem Beitrag darzulegen, dass die Ergebnisse für die Unternehmen nicht ermutigend sind, für Es gibt eine Vielzahl von erheblichen Sicherheitsrisiken die sich aus der weit verbreiteten Verwendung von Open-Source-Software in der modernen Anwendungsentwicklung ergeben, sowie wie viele Unternehmen derzeit schlecht darauf vorbereitet sind, diese Risiken effektiv zu managen.
Konkret stellte der Bericht fest:
Mehr als vier von zehn (41 %) Unternehmen haben kein großes Vertrauen in die Sicherheit ihrer Open-Source-Software;
Das durchschnittliche Anwendungsentwicklungsprojekt hat 49 Schwachstellen und 80 direkte Abhängigkeiten (Open-Source-Code, der von einem Projekt aufgerufen wird); Ja,
Die Zeit, die zum Beheben von Schwachstellen in Open-Source-Projekten benötigt wird, hat stetig zugenommen und sich von 49 Tagen im Jahr 2018 auf 110 Tage im Jahr 2021 mehr als verdoppelt.
Es wird das erwähnt grundsätzlich ein Projekt Anwendungsentwicklung hat durchschnittlich 49 Schwachstellen und 80 direkte Abhängigkeiten. Darüber hinaus ist die Zeit, die zum Beheben von Schwachstellen in Open-Source-Projekten benötigt wird, stetig gestiegen und hat sich von 49 Tagen im Jahr 2018 auf 110 Tage im Jahr 2021 mehr als verdoppelt.
» Heutige Softwareentwickler haben ihre eigenen Lieferketten: Anstatt Autoteile zusammenzubauen, bauen sie Code zusammen, indem sie vorhandene Open-Source-Komponenten mit ihrem einzigartigen Code verbinden. Wenn dies zu erhöhter Produktivität und Innovation führt“, erklärt Matt Jarvis, Director of Developer Relations bei Snyk. Zusammen mit der Linux Foundation planen wir, auf diesen Erkenntnissen aufzubauen, um Entwickler auf der ganzen Welt weiterzubilden und auszustatten, damit sie schnell und sicher weiter entwickeln können."
Neben anderen Ergebnissen, Nur 49 % der Unternehmen haben eine Sicherheitsrichtlinie für die Entwicklung oder Nutzung freier Software (bei mittleren und großen Unternehmen sind es nur 27 %). Während 30 % der Organisationen ohne eine Sicherheitsrichtlinie für freie Software offen anerkennen, dass sich niemand in ihrem Team direkt mit der Sicherheit freier Software befasst.
Auch die Komplexität der Lieferkette ist ein Thema, wobei mehr als ein Viertel der Befragten angibt, dass sie sich Sorgen über die Auswirkungen ihrer direkten Abhängigkeiten auf die Sicherheit machen. Nur 18 % sagen, dass sie von den Kontrollen, die sie handhaben, überzeugt sind.
Bis zu diesem Punkt, Es ist wichtig, zwei Situationen hervorzuheben, Erste von ihnen ist zu dem Zeitpunkt, als Entwickler eine Komponente hinzufügen Open Source in Ihren Anwendungen sind Sie sofort von dieser Komponente abhängig werden und sind gefährdet, wenn diese Komponente Schwachstellen enthält.
Das andere, was in den letzten Jahren häufig zu beobachten war, ist, dass dieses Risiko auch durch indirekte oder transitive Abhängigkeiten verstärkt wird, das sind die Abhängigkeiten der "anderen Abhängigkeiten", hier wissen viele Entwickler nicht einmal von diesen Abhängigkeiten, was es sogar macht schwieriger zu verfolgen und zu schützen.
Damit können wir ein wenig verstehen, dass der Bericht zeigt, wie real dieses Risiko ist, mit Dutzenden von Schwachstellen, die in vielen direkten Abhängigkeiten in jeder bewerteten Anwendung entdeckt wurden. Allerdings sind sich die Befragten bis zu einem gewissen Grad der Sicherheitskomplexität bewusst, die durch Open Source in der heutigen Softwarelieferkette entsteht:
Mehr als ein Viertel der Befragten gaben an, dass sie sich Sorgen über die Sicherheitsauswirkungen ihrer direkten Abhängigkeiten machen, nur 18 % der Befragten gaben an, dass sie den Kontrollen vertrauen, die sie für ihre transitiven Abhängigkeiten haben. undXNUMX Prozent aller Schwachstellen wurden in transitiven Abhängigkeiten gefunden.
Es ist auch wichtig zu erwähnen, dass, wenn diese Unternehmen oder Entwickler mit der von ihnen verwendeten Software nicht „sicher“ sind, viele von uns auf die logischste Weise denken werden, dass sie die Entwicklung „bezahlen“ oder „unterstützen“, entweder durch Zuweisung von Ressourcen oder Entwickler", aber an diesem Punkt kommt eine der großen Debatten über Open-Source-Software ins Spiel, wo Open Source "bezahlt" werden sollte.
Daher gibt es viele Beispiele für Open-Source-Software, die zwei Versionen handhabt, die kostenpflichtig und kostenlos sind, und sogar nur kostenpflichtig, aber der Quellcode ist verfügbar.
Andererseits gab es auch Bewegungen von Entwicklern und großen Unternehmen, in denen sie sich für einen Wechsel des Vertriebsmodells oder den Wechsel zu einem Bezahlmodell, beispielsweise QT, entscheiden.
Ohne mehr, für Interessierte, die mehr darüber erfahren möchten über die Notiz können Sie die Details in einsehen den folgenden Link.