Leitfaden für Praktiker: Sicherheit

Primäre Kennzahlen:

Falls Sie das noch nicht gelesen haben Leitfaden für Praktiker: Einführung – Woran Sie bei der Interpretation von Kennzahlen denken solltenBitte halten Sie jetzt inne und lesen Sie diesen Leitfaden.

Sicherheit ist nur so stark wie ihr schwächstes Glied. Open-Source-Softwarepakete finden sich in fast der gesamten Software, die wir verwenden (Synopsis 2024). Die Sicherheit unserer Open-Source-Projekte kann also weitreichende Auswirkungen auf andere Projekte, unsere Benutzer und das breitere Ökosystem haben.

Sicherheit kann ein wichtiger Faktor bei der Auswahl von Open-Source-Projekten sein, aber die Sicherheit einer Softwarekomponente ist nur so gut wie die Sicherheit ihrer Abhängigkeiten (Imtiaz 2022). Sicherheit ist ein wichtiger Aspekt sowohl bei der Auswahl von Open-Source-Komponenten, von denen Ihr Projekt abhängt, als auch bei der Entscheidung anderer, Ihr Open-Source-Projekt zu verwenden (oder nicht zu verwenden). Bei dieser Auswahl ist es wichtig zu beachten, dass beliebte Pakete nicht mehr oder weniger wahrscheinlich gute Sicherheitspraktiken befolgen (Imtiaz 2022).

Der Synopsys Open Source Security and Risk Analysis Report 2024 ergab, dass 96 % der gescannten Codebasen Open-Source-Software enthielten und leider 84 % davon Schwachstellen aufwiesen (74 % mit einem hohen Schweregrad). Da Open Source allgegenwärtig ist, wirkt sich die Sicherheit von Open-Source-Projekten auf die Gesundheit und Nachhaltigkeit unserer Projekte aus, was sich auf das gesamte Software-Ökosystem auswirkt. Bedenken Sie jedoch, dass Sicherheitsrisiken oft als Funktion von Wahrscheinlichkeit und Auswirkung betrachtet werden können. Die Wahrscheinlichkeit ist das Potenzial für Ausnutzbarkeit und die Auswirkung ist der Schaden, der durch den Exploit im Rahmen der Softwarebereitstellung verursacht werden könnte. Das Risiko muss also jeder Open-Source-Anwender für seinen jeweiligen Kontext, seine Situation und seine Umgebung bestimmen.

Da Sicherheit ein komplexes und kritisches Thema ist, ist dieser Leitfaden nur dazu gedacht, lass dich starten auf Ihrem Weg zur Verbesserung der Sicherheit Ihres Projekts. Es ist kein umfassender Leitfaden zu allem, was Sie über die Sicherheit von Open-Source-Projekten wissen müssen. Das Ziel der Practitioner Guide Series ist es, Menschen durch die Überforderungsphase zu bringen, die viele angesichts einer Vielzahl neuer Kennzahlen empfinden, und ihnen dabei zu helfen, Wege zu finden, um die Gesundheit ihrer Projekte zu verstehen und zu verbessern. Nachdem Sie mit diesem Practitioner Guide begonnen haben, können Sie über Links zu den umfassenden Leitfäden im Abschnitt „Weitere Lektüre“ weiter unten und über Links in diesem Leitfaden mehr erfahren.

Schritt 1: Trends identifizieren

Sicherheit ist ein komplexes Thema, aber Sie können mit einem Blick auf einige Schlüsselmetriken beginnen. Erstens: Abzeichen für bewährte OpenSSF-Praktiken Kriterien schaffen eine gute technische Grundlage, die grundlegende Sicherheitspraktiken beinhaltet. Zweitens ist die Wahrscheinlichkeit von Sicherheitsproblemen viermal so hoch, wenn Sie veraltete Abhängigkeiten verwenden (Cox et al. 2015). Daher ist die Verwendung der Libyears Metrik kann Ihnen helfen zu verstehen, ob Sie Ihre Abhängigkeiten auf dem neuesten Stand halten. Drittens, Release-Frequenz hilft dabei einzuschätzen, ob Ihre Sicherheitsfixes und anderen Updates rechtzeitig in einer Version verfügbar sind, sodass Ihre Benutzer von Ihren Sicherheitsupdates profitieren können.

