Open-Source-Schwachstellen und Sicherheit mit Jeff McAffer von Microsoft

Zum Ende des Jahres 2019 blicken wir auf einige großartige Folgen unseres Podcasts The Secure Developer zurück. Den ersten Beitrag finden Sie hier.

Der Podcast The Secure Developer ist Teil unserer herstellerneutralen Community MyDevSecOps, die sich auf Security Education konzentriert. Die Community, die früher auch als The Secure Developer bekannt war, trifft sich virtuell in unserer Slack-Gruppe und bei virtuellen Events sowie persönlich bei DevSecCon-Events auf der ganzen Welt.

Über unseren Gast

Jeff McAffer ist Direktor des Open Source Programs Office von Microsoft. In dieser Funktion leitet er das Open Source Programs Office und treibt Richtlinien, Prozesse, Tools und einen Kulturwandel im gesamten Unternehmen voran – zu einer Zeit, in der Microsoft seine Sicht auf Open Source verändert. Vor Kurzem war er zu Gast im Podcast The Secure Developer, um über Folgendes zu sprechen:

• Security-Prozesse optimieren

• Schwachstellenmanagement

• Verantwortung für Open Source und mehr

Heute möchten wir die wichtigsten Erkenntnisse aus unserem Gespräch mit Jeff teilen.

Prozesse optimieren

Die zwölf Mitglieder von Jeffs Team haben daran gearbeitet, den Open-Source-Prozess bei Microsoft nach dem Motto „eliminieren, automatisieren, delegieren“ zu optimieren. Das bedeutet:

• Eliminieren:Das Team beseitigt nach Möglichkeit alle Richtlinien, Fragen oder Reibungspunkte, die sich identifizieren und beheben lassen.

• Automatisieren: Das Team erstellt Richtlinien, die weitgehend automatisiert sind, Daten und Kontext verarbeiten und ein Ergebnis liefern können.

• Delegieren: Identifiziert das Team ein Risiko, für das externe Einschätzungen nötig sind, delegiert es die Aufgabe an Dritte mit einschlägiger Expertise, etwa an einen Anwalt oder ein stärker geschäftsorientiertes Teammitglied.

Laut Jeff hat dieser Workflow, weg vom Modell „Anfrage und Genehmigung“ und hin zu „Registrieren und prüfen“, viel bewirkt: „Durch Integrationen in unsere Build-Systeme, diese automatisierten Richtlinien und gute Daten werden inzwischen etwa 99 % unserer Open-Source-Nutzung automatisch erkannt und ohne menschliches Zutun durch unsere Richtlinien-Engines verarbeitet.“

Auch wenn Systeme so weit wie möglich automatisiert werden, sind die Tools nicht perfekt – wie Jeff sagt: Menschen sind Menschen und Tools sind Tools. Deshalb ist es wichtig, einen Sicherheitsplan parat zu haben, um auf möglicherweise auftretende Schwachstellen zu reagieren.

Schwachstellen berücksichtigen

Microsoft verfolgt bei der Sicherheit zwei unterschiedliche Ansätze:

• Aktive Entwicklung: Die erste Gruppe von Sicherheitskomponenten konzentriert sich auf die aktive Entwicklung. Wird eine Komponente mit einem Sicherheits- oder Lizenzproblem hinzugefügt, wird dies gemeldet, das Team benachrichtigt und kann anschließend tätig werden.

• Incident Response: Wird eine Schwachstelle mit hohem Schweregrad offengelegt, übernimmt das Security Incident Response Team und trifft auf Grundlage der verfügbaren Informationen eine Entscheidung. Ob Alarm ausgelöst wird, hängt von der jeweiligen SLA-Definition ab.

Diese Ansätze decken die meisten Anwendungsfälle ab. Jeff zufolge lohnt es sich dennoch zu fragen: „Welche besseren Informationen zur Risikobewertung können wir bereitstellen? Wie kann ich als Nutzer erkennen, ob ich gefährdet bin?“ Bei Snyk teilen wir diese Fragen (und unsere Tools helfen Ihnen dabei, jederzeit Schwachstellen in Ihren Abhängigkeiten zu erkennen). So können Unternehmen beim Umgang mit Schwachstellen vollständige Transparenz schaffen und Erfolge dabei nachweisen.

Schwachstellen proaktiv zu melden – ob über die standardmäßigen CDEs oder auf anderem Weg – ist verantwortungsvoll und zeugt von Respekt gegenüber der gesamten Open-Source-Community. Das gehört zur Verantwortung als Open-Source-Maintainer. Wenn Sie Open-Source-Komponenten verwenden, empfiehlt Jeff, Verantwortung für diese Komponenten zu übernehmen, indem Sie zugehörige Schwachstellen nachverfolgen und melden, während Sie den Code weitergeben.

Mehr Verantwortung für Open Source

In ähnlicher Weise hat Microsoft ClearlyDefined.io ins Leben gerufen, um gemeinsam Lizenzdaten zusammenzutragen – genauso wie Unternehmen daran arbeiten, Schwachstellen besser zu erkennen. In dieser Community können Nutzer schwer auffindbare Lizenzen und Urheberrechtsinhaber ergänzen, damit die Informationen so aktuell wie möglich sind.

ClearlyDefined wird wie jeder andere Open-Source-Beitrag geprüft und anschließend in die Definitionen von Open-Source-Komponenten übernommen. Idealerweise fließen die Angaben in die ursprünglichen Komponenten ein, damit künftige Versionen „klarer definiert“ sind.

Wie Jeff erklärte: „Viele denken immer noch: ‚Es ist Open Source. Ich nehme es einfach, benutze es, und das war's.‘ Aber Sie müssen es wirklich wie Ihren eigenen Code behandeln. Selbst wenn Sie keinen Code dafür schreiben und die Programmiersprache nicht kennen, müssen Sie es als Teil Ihres Systems betrachten und sich um dessen Sicherheit kümmern. Außerdem müssen Sie mit den Teams hinter dem Produkt und dem Projekt zusammenarbeiten und fragen: ‚Wie können wir das gemeinsam umsetzen? Wie machen wir daraus ein sicheres Projekt, das wir alle sicher nutzen können?‘“ Wir stehen voll und ganz hinter diesem Verständnis von Verantwortung für Open Source.

MyDevSecOps engagiert sich dafür, hervorragende Speaker wie Jeff McAffer sowohl zu unseren virtuellen Veranstaltungen als auch in unseren Podcast The Secure Developer einzuladen. Wenn Sie mehr über die verschiedenen Aspekte der Sicherheit erfahren möchten, sollten Sie der Community beitreten.