34c3 preroll music Herald: Der Fefe hatte mich gebeten, mich kurz zu halten, weil, er hat Angst, dass der Talk nicht in die 30 Minuten passt. Von daher gebe ich jetzt mal Gas und sage: „Antipatterns und Missverständnisse in der Software-Entwicklung“! Und wie sagte jemand gestern? „Ach Fefe! Das ist doch der mit der Kolumne beim ehemaligen Nachrichtenmagazin!“ Here we go! Applaus Fefe: Hallo hallo. Hallo hallo. Ja, ja vielen Dank, dass ihr so zahlreich erschienen seid. Ein bisschen zahlreicher, als ich gedacht habe. Nächstes Mal mache ich doch lieber parallel zu Minkorrekt wieder. Es geht um Antipatterns. Antipatterns sind Sachen, die man macht, die man häufig macht, die populäre Maßnahmen sind, um ein Problem zu lösen, die dann aber entweder gar nicht funktionieren oder nach hinten losgehen. Und ich habe mir gedacht, beim Congress gibt es immer so schöne Streitereien um das Motto. Da mache ich auch mal ein Motto. Und das hier ist so ein Motto, was ich sehr profunde finde, und wo ihr hoffentlich im Laufe des Vortrags sehen werdet, warum das das Motto ist. Ja, „wer lesen kann, aber es nicht tut, hat keinen Vorteil dem gegenüber, der das nicht kann“. Die Struktur des Vortrags… Applaus Die Struktur des Vortrags will ich an einem Beispiel kurz umreißen. Es geht immer damit los, dass wir ein Problem haben. Dann geht immer Seal Team 6 los und hackt irgendwas. Also denkt euch hier ein Team von Spezialexperten. Ja ich will jetzt nicht die Seals beleidigen, bestimmt auch alles nette Leute. Und dann kommt eine Umsetzung, da geht es meistens in die Hose. Und dann haben wir einen Effekt, und hoffentlich, hoffentlich eine Erkenntnis gewonnen. Ich habe mir gedacht, wir versuchen mal so eine interaktive Komponente. Und zwar wenn man sich so Übertragungen aus dem britischen Parlament ansieht, dann gibt es immer so ein Gemurmel, wenn die Leute zustimmen. Und ich dachte mir, wenn ich sage, „Hebt mal den Arm, wenn euch das mal passiert ist“, dann haben die Leute vielleicht Angst, auf dem Stream zu landen und sich zu outen. Deswegen dachte ich, wir murmeln mal. Also wenn einer von euch sich bei einem Muster wiedererkennt, könnt ihr mal versuchen. Wir gucken mal, ob das klappt. Ja, vielleicht hört man das dann. Okay. Also, erstes Problem. Dieses Bild, ich möchte das gleich dazusagen, Lachen ist mir gespendet worden. Ich liefere hier keine Kunden ans Messer, und es geht nur um Anekdoten. Also wer sich glaubt, wiederzuerkennen, liegt wahrscheinlich falsch. So, das ist ein typisches Problem in der Software-Entwicklung: die Versionierung von und die Backups von alten Versionen aufzuheben. Das ist hier, ich hoffe, ihr habt das gesehen oben in der Ecke, das ist ein USB-Stick. Und die typische Idee ist: Wir machen jetzt mal ein Versionierungssystem! Und das ist eine gute Idee. Die Umsetzung ist dann gewöhnlich: der, der gerade ein akutes Problem hat, bastelt schnell was, und dann kriegt man so ein Git. Und Git ist eigentlich gut, aber man hat halt nicht nur Git, sondern man hat dann noch so ein paar andere Versionierungssysteme, und da gehen dann die Probleme los. Ja also, ich habe mal einen, ich habe mal so einen Kunden gehabt, die meinten: „Ist im Git“, und dann meinte der Typ daneben: „Ja, musst noch sagen, in welchem“. Also das kommt vor. Lachen Ein anderer Effekt, den man häufig sieht, ist, dass jeder überall einchecken darf. Und das führt dann zu so Sachen wie: man meldet als Bug so was wie: „In dem Image sind aber noch set-UID-Binaries“ oder sowas. Und dann machen die die alle weg, und dann installiert man die nächste Version, und dann sind wieder welche, und dann sagt der Typ: „Ja, ich habe die zwar alle weg gemacht, aber hat halt ein Developer wieder rein gemacht“. Also Versionierung reicht noch nicht. Da muss man noch mehr machen. Überhaupt die Idee, dass Leute Binaries einchecken, ist eine ganz schlechte. Das findet man immer wieder. Ich rede jetzt hier nicht von png oder irgendwie ein mpeg von einer Webseite oder sowas, sondern so eine Library oder ein Executable. Das sollte man eigentlich nicht tun. Es gibt ganz wenige Ausnahmen. Wenn ihr eine von den Ausnahmen habt, wisst ihr es, und ansonsten macht es nicht! Das hier ist jetzt natürlich überspitzt, aber so ähnlich habe ich das schon mal gesehen, dass Leute verschiedene Versionen einchecken, aber nicht verstanden haben, was eigentlich die Aufgabe von so einem Versionierungssystem ist. Das ist auch nicht gut, macht das nicht! Ich habe dann immer so einen Ratschlag am Ende von den jeweiligen Antipatterns. Und mein Ratschlag für Versionierungssysteme ist: Git ist schon in Ordnung. Ich bin mir der Ironie bewusst, dass meine eigene Software im Moment als CVS im Internet ist. Das hat historische Gründe! Lachen und Applaus Patches hält man am besten klein, damit man sie einzeln anfassen kann, wenn sie nicht sauber applyen. Das ist ein Riesenproblem, wenn jemand so einen Megabyte-Patch abliefert. Deswegen macht das nicht. Wenn ihr größere Sachen vorbereiten müsst, dann macht das nicht als einen großen Patch, sondern nehmt einen eigenen Branch dafür. So ein Versionierungssystem will euch helfen. Also beschäftigt euch mit den Features, die sie euch bieten. Wenn man Annahmen hat, über, welche APIs verfügbar sind, oder welche Versionen von Komponenten drin sein sollen, sollte man das im Build in einem Skript checken. Und nicht erst anfangen zu bauen, und nach zwei Stunden abbrechen, weil irgendwas nicht geklappt hat. Sowas möglichst vorher testen, damit es schnell failt, damit man schnell reagieren kann. Es gibt häufig so die Idee in Firmen, dass man verschiedene Abteilungen hat und jede hat ihr eigenes Versionierungssystem oder ihr eigenes Repository. Und das kann funktionieren, aber es ist sehr selten, ja? Häufig, der… der… die Sache, die stimmen muss, damit es klappt, ist, dass die APIs stabil sind. Und erfahrungsgemäß glauben alle, dass ihre APIs stabil bleiben werden, und sie sind es dann aber nie. Also wenn ihr das vermeiden könnt, macht das nicht. So, das nächste Problem ist: die Bugs fallen immer unter den Tisch, werden vergessen, gefixt zu werden. Und die offensichtliche Lösung ist: wir machen so einen Bugtracker. Umsetzung ist natürlich wie immer Seal Team 6. Und der Effekt, der sich ganz schnell einstellt, ist, dass man merkt, man hat ganz viele Bugs. Und das ist dann gleich das nächste Problem: wir haben so viele Bugs, was machen wir jetzt? Eine Sache, die ich inzwischen als Antipattern sehe, ist: Priorisieren von Bugs. Ja, so eine übliche Umsetzung ist: man hat sowas wie „Severity: Blocker“ oder das ist ein Security-Bug – das soll hier eine Checkbox sein. Und der Effekt davon ist, dass alle anderen Bugs liegen bleiben. Das kann man immer und immer wieder beobachten. Also die… der eigentliche… was ich so beobachte, der, der Effekt, der die meisten Bugs tötet, ist, wenn eine Komponente einfach abgeschafft wird. Und dann kann man alles schließen in der Komponente. Dass tatsächlich mal sowas weggeht, gibt es nicht. Applaus Es gibt ein schönes Wort dafür, wo mir jetzt die Übersetzungsteams bisschen leid tun, nämlich Bug-Welle, im Sinne von einer Bugwelle vor so einem Tanker. Ich versuche das gerade mal zu etablieren, als Begriff. Ich finde den nämlich sehr schön. So, also jetzt haben wir ganz viele offene Bugs, was machen wir denn jetzt? Nächstes Problem. Und eine Idee, die häufig kommt, und die auch erstmal total super klingt, ist, dass man bug-freien Code belohnt. Und zwar am besten mit so einem Bonus, am besten in Geld. Wenn euer Team keine offenen Bugs hat, dann werdet ihr belohnt. Und das führt eben dazu, das ist mir mal passiert, dass ich so eine Mail gekriegt habe von einem Typ, wo ich ein paar Bugs gefilet habe, und der kommt und meint: „Du Arschloch, jetzt ist mein Bonus weg. Ich kann meine Hypothek nicht abzahlen!“ Und da wusste ich dann auch erstmal nicht direkt, was ich dem sagen soll. Der hat das dann selbst gelöst, indem er alle Bugs zugemacht hat und zwar mit NOTABUG. Lachen Hat mir natürlich versprochen, dass die trotzdem alle gefixt werden. Aber das könnt ihr euch ja vorstellen, wie gut das klappt. Also sowas ist sehr… ist sehr mit Vorsicht zu genießen. Reward- und Incentives-Sachen am besten nicht mit Geld. Es gibt auch ein Anti-Antipattern dazu. Nämlich habe ich mal erlebt, dass jemand alle Bugs im Code gefixed hat, aber im Bugtracker waren die noch offen. Und dann habe ich nicht verstanden, bin hingegangen, und dann hat er mir erklärt: „Ja, die brauchen mich ja nicht mehr, wenn die Bugs zu sind.“ Lachen und Applaus Der hat halt gesehen, hat halt gesehen, um ihn rum die Kollegen sind alle nach Indien abgeschoben worden, die Projekte, und hat sich gedacht: „Na, die lass ich lieber offen, die Bugs, dann werde ich hier noch ein paar Monate bezahlt.“ Das hat mir echt, das fand ich echt atemberaubend. Da habe ich so ein paar Tage schlecht geschlafen. Weil das ist ja schon… was für ein Selbstbild hat der denn, wenn er glaubt, irgendwie diese, diese Einträge im Bugtracker halten ihn da am Leben? Ganz furchtbar. Aber das gibt es in kleineren Ausmaßen häufiger, dass Leute Bugs offen lassen, weil sie wissen: wenn die Bugs weg sind, dann kommt der Chef mit der nächsten To-Do-Liste. Und der einzige Weg, mal eine Woche Luft zu haben, ist einfach, die Bugs nicht zu fixen. Das gibt es häufiger, achtet mal darauf in eurer Firma, ob ihr das auch sehen könnt. Ich würde fast wetten: ja. Das ist ein häufiges Pattern. Das ist auch ein Klassiker hier. Man hat ein tolles Projekt, und das ist wunderbar, aber es funktioniert nur auf dem Rechner vom Entwickler. Und die Idee ist: man hat jetzt einen Build-Server, ja? Wir haben jetzt einen Build-Server, da wird gebaut, das ist eine neutrale Umgebung, alles super. Seal Team 6 bastelt kurz was, und das sieht auch echt geil aus, ja? Hier, so Drohnen-assistierte Baugeschichten. Aber übliche Sachen, die halt fehlschlagen, ist, dass dieser Build- Server von dem Team ist, und baut halt den Code von dem Team. Und die anderen Sachen werden aus irgendwelchen antiken Snapshots von anderen Leuten reingezogen. Oder was ich auch mal gesehen habe: dass Libraries dann so per SMB da reingelinkt werden. Und das ist natürlich totale Scheiße, ja? Aber das passiert, so was passiert. Eine häufige Sache, die man auch sieht, ist, dass man so einen Build-Server hat, aber da muss dann jemand hinlaufen und so „Build“ klicken. Und das ist auch nicht schlau. Ich habe hier mal versucht, ein Bild herauszusuchen. Die Idee beim Build-Server ist es, dass der am besten automatisiert baut, und zwar mindestens einmal täglich. So, das habe ich auch schon erlebt: der Build ist fehlgeschlagen, und dann hat der Entwickler eben auf dem Build-Server angefangen, irgendwelche Dateien zu editieren. Das ist jetzt gerade im Wachstum von Devops ein Problem, was wir häufiger sehen werden, glaube ich. Das macht natürlich den Vorteil vom Build- Server komplett kaputt, ja? Weil, dann habe ich wieder den Effekt, das ist ja der Rechner vom Developer, aber es ist halt nicht mehr der unter seinem Tisch, sondern in dem Rack da hinten, wo „Build-Server“ dransteht. So, ich hoffe, dass wir demnächst ein Debian haben werden, was diese Namenskonvention übernimmt. Gelächter Das sieht man auch häufig, ja, nicht nur auf Build-Servern, sondern das wird halt irgendwann aufgesetzt und danach bleibt das halt so. Und das hält das ganze Projekt zurück, weil dann irgendwelche Software-Versionen da drauf sind. So übliche Sachen sind irgendwie eine SSL-Library, die kein aktuelles TLS 1.2 kann. Und das werden wir mit 1.3 demnächst wieder haben, das Problem. Oder irgendwie ein uraltes C++, und dann können die Leute die neuen Features nicht benutzen. Also das ist alles ganz furchtbar. Will das mal hier mit so einem schönen Müllhaufen illustrieren. Der Grund, warum man einen Build-Server hat, ist, dass man täglich bauen kann, automatisiert, ohne dass da jemand hingehen muss, und ohne dass jemand hingehen kann, um irgendwas zu fixen. Da gibt es keine Interaktion außer: „Bau mal diese Version“, ja? Der Build soll deterministisch sein. Das ist leider unabhängig vom Build-Server, muss ich euch erzählen. Es gibt tatsächlich Build- Prozesse, da fällt jedesmal ein anderes Binary raus, auch wenn man keine neue Version ausgecheckt hat, weil irgendwie parallel gebaut wird und irgendwelche Dateien, die gebraucht werden, werden asynchron von anderen Teilen aus dem Parallel-Build erzeugt. Und wenn man Glück hat, kommt die richtige an. Und wenn man Pech hat, halt nicht. Also das muss man fixen. Das ist Arbeit. Und es wäre mir sehr lieb, dass so Open-Source-Entwickler auch alle dafür sorgen, dass ihre Projekte mit beliebiger Parallelität baubar sind. Der nächste Grund für Build-Server ist Agilität. Applaus Ja? Wenn ich irgendwas kaputtgemacht habe, dann soll keine Panik ausbrechen, sondern dann sage ich „Rollback“ und bau halt die Version von vorhin nochmal, die funktioniert hat. Wenn das nicht ein Knopfdruck ist, dann könnt ihr den Build- Server auch wegschmeißen. Und natürlich möchte man möglichst schnell mitkriegen, wenn jemand was eingecheckt hat, was den Build bricht. Aber nicht sanktionieren! Ich habe mal so eine Firma erlebt, die hat dann so ein Britney-Spears-T-Shirt gehabt, und das musste der Typ tragen, der den letzten, zum letzten Mal den Build gebrochen hat. Lachen und Applaus Macht das nicht. Das hat gut funktioniert, bis sie so einen Britney-Spears-Fan als Angestellten hatten. Lachen Ja. So, also das nächste Problem: ich habe jetzt zwar einen Build-Server, und der baut das zwar unabhängig vom Entwicklerrechner, aber das Binary funktioniert nur auf dem Rechner vom Entwickler. Ist ein subtil anderes Problem, aber verwandt. Und das löst man heute mit Docker, ist ja klar! Applaus Und Docker ist im Prinzip keine schlechte Idee. Man darf halt nicht Seal Team 6 basteln lassen. Denn da kommen dann so Effekte wie: ich lutsche mir irgendwelche Images von irgendwo aus dem Internet rein. Klassiker sind so Ramses- der-Zweite-Debian und MySQL drei Punkt irgendwas von neunzehnhundert-äh. So, dafür ist Docker nicht da. Docker ist gerade dafür da, dass das agil änderbar ist. Und wenn ihr das nicht macht, dann ist es, als wenn ihr nicht lest. Könnt ihr euch das gleich sparen. Also ich habe hier mal Frankenstein als Illustration gebracht. Das bringt nichts. Dann habt ihr so ein Schrott-Projekt am Ende. Ich sehe das häufig in der Industrie, dass die Leute alle Nachteile mitnehmen, aber die Vorteile gezielt stehen lassen. Lachen und Applaus Häufig gerade bei so Build-Systemen und Docker ist, dass man die Komponenten in irgendwelchen statischen Versionen hart- codet, die halt aktuell waren, als es aufgesetzt wurde, und danach nicht mehr geupdatet werden, ja? Also ich habe in den letzten Jahren immer mehr Leute mit Build-Servern gesehen, die alles automatisiert bauen. Und alle Dateien im Image haben so denselben Time- Stamp grob. Also man sieht, dass es alles frisch gebaut wurde, aber es sind trotzdem Versionen von 2004. Das ist sehr häufig, achtet darauf bei euch, ja? Und wenn ein Zulieferer euch Kram gibt, der vom Build-Server kommt mit alten Versionen, dann weist ihn darauf hin. Negatives Feedback. Das ist sonst wie so ein Rollator: bremst nur. Container hat man für automatisiertes Deployment in deterministischem Zustand. Das ist eine Sache, die haben fast alle verstanden. Aber was nicht so verstanden wird, ist dieser, der Rollback ist eben auch trivial, wenn man das mit so einem Docker- System baut. Dann klicke ich halt „Mach mal die alte Version“ und dann fällt das Image der alten Version raus. Das ist ein Feature, das ist nicht ein Seiteneffekt, sondern das ist einer der Gründe, warum man das überhaupt hat. Nutzt das auch. Das ist nicht mehr… es tut nicht mehr weh, wenn man was kaputtmacht im Build, sondern dann kann ich zurückrollen. Nicht nur im Versionierungssystem, sondern ich kann auch einfach komplett, einen neuen Build, fällt dann halt raus. Und am besten macht man sowas über die Mittagspause, ja? Daher vorhin der Ratschlag, im Skript Abhängigkeiten testen. Und nicht nach zwei Stunden den Build failen lassen. Docker ist… und Container sind eigentlich eine gute Idee. Aber die meisten Leute nehmen nur die Nachteile mit. Komponenten kann man agil updaten. Das muss man auch tun. Also ist hier keine schwarze Magie, die ich hier erzähle. Aber es ist erstaunlich, wie viele Leute das nicht machen. Und der mir als Security-Typ natürlich am wichtigsten erscheinende Aspekt bei Containern ist, dass man damit Komponenten im Gesamtsystem isolieren kann voneinander. Dass nicht ein Typ, der diesen einen Prozess hackt, automatisch alle anderen im Zugriff hat. Sondern die laufen halt in ihren eigenen Containern. Aber in der Praxis sieht man, dass dann der Monster-Container gebaut wird mit den 50 Komponenten drin. Das ist nicht gut. Also nehmt alle Vorteile mit. Richtig gut ist das natürlich erst in Kombination, ja? Der Git hat alle Versionen und dem Build- Server kann ich eine Version zurufen und dann fällt ein Image raus ohne Abhängigkeiten. So, wenn ihr das nicht habt, dann benutzt ihr das nicht richtig. Ganz einfach. Das nächste Problem ist: Der Code funktioniert nicht. Das kennen wahrscheinlich auch alle, ist ein Problem. Was machen wir jetzt? Und die Lösung ist: Unit-Tests! Und die Umsetzung ist häufig: ich habe hier gerade einen Bug, den fixe ich mal, und den Check, ob der Bug weg ist, den mache ich jetzt als Unit-Test. Ja und das ist nicht gut. Da kriegt man dann so eine Coverage von 2,3 Prozent, wenn es hoch kommt. Und ich weiß nicht, ob ihr alle das Video hier gesehen habt. Das war so ein Automat, der erkennen sollte, ob eine Hand drunter gehalten wurde. Und der wurde halt von Weißen gemacht. Und die haben halt nie eine andere Hautfarbe getestet. Und da kommt dann halt nix raus. So, das ist ein typischer Fall von „Unit- Test-Abdeckung zu gering“. Ich glaube auch, dass hier die Perspektive die falsche ist häufig. Die Leute glauben, sie machen Unit-Tests, damit sie wissen, dass der Code jetzt okay ist. Nein! Unit-Tests sind dafür da, dass sich was ändern kann und [man] sehen kann, ob es -noch- geht. Damit ich keine Angst mehr haben muss, alten Code anzufassen. Das ist das, was Unit-Tests euch abnehmen: die Angst, in altem Code was zu fixen. Weil ihr den nicht komplett versteht oder so. Und je mehr Abdeckung ihr mit den Unit-Tests habt, desto stärker ist diese Waffe. Nutzt das. Applaus Ich muss hier ein bisschen durchgaloppieren, weil ich zu viele Folien habe. Ich hoffe, das verzeiht ihr mir. So, das nächste Problem sind, dass die Leute nur positive Tests haben. Die gucken: funktioniert das hier? Und der Effekt ist normalerweise so gut wie keiner, denn die ganzen interessanten Bugs sind in der Fehlerbehandlung, dafür braucht ihr auch Unit-Tests. Und zwar müsst ihr eigentlich für alles, was fehlschlagen kann, einen Test haben, der das fehlschlagen lässt. Und dann gucken, ob das immer noch funktioniert, wie es soll. Das sind die Sachen, die am Ende über Bande woanders einen Fehler erzeugen, ja? Irgendwie eine Memory Corruption in einem Fehlerfall, oder irgendwie „RAM wird nicht freigegeben im Fehlerfall“. Und dann stellt sich raus: das kann man als Angreifer triggern. Und dann habe ich einen Remote-Memory-Leak und der Prozess crasht. Diese Art von Sachen sind völlig überflüssig und mit ordentlichen Unit-Tests abfangbar. Also macht das. Unit-Tests sind aber kein Allheilmittel, den Eindruck möchte ich nicht vermitteln. Selbst wenn ich 100% Unit-Test-Coverage habe, kann ich immer noch einen Fall übersehen haben. Dennoch: das ist ein Ziel, was ihr haben solltet. Es gibt Tools, um die Coverage zu prüfen. Nutzt diese Tools. Das ist wichtig. So, der nächste Fall, jetzt habe ich Unit-Tests ausgerollt, ist: die Entwickler haben Fälle vergessen zu testen, ja? Das kommt häufig vor. Und da gibt es einen neuen Hype: Test- Driven-Development. Du schreibst erst die Tests und dann den Code. Und da kann ich leider nichts zu sagen, weil ich das noch nie in der Produktion gesehen habe. Ich kenne nur Leute… Lachen und Applaus Ich kenne nur Leute, die sich ganz sicher sind, dass das total geil ist. Aber ich habe es noch nie… also wenn ihr da irgendwie wisst, dann schreibt mir mal eine Mail, das würde mich echt interessieren. Ja, das nächste Problem ist: wir haben hier Code, und der tut irgendwas, aber wir haben keine Ahnung, wie das funktioniert. Und die Lösung ist natürlich: Dokumentation! Ist auch eine gute Idee, das will ich keinem ausreden. Aber es kommt häufig vor, Seal Team 6 setzt ein Wiki auf, und da gibt es ganz häufig so Effekte – da werde ich hier Congress-Teilnehmern nichts Neues erzählen – das Zertifikat ist gerade abgelaufen oder das Wiki wirft Exceptions oder ist nicht erreichbar oder so. Das ist ganz häufig. Und dann fallen so Sätze wie: „Ja, das hatte ich, glaube ich, ins Wiki getan“. Und so: „Ja, das musst du halt bookmarken, weil Navigation haben wir noch nicht“. Und ganz häufig gibt es auch: „Jaja, das hier oben, das stimmt nicht mehr“. Also Wiki ist keine Lösung. Je kleiner man die Schwelle setzt dafür, da was zu editieren, desto mehr fällt es unter den… vom Tisch. Weil die Leute einfach das nicht als als wichtigen Schritt sehen, sondern als so kleines Ding. Das muss ein richtiger Schritt im System sein, im Produktivbetrieb, dass man sagt: „Jede Änderung wird dokumentiert, Punkt.“ So, die nächste Idee, die man in großen Firmen häufig hört, dass man sagt: „Wir müssen hier mehr Kommunikation haben, die Leute reden zu wenig miteinander“. Und dann hat man so Großraumbüros. Lachen und Applaus Habe ich auch noch nie funktionieren sehen. Das klappt nicht, ja? Menschen müssen sich mal am Stück konzentrieren können. Und je mehr Unterbrechung man hat, desto schlechter ist das. Und heute geht der Trend sogar dahin… Applaus Heute geht der Trend sogar dahin, dass die Leute sich Slack installieren. Die plakatieren gerade in Berlin. Also, die sich absichtlich gegenseitig unterbrechen. Ist mir völlig ein Rätsel, warum Leute sowas tun würden. Denn nach jeder Unterbrechung braucht man so eine Viertelstunde, bis man wieder drin ist. Und diese Chatsysteme und auch Mail- Unterbrechungen sind darauf ausgelegt, dass man nie diese 15 Minuten schafft. Ja, ich weiß, die Zeit ist knapp, ist gut! lacht Lachen Meetings, ja. Meetings. Da muss ich, glaube ich, nicht viel zu sagen. Aber der Effekt ist immer derselbe: ich kann mich nicht konzentrieren. Und das ist ein ernstes Problem. Da muss man aktiv gegenhalten, ja? Das ist nicht so einfach. Ich habe jetzt überlegt: soll ich vorschlagen, die Meetings kurz zu machen? Aber das ist so, habe ich auch nie funktionieren sehen, den Ratschlag. Alle Leute glauben immer, sie machen ihre Meetings kurz. Funktioniert nicht. Daher sage ich: lieber selten und One-on-One. Denn wenn man jetzt irgendein Problem klären will, und da sitzen alle Leute aus dem Team, dann gibt es eine höhere Schwelle für den Einzelnen, zu sagen: „Ja, da habe ich einen Fehler gemacht.“ Deswegen lieber einzeln. Applaus Niemand, niemand hat Bock darauf, sich vor seinen Kollegen zu entblößen. Und das muss man also nicht künstlich herbeiführen. So, jetzt kommen wir zur Security-Abteilung. Wir haben Code und er tut irgendwas, aber wir trauen dem nicht. Was machen wir jetzt? Nächste Idee: naja okay, wir machen erstmal die Compiler-Warnungen weg, ja? Gute Idee. Der Effekt ist – und ich war schockiert, dass es da einen Begriff für gibt: Onion-Code. So, Onion-Code bedeutet, dass ich so einen Chunk Legacy-Code habe, der total viele Warnungen drin hat, und den seit fünf Jahren keiner mehr angefasst hat. Und da findet jetzt jemand einen Bug drin. Und der würde den gerne fixen. Aber dann compilet der Rest immer noch mit den ganzen Warnungen. Und die müsste ich dann fixen, damit ich den Fix einchecken kann für den Bug. Und ich verstehe diesen Code aber nicht. Ich verstehe nur den kleinen Teil, wo ich den Bug gefunden habe. Und dann mache ich einen Layer drum rum, und der guckt diesen einen Fall, fängt ihn ab. Und wenn das mehrere Leute machen, hat man so eine Zwiebel. Und deswegen heißt das Onion-Code. Das ist ganz furchtbar, ja? Wenn ihr das irgendwo seht, dann ‚burn it with fire‘! So, nächster Vorschlag: wir haben nur noch Releases ohne offene Bugs. Das klingt auch total super. Und ich war auch mal bei einem Kunden, der das probiert hat, und da kam dann so eine Mail: „Mach mal deine Bugs alle zu.“ Und dann meine ich so: „Ich bin aber hier, um Bugs aufzumachen, nicht um sie zuzumachen.“ Und dann meinte er: „Ja, die machen wir danach wieder auf, keine Sorge.“ Lachen und Applaus Muss ich, glaube ich, nicht erläutern, ob die wieder aufgemacht wurden oder nicht. Ja, externer Audit, und das tut mir in der Seele weh, denn das biete ich geschäftlich an, ja, das ist leider auch teilweise ein Antipattern. Denn was hier passiert, ist, dass die Leute so einen Blackbox-Pentest beauftragen. Und ein Blackbox-Pentest heißt, der Tester hat keinen vollen Zugriff auf das System, der weiß nicht, wie das funktioniert, sondern soll das in dem Test selber rausfinden. Und dann passiert sowas hier. Und was mich an der Stelle am meisten beeindruckt hat, ist, dass es dieses Bild schon gab. Das habe ich jetzt nicht gemacht. So, das ist leider üblich. Man testet nicht den Code, sondern man testet den Pentester. Und ich als Pentester habe jetzt natürlich… könnte jetzt sagen: „Ja, ist mir doch egal, wen die da testen, solange ich bezahlt werde.“ Aber ich habe da so einen Moralkodex. Ich hätte gern dem Kunden geholfen und nicht nur das Geld genommen. Das ist für alle Seiten Scheiße. Macht das nicht. Ja, Pentests. Ich sage, das ist ein Compliance-Problem, dass die Leute alle aus Compliance-Gründen Pentests machen. Und das ist eigentlich an sich schon ein furchtbares Zeichen, dass wir die Security nicht hinkriegen, sondern Compliance brauchen, um uns dazu zu bringen, dass wir doch Security machen. Wir sollten uns alle schämen! Fuzzing ist auch so ein Ding. Das wird gerne gemacht. Fuzzing heißt, dass ich zufällige Eingaben generiere und gegen meinen Endpunkt werfe und gucke, ob der platzt oder nicht. Und das ist erschütternd erfolgreich, ja? Das funktioniert. Und ich habe mal erlebt, dass sie gesagt haben: „Nee, den Code hier, den musst du nicht testen, den haben wir schon zu Tode gefuzzt. Seit Monaten läuft unsere Fuzzing-Farm.“ Und da stellt sich dann heraus: die haben zwar Milliarden von Test-Cases geprüft. Aber das war immer derselbe. Lachen Total super. Und häufig ist Fuzzing so ein Feigenblatt, womit dann andere Maßnahmen nicht gemacht werden, weil wir haben doch schon gefuzzt, und das ist auch in Ordnung, ja? Also ich habe nichts gegen Fuzzing an sich, denn es funktioniert leider. Aber es darf kein Hindernis dafür sein, andere wichtige Maßnahmen zu machen. Das ist ein generelles Problem, was ich häufiger sehe, dass, wenn das Management die Wahl hat zwischen einer Maßnahme, die wahrscheinlich funktioniert, aber keine Metriken abwirft, und einer Maßnahme, die wahrscheinlich nicht funktioniert, aber Metriken abwirft, dass immer die mit den Metriken gemacht wird. Management liebt qualifizierbare Geschichten, wo irgend… quantifizierbare Geschichten, wo irgendeine Zahl rausfällt. Und das geht häufig nach hinten los, ja? Ich habe also mal so ein… das war ein wirklich schockierendes Erlebnis für mich. Ich bin, ich sage mal preiswert, aber nicht billig, ja, also meine Tagessätze. – Ich weiß, ich weiß! – So und dann gehe ich dahin, zu dem Kunden, und der Kunde sagt: „Geh mal nach Hause.“ Also ich wurde trotzdem bezahlt, ja? Haben gesagt: „Geh mal nach Hause.“ Und ich so: „Wie jetzt?“ „Ja, ist warm heute.“ Meinte ich so: „Was?“ „Ja die Klimaanlage reicht für das Fuzzing-Lab oder die Consultants.“ Lachen und Applaus Ja. Gut. Das nächste Problem, das ist so ein bisschen schwierig. Aber es ist mir sehr wichtig, weil das so gerade im Kommen ist. Die Coder sind überfordert. Und dann sagt man: wir brauchen irgendeinen soliden Ansatz. Thread-Modeling! Das ist gerade im Kommen. Und das ist eine gute Geschichte, aber es wird häufig missverstanden. Thread-Modeling, der übliche Ansatz ist, dass man sagt: jedes Team macht ein Thread-Model für den Code. Das ist gut. Ja? Aber häufig macht dann der Feature-Owner oder Projektmanager mit dem Dokumentationsteam zusammen, füllt irgendwelche Formulare aus, und die Developer sind überhaupt nicht betroffen. Und das ist ein krasser Fehler. Denn beim Thread-Modeling geht es nicht um das Papier am Ende. Das ist kein Zertifikat. Sondern es geht um den Weg zum Papier. Es geht darum, dass die Entwickler mal aus der Sicht des Angreifers versuchen, auf ihren Code zu gucken, dass sie verstehen, was da Angriffsoberfläche ist, dass sie sehen, wo die Sachen sind, auf die man aufpassen muss, welche Angriffe denkbar sind. Wenn jemand anderes das Thread-Model macht, das hätte man sich auch sparen können, ja? Also: Thread-Model ist gut, aber das müssen die Entwickler machen. Wir sind fast durch. Ich habe noch ein paar allgemeine Ratschläge, weil ich mir dachte: ich kann euch hier nicht so deprimiert nach Hause gehen lassen. Aus Sicht des Management ist aus meiner Seite ganz wichtig, dass man eine Fehlerkultur etabliert. Das heißt: niemand wird bestraft für Bugs. Denn sonst verstecken die Leute Bugs, und das ist noch schlechter, ja? Man muss Leute belohnen, … Applaus Man muss Leute belohnen, wenn sie einen Bug finden und fixen. Aber nicht mit Geld belohnen, sondern mit Ruhm und Ehre. Ich schlage immer vor, einmal die Woche, irgendwie Freitag ab 4 oder so, macht man so ein All-Hands-Meeting, wo – wenn die Leute wirklich was Anderes vorhaben, müssen sie nicht hingehen, also kein Zwang – aber wo dann die alten Hasen ihre schönsten Bugs erklären, ja? Damit es als etwas Positives gesehen wird, einen Bug zu finden, und damit die Jungen was dabei lernen. Das ist eine gute Sache, das kann ich empfehlen. Das funktioniert auch gut, und das bringt auch das Team zusammen. Und es nimmt so diesen Rockstar- Status weg, der auch nur schadet. So, die nächste Sache ist, dass man dafür sorgt, dass der Bug auch von dem gefixed wird, der den Code geschrieben hat. Es gibt große Firmen, die teilweise ein zweites Team dafür haben, Sicherheits-Bugs zu fixen. Und dann kriegt der Typ, der das programmiert hat, überhaupt nicht mit, dass er die ganze Zeit schlechten Code programmiert. Der zieht dann am besten noch so von Team zu Team, hinterlässt überall so Tretminen. Das ist wichtig, dass es Feedback gibt. Und zwar nicht als Strafe, sondern damit die Leute merken, wenn sie Fehler machen, ja? Menschen lernen aus ihren Fehlern. Dafür muss man verstehen, wenn man einen Fehler gemacht hat. Und das ist die, wo… komme ich zurück zu dieser Meeting-Kultur. Wenn man ein Meeting hat und sagt: „Du hast hier aber Scheiße gemacht“, dann macht man den vor dem ganzen Team nackig. Das hilft überhaupt nicht, ja? Man… es ist auch eine Kulturkreis-Frage. Manche Kulturkreise können damit besser umgehen als andere. Aber es gibt eben viele Leute, die haben ein starkes Problem damit, dass ihnen gesagt wird: „Du hast einen Fehler gemacht“, ja? Weil das, in Japan zum Beispiel ist es sehr wichtig, dass man der Firma hilft und nicht gesehen wird, wie man irgendwie an irgendwas schuld ist. Also das ist schwierig, so etwas aufzubauen. Aber das ist sehr wichtig. Fehler sind nicht schlecht, sondern aus den Fehlern kann man lernen, ja? Fehler sind gut. Dann finde ich, dass die Firma Werte kommunizieren sollte. Werte wie: uns ist der Code wichtiger, die Güte des Codes ist wichtiger als die Quantität, ja? Es kommt nicht darauf an, hier mehr Kram dran zu tun, sondern es kommt darauf an, dass wir, wenn wir was geschrieben haben, da auch noch einmal darauf zurückkommen später, ja? Wenn wir was dazugelernt haben, dass wir das auf den alten Code anwenden. Und damit das stressfrei machbar ist, braucht man ordentliche Unit-Tests. So haben wir dann so einen Kreisschluss. Die Anekdote, die ich hier erzählen wollte, war, dass ich mit einem Freund einen Job hatte. Und da war… Teil von dem Problem war ein User-Interface. Und da hatten wir beide überhaupt keine Ahnung von. Und der Freund meinte dann ganz locker: „Ja lass uns das in Qt machen.“ Und ich meinte so: „Wir haben beide keine Ahnung von Qt. Was machst du hier?“ Und da meint er: „Ja, das hätte ich gerne im Resümee stehen, ja? Das muss… in meinem Lebenslauf sieht das gut aus.“ Das ist schon ein paar Jahre her. Aber was ich sagen will: wenn die Firma den Leuten nicht die Zeit gibt, Sachen zu lernen, dann lernen sie das in Projekten der Firma, und die werden dann Scheiße. Applaus Was man auch häufiger sieht, ist, dass das Management glaubt, sie müsste die Architektur der Software vorgeben, oder welche Datenbank verwendet wird oder so. Und das ist eigentlich auch immer eine schlechte Idee. Denn entweder die Architektur ist offensichtlich, dann hilft es nichts. Oder sie ist nicht offensichtlich, dann sind die Ratschläge wahrscheinlich falsch, weil wir das Problem noch nicht wirklich verstanden haben. Also das ist auch eine Sache, da sollte sich das Management zurücknehmen an der Stelle. Applaus Und hier noch so ein bisschen Selbsthilfe für Entwickler. Ist die letzte Folie, ganz entspannt bleiben. Der Druck kommt immer von euch selbst. Das Management kann viel erzählen, ja? Deadline hier, Deadline da. Lasst euch da nicht dazu bringen, Überstunden zu fahren. Immer schön um 9 kommen, um 5 nach Hause gehen. Also… Applaus Wenn unrealistische Anforderungen reinkommen, dann müsst ihr da ganz ehrlich sein und sagen: „Das wird wahrscheinlich nicht klappen. Ich nehme jetzt euer Geld und arbeite daran. Aber ich sage euch jetzt: das wird nix, ja?“ Immer schön Paper-Trail hinterlassen, dass das nichts wird und man es rechtzeitig gesagt hat. Man kann dann dran arbeiten, weil viele von euch werden wahrscheinlich die Kohle brauchen, aber ehrlich sein, nicht so tun, als wenn wir das mit ein paar irgendwie die-Nacht-durchgemacht am Ende noch reißen können. Das ist besonders in der Spielebranche ein riesiges Problem, dass die Leute total Burnout kriegen. Man muss das verstehen mit dem Management wie ein gegenseitiges Training, ja? Wenn ich dem Management so etwas durchgehen lasse, dann zeige ich ihnen: das ist die neue Baseline, ja? Das erwarten die ab dann. Herald: Soll ich mir einen Stuhl holen, damit ich mich daneben setze? Fefe: Kannst du machen, das ist die letzte Folie. Herald: Okay. Fefe: Ganz ruhig! So, und der letzte Satz, den ich habe: Zeit ist… muss man sich selber nehmen, ja? Ich habe zwar gerade gesagt… Lachen und Applaus Herald: Raus mit dir! weiter Applaus Ich habe zwar gerade dem Management empfohlen, euch Zeit zu geben, aber wenn ihr darauf wartet, das wird nichts. Lachen So, ich fürchte, die Fragezeit ist schon vorbei, oder? Herald: Jo. Lachen und Applaus Das Beeindruckende ist ja wirklich: die sind alle da geblieben, und da ist nicht einer vom Stuhl gefallen. Fefe: Ja! lacht Herald: Vielen, vielen Dank! Ausgänge sind beide offen. Das war’s von Fefe. Hier noch mal ein Applaus für ihn bitte! Applaus Abspannmusik Untertitel erstellt von c3subtitles.de im Jahr 2018