Best Practices für OpenSSF

Die Open-Source-Sicherheitsstiftung (OpenSSF) bietet Möglichkeiten, Ihr Open-Source-Projekt in einer Reihe verschiedener Dimensionen zu bewerten, um eine Übersicht darüber zu erhalten, wo die Praktiken Ihres Projekts verbessert werden können. Während Sicherheitspraktiken eine wichtige Komponente sind, OpenSSF Best Practices-Abzeichen geht über reine Sicherheit hinaus und schlägt eine Reihe von Best Practices für Ihr Projekt vor. Dies ist nicht nur eine gute Möglichkeit, Ihre Sicherheitspraktiken zu bewerten und sie zu verbessern, um die Badge-Kriterien zu erfüllen, sondern es signalisiert Ihren Benutzern auch, dass Sie die Best Practices von OpenSSF befolgen. Die Kriterien in den Abschnitten Berichterstattung, Sicherheit und Analyse sind diejenigen, die am besten geeignet sind, um die Sicherheit Ihres Projekts zu verstehen und zu verbessern.

Öffnen Sie das SSF-Abzeichen. Beispiel eines goldenen Abzeichens aus dem Curl-Projekt.

Bildquelle: https://www.bestpractices.dev/en/projects/63

Libyears

Die Libyears Die Metrik gibt das Alter der Abhängigkeiten an, auf die Sie sich verlassen, im Vergleich zu den aktuellen stabilen Versionen dieser Abhängigkeiten. Sie wurde erstmals in „Measuring Dependency Freshness in Software Systems“ (Cox et al. 2015) vorgeschlagen. Im Allgemeinen ist eine niedrigere Libyear-Zahl besser, da sie anzeigt, dass Sie Ihre Abhängigkeiten auf dem neuesten Stand halten.

Libyear-Beispiel eines Projekts, das 103.78 Jahre im Rückstand ist

Bildquelle: https://github.com/nasirhjafri/libyear

Indem Sie die aktuelle Version einer in Ihrem Projekt verwendeten Abhängigkeit mit der neuesten verfügbaren Version jeder Abhängigkeit vergleichen, können Sie besser erkennen, wo Sie bei der Aktualisierung Ihrer Abhängigkeiten möglicherweise sorgfältiger vorgehen müssen. Die technische Verzögerung bei der Aktualisierung von Abhängigkeiten entsteht jedoch häufig durch die Spannung zwischen der Verwendung der neuesten Version und der Vermeidung der Beschädigung einer bereits gut funktionierenden Lösung. In einigen Fällen entscheiden sich Entwickler daher aufgrund von Inkompatibilitäten oder anderen technischen Problemen bewusst für die Verwendung einer älteren Version anstelle der neuesten Version (Zerouali et al. 2019).

Release-Frequenz

Es ist wichtig, dass Sicherheitsupdates, Bugfixes und neue Features zeitnah veröffentlicht werden. Bei der Veröffentlichungshäufigkeit ist es wichtig, nicht nur die großen Veröffentlichungen, sondern auch alle kleinen Point-Releases zu berücksichtigen, da dringende Sicherheitsfixes normalerweise außerhalb der Hauptversionen veröffentlicht werden.

![Release-Frequenz eines Projekts mit häufigen Releases][https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/images/releases.png?raw=true]

Beachten Sie, dass die Interpretation dieser Metrik eine Herausforderung sein kann, da unterschiedliche Projekttypen und unterschiedliche Situationen Einfluss darauf haben können, ob das Projekt häufiger oder weniger häufig veröffentlicht werden muss. Eine konsistente Veröffentlichungsfrequenz kann auf ein stabileres oder ausgereifteres Projekt hinweisen.

Schritt 2: Diagnose

Ein guter Ausgangspunkt zur Diagnose potenzieller Probleme mit den Sicherheitspraktiken Ihres Projekts ist die Arbeit mit den OpenSSF-Projekt-Badging-Kriterien. Während der Arbeit wird es wahrscheinlich ungefähr so ​​aussehen wie dieses Beispiel:

