Google schlägt vor, neue Regeln zur Verbesserung der Open Source-Sicherheit festzulegen

Die Sicherheit von Open Source-Software hat die Aufmerksamkeit der Branche auf sich gezogenLösungen erfordern jedoch einen Konsens über die Herausforderungen und die Zusammenarbeit bei der Umsetzung.

Das Problem ist komplex und es gibt viele Facetten zu behandeln, unter anderem aus der Lieferkette, Abhängigkeitsmanagement, Identität. Zu diesem Zweck hat Google kürzlich ein Framework veröffentlicht ("Know, Prevent, Fix"), in dem erläutert wird, wie die Branche über Schwachstellen in Open Source und bestimmte Bereiche denken kann, die zuerst behoben werden müssen.

Google erklärt seine Gründe:

„Aufgrund der jüngsten Ereignisse hat die Software-Welt ein tieferes Verständnis für das tatsächliche Risiko von Supply-Chain-Angriffen gewonnen. Open-Source-Software sollte aus Sicherheitsgründen weniger riskant sein, da alle Codes und Abhängigkeiten offen sind und zur Überprüfung und Überprüfung zur Verfügung stehen. Und obwohl dies im Allgemeinen zutrifft, wird davon ausgegangen, dass die Leute diese Inspektionsarbeiten tatsächlich durchführen. Bei so vielen Abhängigkeiten ist es unmöglich, alle zu überwachen, und viele Open Source-Pakete werden nicht gut gepflegt.

„Es ist üblich, dass ein Programm direkt oder indirekt von Tausenden von Paketen und Bibliotheken abhängt. Zum Beispiel hängt Kubernetes jetzt von ungefähr 1000 Paketen ab. Open Source verwendet wahrscheinlich eher Abhängigkeiten als proprietäre Software und stammt von einer größeren Anzahl von Anbietern. Die Anzahl der unabhängigen Entitäten, denen vertraut werden kann, kann sehr groß sein. Dies macht es äußerst schwierig zu verstehen, wie Open Source in Produkten verwendet wird und welche Schwachstellen relevant sein können. Es gibt auch keine Garantie dafür, dass das, was erstellt wird, mit dem Quellcode übereinstimmt.

Innerhalb des von Google vorgeschlagenen Rahmens wird vorgeschlagen, diese Schwierigkeit in drei weitgehend unabhängige Problembereiche mit jeweils spezifischen Zielen zu unterteilen:

Kennen Sie die Schwachstellen Ihrer Software

Es ist schwieriger, Ihre Software-Schwachstellen zu kennen, als Sie vielleicht erwarten aus vielen Gründen. ja ok Mechanismen existieren, um Schwachstellen zu melden, Es ist unklar, ob sie sich wirklich auf die spezifischen Versionen der von Ihnen verwendeten Software auswirken:

  • Ziel: Genaue Schwachstellendaten: Zunächst ist es wichtig, genaue Schwachstellenmetadaten aus allen verfügbaren Datenquellen zu erfassen. Wenn Sie beispielsweise wissen, welche Version eine Sicherheitsanfälligkeit eingeführt hat, können Sie feststellen, ob Software betroffen ist, und wissen, wann sie gepatcht wurde, führt zu genauen und zeitnahen Korrekturen (und einem engen Fenster für eine mögliche Ausnutzung). Idealerweise sollte dieser Klassifizierungsworkflow automatisiert werden.
  • Zweitens liegen die meisten Schwachstellen in Ihren Abhängigkeiten und nicht in dem Code, den Sie direkt schreiben oder steuern. Selbst wenn sich Ihr Code nicht ändert, kann sich die Landschaft der Schwachstellen, die Ihre Software betreffen, ständig ändern - einige sind behoben, andere werden hinzugefügt.
  • Zweck: Standardschema für Schwachstellendatenbanken Infrastruktur- und Industriestandards sind erforderlich, um Open Source-Schwachstellen zu verfolgen und zu warten, ihre Folgen zu verstehen und ihre Schadensbegrenzungen zu verwalten. Ein Standard-Schwachstellenschema würde es gemeinsamen Tools ermöglichen, auf mehreren Schwachstellendatenbanken ausgeführt zu werden, und die Nachverfolgung vereinfachen, insbesondere wenn Schwachstellen mehrere Sprachen oder Subsysteme überschreiten.

Vermeiden Sie das Hinzufügen neuer Sicherheitslücken

Es wäre ideal, die Entstehung von Schwachstellen zu vermeiden Und während Test- und Analysewerkzeuge helfen können, wird Prävention immer ein schwieriges Thema sein.

Hier, Google schlägt vor, sich auf zwei spezifische Aspekte zu konzentrieren:

  • Verstehen Sie die Risiken, wenn Sie sich für eine neue Abhängigkeit entscheiden
  • Verbessern Sie kritische Softwareentwicklungsprozesse

Reparieren oder entfernen Sie Schwachstellen

Google räumt ein, dass das allgemeine Problem der Reparatur außerhalb seines Zuständigkeitsbereichs liegt, aber Der Verlag ist der Ansicht, dass die Akteure noch viel mehr tun können, um das Problem anzugehen spezifisch für die Verwaltung von Schwachstellen in Abhängigkeiten.

Es erwähnt auch: 

„Heute gibt es an dieser Front wenig Hilfe, aber da wir die Genauigkeit verbessern, lohnt es sich, in neue Prozesse und Werkzeuge zu investieren.

„Eine Möglichkeit besteht natürlich darin, die Sicherheitsanfälligkeit direkt zu beheben. Wenn Sie dies abwärtskompatibel tun können, steht die Lösung allen zur Verfügung. Die Herausforderung besteht jedoch darin, dass Sie wahrscheinlich keine Erfahrung mit dem Problem oder der direkten Fähigkeit haben, Änderungen vorzunehmen. Das Beheben einer Sicherheitsanfälligkeit setzt auch voraus, dass die für die Wartung der Software Verantwortlichen das Problem kennen und über das Wissen und die Ressourcen verfügen, um die Sicherheitsanfälligkeit offenzulegen.

Quelle: https://security.googleblog.com


Hinterlasse einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert mit *

*

*

  1. Verantwortlich für die Daten: AB Internet Networks 2008 SL
  2. Zweck der Daten: Kontrolle von SPAM, Kommentarverwaltung.
  3. Legitimation: Ihre Zustimmung
  4. Übermittlung der Daten: Die Daten werden nur durch gesetzliche Verpflichtung an Dritte weitergegeben.
  5. Datenspeicherung: Von Occentus Networks (EU) gehostete Datenbank
  6. Rechte: Sie können Ihre Informationen jederzeit einschränken, wiederherstellen und löschen.

  1.   José Antonio sagte

    Das Original in Englisch sagt:

    Hier konzentrieren wir uns auf zwei spezifische Aspekte:

    - Risiken verstehen, wenn Sie sich für eine neue Abhängigkeit entscheiden

    - Verbesserung der Entwicklungsprozesse für kritische Software

    Die Version "LinuxAdictos" sagt:

    Hier schlägt Google vor, sich auf zwei spezifische Aspekte zu konzentrieren:

    - Verstehen Sie die Risiken bei der Auswahl einer neuen Sucht.

    - Verbesserung kritischer Softwareentwicklungsprozesse

    Eine neue Sucht !?