Transcript
Lisa:
Hallo und herzlich willkommen zu einer weiteren Episode vom INNOQ Security Podcast. Heute möchten wir über Open Source Software und Security sprechen, so als Nachgedanken zu dem Thema Log4Shell, was wir im letzten Jahr schon angeschnitten haben im Adventskalender. Zu Gast habe ich heute Christoph Iserlohn und Stefan Bodewig. Bevor wir anfangen, noch eine kleine Einleitung. Ich habe es eben schon gesagt. Wir haben schon über Log4Shell gesprochen. Solche Arten von Sicherheitslücken mit Open Source Software gab es schon öfter; im Adventskalender hatten wir da einige angesprochen. Hättet ihr noch weitere Beispiele für Sicherheitslücken in Open Source Software?
Christoph:
Ja, da gibt es ganz viele. Die begegnen einem ja sozusagen täglich die Sicherheitslücken in Open Source Software, was auch schlicht und ergreifend daran liegt, dass es so viel Open Source-Software gibt. Aber wir können versuchen das einzuschränken. Auf Lücken, die so eine ähnliche Popularität erreicht haben wie Log4Shell, wir machen den Rückgriff unter anderem, darum und hatten Log4Shell wahrscheinlich auch vorher im Podcast, weil das so weitreichende Auswirkungen hatte. Nicht jede Lücke im Open Source Software hat solche Auswirkungen, sondern wahrscheinlich eher die wenigsten. Aber man sieht das in letzter Zeit ein bisschen gehäuft, dass sehr populäre Sachen doch Probleme haben in Sachen Security. Als Beispiel würde ich noch den UAParser.js nenne, das ist ein NPM-Paket, was gekapert wurde und was in einer neueren Versionen Malware mit installiert hat. Und als zweites was sozusagen ganz frisch ist, sind die Pakete color.js und faker.js. Die nicht direkt Sicherheitslücken hatten, sondern da war es der Fall, dass der Maintainer und Entwickler davon die absichtlich kaputt gemacht haben. Nichtsdestotrotz hatte das schlimme Auswirkungen, weil ganz viele Projekte davon abhängig sind und die waren nach dem Update alle kaputt. Und warum ich das ausgewählt habe als Beispiel liegt auch daran - wenn wir später draufkommen, was man machen kann, ob man auch mehr Geld zahlen sollte oder nicht. Der hatte das nämlich schon vor einer ganzen Zeit so angekündigt, dass die großen Firmen das nicht umsonst nehmen sollten, sondern da sich mehr beteiligen bzw. Geld spenden sollten. Und wenn nicht würde er das nicht mehr so weitermachen. Und das hat er relativ konkret in die Tat umgesetzt, in dem er die Pakete absichtlich kaputt gemacht hat. Hat auf jeden Fall viel Aufmerksamkeit geschaffen für das Thema. Und das prominenteste Beispiel, nicht das prominenteste, aber als diese ganze Sache schon sozusagen zum Ersten richtig hochgekocht ist, war wahrscheinlich Heartbleed, hatten wir schon im Podcast, in den TLS Folgen. Und das ist ja aus dem Jahr 2014 und da ist auch eine extrem kritische Sicherheitslücke aufgefallen. Ich weiß gar nicht, was schlimmer ist, Log4Shell oder Heartbleed oder ob die gleich sind. Die ganze Problematik drumherum sollte spätestens seit Heartbleed klar gewesen sein, aber es hat sich nicht überall so viel verändert bzw. manches hat sich verändert, aber groß im öffentlichen Bewusstsein ist das meines Erachtens noch nicht, nach Heartbleed ist die unbedachte Nutzung von Open Source eher noch deutlich gestiegen, obwohl man daraus hätte lernen können, dass man das nicht zu unbedacht machen sollte.
Lisa:
Wir sehen, es gibt das Problem öfter. Ein paar Beispiele hast du schon genannt. Wir haben heute auch den Stefan hier zu Gast und haben damit die Chance wirklich gut aus dem Nähkästchen zu plaudern was Open Source Entwicklung angeht, weil ihr beiden seid ja Committer bei Open Source Projekten. Stefan ist bei Apache unterwegs und Christoph du bist bei MacPorts unterwegs. Wie ist es bei euch in den Open Source Projekten, wie wird dort mit Sicherheitslücken umgegangen. Gibt es Regeln, und wie sieht generell die Organisation bei euch in den Projekten aus?
Stefan:
Ich fange ein bisschen an, von Apache zu erzählen. Ich bin in einigen Apache Projekten aktiv. Ein paar davon aktiver gewesen in der Vergangenheit als ich das im Moment bin und habe bei Apache Commons Compress und bei Apache jeweils auch CVEs mit begleitet, wo Sicherheitslücken gemeldet worden sind, die mal mehr und mal weniger kritisch waren in dem Fall von Compress waren das mehr so die Denial of Service Attacks, die man damit hätte auslösen können, zumindest nicht die Möglichkeiten Remote Code auszuführen. Aber wo eben Sicherheitslücken gemeldet wurden und wir geschaut haben, dass wir die Lücken schließen und möglichst zügig ein Release rausbringen, um die Lücken zu schließen. Und es hat sich über den Laufe der Zeit auch ein bisschen verändert, wie damit umgegangen wurde. In jedem Fall gibt es bei der Apache Software Foundation ein relativ klar formulierten Prozess wie ein einzelnes Projekt, die Foundation ist eine Stiftung, aber die Projekte haben sehr viel Freiheit, wie sie konkret ihre Prozesse ausgestalten. Es gibt ein paar Dinge, die die Foundation an Unterstützungs Dienstleistungen mitbringt, für die Projekte sozusagen. Eines davon ist ist Apache Security Team. Das sind ein paar Leute, die auch wirklich sonst außerhalb der Open Source Entwicklung, die sie möglicherweise nur als Hobby betreiben, auch einfach sonst Experten im Security Bereich sind. Der Kopf des Apache Security Teams Marc Cox, der arbeitet auch im Security Team von RedHat. Das sind Leute, die sich professionell mit Security auseinandersetzen. Die haben Guidelines verfasst: Wie sollen Projekte mit solchen Dingen umgehen? Und einer der wichtigen Aspekte ist eben ganz zu Anfang, dass man versuchen sollte, Sicherheitslücken direkt dem Security Team und nicht einem Bug Tracker zu melden, damit möglichst lange unbekannt bleibt, dass diese Lücke existiert, um eben eine Chance zu haben, einen Release herauszugeben, der mit einer neuen Version, bevor die Exploits dafür in freier Wildbahn sind. Es gibt einen mehrere Schritte langen Prozess, bei dem man klar regelt: Nimm erst Kontakt mit demjenigen auf der die Sicherheitslücke gemeldet hat. Dann versuchen wir gemeinsam rauszufinden, woran es liegt, wie man das reproduzieren kann, wie man das fixen kann. Wir verifizieren mit dem ursprünglichen Reporter, dass der Fix tatsächlich hilft und dann wird ein Neues Release gemacht, wo der fix enthalten ist. Da kollidiert manchmal schnell sein wollen mit dem, wie die Apache Software Foundation an vielen anderen Stellen tickt so ganz furchtbar tief in. In der Faser der Apache Software Foundation steckt: Jedes Projekt besteht aus einem großen, global verteilten Pool mit mehr oder weniger großen Pool von Menschen, die daran mitentwickeln. Und weil die eben über alle Zeitzonen verteilt sind, kann man nicht einfach innerhalb von zwei Stunden was beschließen, sondern da gibt es eine drei Tage Frist, die bei allen Entscheidungen eingehalten werden muss. Und das würde auch heißen, dass man bei einem Release Mode, wir haben ein neues Release, mit dem wir eine Sicherheitslücke stopfen wollen drei Tage warten muss, bevor das Release wirklich rausgehen kann, bis die Abstimmung durch ist. Das lässt sich in wichtigen Gründen verkürzen, zu mal man sich im Zweifel auch vorab schon koordiniert hat außerhalb der öffentlichen Mailingliste und es klar ist, dass alle mit an Bord sind. Vor acht Jahren glaube ich, habe ich das erste Mal für Commons Compress eine Sicherheitslücke gehabt. Da habe ich ein Committ gemacht und irgendwann drei Tage später haben wir ein Release gemacht und das war alles okay. Im Commit habe ich eben nicht gesagt, ich fixe eine Sicherheitslücke, sondern irgendwas anderes. Ich hab eine Optimierung oder sonst was getan, steht in der Commit Message und dann war das alles gut. Heute ist es tatsächlich eher so, dass ist offensichtlich zumindest bei einigen Projekten genügend Interessierte gibt, die monitoren, was da committed wird und versuchen herauszufinden, ob damit Sicherheitslücken geschlossen werden und daraus dann rückwärts abzuleiten, wie ein Exploit aussehen könnte, so dass das eben schon schwieriger wird, sobald ein Fix in einem öffentlichen Repository steckt, ist die Tür offen für Menschen, die versuchen, das als Hintertür für irgendwas nutzen zu können.
Lisa:
Ich hätte eine Nachfrage gerade. Und zwar hast du eben schon gesagt, dass versucht wird, so lange wie möglich zu verheimlichen, dass diese Sicherheitslücke existiert. Hat Apache Strategien, um den Reporter davon abzuhalten, die Sicherheitslücke zu veröffentlichen, oder wird er einfach an das Gute im Menschen gehofft?
Stefan:
Du bittest die Leute, viel mehr kannst du nicht tun. Und man hat das rund um Log4Shell, nachdem die ersten Fixes da waren, sind noch mehrere kleinere CVEs hinterher gekommen, weil offensichtlich die initialen Fixes nicht vollständig waren. Und ich erinnere mich daran, dass in einem der Fälle der Reporter als Nachricht bekommen hat von dem Logging Projektmanagement Team: Okay, wir haben das gefunden, wir haben den fix für uns und wir werden innerhalb der nächsten Tage ein neues Release rausgeben und er hat tatsächlich diese Mail genommen und ein bisschen anonymisiert und bei Twitter veröffentlicht, dass er etwas gefunden hat und dass es bald eine neue Log4j Version geben wird, die die von ihm gefundene Sicherheitslücke schließen wird. Das ist schon ein sehr seltsames Verständnis von: Ich gebe Sicherheitslücken bekannt, wenn man nicht einmal die Zeit lässt, ein Release auszugeben. Man kann nicht viel tun, außer die Menschen zu bitten, gesunden Menschenverstand walten zu lassen. Klappt nicht immer.
Lisa:
Bei Apache ist das schon sehr durchorganisiert und wir packen nachher auch noch einen Link in die Show Notes, wo es um die Security bei Apache geht. Ist es bei MacPorts auch so strukturiert, durchorganisiert wie bei Apache oder sieht es da anders aus Christoph?
Christoph:
Ja, da muss ich sagen, wir sind leider nicht ganz so professionell organisiert wie Apache, sondern da so ein bisschen der ursprüngliche Hobby Gedanke von Open Source noch ziemlich durchdringt. Hier noch einen kurzen Exkurs für die Hörerinnen Was MacPorts ist, das kennt gar nicht jeder, Apache glaube ich, braucht man nicht so sehr zu erklären, MacPorts schon. MacPorts ist ein Package Manager für das Mac OS Betriebssystem. Package Manager kennt man wahrscheinlich von den meisten Linux-Distribution, wo man halt die ganzen 20–30000 Pakete von Freier Software installieren kann. So was gibt es inzwischen auch für Windows. Da kenne ich zum Beispiel Chocolatey heißt es, glaube ich. Für den Mac gibt es zwei große. Das ist das Homebrew und MacPorts. Und da bin ich halt unterwegs. Und da gibt es halt zwei Aufgaben, sozusagen, die die Security betreffen. Das es einmal den eigentlichen Package Manager, der kann ja auch Sicherheitslücken haben, dass man darauf ein Auge hat und natürlich das Betreuen der einzelnen Pakete. Wir haben tausend Pakete, die man damit installieren kann und die werden von dem jeweiligen Maintainer im MacPorts Projekt betreut. Ich zum Beispiel betreue einige Pakete, die auch relativ populär sind, node.js, git und go kann ich da nennen. Die werden schon ziemlich häufig darüber installiert. Da kommt einem schon eine gewisse Verantwortung zu. Und das ist natürlich ein bisschen anders organisiert, als der Stefan das gerade erzählt hat. Nehmen wir den Part, dass der Package Manager selbst ein Problem hat, raus, sondern wenn zum Beispiel Node ein Problem ist oder ein Go, ist man sozusagen als Downstream Maintainer nennt sich das halt in der Lage. Muss man halt schnell reagieren, weil dann wird in dem Upstream Projekt, in Node selbst, schon ein Fix gemacht und veröffentlicht, bevor MacPorts ein neues Paket bereitstellen kann, weil man da noch nicht in der Lage war da zu reagieren. Man muss das natürlich auch erst mal den fix einspielen oder die Version updaten und das auch testen, dass das noch so alles läuft wie vorgesehen, weil wir Package Manager auch immer in Paketen gewisse Patches drin, Zum Beispiel, dass das auch unter Mac OS läuft, weil es eigentlich ein Linux Projekt ist oder hauptsächlich unter Linux entwickelt wird. Es muss nicht immer so einfach gehen, dass man sagt: Ich erhöhe einfach die Version, lade sozusagen das neue runter, paketiere das und fertig, das ist schon ein bisschen mehr Aufwand. Und dann ist das manch relativ schwierig, das zu handlen, wenn man Glück hat, ist man mit auf einer Mailingliste für die Downstream Maintainer. Das gibt es auch in einigen Projekten. Da werden solche Sicherheitslücken vorher besprochen und veröffentlicht es ist eine geschlossene Mailingliste, und dann wissen alle Bescheid, die das irgendwo paketieren, dass da ein Sicherheits Fix ansteht und können sich darauf vorbereiten und das auch schon machen oder zum Beispiel vom privaten git Repo was klonen, um den Fix auszuprobieren bevor der veröffentlicht wird. Da gibt es Möglichkeiten, aber das ist nicht bei allen Paketen so, bei manchen, die kümmern sich auch nur um ihr eigenes Projekt und denen ist es egal wie die Leute die das Paketieren damit umgehen. Das ist mal ein großer Unterschied. Von dem zeitlichen Rahmen werden wir immer gedrängt von dem was upstream passiert. Das andere ist mit unserer Organisation: Haben wir halt nicht so Leute, die sich dediziert um Security kümmern. Das ist schon in der Verantwortung des jeweiligen Maintainer, sich darum zu kümmern. Und da können die verschiedenen Leute auch ganz unterschiedlich damit umgehen. Was wir organisiert haben, sind sozusagen den Status dieses Paket: Wie gut wird das maintained sozusagen. Da gibt es ein den Status no Maintainer. Das wird sozusagen so von allen betreut. Das sind so typischerweise Abhängigkeiten, die man in anderen Paketen braucht, aber die nicht einen Hauptmaintainer haben, der sich darum kümmert. Das ist natürlich auch am wenigsten vertrauenswürdig, weil da muss man entsprechend Glück haben, dass auch die Leute darauf achten. Wenn man das installiert, kann man sich eine Info über das Paket rausgeben und bei no Maintainer wäre welche immer so ein bisschen vorsichtig ehrlich gesagt. Weil wir haben halt nicht für über 20000 Pakete jeweils eine Person, die sich dediziert darum kümmern kann. Auch wenn wenn jeder Maintainer X Pakete unter seinen Fittichen hat, funktioniert das einfach nicht. Dann gibt es den Start des Open Maintainer, da gibt es jemand, der sich sozusagen hauptsächlich drum kümmert, aber Open Maintainer heißt: Andere Leute dürfen auch auf committen. Das ist mit das beste, weil man weiß, man hat mehrere Leute, die sich drum kümmern und kann davon ausgehen, dass solche Security Fixes relativ fix eingespielt werden. Und der dritte Status ist sozusagen geschlossen. Da hat man eine Person oder manchmal auch zwei Personen, die stehen explizit drin, die sich darum kümmern und kein anderer darf darauf entsprechend eine neue Paketierung vornehmen. Und jetzt komme ich dazu, dass es sozusagen die eine der wenigen formellen Regeln, die wir haben, die Security betreffen. Wenn eine Lücke vorliegt, kann man diese Regel sozusagen brechen. Wenn man den anpingt, den Maintainer oder die Maintainerin und die reagiert nicht sofort darauf, dann kann man sagen ich paketier hier das neu, weil eine Sicherheitslücke vorliegt und vorher so ein Fix veröffentlichen. Da kann man sozusagen die Regel brechen ohne Sanktionen. Das ist auch so gewollt. Weil ich hatte es vorhin erwähnt, das ist mehr hobbymäßig und nicht so ganz durchorganisiert und das ist schon einmal passiert, dass solche Leute, die da Maintainer waren, auf einmal abgetaucht waren. Die waren nicht mehr erreichbar über ihre Kontaktinformationen, was meistens nur die E-Mail-Adresse ist und haben auf nichts mehr reagiert. Deshalb gibt es da sozusagen die einzige Stelle, wo wir das auch formuliert haben, dass man das machen kann. Das steht auch meistens im Committ, das ist hier Security-relevant mit dem Verweis auf das CVE oder wo sonst die Lücke veröffentlicht ist. Und dann kann man sagen, deshalb wird das hier neu paketiert das ist es ein bisschen einfacher. Bei dem Package Manager selbst, ist das nicht ganz so einfach, weil wir signierte Releases rausgeben und nur eine kleine Anzahl von Leuten den Schlüssel dafür haben die Signaturen dafür zu erstellen. Und von daher muss man sehen, dass man die ran kriegt, die ein neues Release machen können. Sonst haben wir da wenig Regeln, sondern das wird einfach über die Mailingliste abgestimmt. Wenn sowas auftritt, wird das in der internen Mailingliste diskutiert was zu tun ist und wer sich daran beteiligt, beteiligt sich dran und wenn es keiner wäre, passiert halt auch nichts. Ist zum Glück noch nicht so gewesen, es gibt genügend Freiwillige sozusagen damit das nicht so ist, aber es gibt da keinen geregelten Prozess in irgendeiner Form. Wir haben auch keine Organisation, Apache ist ja auch eine Institution. Ich weiß nicht, welche Rechtsform das hat, aber ich glaube eine Stiftung oder so. Stefan da kannst du ja etwas zu sagen.
Stefan:
Mich juckt es in den Fingern einzuschreiten.
Christoph:
Wir haben keine Rechtsform oder sonstiges, sondern das geht alles über den Austausch unter den beteiligten Personen im gewissen Sinne auch relativ unprofessionell sozusagen. Und von daher, bis jetzt ist es ganz gut gelaufen. Verantwortung will ich aber ungern dafür übernehmen. Und ich habe glaube ich ganz viel Anti Werbung gemacht, dass man diesen Package Manager einsetzen sollte, aber es ist trotzdem gut. Wenn er Git oder Go oder Node installiert, bin ich ja der Maintainer, dann ist das alles super. Aber Stefan, erzähl doch noch mal.
Stefan:
Zum einen muss ich zugeben, ich habe mir über die Downstream Packages bisher nie wahnsinnig viele Gedanken gemacht. Wenn ich ant gebaut habe, mit dem eine Sicherheitslücke gefixt wurde, habe ich das irgendwann gebaut und wenn die Abstimmung durch war, habe ich die Mail rausgeschickt und dann ging auch gleichzeitig das CVE Announcement mit raus. Und wahrscheinlich hat der MacPorts Maintainer, die Announcement Mail gesehen und anschließend angefangen das Ding zu bauen, was auch immer für MacPorts notwendig ist. Ist vielleicht nicht der optimale Prozess.
Christoph:
Ich möchte kurz nochmal eingreifen, bevor du weiter erzählst. Ich habe das mal gemacht, weil ant im No Maintainer Status ist. Ant wird nicht mehr so häufig released. Aber du hast mir das einmal erzählt, dass es schon mehrere Jahre her, wurden, ich kann mich gar nicht erinnern, irgendeine Lücke war da drin und einen Release machen musstest. Und da habe ich das nachgeschaut bei uns und es war im Status no Maintainer und da habe ich das einfach nochmal verpackt. Bei diesen Sachen geht sogar noch, bei den meisten Sachen so in Sachen Java Pakete, Python Pakete, Node, also npm Pakete, die installiert man sozusagen im Java Umfeld über Maven, Gradle und Co. und im Python Umfeld über pypi und npm im Node Umfeld. Aber wir müssen das manchmal auch paketieren. Ant hat zum Beispiel auch Abhängigkeiten auf andere Pakete oder sonstiges, oder bestimmte Python Sachen die ein Kommando Zeilen Tool haben oder so, die haben wieder Abhängigkeiten und die können wir nicht über den Package Manager von Python installieren, sondern müssen diese Python Pakete selbst nochmal paketieren. Deshalb haben wir da auch eine ganze Menge drin, die man sonst so gar nicht installieren würde. Und Ant ist auch auf der Kommandozeile. Das ist ja ein Programm, was man auch installiert und so nutzen kann und gar nicht unbedingt über Maven installieren würde, außer man nimmt dieses Maven Ant Plugin, dann kriegt man das vielleicht auch mit. Und deshalb ist das bei uns auch paketiert. Vielleicht könnt ihr nochmal darüber nachdenken solche Listen für die Downstream Maintainer zu machen.
Stefan:
Ja, ist schwierig, wen musst du da alles drauf haben. Das was mich in den Fingern juckt, ist natürlich die Charakterisierung von der schwergewichtigen Organisation, die irgendwo so ein bisschen durchklang, und die anderen, die machen ja das alles zum Spaß und dann ist alles gut. Die verschiedenen Apache Projekte sind schon sehr unterschiedlich aufgestellt. Es gibt nicht das Konkrete die immer gleichartig aussehende Apache Projekte? Ganz kurz, die Rechtsform ist eine, ich glaube im deutschen Recht wäre es eine Stiftung. Es ist eine Foundation, die gemeinnützig ist, die darf auch kein Geld verdienen, die bekommt Spenden und diese Spenden muss sie ausschütten in irgendeiner Art und Weise. Sie hat seit einigen Jahren auch Angestellte tatsächlich, über ganz lange Zeit waren das Freiwillige, die sich auch um die komplette Infrastruktur gekümmert haben. Ich habe meinen eigenen Account damals persönlich von Brian Behlendorf, der damals Präsident der Apache Software Foundation war, bekommen, damals heißt 2000. Und das war nicht so wahnsinnig professionell, wie sich das anhört, wie die Infrastruktur organisiert war. Und inzwischen gibt es eben tatsächlich Leute, die dafür bezahlt werden in verschiedenen Zeitzonen, um die Infrastruktur am Laufen zu halten. Das ist im Wesentlichen das, wo es Angestellte gibt. Der Rest, das sind einfach Menschen, die Software entwickeln. Und da gibt es in verschiedenen Projekten Leute, die das aus Hobby tun, so wie ich im Wesentlichen meine Open Source Aktivitäten am Wochenende oder nach Feierabend mache. Das ist nichts, was ich jeden Tag auf INNOQ Rechnung täte, sondern das ist tatsächlich in meinem Fall Hobby. Es gibt andere Projekte, bei denen sehr viele Entwickler sind, die von Firmen bezahlt werden. Gerade in diesem Hadoop Umfeld gab es eine ganze Reihe von Projekten, bei denen die entsprechenden Firmen, die da in den Big Data Umfeld unterwegs sind, ihre Entwickler bezahlen. Bei Kafka ist das der Fall, dass da eben sehr viel Entwicklung durch Menschen betrieben wird, die das als ihren ganz normalen Daily Job haben und entwickeln. Ein Punkt, bei dem du ein bisschen vorsichtig sein musst Christoph, dass ich irgendwann gemerkt und gelernt habe, ist wenn du darüber sprichst, dass es ja nur ein Hobby ist und Leute das eben nicht professionell machen, klingt für ungeübte Zuhörer wie: Die wissen ja gar nicht, was sie tun, lasst da mal die Profis ran. Im Normalfall sind es ja Leute, die auch tagsüber in Anführungsstrichen Software entwickeln und wirklich Entwicklerin und Entwickler, die wissen, wie man Software entwickelt und das in ihrer Freizeit noch nebenbei erledigen. Aber das sind eigentlich alles Profis oder eben in ganz großem Umfang Profis. Und das, was bei Apache vielleicht ein bisschen formaler ist, sind so ein paar Dinge, die wir haben an Regeln, weil ein Software Release ist ein juristischer Akt der Foundation, der notwendig ist, um einfach einen juristischen Schutz zu haben. Das heißt, wenn jemand aus irgendwelchen Gründen auf die Idee käme, ein Open Source-Projekt zu verklagen, weil ein Bug gefunden worden ist, dann ist derjenige, den ich verklagen kann, die Apache Software Foundation und nicht die einzelnen Entwickler im Projekt. Und damit das juristisch wasserdicht ist, muss das so als juristischer Akt der Foundation daherkommen. Und daher kommen diese drei Tage Abstimmungs Frist und ein bisschen Regeln an der Stelle einhalten. Im Großen und Ganzen sind die Projekte nach meiner Erfahrung die Projekte, in denen ich unterwegs bin und mich wohlfühle solche, bei denen es sehr familiär abläuft und niemand da ist, der mir auf irgendeinem Board zeigt, welches Ticket ich als nächstes angehen müsste.
Christoph:
Ja, das meinte ich ja auch mit mit Hobby-Entwickler, um das Thema aufzugreifen gar nicht so in Sachen, dass sie das nicht können, sondern genau das, was du gesagt hast: Das ist Hobby und das ist nicht in meiner Arbeitszeit, das ist Freizeit und es ist abends oder am Wochenende und das kann aber auch heißen, wenn ich im Urlaub bin und sozusagen wie heißt es so schön neudeutsch Digital Detox mache, dass ich da nicht reagiere auf Sachen, die für das Projekt reinkommen, weshalb ich ja, was ich vorhin erwähnt habe, auch meine Sachen als Open Maintainer mache, damit andere wenn zum Beispiel eine Sicherheitslücke käme und ich bin gerade im Urlaub und fasse mein Handy und mein Rechner nicht an, dass da trotzdem reagiert werden kann. Das war der Hobby Aspekt. Nicht dass die Leute nach dem VHS-Kurs Einführung in Visual Basic die Sachen machen, jetzt überspitzt gesprochen, das ist schon klar. Das sind bei uns auch alles Leute, die sonst in der IT arbeiten. Manchmal auch Informatikstudenten bzw. Computer Science die in den USA studieren oder woanders, aber das sind schon professionelle Leute. Aber hobbymäßig, das heißt: In ihrer Freizeit.
Stefan:
Mir war das klar, ich wollte das nur noch deutlicher aussprechen, wobei ich eigentlich davon ausgehe, wer uns hier zuhört, der weiß das ohnehin.
Lisa:
Stefan, in welchen Apache Projekten bist du denn unterwegs und fühlst dich wohl?
Stefan:
Angefangen habe ich bei Apache Ant und da bin ich immer noch. Das heißt seit fast etwas mehr als 22 Jahren inzwischen. Das wechselt natürlich auch ein bisschen durch. Es gibt Leute, die ungefähr so lange dabei sind wie ich. Ein paar Menschen sind nicht ganz so lange dabei. Ist natürlich auch ein Projekt, das vor 20 Jahren sehr viel mehr Aktivität gesehen hat und sehr viel mehr Popularität hatte, als das heute der Fall ist. Wir haben jetzt noch unsere User. Vor 15 Jahren war das ein bisschen anders, da machte das mehr her, wenn man gesagt hat, ich bin Release Manager bei Apache. Jetzt ist das nicht mehr ganz so hip. Aber das ist auch nicht so schlimm, kann ich gut leben. Ansonsten sind es tatsächlich eher kleinere Projekte, Dinge, bei denen ich an Bibliothekssachen mitarbeite. Im Apache Commons habe ich ein paar Sachen gemacht, seit Mitte vergangenen Jahres nicht mehr so, weil ich ein paar Sachen zurückgezogen habe, weil mir die Zeit gefehlt hat. Ich war eine Weile bei Log4net der Maintainer. Das ist von Log4j der .net Cousin. Ich bin immer noch der Vice President. So heißt das, wenn man bei einem Apache Projekt derjenige ist, den das Apache Board fragt: Erzähl mal was zu deinem Projekt. Für Apache Gump, das ist glaube ich der unbekannteste Continuous Integration Server der Welt, weil der eine völlig andere Philosophie verfolgt, nämlich eine, die uns im Abhängigkeitsmanagement vielleicht helfen würde, weil er nämlich nicht die Abhängigkeiten benutzt, die man deklariert, sondern die neueste Version aller Abhängigkeiten, die da sind. Das ist spannendes Konzept gewesen zu Zeiten, als die Leute noch geglaubt haben, dass sie ihre Abhängigkeiten selbst managen sollten und das nicht irgendwem zu überlassen. Jetzt ist das auch nicht mehr so wahnsinnig beliebt. Im Wesentlichen sind die Tomcat und Ant Communities, die auch ansonsten ziemlich eng miteinander sind, die sich da noch tummeln.
Lisa:
Du hattest vorhin noch was gesagt, was mir ein bisschen, nicht Bauchschmerzen bereitet hat, aber so ein mulmiges Gefühl, als du sagtest, dass Apache mehr Regeln braucht, falls jemand sie verklagt, weil irgendwas in dem Open Source Paket war. Muss ich Angst haben, wenn ich eine Open Source Bibliothek zur Verfügung stelle, verklagt zu werden. Ich habe eine echt coole Idee für ein Open Source-Projekt und ruf das ins Leben und stell das für andere zur Verfügung und da war jetzt ein Fehler drin, weil ich habe das alleine nach Feierabend immer geschrieben und habe vielleicht irgendwas nicht erkannt und jetzt werde ich von einer großen Firma verklagt, weil die das benutzen. Kann das wirklich realistisch passieren? Das macht ja doch ein bisschen Angst.
Stefan:
Verhindern, dass du verklagt wirst, kannst du ja eigentlich nie. Klagen kann jemand, auch wenn er nachher nicht Recht bekommt. Aber das Klagen kann ja immer erstmal passieren. Und bei den allermeisten Open Source Projekten ist es die Lizenz, die relativ klar sagt: Wir übernehmen keine Garantie dafür, dass das alles funktioniert. Und wenn du einen Fehler findest, teile uns das gerne mit, aber du kannst nicht davon ausgehen, dass du in irgendeiner Art und Weise dafür kompensiert wirst, dass du diesen Fehler gefunden hast. Das steht so selbstverständlich auch in den Lizenzen, die von der Apache Software Foundation benutzt werden. Der üblichere Klageweg wäre nicht: Ich habe einen Fehler gefunden, sondern irgendjemand hat mein geistiges Eigentum verletzt. Das ist glaube ich eher so die Ecke, um die wir uns vor zehn Jahren Sorgen gemacht haben, weil man einfach nicht wissen kann, dass irgendjemand ein völlig unsinniges Patent auf irgendeinen Algorithmus angemeldet hat. Und wenn man dann den Algorithmus verwendet, dass man damit möglicherweise Lizenzen zahlen soll oder so was in dieser Form. Und das waren eher so die Gründe, warum das wichtig war, diese Foundation ein Stück weiter im Rücken zu haben für mich. Ansonsten hängt es bei den Open Source Projekten auch ein Stück weit davon ab, wie paranoid du bist. Eigentlich wird dich niemand verklagen. XML Unit ist ein Projekt, das ich alleine mache, mehr oder weniger und ich bin mir sehr sicher, niemand kommt auf den Gedanken mich zu verklagen, weil bei mir nichts zu holen ist und das lohnt sich nicht. Und auf der anderen Seite ist es bei der Apache Software Foundation, die verklagt im Zweifel auch niemand, weil das der PR Supergau wäre. Ich glaube, das würde keine gute Presse für den Klagenden bedeuten, wenn man so ein großes Ding wie die Apache Software Foundation, die jedoch glaube ich sehr viel Sympathien genießt. Auch wenn es für manche Projekte als: Die alten Leute, die zu behäbig sind, gilt. Aber es ist schon eine Institution und da ist glaube ich auch relativ wenig Angst, dass es wirklich zu Klagen käme. Aber es ist trotzdem einfach ganz gut die juristische Einheit darüber zu haben.
Christoph:
Ich greife da mal kurz ein. Ich bin ja nicht so ganz sicher, ob das immer so ist, dass man sagen kann, man braucht keine Angst vor haben. Ich greife mal bisschen vor, in Sachen wie große Firmen auch zum Teil mit Open Source-Software umgehen. Für die Shownotes hatte ich ein Beispiel mitgebracht, dass der Maintainer von Curl angeschrieben wurde in Sachen eines Fragebogen, auf den er bitte ganz schnell antworten möchte, ob denn Curl von Log4j betroffen wurde. Da haben die Leute, die das machen, wahrscheinlich nur ganz wenig verstanden über Open Source. Erstmal haben sie sich das Projekt nicht angeschaut, weil Curl überhaupt kein Java Project ist, sondern ein C Projekt und Log4Shell gar nicht nutzt. Aber trotzdem einfach mal alle angeschrieben haben, und sagen: Ihr seid sozusagen unsere Zulieferer. Obwohl das ein Open Source-Projekt ist und die müssen gewisse Bedingungen erfüllen, so Compliance. Stefan, ich glaube, da kannst du auch noch was zu erzählen, das hast du ja auch schon öfter mitgekriegt. Und wenn ich sehe, dass Leute sowas gar nicht verstehen, wie das funktioniert, Open Source-Software oder sonst wie, da kann ich mir auch vorstellen, dass da manche geneigt zu wären, zu sagen: Die verklagen wir einfach. Weil sie das ganze Open Source Konzept so noch gar nicht verstanden haben. Das müssen ja noch nicht mal die Entwickler sein, die irgendein Open Source-Projekt in die kommerzielle Software reinziehen und das dort benutzen, sondern das kann auch die Rechtsabteilung sein, die sozusagen fachfremd ist und das noch nicht verstanden hat und zum Beispiel solche Anschreiben macht wie: Ihr seid unsere Zulieferer, ihr müsst immer compliant sein. Ob da nicht manche auf die Idee kommen könnten zu klagen. Ich finde das Risiko ist schon auch da.
Stefan:
Solche Mails kenne ich auch. Aber im Normalfall beantworten wir die mit einem Verweis auf unsere Website und auf die Lizenz auf Links und haben dann nie wieder irgendwas gehört. Insofern ist da meine Beunruhigung ziemlich klein. Ich bin sonst eher so ein nervöses Hemd, aber das lässt mich relativ kalt.
Lisa:
Ich bin auf jeden Fall auch beruhigter, muss ich sagen und ich glaube, wir können von dieser juristischen Ecke wegkommen hier im Security Podcast. Die eigentliche Frage war ja eben gewesen, wie eure Open Source Projekte organisiert sind. Und was ich mitgenommen habe ist, dass sie extrem unterschiedlich organisiert sind. Apache mit ein paar mehr Regeln, aber auch nicht als großer Konzern oder so organisiert, dass nehme ich auch mit raus. Wie ist es möglich, oder ist das überhaupt möglich, unter solchen Bedingungen sichere Software entstehen zu lassen und zu pflegen?
Christoph:
Ja, aber wahrscheinlich nicht für jedes Projekt. Es gibt ja so ein paar Sachen, die bei Open Source Software kolportiert werden. Zum Beispiel, dass Linus Law, das ist: Given enough eyeballs, all bots are shallow. Das heißt: Wenn bei Open Source genügend draufgucken, werden auch alle Bugs gefunden mit der Zeit. So kann man das sozusagen frei übersetzen. Und das stimmt wahrscheinlich für gewisse Projekte. Aber in vielen anderen Sachen ist das wahrscheinlich auch eher ein Mythos und es gibt da wahrscheinlich noch andere Mythen. Open Source ist wahrscheinlich in die Öffentlichkeit ja auch gekommen durch so Vorzeige Sachen wie den Linux-Kernel. Und da stimmt das wahrscheinlich auch. Da gucken ganz viele Leute drauf, da arbeiten aber auch ca. 90 prozent der Leute Vollzeit dran und werden dafür bezahlt. Das ist nicht mehr das Hobby, sondern das ist deren Job daran zu arbeiten. Die restlichen 10 prozent machen die Typos weg oder so oder sind Studenten die sich damit beschäftigen und etwas beitragen. Aber das ist einfach ein super professionelles Projekt, das von professionellen Entwicklern nicht in ihrer Freizeit gemacht wird, wie bei Stefan und bei mir, sondern die dafür bezahlt werden und ihre ganz normalen acht Stunden, die sie am Tag daran arbeiten dransitzen. Es ist kein kommerzielles Projekt, was von einer Firma verkauft wird, da sind ganz viele Firmen dran beteiligt, natürlich auch mit dem Eigennutz. Wenn eine Hardware Firma einen Treiber für ihre Hardware da rein haben will, dass sie unter Linux unterstützt wird, dann arbeiten die halt daran und die Leute werden dafür bezahlt und da stimmt das auch. Aber wir haben schon gesehen bei Stefan und mir aus unserem Beispiel, dass es ganz verschiedene Projekte gibt, die ganz unterschiedlich aufgesetzt sind mit unterschiedlichen Ressourcen, Kommunikationswegen, Regeln, die man so versucht innerhalb des Projekts einzuhalten oder auch nicht. Es gibt das klassische ein Mann/ein Frau Projekt, das in der Freizeit gepflegt wird, es gibt Projekte, die werden von wirklich dann auch von Hobby, Entwicklern und Entwicklerinnen gepflegt, die wirklich keine professionellen ITler sind, sondern die sich nur in ihrer Freizeit mit IT beschäftigen und da was Gutes gemacht haben, so was gibt es auch. Es gibt große Projekte, wo viele Leute dran arbeiten, aber auch alle hobbymäßig. Das ist so super unterschiedlich. Dabei muss man einfach sagen, das kann man nicht über einen Kamm scheren und etwas wie dieses Linus Law sind Mythen, dass das überall zutrifft. Und das sollte man berücksichtigen dabei, wenn man die Frage beantworten will: Können wir denn sichere Software als Open Source entwickeln oder nicht? Pauschal kann man das nicht sagen. Ich sage das geht. Aber das muss man sich auch angucken und nicht einfach blind vertrauen und sagen: Das ist Open Source, da gucken ja schon alle Leute drauf, das wird schon gut sein. Das stimmt einfach nicht, dass ist ein totaler Mythos.
Stefan:
Gerade im Security Bereich würde ich auch noch ergänzen, dass es nicht ausreicht, genügend Augen zu haben, es müssen auch die richtigen sein. In dem Kontext, wenn wir darüber sprechen zu erkennen, dass irgendwo ein Bug ist, dass der auch Sicherheitsrelevanz hat, das ist noch mal eine Stufe weiter und ganz viele Entwicklerinnen und Entwickler bringen auch nicht unbedingt die Kompetenz mit, die man haben muss, um ein Security Audit zu machen. Das würde ich mir bei irgendeinem beliebigen fremden Quelltext selbst auch nicht zutrauen. Und da muss man eben auch mit einem anderen Blick drauf schauen. Selbst wenn man eine relativ große Community hat, heißt das noch lange nicht, dass deshalb Sicherheitslücken nicht trotzdem lange unentdeckt bleiben könnten. Im Fall von Log4Shell existiert die Lücke ja im Endeffekt mindestens seit acht Jahren oder so etwas. Und die ist über acht Jahre unentdeckt geblieben, ohne dass irgendjemand von dem möglicherweise vielen Augen, die da waren, das bemerkt hat. Oder zumindest ist es nicht mitgeteilt worden, dass man es bemerkt hat. Vielleicht hat es irgendjemand gesehen und für seine Zwecke bereits genutzt, ohne das gemeldet zu haben.
Christoph:
Und das, obwohl diese Art von Lücken, dass JNDI im inneren unsicher ist, sozusagen, weil man da über fremde Quellen was laden kann und diese realisieren kann, dass man dadurch beliebigen Code ausführen kann. Das ist ja auch schon viel länger bekannt. Es gibt Talks auf Konferenzen wie Blackhead, da wird das schon vorgeführt. Nicht im Kontext von Log4j, sondern dass das JNDI gefährlich ist. Und um diesen Brückenschlag zu machen über öffentlich zugängliche Informationen, das hat einfach nicht stattgefunden. Und da würde ich Stefan zustimmen, da fehlt es an Leuten, die so etwas machen können, die sozusagen in beiden Welten unterwegs sind; die Security Experten sind, aber auch so etwas auf dem Schirm haben: Das wird auch in so einem Logging Framework benutzt. Das fehlt einfach. Und solche Leute sind rar und sehr selten. Und solche Leute verdienen viel Geld und die machen wahrscheinlich in ihrer Freizeit nicht so was, dass sie sagen: Wir helfen hier den Open Source Projekten dadurch. Da fehlen auf jeden Fall die entsprechenden Kompetenzen und das hat nicht jedes Projekt. Man kann immer zurückgreifen auf das, was Stefan sagt. In meinem Open Source-Projekt, in MacPorts gibt es keine Security Themen. In der Apache Software Foundation gibt es immerhin schon ein Security Team, also dedizierte Ansprechpartner. Da würde ich sagen, seid ihr ein bisschen besser aufgestellt. Aber was ich noch sagen wollte: Wir haben jetzt gesehen Log4Shell. Wir können auch noch den Rückgriff machen auf Heartbleed. Es ist auf jeden Fall kein Kriterium, wie populär ein Projekt ist. Ich hatte am Anfang gesagt Linux-Kernel, da trifft das zu, weil der so weit im Einsatz ist und so viele Leute schauen drauf. Das alleine kann man aber nicht als Merkmal sehen. Bei Log4Shell, das haben wir ja auch gesehen, Log4j ist auch extrem viel im Einsatz, da ist nichts passiert und da haben schon viele Leute dran gearbeitet. Nicht so professionell wie beim Kernel, aber trotzdem. Anderes Beispiel OpenSSL Heartbleed, das war und ist die SSL- und Krypto-Bibliothek überhaupt. Und trotzdem hat man bei Heartbleed erst gemerkt okay, da arbeiten ganz wenig Leute dran. Der Haupt-Maintainer muss sich auch finanzieren und leben, und der hat in einem Jahr 2000 Dollar Spenden bekommen. Davon kann halt keiner leben. Popularität hat keine Aussagekraft darüber, ob das so passiert oder nicht, ob diese “Enough Eyeballs” denn da sind. Das ist auch ziemlich schwierig rauszukriegen beim Projekt: Hat da jetzt jemand drauf geschaut, schaut noch jemand drauf, weiß man alles nicht.
Lisa:
Du hattest ja eben gesagt, dass dieses “Enough-Eyeballs-Prinzip” bei Linux auch gerade deswegen funktioniert, weil diese Leute in ihrer normalen Arbeitszeit an diesem Projekt arbeiten und auch dafür bezahlt werden. Würde sich denn irgendwas ändern, wenn man OpenSource Entwicklern Geld entgegenwerfen würde? Könnte das irgendwas an der Sicherheit ändern oder vermutlich eher nicht?
Christoph:
Pauschal kann man das nicht beantworten. Vielleicht kann Stefan seine Meinung dazu auch noch sagen, wie er damit umgehen würde. Ich würde gar kein Geld haben wollen. Wenn man sagen würde für MacPorts: Wir nutzen das, wir geben euch etwas Geld dafür. Wir haben erstmal ein Problem, weil wir auch keine Institution sind in irgendeiner Form, wie man das spenden müsste. Kann man gar nicht, es gibt nichts, wo man hin spenden kann. Aber sagen wir, das würde gehen, oder man würde mir das privat spenden, weil man sagt: Wir benutzen hier Node auf macOS und installieren das über MacPorts und du bist der Maintainer dafür und bekommst etwas Geld, weil das kommt ja auch mit einer Verantwortung darauf. Wenn ich Geld annehme, würde ich mich verpflichtet fühlen, da auch eine Verantwortung zu übernehmen. Und die will ich auch gar nicht unbedingt haben. Ich will auch Urlaub machen und dann dafür nicht bereitstehen. Das heißt, ich persönlich würde das nicht machen. Und ich sehe noch ein zweites Problem. Man müsste mich schon mit ganz schön viel Geld beschmeißen, damit ich das mache, weil wenn ich professionell daran arbeiten würde, dann müsste sich das noch mehr rentieren als mein normaler Job, oder mindestens gleichwertig sein. Man kann nicht sagen: Das muss genauso viel Geld machen, weil man sagt, ich mache was gern als Hobby und ich werde dafür bezahlt, dann sagt man: Ich nehme auch weniger Geld dafür, weil ich mein Hobby auch noch als Beruf mache, ob das immer so gut ist, steht auf einem anderen Blatt. Aber das ist problematisch. Und man man sieht das so auch an anderen Stellen. Ich bin etwas auch in der Python Community unterwegs und das ist auch schon ein sehr professionelles Projekt. Aber das beruhte bis hauptsächlich auch auf Freiwilligenarbeit bzw. wo Arbeitgeber gesagt haben, ihr könnt soundsoviel Prozent eurer Arbeitszeit auch daran arbeiten. Und die Python Software Foundation hat jetzt einen Vollzeit Entwickler den Python Developer in Residence nennt sich das. Er hat den eingestellt dafür und der kann ein oder zwei Jahre, weiß ich nicht genau, daran arbeiten, da das fortzuentwickeln, sozusagen in Vollzeit um sich darum kümmern. Das ist für das Python Projekt eine super Sache, dass man da einen Festen hat, der sich sozusagen tagtäglich nur darum kümmert. Aber der Job ist unattraktiv. Der ist zeitlich befristet und im Silicon Valley angesiedelt, mit einer Bezahlung, die deutlich unter dem ist, was man sonst so kriegt. Das Gute für den natürlich: Für seinen Lebenslauf ist das super. Das ist auch ein jüngerer. Aber sonst, wenn man schon länger dabei ist und nicht mehr seinen Lebenslauf so aufpolieren muss, finde ich das gar nicht so attraktiv, ehrlich gesagt. Stefan du hast bestimmt auch eine Meinung dazu, ob man Geld dafür zahlen sollte für solche Sachen.
Stefan:
Ja, ich will da niemandem zu nahetreten. Ich komm mit meiner Open Source Entwicklungsgeschichte aus einer Ecke, bei der man das eher absurd gefunden hätte, sich vorzustellen, dass jemand dafür bezahlt wurde, dass er was verschenkt. Weil eigentlich war die Idee von Open Source ja durchaus auch eine, die davon ausging, dass man auch etwas durchaus gibt in irgendeinem altruistischen Hintergedanken, der noch mit dabei steckt, der aber bestimmt nicht bei allen Open Source Projekten der Fall ist und der auch nicht unbedingt die Motivation für jeden und jede sein muss. Ich finde es auch völlig okay, wenn man dafür bezahlt wird. Ich persönlich würde das nicht wollen. Ich würde wahrscheinlich auch nicht den ganzen Tag das gleiche Projekt machen wollen auf lange Sicht. Insofern würde mich das möglicherweise auch langweilen, selbst wenn es das liebste meiner Open Source Projekte wäre, an dem ich den ganzen Tag arbeiten kann. Ich glaube, irgendwann würde ich auch etwas anderes machen wollen. Das passt einfach nicht zu mir. Und man muss eben auch bei dem Bezahlen von Entwicklern sich fragen: Was bekomme ich da möglicherweise überhaupt als Gegenleistung, wenn ich das bezahle? Wenn es mir nur darum geht, dafür zu sorgen: Das Software Projekt hat jemanden, der davon leben kann, dass er an diesem Software Projekt, dass jeder daran arbeitet und dadurch wird es mein maintained, dann heißt es immer noch nicht, dass die Sicherheitslücken schneller gefunden werden, das haben wir eben schon gesagt. Man muss die richtigen Leute dafür bezahlen, damit das funktioniert. Und vielleicht macht das Projekt am Ende trotzdem nicht unbedingt das, was ich mir von meinem Geld erhofft hatte. Die Frage ist: Wie stark kann ich Einfluss auf das Projekt nehmen, das ich da in irgendeiner Art und Weise mit Geld steuern möchte. Ich glaube, da muss man sich zumindest von der Idee lösen, dass man allzu viel Einfluss gewinnen kann, wenn man OpenSource Entwicklern Geld gibt. Es sei denn, man stellt sie ein, in irgendeine Art von Festanstellung, aber nicht mit: Hier hast du mal eine eine Spende und jetzt mach was! Ich glaube das funktioniert nicht gut. Ich glaube, dass das Geld, wenn man es denn da benutzen möchte, unterm Strich wahrscheinlich in anderen Dingen besser aufgehoben ist, nämlich tatsächlich in die Richtung, mehr dafür zu sorgen, dass Augen da sind, die etwas davon verstehen und Sicherheitslücken finden. Das ist glaube ich das, was ich für sinnvoller halten würde Geld für auszugeben. Auch wenn ich möglicherweise jetzt beschimpft werde, weil Leute gehofft hatten, sie könnten von Open Source leben und ich das verhindere, indem ich solche Aussagen treffe. Das ist bestimmt eine Minderheitenmeinung. Ich glaube, es gibt eine ganze Menge Menschen, die gerne Geld nehmen würden für ihre Open Source Entwicklung. Christoph und ich zählen nicht dazu.
Christoph:
So etwas wird ja auch gefördert. GitHub hat seit gar nicht so langer Zeit Möglichkeiten, dass man an diese Projekte spendet, Sponsoren heißen die da und für die Sponsoren auch noch private Bereiche einrichten kann seit allerneuesten, wo man so etwas herstellen würde, wie du das gesagt hast, dass man sozusagen Einfluss darauf nehmen kann oder die Richtung steuern kann oder bevorzugte Behandlung erhält, weil man die Tickets, die man selbst einstellt frühzeitig gelöst bekommt oder sich das erhofft. Muss man ja auch nicht machen. Es gibt ja keine vertragliche Verpflichtung dazu. Aber diese Möglichkeiten, Geld an Open Source zu spenden, werden schon in letzter Zeit erweitert. Ich glaube eine Menge Leute denken, dass das funktioniert. Ich bin auf deiner Seite. Ich glaube nicht, dass das so gut funktioniert. Es gibt bestimmt ein, zwei Leute, bei denen das so ist, die vielleicht auch relativ populäre Open Source Projekte haben, dass da genügend Leute sich finden, um von Spendenbasis zu leben. Ohne groß zu gucken, dass ich Interessen berücksichtigen muss, weil das Spendenaufkommen von diversen Firmen kommt. Und das was du gesagt hast, die angestellten Entwickler. Es gibt ja ganz viel bei, gerade bei den ganz großen, die das auch sehr für sich ausnutzen Open Source zu machen, indem sie ihre Softwareprodukte als Open Source freigeben, z. B. Kubernetes von Google oder VS Code als Tool von Microsoft und PyTorch oder Tensor Flow oder sonstige große Sachen, die von den großen Silicon Valley Größen kommen, die dafür aber trotzdem noch eine große Entwicklungsmannschaft bereit halten. Da profitieren wahrscheinlich die Firmen mehr von als die eigentlichen Entwickler dabei, weil die können diese Sachen mit einer großen Mannschaft intern pflegen. Die haben die finanziellen Mittel dazu, was weiß ich wie viele Entwickler und Entwicklerinnen dafür bereitzustellen und nehmen aber gleichzeitig noch auf, weil die Sachen auch sehr erfolgreich sind, dass alles was aus der Open Source Community kommt, können das sozusagen alles wieder aufsaugen dafür. Da ist es glaube ich etwas anders. Aber wie wir vorhin besprochen haben, sind die ganzen Open Source-Projekt alle sehr anders. Ich glaube aber, die Mehrzahl dieser Projekte sind halt nicht solche super erfolgreichen Sachen, sondern das sind mehr die kleinen Sachen. Wenn man sieht wie viele Packages in Java, Node, Python oder Ruby Umfeld gibt, die alle Open Source sind, da werden wahrscheinlich bei den allermeisten nur ganz wenig Leute hinter stehen. Und ganz am Anfang hatten wir die Beispiele mit color.js und faker.js. Die haben einen Riesen Impact wenn sie nicht mehr funktionieren, da steht aber auch nur eine Person hinter. Und ich glaube das ist der Regelfall und deshalb glaube ich, dass das im Regelfall auch nicht funktioniert, mit dem: Wir können das mit Geld alles bewerfen. Das können wir vielleicht bei ein paar Sachen machen. OpenSSL hat man mit Geld beworfen. Das hat sehr gut gewirkt nach Heartbleed. Aber nicht jedes Projekt ist OpenSSL, sondern die meisten Projekte von den 150000 MPM Paketen, sind so ein Mann, ein Frau Sachen, die Hobby sind. Aber es gibt vielleicht trotzdem 20000 Pakete, die unglaublich viel von anderen genutzt werden und wenn da was kaputt geht, das halbe JavaScript Ökosystem zerbricht. Von daher stimme ich dir zu.
Lisa:
Jetzt hattest du gerade schon Google, Facebook, Microsoft und deren Open Source Projekte in den Raum geworfen, aber auch gesagt, dass die meisten Open Source Projekte nur von Einzelpersonen gemaintained werden. Wäre es eine Möglichkeit für mich als paranoiden Entwickler nur noch auf kommerzielle Software zu setzen und kommerzielle Pakete, weil die besser gepflegt werden? Oder ist das keine valide Möglichkeit? Oder hilft mir das gar nicht weiter?
Christoph:
Was dir weiterhilft, ist natürlich die vertragliche Ebene. Du hast Ansprüche dir gesichert auf, wie schnell soll so ein Sicherheitsfix zum Beispiel da sein oder so. Das kommt ganz auf die Vertragsgestaltung an, aber generell kann man ja auch sagen kommerzielle Software schön und gut, aber kommerzielle Software ist ja auch sehr oft von Open Source, durchsetzt ist das falsche Wort, aber da sind ganz viele Open Source Komponenten, man hat es ja gesehen bei Log4Shell, wie viele Sachen davon betroffen waren, die auch kommerziell sind, weil wenn die so eine Lizenz haben, die nicht GPL ist, nicht so eine virale Open Source Lizenz, sondern MIT oder eine Apache-Lizenz, dass man die auch durchaus in kommerziellen Produkten einsetzen kann, sind die genauso davon, können genauso davon betroffen sein wie auch. Da macht es für mich ehrlich gesagt wenig Unterschied und ehrlich gesagt, wenn sie das nicht haben, habe ich auch kein Vertrauen da rein. Also wenn sie alles kommerziell entwickeln, muss es schon klein oder Nische sein, ja, aber sonst, wenn Sie alles sozusagen auf Eigenentwicklung setzen, glaube ich nicht, dass sie das sozusagen für die Security dieser ganzen Sachen auch noch geradestehen können. Da werden genauso Bugs auftreten und da ist es noch viel schwieriger, sozusagen nicht auf externe Pflege zu setzen. Das können manche Firmen, also Microsoft und Google könnte das wahrscheinlich. Die haben so viel Geld und so viel Entwicklungspower, dass sie sagen können, wir könnten sozusagen ohne Abhängigkeiten leben. Aber wenn ich hier so einen Mittelständler sehe, was weiß ich, der eine Software dann vertreibt, dann glaube ich nicht, dass wenn er das alles in Eigenregie macht, dass es dann besser wäre. Es ist dann nur nicht so sichtbar, aber das ist für die Security auch nicht so gut, wenn wir sagen, wir verlassen uns darauf, weil es so klein und selten ist, dann findet keiner die Bugs. Das ist keine gute Strategie. Von daher glaube ich nicht, dass es heutzutage durch kommerzielle Software besser wäre. Ich glaube, als Stefan gerade gesagt hat, dass er meinte, ich nenne das ganz pathetisch, mit einem ganz anderen Ethos angefangen, dieses wir sharen das und für alle frei, man käme gar nicht auf die Idee, Geld dafür zu nehmen. Du sagst, du bist seit 20 Jahren dabei, glaube ich. Ich glaube damals wäre das mit dem Unterschied kommerziell Open Source nochmal was anderes gewesen, aber das hat sich so geändert. Also sozusagen da ist Open Source so professionell geworden und auch in die kommerzielle Software eingezogen, dass man das heute so nicht mehr sagen kann. Aber das ist meine Meinung, hat Stefan da auch noch andere Ansichten zu oder gleiche?
Stefan:
Also das was sich sicherlich verändert hat ist, dass Open Source viel allgegenwärtiger ist, als es das vor fast 30 Jahren, als ich angefangen habe, vor 20 Jahren war EPG noch gewesen ist. Das hat so vor 20 Jahren mit den EPG Projekten im Java Umfeld, das ist glaube ich stärker geworden. Vor allen Dingen mit der Java Platform habe ich den Eindruck, dass Open Source Projekte, Open Source Bibliotheken, Open Source Frameworks immer wichtiger geworden sind. Das Spring Framework, durch das und das heute ja praktisch keinen Java Projekt mehr entwickelt werden kann, ein bisschen spötteln darf. Und auf der anderen Seite, ich glaube, dass das neuere Java Script Ökosystem beispielsweise, also da hat man einfach ganz andere Plattformen, die von vornherein darauf gesetzt haben, sehr viel stärker Open Source Komponenten einzubinden und auch in irgendeiner Form in Abhängigkeitsmanagement zu haben. Das war eben früher der alte Mann, der vom Krieg erzählt, war das eben so, dass man seine fünf Abhängigkeiten, die man hatte, mit in das CVS Repository eingecheckt hat. Und man brauchte keinen Dependency Manager, der transitive Abhängigkeiten aufgelöst hat. Es gab diese Tools auch eigentlich gar nicht. Also dann gab es irgendeinen Shell Script, das man ausgeführt hat, um Dinge zusammenzusuchen. Und ich glaube, dass sich da eben ganz viel geändert hat, was den Stellenwert von Open Source Komponenten angeht. Als du das fragtest, wenn ich nur noch auf kommerzielle Software setze, fängt dann nämlich für mich die Frage an, findest du denn überhaupt kommerzielle Software, die das leistet, was du da eigentlich haben möchtest? Eigentlich hast du oft die Wahl gar nicht, sondern wenn du das nicht selbst schreiben möchtest, ich bin mir sicher, ihr hattet auch schon ein Security Podcast, bei dem ihr darüber gesprochen habt. Das ist eine blöde Idee Crypto Algorithmen selbst zu implementieren. Also wenn man nicht alles selbst implementieren möchte, dann nimmt man doch fertige Komponenten und die sind in der Regel Open Source. Und ich hätte persönlich auch wenig Vertrauen darin, dass kommerziell entwickelte Software weniger Sicherheitslücken hat, als Open Source entwickelte Software, weil ich nicht darauf vertrauen würde, dass da Security Audits stattgefunden haben, dass da die richtigen Menschen noch ein zweites Mal darauf geschaut haben.
Christoph:
Wo du das gerade sagst, das hat sich geändert so, wie allgegenwärtig da fällt mir eins ein. Ich bin ja schon lange auch bei Go unterwegs, seit Version 0.4. Und ich weiß nicht bei welcher Version, aber es hat sich mal geändert, wie da mit Dependency umgegangen wird. Nicht das, was man so kennt, wie schlecht das Go Dependency Management war und was sich jetzt geändert hat, sondern im Sinne von, man konnte mal eine ganze Zeit auch binär Dependencies reinziehen. Also binär Pakete, gegen die man dann linken konnte. Diese Möglichkeit ist aus dem Bild System verschwunden von Go. Sie haben irgendwann gesagt: Ne, also entweder gibt es mindestens den Source, das kann man ja immer noch vertraglich machen, also den Source nur so bereitstellt und das gelinkt wird. Aber die Wirklichkeit sozusagen Binaries da rein zu bauen, gegen die man dann linken kann, ist komplett daraus verschwunden. Und normal da sozusagen was reinzubekommen, ist auch gar nicht so einfach, weil das Package Management direkt auf GitHub und Co geht. Die Pakete werden direkt sozusagen mit ihrer URL referenziert. Das ist die die offizielle Sache. Man kommt da drumherum und so, man kann da was machen, aber man hat irgendwann gesagt, dafür gibt es keinen Use Case, dass Leute kommerziell solche Komponenten bereitstellen als Binaries. Das ist so selten, das machen wir gar nicht. Das schmeißen wir einfach raus. Und das ist dann einfacher für uns, das Buildsystem zu pflegen, wenn sowieso alles aus Source kommt und alles neu kompiliert werden kann. Weil bei Binaries hat man halt Probleme mit welcher Version war das? Kann ich dagegen einfach linken, hat sich das Objekt Layout geändert und all solche Sachen. Hat man dann gesagt, dass lohnt sich nicht, weil diesen Use Case gibt es kaum noch. Das schmeißt man einfach raus. Da geht man davon aus, was in dieser Programmiersprache ist, ist eigentlich als Open Source verfügbar.
Lisa:
Auch ein interessanter Ansatz. Gerade haben wir so ein bisschen das Thema durchgenudelt, ob und wie trotzdem sichere Software entstehen kann, auch wenn verschiedene Regeln durchgesetzt werden an einzelnen Open Source Ecken. Also ich vermute durch Log4Shell ist auch einiges passiert. Welche Konsequenzen sind denn durch Sicherheitslücken in Open Source Frameworks gekommen oder gibt es Konsequenzen, die gerade am Kommen sind?
Christoph:
Ja, es gibt schon einiges. Der Stefan kann glaube ich gleich noch erzählen, wie er so was auch schon einmal eingesetzt hat. Das hat schon angefangen nach Heartbleed. Das hatte ich früher erwähnt, da habt man Geld darauf geworfen. Das hieß, die Core Infrastructure Initiative wird gegründet, die solche sagen wir mal lebenswichtigen Projekte, für das Internet am Laufen halten, die das unterstützen. Und da ist eine Menge Geld rein geflossen. Da konnte man halt, ich weiß nicht wie viele Personen in Vollzeit bezahlen, die dann an OpenSSL gearbeitet hatten. Und das deutlich verbessert haben von der Qualität. Gleichzeitig hat Google Project Zero gegründet. Die suchen Sicherheitslücken in verschiedenen, also in allen möglichen Projekten und veröffentlichen die dann unter dem Responsible Disclosure und nicht so, wie Stefan das ganz am Anfang gesagt hatte, dass man einfach so dann auf Twitter was veröffentlicht, bevor der Patch draußen ist. Darüber lohnt sich wahrscheinlich auch noch eine eigene Folge zu machen. Die haben aber auch relativ strenge Regeln, wann so ein Patch da sein müssen. Also, sie veröffentlichen das auch wenn der Patch nicht da ist, wenn man nicht schnell genug war und nicht um zusätzliche Zeit gebeten hat und die dann eingesehen haben, dass man die vielleicht auch braucht. Aber gut, sagen wir so, dass wird damit gegründet. Da hat man sehr viele, sehr gute Leute eingekauft, die da jetzt arbeiten. Sozusagen die Topleute in dem Bereich, um Sicherheitslücken zu finden. Stefan hat das ja vorhin erwähnt. Leute fehlen oder Leute, die man gebrauchen kann. Ich glaube, das sind Leute, die kann man gebrauchen dafür, wenn die sich so Projekte anschauen. Das hat schon vor Jahren angefangen. Das ging aber so ein bisschen unter, ehrlich gesagt, weil danach hat sich nicht mehr so viel getan. Und dass man, ich sag mal allzu sorglos Open Source Software einsetzt, ohne mal darauf zu achten: okay, brauche ich das unbedingt? Kann ich das nicht selbst schreiben? Weil so eine Abhängigkeit halt, da muss ich denen vertrauen, die das machen. Ich kenn die nicht. Ich weiß nicht, wie das Projekt aufgestellt ist und alles Mögliche, was wir vorhin schon gesagt haben. Rein die Popularität sagt nichts aus. Da hat sich wenig geändert. Das ist jetzt so ein bisschen seit Log4Shell, hat sich doch wieder was getan, ehrlich gesagt. Das hat ein paar Jahre gedauert, aber das hat die Leute nochmal wachgerüttelt. Einmal auf der Gesetzes Ebene, also gerade in den USA gibt es ein paar Initiativen darüber. Zum Beispiel müssen die in den Staaten, eine Bill of Materials aufstellen für ihre Projekte, damit man erstmal den Überblick bekommt, was denn überhaupt so benutzt wird an Open Source Software. Vom Pentagon gibt es ganz frisch, von Ende Januar, ein Memo darüber, wie mit Open Source Software umgegangen werden soll. Es gibt so eine große FAQ dazu, die verlinken wir auch in den Shownotes, wo so einen Leitfaden an die Hand gestellt wird, auf was alles geachtet werden soll, wenn das eingesetzt werden wird. Wie ist der allgemeine Umgang? Das kam alles so als Nachwellen von dem ganzen Log4Shell Zeug. Und ich glaube, Stefan hat vor der Sendung kurz erwähnt ich weiß nicht, ob er da noch mehr weiß, kannst vielleicht gleich was dazu sagen, in Europa gibt es auch solche Initiativen, wohl auch auf EU-Ebene, aber da weißt du mehr.
Stefan:
Nicht wahnsinnig detailliert vielmehr, aber tatsächlich hat es Anfang des Jahres in den Vereinigten Staaten im Zusammenhang des Weißen Hauses so ein relativ großes Treffen gegeben bei dem Spitzenvertreter der Industrie, die haben ihre CTOs und CSOs hingeschickt und mehrere Organisationen aus dem Open Source Kontext und darunter auch die EPG Software Foundation zusammengerufen worden sind, um zu diskutieren: Was können wir denn tun? Und daraus sind so ein paar Initiativen durchaus entstanden. Es gibt schon relativ lange diese Open Source Security Foundation OpenSSF. Das ist, glaube ich, ursprünglich so entstanden als Ableger von irgendwas, was als Reaktion auf Heartbleed ursprünglich gemacht worden ist. Unter dem Dach werden einige Dinge organisiert, können wir sicherlich gleich noch ein bisschen was darüber sprechen, und in Europa weiß ich halt, weil die EPG Software Foundation da auch durchaus mit eingeladen ist, an Gesprächen teilzunehmen. Das ist zumindest auch organisiertere Aktivitäten gibt an den Regierungs oder zumindest Behörden, EU-Behörden, die daran beteiligt sind, nicht direkt Regierungs unterstehende Stellen. In den USA ist das doch noch mehr politisch aufgehängt. Ich glaube in Europa ist es mehr auf der Arbeitsebene aufgehängt. Aber eben dort zu schauen, was können wir auch in Europa mit den größeren Unternehmen, die wir auch in Europa ja durchaus haben, gemeinschaftlich anpacken, um dafür zu sorgen, dass wir hier die Infrastruktur Komponenten, die in Open Source vorliegen, von denen so wahnsinnig viele abhängen, in irgendeiner Art und Weise die Sicherheit zu erhöhen dafür. Und aus diesem Project Zero, wenn ich daran knüpfen darf, glaube ich im Zusammenhang damit steht zum Beispiel von Google ein Projekt, dass OSS Fuzz heißt, Fuzz kommt von fuzz testing, und wo man mit zufälligen Inputs, also die ursprüngliche Idee von fuzz testing ist eher auf einer Unit Test Ebenen. Ich teste meine Funktion, in der ich da irgendeinen Müll als Argumente rein schmeiße und gucke, was die denn damit macht und ob die in irgendeiner Art und Weise interessant reagiert. Und interessant gerade in so einem Sicherheit Kontext ist irgendwas geht kaputt, eine Exception fliegt oder die Software stürzt ab. So was in der Art und bei OSS Fuzz gibt es seit einem knappen Jahr die Möglichkeit auch Java Projekte zu fuzzen. Und die Leute, die das für Java eingebaut haben, die haben sich bei Apache Commons Compress gemeldet, weil sie das für ein interessantes Projekt hielten, um das ausprobieren zu können. Apache Commons Compress ist eine Bibliothek, mit der ich komprimierte Streams, die komprimieren kann, mit dem ich Archive lesen kann. Und das was sie immer gemacht haben ist, dass sie zufällige Datenströme in die Parser verzipped und in 7zip reingesteckt haben und geschaut haben, was dabei passiert. Und das ist ungefähr zwei Wochen gelaufen als Test. Das wird von Google in der Cloud auf vielen Server mit großer Rechenleistung ausgeführt. Das könnte man lokal auf dem Entwicklungsrechner eben nicht so lange laufen lassen und es hat relativ schnell durch seine zufälligen Permutationen tatsächlich Fälle gefunden, die am Ende zu vier verschiedenen CVEs geführt haben und das innerhalb von wenigen Tagen, die durchaus spannend waren. Ursache ist an der Stelle fast immer fehlende Input Validierung gewesen. Ich bin sicher, da habt ihr auch schon einen Podcast dazu gemacht. Weil eben das Archiv behauptet hat, gleich käme irgendwas an Daten hinterher und dann hat der Parser das geglaubt, dass das so sein würde und sich in den echten Daten, die da vorhanden waren, verloren, und sie nicht so ausgesehen haben oder gesagt jetzt kommen zwei Gigabyte Dateiname und alloziert man mal zwei Gigabyte und dann ist die Out of Memory Exception da. In dem Fall sind es relativ niederschwellige CVEs, weil das, was dabei passieren kann, Denial of Service Attacks im Wesentlichen gewesen sind. Dann stürzt halt das Programm ab. Schade, aber es ist zumindest keine Remote Code Execution oder irgendwas in dieser Form möglich gewesen. Wenn ich damit mit den Virenscanner zum Absturz bringe, dann wird es schon wieder interessanter. Oder die Web Application Firewall oder sonst irgendwas, weiß ich nicht, wie da die Fallback Mechanismen sind. Aber das hat ganz gut funktioniert für uns in dem Projekt. Da haben wir aber auch sehr schnell gemerkt, die Standardeinstellung bei diesem OSS Fuzz war in dem Moment, wo es feststellt, dass es in Main Branch gefixt ist, wird das Issue öffentlich bevor ein Release da ist. Dann haben wir erstmal mit den Leuten reden müssen, dass das so nicht ganz mit unseren Prozessen zusammenpasst. Und glücklicherweise damals auch eine Lösung gefunden. Aber es gab dann die ersten Security Scanner, die darauf angesprungen sind, weil sie gesehen haben, dass es ein OSS Fuzz Ticket dazu gegeben hat, also die einfach tatsächlich offensichtlich Commits monitoren und festgestellt haben: Aha, da hat jemand das bei OSS Fuzz was gefunden, deshalb ist es potenziell sicherheitsrelevant und dann hattest du eben Warnungen, dass die Version, die gerade noch die aktuellste war, Sicherheitslücken hätte, obwohl es noch keine neuere gab und führt auch bei den Benutzern zu ziemlich blöden Situation. Aber da gibt es eben solche Möglichkeiten und es scheint so zu sein, dass es da noch deutlich weitergeht. Anfang Februar ist eine Initiative Alpha Omega angekündigt worden, bei denen eben in der ersten Phase der Alpha Phase mit viel Geld und mit Security Experten, die zunächst von Microsoft und Google, auch das Geld kommt zunächst von Microsoft und Google, loslaufen und bei den wichtigsten Open Source Projekten, was immer die Metrik für wichtig an der Stelle sein wird, ist noch nicht so ganz bekannt, also welche denn die sind, die da kontrolliert werden, aber wo eben tatsächlich gezielt Security Experten Security Audits machen sollen für zentrale Komponenten und ihre Findings zurückgeben und vielleicht auch die Entwicklungsteams der entsprechenden Projekte ein wenig schulen, um zu verhindern, dass sowas in Zukunft passiert. Daraus soll abgeleitet werden, noch mehr solcher automatisierte Tests Infrastruktur auch aufzubauen, wie OSS Fuzz das herstellt. Das ist dann die Omega Phase, um in dieser Phase dann ein möglichst breites Feld, also das Ziel, dass die Pressemitteilung dazu anbietet, spricht von 10.000 Open Source Projekten, die sie im ersten Schritt anbinden wollen. Da kann man sich glaube ich einen relativ breiten Effekt von versprechen, wenn da mehr passiert. Natürlich gibt es Grenzen dessen, was man mit solchen Tests finden kann. Statische Code Analyse kann ein bisschen was finden, kann aber auch false positives haben. So ein Fuzz Testing findet eben bestimmte Arten von Fehlern, aber ich tue mich gerade schwer damit, mir vorzustellen, wie ich durch zufällige Inputs, die JNDI Ausnutzbarkeit von irgendwelchen Mustern in Log Nachrichten hätte entdecken sollen. Und auch die statische Code Analyse würde das im Zweifel nicht herausfinden. Ich glaube, das sind die Arten von Sicherheitslücken, bei denen mir zumindest im Moment noch die Fantasie fehlt, wie man das nur tue, gestützt finden kann, ohne dass Leute, die wissen, worauf sie achten müssen, das tatsächlich tun. Vielleicht ist auch mein Vertrauen in künstliche Intelligenz zu gering.
Lisa:
Wobei es natürlich schon die Sicherheit erhöht, wenn wenigstens andere Lücken entdeckt werden. Ja klar, die JNDI Lücke wäre nicht durch so was entdeckt worden vermutlich, aber eventuell kann das OSS Fuzz dafür eben diese anderen Lücken aufdecken. Es war ja trotzdem für euer Projekt in dem Falle wertvoll. Bei dem OSS Fuzz hätte ich jetzt meine Frage: Ist das was ich jetzt in diesem Moment schon in meinen Open Source Projekt einbinden könnte und in meiner CI/CD Pipeline mitlaufen lassen könnte oder ist das noch nicht so weit?
Stefan:
Es funktioniert eher ein bisschen anders. Du bindest das nicht in deiner Pipeline, sondern die haben ihre eigene Pipeline. Du meldest dich bei den an, du meldest dein Projekt an und du lieferst einen Testfall, der ein im Java Fall ein Byte Array bekommt. Ein zufälliges Byte Array. Also, lieferst einen Test mit einer Methode mit einer bestimmten Signatur, die bekommt ein Byte Array und konfigurierst dann OSS Fuzz so, dass du ihm sagst diese Methode bitte aufrufen und wird es irgendwo in dieses riesengroße Cluster, das Google dazu betreibt, ich weiß gar nicht, wie groß das ist, also das Cluster, das Google dafür zur Verfügung stellt, deployed und dann wird ununterbrochen darauf rum gehämmert und das ist nicht ganz so naiv, das es einfach zufällige Inputs macht, sondern offensichtlich aus dem Nichts ein Ding, das wie ein valides Zip Archiv aussieht, zu erfinden. Das ist schon nicht so einfach. Und wenn es tatsächlich auf Probleme stößt, dann versucht OSS Fuzz die fuzzing Bibliothek, die darunter ist, auch ein minimales Beispiel zu finden. Ob es mit weniger Variationen das gleiche Problem auslösen kann, um einen möglichst kleinen Proof of Concept für irgendeinen Bug zu produzieren, den man eben ausgibt. Und die Dinge, die fehlgeschlagen sind, werden nach jedem Commit neu probiert und gleichzeitig läuft das Ding aber auch immer weiter. Auch ohne, dass du irgendwas tun musst. Das läuft einfach mehr oder weniger ununterbrochen. Wahrscheinlich wenn es seit Ewigkeiten nichts mehr gefunden hat, werden weniger Ressourcen für dieses Projekt zur Verfügung gestellt, weil irgendwann auch der Raum von zufälligen Byte Arrays, die interessant aussehen, erschöpft ist. Aber nach jedem Commit muss man nochmal alles neu testen. Es könnte ja ein neuer Bug hinzugefügt worden sein. Insofern läuft das Continuous, ohne dass du was dafür tun musst und das ist offen, man kann tatsächlich sein eigenes Projekt dort anmelden.
Lisa:
Also kostet das nicht mal etwas. Okay, ich hatte nämlich als du gerade gesagt hast, irgendwas mit riesigen Ressourcen oder vermutlich riesigen Ressourcen hatte ich erst Angst, dass es was kostet, weil das ja wieder diesem widersprechen würde, dass man dem Open Source Menschen kein Geld gibt. Ich würde ja für meine Open Source Bibliothek auch keine 1000 Euro im Monat ausgeben wollen um sie zu maintainen, wenn ich damit nichts verdienen würde.
Stefan:
Nein, das ist tatsächlich zumindest für die Projekte kostenlos gewesen. Ich gehe auch davon aus, dass das prinzipiell ist und es ist nicht auf Java Projekte beschränkt, ganz im Gegenteil. Ich glaube, die fuzzing Bibliothek, die darunter ist, ist ursprünglich für C geschrieben und OSS Fuzz ist schon länger vorher auch für C Projekte zur Verfügung gestanden. Das sind einfach verschiedene Integration. Wir verlinken das nachher in den Shownotes und ich glaube schon, dass das für viele Arten von Projekten nützlich sein kann, sowas zu nutzen.
Christoph:
Man kann sich da aber nicht selbstständig einlinken, man muss sozusagen einen Antrag auf Aufnahme stellen dafür. Ich weiß nicht, wer da alles angenommen wird, aber man kann nicht selbstständig sozusagen sein Open Source Projekt einfach da rein setzen und sagen, es wird jetzt gemacht, sondern man muss erst sagen, ich würde gerne und wenn ich das richtig sehe, sind zurzeit knappe 500 Projekte da drinnen oder etwas über 500.
Stefan:
Aber vielleicht wird auch das mehr Projekten zugänglich dann.
Christoph:
Auf jeden Fall. Zu den Ressourcen: für normale Entwickler auf jeden Fall nicht zu stemmen, für Google aber ein Klacks. Was die an Rechnern insgesamt weltweit betreiben, ist es nicht so viel. Muss man sehen, aber es ist auf jeden Fall ganz gut, wenn man das macht. Ich befürchte nur, dass man nicht alle 100.000 NPM Projekte da reinpacken kann, sondern dass man da auch eher weniger hat. Wo du sagtest, wo ich gerne noch darauf zurückkommen würde, ist das du sagtest 10.000, das sind ja schon ganz viele. Ich bin mir da nicht so sicher. Wenn man es böse sagt, sind 10.000 Abhängigkeiten ja der Durchschnitt beim normalen NPM Projekt. Und wenn wir sehen okay, es gibt NPM, aber es gibt auch noch Python, es gibt Ruby, es gibt Go, es gibt Rust, es gibt Java. Wie viele Open Source Projekte es da schon gibt und mit den ganzen Abhängigkeiten, die man sich heutzutage damit einhandelt. Du hattest das schon gesagt, bei Spring hat man halt ganz viele, das gibt es in jeder Programmiersprache halt. Ich weiß gar nicht, ob das dann wirklich so viel ist: 10.000. Ist jetzt reines Bauchgefühl. Ich würde sagen, das ist gar nicht so viel. Es ist ein super Anfang. Man muss das auch erstmal machen. Man muss ja auch erst die identifizieren, das ist klar. Und das wird schon eine ganze Zeit kosten, auch Leute. Das kann man wahrscheinlich auch nicht so super automatisiert machen. Da kann man vielleicht die Kandidatenauswahl mitmachen, aber da muss man da doch trotzdem Leute darauf schauen. Ja, ich weiß es nicht.
Stefan:
Tatsächlich ist auf der Seite, die das Alpha Omega Projekt beschreibt, verlinkt irgendein Open Source Zensus, den ich vorher auch nicht kannte, wo nach verschiedenen Metriken Open Source Projekte betrachtet worden sind, um zu identifizieren, wie viele andere hängen von diesen Projekten ab? Wie alt sind die? Wie maintained sind sie? Wie hoch ist das Risiko, dass irgendetwas passieren könnte und wie wichtig sind sie auf der anderen Seite tatsächlich? Und das sind eben Metriken, die gemeinsam zusammenkommen sollten, um zu entscheiden, welches sind die Projekte, auf die wir uns da als erstes stürzen. Also, die idealerweise Projekte zu nehmen, von denen viele abhängen und die gleichzeitig nicht so aussehen, als wären sie besonders gut maintained. Das sind die low hanging fruits, denke ich, und da auf die Schnelle Dinge fixen zu können.
Christoph:
Ja, auf jeden Fall eine gute Idee, wenn man Open Source macht, dass man schaut, ob man so in einem Projekt da rein kann. Weil das ist halt ein initialer Aufwand, danach ist es aber sozusagen umsonst von daher passt das schon.
Lisa:
Ich glaube, wir nähern uns ja so langsam dem Ende des Ganzen und ich glaube, eine spannende Abschlussfrage für Zuhörerinnen und Zuhörer wäre noch was kann ich in meinem eigenen Softwareprojekt tun, um die Sicherheit zu verbessern, mich vor solchen Lücken zu schützen oder die schneller zu erkennen, wenn sie auftauchen.
Christoph:
Es gibt eine ganze Reihe an Sachen, die man machen kann und die man auch tun sollte, die würden wir aber wahrscheinlich unter dem Begriff best practice fassen. Die man tun sollte, solange man von diesem ganzen Zeug abhängig ist. Das einfachste wäre natürlich, was aber völlig unrealistisch ist, dass man keine Dependencies hat, dann handelt man sich auch keine Sicherheitslücken davon ein. Aber dann ist man wahrscheinlich in demselben Problem wie ich, das vorhin für kommerzielle Software gesagt habe und wo Stefan das auch gesagt hat, wenn man es alles selbst macht, wird es wahrscheinlich die Situation nur verschlimmbessern. Deshalb ist aber ein wichtiger Tipp auf jeden Fall, dass man Dependencies minimiert. Ich sage mal in manchen Ökosystemen so eine Unart, dass man bei Funktionen, die nur wenige Zeilen umfassen, schon das als Dependency hat und das nicht mal eben selbst schreibt. Komplett vermeiden kann man das natürlich nicht, sondern man wird das Rad nicht immer neu erfinden und es ist ja auch gut. Aber das wäre das erste Dependencies minimieren. Und wenn ich Dependencies nutze, sollte ich die auch pinnen. Das heißt, die Version sollte festgelegt sein, damit nicht so was passiert, wie wir das ganz am Anfang mit diesem color.js und faker.js hatten. Das ich so eine Versions Range habe, wenn da was passiert, weil in dem Fall der Entwickler gesagt hat, mir reicht’s, die großen Firmen verdienen zu viel an so einem Zeug und tun dafür nichts. Oder wenn das wie bei den anderen, was wir auch als Beispiel hatten, passiert, dass so ein Paket gekapert wird und die neueste Version dann mit Malware ausgeliefert wird. Da hat der oder die Maintainer selber angegriffen, kann ja auch passieren. Hat man ja auch schon öfter gehört, dass man nicht automatisch die neueste Version bekommt, sondern sozusagen immer auf einem bekannten guten Stand ist. Das wäre schon mal ganz wichtig. Und zu den weiteren Sachen, wenn ich mir die Sachen ansehe, sollte ich die Dependency möglichst aus vertrauenswürdigen Quellen beziehen, was jetzt natürlich extrem schwierig ist. Was ist denn eine vertrauenswürdige Quelle? Ich habe vorhin dieses Pentagon Memo erwähnt und die FAQs dazu, da sind so einige Kriterien drinnen. Was Stefan gerade gesagt hat über das Open Source Zensus oder wie hieß das? Sozusagen so ein paar Metriken, die man feststellen kann. Da kann man auch was rausbekommen. Wie schnell zum Beispiel Fixes rauskommen, wie viele Commits da darauf kommen, wird das überhaupt noch maintained oder nicht? Und von diesem Open SSF das, was auch der Stefan schon erwähnt hatte, gibt es auch so eine Open Scorecard. Da sind auch ganz viele Kriterien sozusagen um diesen Gesamtwert zu bestimmen. Und da zählt auch sozusagen der Faktor Vertrauenswürdigkeit spielt da auch rein und da ist auch aufgeschlüsselt unter welchen Kriterien, wie man den sozusagen versuchen kann zu ermitteln. Aber das bleibt halt kompliziert. Weltweite Internet die Vertrauenswürdigkeit von einer Entwicklerin, die am anderen Ende der Welt sitzt, kann ich schwer einschätzen, während ich sagen kann: Ja, der Stefan macht Ant, dann kann ich Ant wohl vertrauen, weil ich kenne den Stefan schon lange und gut und das ist wahrscheinlich was gutes, aber so funktioniert das ja nicht mehr, dazu ist die Open Source Gemeinde viel zu groß, dass man sozusagen auf so einer Basis das machen kann das halte ich für eines der schwierigsten Probleme von den ganzen Maßnahmen, die auch überall empfohlen werden, weil das nicht so einfach ist und auch nicht so einfach zu automatisieren. Es gibt nur so ein paar Indikatoren. Man kann natürlich noch andere Dinge machen, zum Beispiel Security Scanner einsetzen, die Sachen automatisieren, jetzt sind wir wieder auf der technischen Ebene. Also Vertrauen ist die menschliche Ebene sozusagen und die technische Ebene kann man auch was machen. Security Scanner sind da ein Beispiel, die man einsetzen kann während des Bilds, die zum Beispiel einen warnen, das, wenn man Dependencies hat, die bekannte Sicherheitslücken aufweisen. Aber da muss man vorsichtig sein, da gibt es auch eine ganze Reihe an Problemen mit denen. Wir hatten zum Beispiel auch ein Projekt, wo ich beruflich Mitarbeiter war, haben wir auch in den Nachlauf von Log4Shell sollten überall Dependency Scanner eingesetzt werden, die in dieser Continuous Delivery Pipeline schon mit dabei sind. Und wir programmieren da ein Go und dieses Tool, was da in der Pipeline ist, ist aber noch nicht so wirklich ausgereift. Weil bei Go werden Dependencies alle in einer Datei deklariert und da gibt es nicht so was wie Scopes, wie es zum Beispiel in Java gibt. Ich kann nicht sagen, diese Dependency brauche ich nur für Tests oder so optionale Dependencies, die ich nur in bestimmten Fällen brauche. Wir haben da zum Beispiel eine Library bei, die für Daten Migration nötig ist oder Schema Migration vielmehr, und die unterstützt eine ganze Reihe von Datenbanken. Also richtig viele. Und das heißt, die Dependencies für die Datenbank Treiber sind auch alle dabei und die haben wieder nochmal Dependencies. Das Tool schaut darauf auf der Liste von allen Dependencies, die es sozusagen da rausbekommt. Also die, die deklariert sind und die transitiven Dependencies. Und diese Liste ist dadurch extrem groß und gibt jede Menge Fehlalarme, weil wir benutzen eine Datenbank, eine Postgres-Datenbank. Und bei Go ist es so, dass in dem Binary auch nur der Code landet, der auch angezogen wird. Man kann das beim Build steuern, da gibt es sogenannte Buildtags. Da kann ich zum Beispiel sagen, ich baue das mit dem Tag sqlite oder MySQL. Dann kommt der Code mit rein und ich kann auch beide mitnehmen. Aber das Tool geht halt nicht auf die wirklichen Dependencies, die benutzt werden, die im Binary landen, sondern auf alle die deklariert sind und deren Abhängigkeiten. Und dann hast du viel zu viele und dann hast du das Problem der false positives. Jede Menge Lücken werden angezeigt, wo wir sagen okay, aber die benutzen wir ja gar nicht. Die ist da zwar drinnen deklariert, weil man es auch mit einer anderen Datenbank benutzen kann, aber tun wir halt nicht. Das ist jetzt ein Beispiel, aber das große Problem ist, wenn man diese Scanner einschaltet, bekommt man oft eine ganze Menge von false positives. Der Stefan hat glaube ich auch ein ganz interessantes Beispiel über Spring oder so.
Stefan:
Ja, das ist in dem Fall, wo ich das tatsächlich in meinem aktuellen INNOQ Projekt gesehen habe. Nutzen den OWASP Dependency Check. Das ist ein Plugin, das für Java und auch für andere Plattformen gibt. Das basiert auf OWASP, das Open Web Application Security Project, ein Projekt das Tools und Guidelines rund um Security anbietet. Ich glaube, dass ihr da auch schon mal was dazu gesagt habt. Und die haben eben ein Tool, das eben genau solche Dinge tut. Das versteht Gradle und Maven und kann nachschauen, welche Abhängigkeiten mein Projekt hat und es basiert auf einer Datenbank, in der die bekannten CVEs drinnen sind. Diese Datenquellen sind manchmal ein bisschen krümpelig gepflegt. Es ist nicht so ganz klar, was damit jetzt gemeint ist. Und dann gibt es eben gelegentlich Meldungen, die überhaupt nicht passen, dass irgendein uraltes CVE, das gegen Spring Security in einer Version 2.0 irgendwas aktuell ist, irgendwas größer fünf gemeldet wird und gemeldet war. Und dann gibt es ein anderes Projekt, das auch aus dem Spring Security Kosmos kommt, aber eben nicht das Spring Security Projekt ist, sondern Spring Security OS irgendwas meinetwegen, das die Versionsnummer 2 irgendwas hat und dann wird dieser CVE gegen dieses Projekt gemeldet. Das heißt, man ist regelmäßig damit beschäftigt irgendwelche exclusions zu konfigurieren, weil man weiß, diese Regel schlägt hier einfach falsch an. Um sicherzugehen, dass man das tatsächlich dem Ganzen noch vertraut und nicht die übliche, er hat Wolf gerufen, dann kümmere ich mich da nicht mehr darum, weil er das ja immer macht Sache anfängt, dass man eben nicht mehr darauf hört, dass da Alarm geschlagen wird. Andere Aspekte vielleicht auch ganz wichtig ist, du sagtest, das kann man während des Bildprozesses ausführen. Das tun wir im Prinzip auch. Das nutzt natürlich nichts, wenn mein Projekt gar nicht mehr gebaut wird. Man muss das auch dann tun, wöchentlich, monatlich nicht ganz so oft, aber man muss es schon regelmäßig auf existierende Software ausführen, weil vielleicht zu dem letzten Zeitpunkt, an dem das Projekt gebaut worden ist, noch keine Sicherheitslücken bekannt waren, aber inzwischen welche bekannt geworden sind. Es reicht, dass es nicht in den Continuous Build Process einzusetzen. Zumindest dann reicht es nicht mehr, wenn die Projekte, über die wir reden, solche sind, die eben nicht mehr regelmäßig neue Entwicklungen sehen.
Christoph:
Ja, das erinnert mich daran, dass man bei so Container Scannern, die ja auch meistens in der Pipeline laufen, dass die oft auch nochmal passieren, wenn da die Container dann deployed werden. Time of Check, Time of Use läuft manchmal sehr weit auseinander oder kann sehr weit auseinander laufen. Und in dem Container sind halt auch wieder viele Sachen drinnen. Gerade wenn man Base Images hat oder so, wo alle Sachen drinnen stecken, die Ewigkeiten nicht mehr zusammengebaut werden. Das stimmt, da muss man ein bisschen aufpassen. Bei den false positives fällt mir auch noch ein Beispiel ein, das ich auch erlebt habe. Gerade bei Log4Shell gab es auch eine ganze Reihe an false positives, weil das Paket ist ja unterteilt, es gibt diesen ich glaube Log4j Core heißt das und es gibt das API. Das sind zwei verschiedene Pakete und das API sind ja nur die Interfaces und nicht die Implementierung. Und es ist API steckt auch in relativ vielen Projekten mit drinnen, gerade über transitive Beziehungen oder transitive Dependencies kommt das da rein, aber intern wurde einfach ein ganz anderer Locker benutzt, also nicht Log4j, sondern Tinylog oder Block Back und so und da haben die Scanner auch alle angeschlagen, weil halt noch Log4j drinnen stand, aber der Unterschied gar nicht gemacht wurde von den Tools, dass es da zwei Pakete gibt und man halt, wenn man das Core Paket hat, betroffenes und nicht wenn man nur das API Paket irgendwo drinnen hat. Das hat auch für viel unnötigen Alarm gesorgt. Das ist ja das große Problem dabei, wenn das zu oft kommt, dann wird so was einfach alles ausgestellt. Stefan sagte dann, pflegt man dann zu Exclusion List und oft ist es so, dass die Exclusion List das Sternchen ist, also alles. Das kennt man so auch wenn man sonst eine statische Analyse Tools machen, die so Quality checken und dann hat man da was, was ich wie viele Violations drinnen und so was weiß ich Sonarcube in ein bestehendes Projekt einbauen, da gibt es ganz viele Regeln. Jetzt gar nicht unbedingt sicherheitsrelevant sein müssen, sondern erstmal insgesamt für die Code Quality und dann ist alles rot und dann denkt man geht halt nicht. Und ja, dann muss man es halt ausschalten. Gerade wenn man mit so einer No Go Policy kommt, entweder geht das durch oder wir deployen oder wir bauen nicht und dann bekommt man 2.000 Verletzungen. Dann bauen wir erstmal die nächsten Monate nichts mehr, bis wir die alle gefixt haben oder wir schließen das mal alles aus, dann wird sich leider oft dafür entschieden, wir schließen alles aus, obwohl ja der Weg wäre zu sagen: Okay, wir machen die Regeln nicht so, dass wenn da irgendwelche Violations angezeigt werden von so einem Tool, dann machen wir kein Bild oder kein Deployment mehr, sondern zum Beispiel eine intelligentere Regel wie, nach jedem Commit darf die Anzahl der Violations nicht nach oben gehen. Dann geht das nicht, aber oft sind das leider so binär Entscheidungen. Ja gut. Schwieriges Thema trotzdem sollte man das deswegen nicht beiseiteschieben, sondern auch mal angehen, sozusagen mit ein bisschen Verstand einsetzen. Dann kann einem das auch weiterhelfen. Und es gibt noch einen ganz wichtigen Punkt, den hattest du auch noch aufgebracht, Stefan was man auf jeden Fall haben muss.
Stefan:
Ja, ich denke, man muss ein Stück weit akzeptieren, dass alle Abhängigkeiten, die man hat, Bugs haben, wie jedes Stück Software, das man selber geschrieben hat, auch Bugs hat und manche davon vielleicht auch sicherheitsrelevant sein können. Das heißt, wir müssen in unseren Projekten einfach auch in der Lage sein, neue Versionen zu nutzen von Software. Wir müssen in der Lage sein, Updates durchzuführen. Und das gilt nicht nur während der Entwicklungszeit, sondern insbesondere auch, wenn die Entwicklungszeit rum ist, damit man, wenn nachträglich Sicherheitslücken bekannt werden, noch in der Lage ist, den Softwarestack zu aktualisieren. Und man hat es gerade auch in einem Kontext von Log4Shell gesehen. Da wurde die Sicherheitslücke gepatched, basierend auf der neuesten Log4j Version, wo relativ schnell größere Anbieter kamen, deren Kunden auf Java 7 noch waren und Log4j seit, weiß nicht genau, Log4j 2.13 oder so was Java 8 als minimal Version hat, so dass dann die Log4j-Entwickler beschlossen haben, wir machen noch einen Patch Release für diese letzte Version, die auf Java 7 läuft, haben davon noch eine Version rausgebracht. Es hat nicht lange gedauert, bis die nächsten kamen und gesagt haben, wir brauchen aber noch Java 6, weshalb es ich jetzt gerade nochmal nachschaue, es gibt von Log4j 2.3, aktuell ist 2.17. Sie haben noch einen Minor Release, das 2.3.2 heißt, gemacht, weil das die letzte Version war, die noch unter Java 6 läuft. Damit eben Projekte, die immer noch auf Java 6 angewiesen sind, die wahrscheinlich trotz in einer Uralt-Version einsetzen und viele andere Projekte, die seit zehn Jahren nicht mehr weiterentwickelt werden, einsetzen und davon ausgehen, dass sie solche Sicherheitslücken noch stopfen können. Ich habe in dem Kontext auch viele Leute, ich bin eben auf den Logging Mailinglisten noch drauf und habe deswegen schon viele Leute gesehen, die überhaupt nicht in der Lage waren einzuschätzen, wie ihre Situation war. Dazu gehört eben auch zu wissen was meine Abhängigkeiten sind und in der Lage sein Upgrades durchzuführen. Es gab die Frage, ob ihre Log4j 1.X Version noch aktualisiert werden kann. Ein Projekt, das seit sieben Jahren offiziell für tot erklärt ist und dem offiziell bekannt gegeben wurde, wir werden nicht mehr weiterentwickeln, es wird keine Sicherheits Fixes geben, die aber auch nach sieben Jahren immer noch erwarten, dass man jetzt nochmal schnell irgendwas tun könnte. Die Migration von eins auf zwei ist nicht trivial. Das ist ein Budget, das oft nicht vorhanden ist. Wir haben ein Projekt, das Projekt ist abgeschlossen, was auch immer abgeschlossen für ein Softwareprojekt bedeuten kann. Es gibt vielleicht noch ein Wartungsteam, aber in der Regel läuft die Software dann für die nächsten Jahre bei einigen. Und das ist ein Zustand, der so nicht haltbar ist. Ich denke, da sind wir alle in unseren Projekten auch gefragt, auch wenn es darum geht zu entscheiden darüber, wie so ein Projekt am Ende der Entwicklungsphase weiterläuft. Es muss immer die Möglichkeit geben, noch zumindest solche Entwicklungen nachziehen zu können und aktualisieren zu können. Die Lücken in Log4j sind rund um Weihnachten gefixt worden und wir haben heute noch Server rumstehen, die anfällig sind, weil sie nicht aktualisiert werden können. Das ist nach sechs Wochen später eigentlich nicht akzeptabel, dass das nur aus Gründen, dass da vorher kein Budget für zur Verfügung gestanden hat, passiert. Da wird einfach viel zu kurz gedacht und ich glaube, da muss sich was ändern.
Christoph:
Es ist ja eigentlich auch absurd zu sagen, wir haben hier Java 6 Struts in uralt und wir fixen eine Lücke in Log4j. Meiner Einschätzung nach ist dieses Produkt oder diese Software trotzdem löchrig wie Käse, wie Schweizer Käse, weil x tausend andere Lücken da drinnen sind. Das ist ein bisschen Security Theater oder vielleicht die Entscheidung des Chefs, der das mitbekommen hat und sagt, dass muss noch gefixt werden oder so oder der Kunde, weil es so viel Öffentlichkeit hat. Aber das ist eigentlich absurd. Also, wenn man so punktuell sagt, aber dann braucht man einen Log4j. Eigentlich müsste es sein: Nein, wir brauchen eine komplette Renovierung eurer Software, mindestens auf den Dependencies. Muss ja gar keine Features sein, sondern mindestens sollt ihr auf dem Stand sein, wo alle bekannten Lücken gefixt werden. Aber gut, so ist das halt.
Stefan:
Wenn die Sicherheitslücke in einem Open Source Projekt in der Tagesschau kommt, dann weckt das glaube ich viele Leute, die sich da vorher nicht für interessiert haben. Die Sicherheitslücken in Java 6, die kommen da im Zweifel nicht.
Christoph:
Also vielleicht brauchen wir so in Tagesthemen und heute journal, da kommt immer die Börse und Wetter. Da brauchen wir noch den aktuellen Security Klima Bericht sozusagen, um zu sagen das und das ist aktuell, achtet da da mal darauf. Vielleicht muss das prominenter sein. Und ich sage das so scherzhaft natürlich, aber eigentlich stimmt das ja auch. Unsere Welt ist durch und durch computerisiert in irgendeiner Form und auch noch alles mit allem vernetzt. Von daher wäre das nicht schlecht, wenn man das besser in die Öffentlichkeit bekommt, die so abseits von der IT ist. Wir alle wissen das vielleicht, aber wir können uns unterhalten und unsere Hörer können uns da allen folgen oder so, aber das muss man auch ganz anderen Leuten beibringen, die damit nicht sofort was zu tun haben.
Lisa:
Schönes Schlusswort, Christoph, finde ich, oder habt ihr noch was zu ergänzen zu dem Thema ich glaube, wir haben es genug durchgenudelt.
Christoph:
Noch den Appell, dass man oder meine persönliche Zusammenfassung und Appell ist, es sollte nicht so kommen, dass Open Source Software schlecht ist, dass man die nicht benutzen sollte. Die sollte man schon weiter benutzen, aber nicht so völlig bedenkenlos, wie man das so macht. So ein bisschen Nachdenken vorher dabei und auch nicht blind. Nicht einfach sagen: Ah, da ist was, schnell in meine package.json rein oder in meine gomodules Datei oder in meine pom.xml. Nicht einfach blind alles aufnehmen, sondern ein bisschen nachdenken und dann ein paar Maßnahmen trifft, die wir auch am Ende genannt haben, dann kann man glaube ich Open Source auch weiterhin gut benutzen. Das wäre glaube ich für alle ganz gut.
Lisa:
Prima, vielen Dank euch beiden, dass ihr heute hier wart und mit dem Podcast aufgenommen habt und vielen Dank an alle Zuhörerinnen und Zuhörer, dass ihr zugehört habt. Und hoffentlich hat es euch auch gefallen, wenn ihr Feedback geben möchtet, entweder zur heutigen Folge oder auch zum Security Podcast generell, könnt ihr das gerne per Mail tun und zwar an [email protected]. Und wir bedanken uns recht herzlich bei euch und sagen Tschüss und bis zum nächsten Mal.
Christoph:
Ciao!