OSSF-Badging-Kategorienliste für ein Projekt, das auf ein Badge hinarbeitet, aber noch mehr Arbeit vor sich hat

Bildquelle: https://www.bestpractices.dev/en/projects/40

Wie bereits erwähnt, umfasst dies bewährte Sicherheitsmethoden, aber auch allgemeinere bewährte Methoden der Softwareentwicklung, um Ihr Projekt auf verschiedene Weise zu verbessern. Unter jedem dieser Vorschläge finden Sie Fragen, die Sie beantworten müssen, sowie die erforderlichen Kriterien zum Erhalt des Badges.

Hier sind beispielsweise einige der Fragen im Abschnitt „Sicherheit“:

OSSF-Badging-Kriterien aus dem Sicherheitsbereich für MITM-Angriffe und Schwachstellen behoben

Egal, ob Sie sich entscheiden, das Abzeichen anzustreben oder nicht, die Kriterien Die verwendeten Methoden, insbesondere in den Abschnitten Sicherheit und Berichterstellung, sind eine gute Möglichkeit, darüber nachzudenken, wie Sie die Sicherheit Ihres Projekts verstehen und verbessern können. Es gibt auch andere Möglichkeiten, Sicherheits-Selbstbewertungen für Ihre Projekte durchzuführen, einschließlich der Selbsteinschätzung, dass die CNCF für ihre Projekte verwendet werden.

Der nächste Diagnoseschritt könnte darin bestehen, Ihren Libyears-Bericht zu überprüfen und sich dabei auf die Abhängigkeiten zu konzentrieren, die am veraltetesten sind. Wenn Sie veraltete Abhängigkeiten verwenden, ist die Wahrscheinlichkeit von Sicherheitsproblemen viermal so hoch (Cox et al. 2015). Daher ist es ein wichtiger Faktor zur Verbesserung der Sicherheit Ihres Projekts, Ihre Abhängigkeiten auf dem neuesten Stand zu halten. Wie bereits erwähnt, gibt es manchmal gute Gründe dafür, dass eine Abhängigkeit hinter der aktuellen Version zurückbleibt: schwerwiegende Änderungen, Inkompatibilitäten mit Ihrer Software/anderen Abhängigkeiten oder andere technische Probleme. Die Diagnose in diesem Fall erfordert eine sorgfältige und gründliche Prüfung, ob es einen guten Grund gibt, eine Abhängigkeit nicht zu aktualisieren.

Um zu diagnostizieren, ob Sie zeitnahe Releases herausbringen, sollten Sie sich die Sicherheitspatches ansehen, die Sie im letzten Jahr erstellt haben. Wenn Sie ein Release ungefähr zu dem Zeitpunkt herausgebracht haben, zu dem Sie alle Sicherheitspatches veröffentlicht haben, sind Sie wahrscheinlich in ziemlich guter Verfassung. Wenn sich die Sicherheitspatches angehäuft haben und nicht in einem Release veröffentlicht wurden, sollten Sie wahrscheinlich untersuchen, warum das passiert ist, und prüfen, ob Sie Ihren Releaseprozess verbessern können, um häufiger Releases herauszubringen, wenn Sie Schwachstellen beheben.

Schritt 3: Sammeln Sie bei Bedarf zusätzliche Daten

Die in den Schritten 1 und 2 verwendeten Beispiele bieten einen Ausgangspunkt, der durch den Einsatz zusätzlicher Tools und Metriken erweitert werden kann. Ein guter nächster Schritt im Diagnoseprozess wäre, auch den OpenSSF-Scorecard, das sehr detailliert auf Prüfungen eingeht, die Ihnen dabei helfen, Bereiche zu finden, in denen Ihr Projekt in den Kategorien Quellcode, Build, Abhängigkeiten, Tests und Projektwartung anfällig sein könnte.

