Microsoft erweitert Githubs integrierte Vulnerability Management Fähigkeiten
Software eats the world - Microsoft eats Software?
Mit der Übernahme von Github hat Microsoft ein klares zeichen gesetzt, dass es seinen Führungsanspruch in der Gestaltung von Software nicht nur erhalten, sondern ausbauen will. Mit den nun in aller Eile geschaffenen Vulnerability-Werkzeugen in Github untermauert Microsoft seinen Anspruch als Platzhirsch in der Software-Entwicklung.
Github hat mit seiner erfolgreichen Mirror-Strategie den Anspruch als quasi-Standard-Repository für Software erfolgreich platzieren können. Neben einer stabilen und smarten Versionierungs- und Synchronisationslösung für Quellcode hat das Mirroring sämtlicher Open-Source-Projekte dazu beigetragen, das Gefühl von Größe geschickt zu vermitteln. Github wurde der Platz, an dem man Software findet.
Microsoft hat dies erkannt. Zudem haben Satya Nadella – und/oder sein Team – erkannt, welche Themen gerade in der Software-Entwicklung Relevanz entwickeln. Nachdem sich mit IoT letztlich Software in alle Arten von Gegenständen verbreitet, bekommen Schwachstellen (Vulnerabilities) und rechtliche Konformität (legal Compliance) eine erheblich höhere Bedeutung.
Mit Macht besetzt Microsoft nun dieses Thema. Durch die Übernahme von Github hosted Microsoft über Nacht einen Großteil der offenen Quellcodes dieser Welt. Die Software-Industrie hat mit CI/CD-Lösungen schon viel für ihre Qualitätssicherung getan und diese nahtlos an Github angeschlossen. Immerhin gibt es in diesem Segment noch eine handvoll alternative Lösungen.
Das leidige Thema „Schwachstellen- und Patch-Management“ ist derzeit noch etwas unsortiert, da es zum einen keiner gerne macht, zum anderen auch ein sehr zähes und unproduktives Geschäft ist. Dennoch haben Equifax und andere Fälle eindringlich aufgezeigt, was Folgen des Unterlassens sein können. Also beschäftigt sich inzwischen jeder notgedrungen damit.
Mit den in den letzten Wochen bekanntgegebenen Lösungen rund um das Multi-Language-Package-Management, die freien Vulnerability-Alerts – jetzt auch gestützt durch die Whitesource Vulnerability-Database für Enterprise Kunden — und durch die Übernahme von Dependabot – für eine Versionskontrolle á la Versioneye – stopft Microsoft diese Lücke und zementiert somit die Führungsposition von Github als Heimat allen Quellcodes.
Wer sollte sich jetzt noch mit diesen leidigen Aufgaben beschäftigen wollen, wenn er sie quasi freihaus durch ein Hosting bei Github erledigt bekommt? Vermutlich nur Verschwörungstheoretiker und Technikverliebte.
Letzten Endes bleibt es eine Vertrauenssache, wem man zutraut, die richtigen Abhängigkeiten bzw. Vulnerabilities zu identifizieren:
- Werden hier meine tatsächlich zum Einsatz kommenden Abhängigkeiten analysiert oder dient nur das Original als Vorlage für die Alarme?
- Können die aufgezeigten Vulnerability-Alerts tatsächlich einen Mehrwert bringen oder erzeugen sie aufgrund des hohen Lärmpegels, der mit meiner Bedrohungssituation nichts mehr zu tun hat nur ein ohrenbetäubendes Rauschen, welches meine Entwickler von der Arbeit abhält?
Die Antworten zu diesen Fragen werden die nächsten Monate liefern. Ansatz und Ambition dieses Schrittes erscheinen mir jedoch brillant! Wesentlich substanzieller als die bereits überraschende Übernahme von RedHat durch IBM.
Wenn man Einfluss und Informationsgewinn vergleicht, erschient die Cost-Impact-Ratio bei MS etwas günstiger auszufallen. Unabhängig davon verfügt Microsoft über hinreichend Capability to achieve, um das Vorhaben mittelfristig zu einem Erfolgsmodell zu drehen und den Platz als „Heimat allen Quellcodes“ zu behaupten. Was das wiederum für die Offenheit von Open Source bedeutet, mag jeder für sich selbst beurteilen.
Was bedeutet das für TrustSource?
Kurz nach dem Announcement haben mich erste Kunden gefragt, was das für uns bedeutet. Nach einiger Überlegung bin ich zu dem Schluss gekommen, dass uns diese Ergebnisse das Leben einfacher machen werden.
Zum einen ist die Maintenance so vieler Package-Manager – wir unterstützen derzeit 13 – auf Dauer ein aufwändiges Unterfangen. Open Source hin oder her, am Ende liegt die Maintenance dennoch beim Hauptsponsor.
Zum anderen erwarten wir eine verbesserte Informationslage aus den neue APIs. Derzeit ist die Information mehr als oft noch gruselig dürftig. Die Option, das Vulnerability-Assignment uns schenken zu können, ließe uns jubeln. Ich sehe das zwar noch nicht, da die Grundlage für das Vulnerability-Assignment neben einer sehr
Zudem fokussiert TrustSource auf den Compliance-Aspekt. Wir bieten eine OpenChain-konformen Prozess, samt Policy-Propagation, Trainings, einer automatisierten Legal-Analyse, die Compliance-Artefakt-Generierung, und und und. Das sind Berge von Aufgaben, die auch ein Clearly Defined nicht abbildet.
Auch erscheint mir eine Repository-basierte Analyse von Schwachstellen und Abhängigkeiten nicht unbedingt geeignet, den Lebenszyklus und die rechtliche Eignung einer Komponente im Anwendungskontext zu beurteilen. Immerhin ergibt sich die Eignung der Komponente nicht aus dem Repository, sondern dem gewählten Einsatzzweck in Verbindung mit einem kommerziellen Kontext. Dies lässt sich auf Repository-Ebene schlicht nicht abbilden.
Wir freue uns daher darauf, in den kommenden Monaten die neuen APIs zu integrieren, damit (hoffentlich) unseren Kunden eine verbesserte Informationslage zu bieten und ggf. die letzte Lücke in der Kette der Software-Herstellung zu schließen. Zudem unterstreicht es unsere Auffassung, dass wir in einem relevanten Segment aktiv sind, dass derzeit viel in Bewegung ist.
Sie wollen Ihre Open Source Compliance stärken, wissen aber nicht, wie starten?
Reflexion BFOSS 2018
Das war sie nun, gestern, die BFOSS 2018. Beachtlich, wie voll der Erfurter Kaisersaal geworden ist. Gegenüber dem letzten Mal ist wiederum eine erhebliche Steigerung der Teilnehmerzahl festzuhalten. Das entspricht dem gefühlten Druck, der zunehmend auf dem Thema liegt.
Ausgehend von einer Einführung in die Problematik wurden durch die Redner unterschiedliche Erfahrungen und Ansätze vorgestellt, wie sich Herstellerfirmen den Herausforderungen der OS-Governance (OSG) nähern. Mit 8 Vorträgen war das Programm voll und intensiv.
Interessant war zu sehen, dass sich die vorgestellten Ansätze zwar in Fokus, Gestaltungstiefe und jeweiliger Ausführung unterschieden, jedoch in der Ambition und dem Lösungsprozess vergleichbar sind:
- Integration der Governance in die Tool- bzw. Build-Chain (Fail-fast)
- Automatisierung bei der Analyse der relevanten Lizenzinformationen
- Möglichst automatisierte Komposition der BoM
- Bereitstellen einmal ermittelter Informationen für spätere Nutzung
Erstaunlich war für mich, wie wenig Fokus auf den Governance-Prozess an sich gelegt wurde. Das mag zum einen an den nach wie vor hohen fachlichen Anforderungen an die Werkzeuge liegen, die noch zu lösen sind. Zum anderen an den Protagonisten, die ja zumeist aus den technischen Bereichen stammen und sich daher mehr mit der technischen Lösung als mit dem Nachhalten der Ergebnisse beschäftigen.
Sehr erfreulich, insbesondere für uns als TrustSource, ist die übergreifende Erkenntnis, dass dieser Schritt ohne Werkzeugunterstützung nicht abbildbar ist. Aus meiner Sicht ist uns Ansatz, alles rund um die Stellen zu automatisieren, die man kennt und die rote Lampe zu zünden, wenn es manuelles Eingreifen braucht aufgrund der gegenwärtigen Situation vermutlich auch der pragmatische und zuverlässige. Ergänzend zu dieser Betrachtung, wurden darüber hinaus diese drei wesentlichen Herausforderungen immer wieder unterstrichen:
- Einführung von Open-Source Governance ist eine Aufgabe für sich. Obwohl es eigentlich eine Selbstverständlichkeit sein sollte, wie das Händewaschen oder das Verständnis, niemandem etwas wegzunehmen, so ist die Notwendigkeit von IP-Schutz / OSG doch nicht allen präsent. Diese Bewusstseinsbildung ist in einer Organisation ein harter und zäher Prozess, der viel Aufmerksamkeit erfordert.
- Informationslage ist oft unzureichend. Software-Entwickler sind keine Rechtsanwälte und dementsprechend sind stellenweise die Grundlagen für die rechtssichere Nutzung, bzw. Bereitstellung von Komponenten gar nicht hinreichend vorhanden. Aus den Gesprächen lässt sich eine Tendenz ableiten, je hardware-näher bzw. älter die Komponenten, desto aufwänder die Aufbereitung der erforderlichen Information.
- Unternehmensübergreifende Zusammenarbeit wird zum Thema. Zwar kam eine Großzahl der Vorträge aus dem Siemens/Bosch-Umfeld, jedoch lies sich generell der Wunsch nach mehr Unterstützung in der Governance-Arbeit vernehmen. Dabei wurden unternehmensübergreifende Ansätze für Repositories wie bspw. ClearlyDefined in den Fokus gerückt. Folgerichtig hat sich der AK Open Source des Bitkom dieses Thema auch als Fokus für nächstes Jahr vorgenommen.
Gerade der letzte Aspekt wurde auch in den vergangenen Monaten bereits des öfteren diskutiert. Grundsätzlich ist die Idee gut, Open Source-Mechanismen zu nutzen, um Open Source besser zu organisieren. Aber was bedeutet das?
Shared clearing - Gedankensammlung
Im Grunde genommen geht es primär um das „Clearing“ der Lizenzinformationen für das Notice-File, also die Begleitinformation, die einem Produkt, welches Open Source einsetzt, beigelegt werden muss, um die Nutzungsrechte an der eingesetzten Software sicherzustellen.
Das Konzept
Hierbei sind aufgrund der nicht standardisierten Grundlage und den stellenweise unklaren, unvollständigen oder auch fehlerhaften Lizenzbedingungen der ggf. zum Einsatz kommenden OS-Artefakte erhebliche Klimmzüge zu veranstalten, um eine rechtlich korrekte Dokumentationslage als Einsatzvoraussetzung zu schaffen.
Die Idee ist nun, dass ein Unternehmen A nach den Klimmzügen die Früchte seiner Arbeit einem crowd-sourcing-artigen Gremium überträgt und somit den anderen Unternehmen diese Arbeit abnimmt. Analog könnte das partizipierende Unternehmen aus dem bereitgestellten Pool schöpfen, um sich selbst Arbeit zu ersparen. Wenn der Pool öffentlich wäre, gäbe es hier auch keine wettbewerbsbeschränkenden Aspekte zu beachten.
Vertrauen als Basis
Dieser Ansatz erfordert jedoch nicht nur die Bereitschaft, seine Arbeitsergebnisse zu teilen, es erfordert auch Vertrauen. B muss A vertrauen, dass er seine Arbeit richtig und vollständig gemacht hat. Andernfalls müsste B die Ergebnisse von A zumindest noch einmal prüfen, was vermutlich dem eigenen Clearing nicht wesentlich nachsteht, will man es „vollständig“ prüfen.
Alternativ könnte man sich einen mehrstufigen Reifeprozess vorstellen. A stellt eine Ergebnis ein, B prüft es (weniger Aufwand als A) und bestätigt es, wenn die Prüfung erfolgreich ist. Somit könnte C tatsächlich mit recht hohem Vertrauen auf das Ergebnis zugreifen.
Anforderungen an das Clearing
Bleibt die Frage, ob ein Clearing unabhängig vom Anwendungsfall erfolgen kann. Denn das Arbeitsergebnis kann für einen spezifischen Anwendungsfall vollständig „cleared“ sein, für einen anderen noch nicht. Das ergibt sich aus den erheblich abweichenden Anforderungen, die sich aus der Kommerzialisierung, der technischen Nutzung oder der Art der Distribution ergeben.
Da es vermutlich wenige Lizenzen gibt, die eine Dokumentation untersagen, könnte man sich beim Shared-Clearing auch darauf einigen, immer die maximale Dokumentation herzustellen. Das bedeutet, immer für alle Komponenten die alle üblicherweise erforderliche Dokumentation einzufordern. Somit wäre sichergestellt, dass ein einmal eingestelltes Paket, alle Anwendungsfälle abdeckt.
Da dies wiederum erheblich erhöhte Aufwände für den Erstbereitsteller bedeuten könnte, könnte sich diese Forderung negativ auf die . Um dennoch den Ansatz nicht fallen zu lassen, wäre ggf. zu überlegen, ob nicht die Dokumentation des Anwendungsfalles, für den es erzeugt wurde, eine zu wichtige Meta-Information an dem Artefakt wäre. Damit wäre es einem Nutzer möglich, die Eignung bzw. das Risiko für den eigenen Anwendungsfall abzuschätzen.
Haftung im Shared-Clearing
Da der Einsatz hier ja in einem unternehmensübergreifenden Kontext stattfindet, stellt sich die Frage nach der Haftung. Was passiert, wenn B einen Produktrückruf aufgrund des nachweislich unvollständigen, bzw. fälschlichem Clearings durch A zu verkraften hat?
Der natürliche Reflex jedes wirtschaftlich Handelnden ist es, außerordentlichen Aufwände an möglichst an Dritte weiterzureichen. Ist A für diese Information haftbar? Das ist sicherlich etwas, das es im Rahmen des Contributor Agreements zu klären gilt. ClearlyDefined hat dies durch den Open-Source-typischen Haftungsausschluss und eine Schadenslimitierung auf 5 USD. gelöst.
Das ist sicherlich die gute Voraussetzung, um die Bereitschaft für Kontributionen zu erhöhen. Es führt jedoch wieder zur verbleibenden Prüflast seitens des Benutzers. Somit bleibt die Frage offen, welche Arbeit ihm durch die Wiederwendung erspart bleibt. Die Vorstellung den Linux-Kernel einem Clearing zu unterziehen ist sicherlich gruselig. Die Vorstellung, eine als cleared bereitgestellte Version stichhaltig zu prüfen, erscheint mir jedoch nicht weniger gruselig.
Zertifizierung als Ergänzung bzw. Alternative?
Die Idee der verteilten Zusammenarbeit ist zwar gut und passt ins Genre, tangiert jedoch ein Thema, das sich komplett außerhalb dieser Welt bewegt. Dementsprechend schwierig gestaltet sich der Anpassungsprozess.
Möglicherweise wäre eine Zertifizierungsstelle der geeignetere Ansatz? Angenommen es gäbe einen Body, der sich den Schuh der Prüfung bzgl. eines Anwendungsfalles anziehen und eine Garantie für die Vollständigkeit bzw. Korrektheit des Clearings in Form eines Zertifikates abgeben würde.
Hierdurch würden sich die Bedürfnisse beider Welten vereinen lassen. Zum einen ließen sich die Ergebnisse teilen und wiederverwenden, zum anderen wären sie hinreichend überprüf- und belastbar, um tatsächlich Einsparungen zu erzeugen.
Diskutieren Sie mit uns!
Gerne lernen wir Ihre Sicht auf diese Aspekte kennenlernen. Diskutieren Sie mit uns oder teilen Sie uns mit, was Sie für richtig halten.