Möglicherweise fällt Ihnen auf, dass in diesem Handbuch keine Metrik enthalten ist, die sich auf die Zeit zum Beheben von Sicherheitslücken konzentriert. Diese ist sehr wichtig, aber schwierig zu messen, da Sie in der Lage sein müssen, die Sicherheitsprobleme von Bugs und anderen Problemen zu trennen und gleichzeitig den ursprünglichen Bericht über die Sicherheitslücke mit den Änderungsanforderungen zu verknüpfen, in denen die Korrektur vorgenommen wurde. Es gibt viele Möglichkeiten, dies zu tun, aber wie Sie es tun, hängt von Ihren Tools ab. Obwohl dies möglicherweise nicht die beste Metrik für den Anfang ist, sollten Sie die Messung als einen Ihrer nächsten Schritte in Betracht ziehen. Die folgenden zusätzlichen Metriken bieten einen guten Ausgangspunkt für die Messung.

Zusätzliche Metriken:

Schritt 4: Nehmen Sie Verbesserungen vor

Einer der besten Ausgangspunkte bei der Verbesserung Ihrer Sicherheitspraktiken ist die Sicherung Ihres Code-Repositorys. Dazu gehören die Verwaltung des Zugriffs, der Schutz von Zweigstellen, die Verwaltung von Beiträgen und vieles mehr. Die Bewährte Methoden für die Konfiguration der OpenSSF-Quellcodeverwaltungsplattform Der Leitfaden enthält eine Liste mit Vorschlägen und Links zur Implementierung sowohl für GitHub als auch für GitLab.

Ein weiterer guter Ausgangspunkt ist die Erstellung eines detaillierten Sicherheitsrichtliniendokuments für Ihr Projekt. Dieses finden Sie normalerweise in einem SICHERHEIT.md Datei im Stammverzeichnis Ihres Repositorys. Der Zweck dieses Dokuments besteht darin, Anweisungen zum Melden von Sicherheitslücken bereitzustellen und zu dokumentieren, wie Sie auf diese Berichte reagieren, einschließlich der Verwaltung Embargos. Dieses Dokument hilft Ihnen dabei, die Anforderungen für die Berichtskriterien des OpenSSF Best Practices Badge zu erfüllen. Es gibt viele Orte, an denen Sie detaillierte Anweisungen zum Erstellen von Sicherheitsrichtlinien finden können, daher werden wir diese Details hier nicht wiederholen. Zum Beispiel das OpenSSFs OSS-Sicherheitsleitfaden enthält weitere Einzelheiten darüber, was diese Datei enthalten sollte, sowie Vorlagen und Anweisungen zur Implementierung einer Sicherheitsrichtlinie, die über die bloße Erstellung des Dokuments hinausgeht und Einzelheiten zur Infrastruktur und anderen Anforderungen für die Verwaltung des Sicherheitsprozesses enthält.

Wie bereits erwähnt, ist die Wahrscheinlichkeit von Sicherheitsproblemen viermal so hoch, wenn Sie veraltete Abhängigkeiten verwenden (Cox et al. 2015). Daher ist es wichtig, Ihre Abhängigkeiten auf dem neuesten Stand zu halten, um die Sicherheit Ihres Projekts zu verbessern. Abhängigkeiten erfordern eine sorgfältige und gründliche Prüfung, ob es einen guten Grund gibt, eine Abhängigkeit nicht zu aktualisieren, sowie das Testen neuerer Versionen, um sicherzustellen, dass Sie beim Aktualisieren einer Abhängigkeit nichts anderes beschädigen. Obwohl es gute Gründe gibt, die Aktualisierung bestimmter Abhängigkeiten zu vermeiden, werden Abhängigkeiten in den meisten Fällen nicht aktualisiert, da es schwierig sein kann, den Überblick darüber zu behalten, wann sie aktualisiert werden sollten. Ein Tool wie Dependabo or Renovatebot kann helfen, bestimmte Abhängigkeiten zu identifizieren und automatisch zu aktualisieren.

Eine gute Dokumentation von Sicherheitsfixes kann dazu beitragen, das Bewusstsein für verfügbare Sicherheitsfixes zu schärfen (Imtiaz et al. 2022), und es ist wichtig, sicherzustellen, dass diese Fixes zeitnah in einer Version landen. Wenn Sie häufig Sicherheitspatches erstellen, diese aber nicht schnell in eine Version aufnehmen, sollten Sie sich wahrscheinlich ansehen, warum das so ist, und prüfen, ob Sie Ihren Veröffentlichungsprozess verbessern können, um häufigere Versionen zu veröffentlichen, wenn Sie Schwachstellen beheben. Es ist auch wichtig, dass Ihre Versionshinweise oder andere Dokumentationen Details zu den Sicherheitsfixes enthalten, um die Bedeutung der Aktualisierung für die Benutzer Ihrer Software hervorzuheben.

Wie bereits erwähnt, ist das Durcharbeiten der OpenSSF Best Practices-Abzeichenkriterien eine gute Möglichkeit, Sicherheitsverbesserungen vorzunehmen. Die Detailansicht der Kriterienseite für alle Level enthält Erklärungen und Links mit weiteren Einzelheiten, die Ihnen helfen können, sich in jedem dieser Bereiche zu verbessern.

Schritt 5: Ergebnisse überwachen

Da Sicherheit ein so komplexes Thema ist, kann es schwierig sein, es zu überwachen. Es gibt jedoch einige Dinge, die Sie im Laufe der Zeit überwachen können, um zu sehen, ob die Maßnahmen, die Sie zur Verbesserung Ihrer Sicherheit ergriffen haben, Auswirkungen haben. Hier sind einige Vorschläge zur Überwachung Ihres Fortschritts:

  • OpenSSF-Scorecard: Hat sich Ihr Gesamtergebnis verbessert? Haben Sie Ihr Ergebnis in einigen der einzelnen Bereiche verbessert, in denen Sie Verbesserungsbedarf festgestellt haben?
  • Libyears: Hat sich Ihre Libyear-Nummer verbessert?
  • Veröffentlichungen: Erstellen Sie jedes Mal eine Veröffentlichung, wenn Sie einen Sicherheitspatch erstellen?

Vorsichtsmaßnahmen und Überlegungen

  • Da Sicherheit ein kritisches Thema ist, dient dieser Leitfaden nur dazu, lass dich starten auf Ihrem Weg zur Verbesserung der Sicherheit Ihres Projekts. Es ist kein umfassender Leitfaden zu allem, was Sie über die Sicherheit von Open-Source-Projekten wissen müssen. Weitere Informationen finden Sie unter den Links im Abschnitt „Weitere Lektüre“ weiter unten.
  • Möglicherweise fällt Ihnen auf, dass es in diesem Handbuch keine Metrik gibt, die sich auf die Zeit zum Beheben von Sicherheitslücken konzentriert. Diese ist sehr wichtig, aber schwierig zu messen. Daher empfehlen wir, diese Metrik als einen Ihrer ersten nächsten Schritte einzubeziehen. Weitere Einzelheiten finden Sie in Schritt 3.

Zusätzliche Lektüre

  • OpenSSF-Website enthält eine große Vielfalt an sehr ausführlichen Anleitungen, Schulungen und anderen Ressourcen.
  • Die CNCF-Sicherheitsrichtlinien Das Dokument ist wesentlich weniger umfassend als die OpenSSF-Anleitungen, könnte aber hilfreicher sein, wenn Sie gerade erst damit beginnen, Ihre Sicherheit zu verbessern.
  • OpenSSFs OSS-Sicherheitsleitfaden enthält einen Leitfaden sowie Vorlagen und ein Runbook, das sich auf die Entwicklung und Implementierung einer Sicherheitsrichtlinie konzentriert.

Feedback

Wir würden uns über Feedback freuen, um mehr darüber zu erfahren, wie Menschen die CHAOSS Practitioner Guides nutzen und wie wir sie im Laufe der Zeit verbessern können. Bitte füllen Sie dies aus kurze Umfrage um Ihr Feedback abzugeben.

Mitwirkende

Die folgenden Personen haben zu diesem Leitfaden beigetragen:

  • Morgenröte
  • Matt Germonprez
  • Emil Fuchs

Referenzen

CHAOSS Practitioner Guides sind MIT-lizenzierte, lebendige Dokumente und wir freuen uns über Ihr Feedback und Ihren Input. Sie können Änderungen an diesem Dokument vorschlagen unter https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/security.md