Die ovas top 10 bekommen etwa alle 4 Jahre ein Update und 2025
ist es wieder so weit. Wir schauen uns heute die 2
neuen Kategorien an Software, Supply Chain, Fadiers und
misshandling of exceptional conditions wir analysieren die
strategische Verschiebung und diskutieren, wie sich das auf
euren Entwickleralltag auswirkt. Außerdem besprechen wir, wie
realistisch die Umsetzung bei kleinen Teams ist und was das
für die appsact Zukunft allgemein bedeutet.
Hallo und ganz herzlich Willkommen zu einer
Nigelnagelneuen, ofenfrischen Folge vom to do Cast, dem
deutschen Developer Podcast mit Malte Lantin.
Den habt ihr gerade eben schon im Intro gehört, der ist
Strategic Solutions Engineer bei Github und mit mir Robin Manuel
Thiel, Ich bin Direktor für AI und Cloud bei dem E Commerce
Unternehmen Jtl diesen Podcast hier machen wir aber privat und
teilen hier quasi. Unsere Erfahrungen aus echten
Kundenprojekten oder wir das diskutieren aktuelle Themen, die
die Developer Welt bewegen oder wir Care News zusammen und ein
ganz dickes Thema, was die developer Welt so ein bisschen
diese Woche bewegt hat, ist wie immer das Thema Security.
Diesmal freuen wir uns aber, dass wir nicht über eine
Security Schwachstelle berichten müssen, Gott sei Dank, das war
ja auch dieses Jahr einigermaßen häufig der Fall.
Sondern dass wir über ein Update der overs Top Ten sprechen.
Aber wie immer gehen wir kurz vorher noch durch unsere
Kaffeeliste, weil wir haben wieder zahlreichen Kaffee
bekommen und wollen natürlich auch uns herzlich bedanken.
Insbesondere starten wir hier bei David und David hat uns 3
Kaffee ausgegeben. Außerdem haben wir von Stefan
einen Kaffee bekommen und von Maximilian auch einen Kaffee.
Ganz, ganz, ganz lieben Dank. Das hilft uns durch die kalten
Wintertage oder wenn man morgens schon früh aufstehen muss.
Und es ist noch dunkel draußen, dann freuen wir uns auf Kaffee,
auf den Nacken von der Community, wenn auch ihr uns
einen Kaffee ausgeben wollt, freuen wir uns natürlich sehr.
Findet ihr einen Link zu bei mir Coffee unten in den Shownotes.
Und damit starten wir direkt in das Thema, und zwar die ovas top
10 und für diejenigen, die sich noch nicht mit dem Thema
auseinandergesetzt haben. Ovasp ist eine Foundation, die
Open Worldwide Application Security Project Foundation und
kümmert sich als non Profit darum, die Software Security
allgemein zu verbessern und sie stellt Open Source Tools bereit
und zahlreiche Initiativen. Rund um das Thema Application
Security und ganz wichtig und dafür kennen die meisten diese
Foundation, ist die Top Ten, und das sind die größten und
wichtigsten Bedrohungsszenarien und Angriffsvektoren für
Applikationen zu einer gegebenen Zeit und dementsprechend werden
sie auch regelmäßig. Aktualisiert und ganz häufig
wenn wir über Application Security sprechen, geht es im
ersten Schritt darum, zumindest diese ovas top 10 abzudecken,
weil das die häufigsten Schwachstellen sind, die auch
aktuell ausgenutzt werden. Und da gibt es ein paar
Änderungen bei diesen Top 10 und die wollen wir heute ein
bisschen zusammenbringen und einfach mal ein bisschen im
Detail schauen, was gibt es da neues und als Überraschung für
mich. Es ist nichts mit AI dabei.
Ich hatte so ein bisschen damit gerechnet, dass jetzt auch in
dieser Folge das AI Thema so ein bisschen Einzug erhält und wir
jetzt da irgendwas mit prompt injection finden.
Aber nein, es dreht sich hier weiterhin um ganz klassische
Application Security. Oh stimmt, das ist mir ist mir
gar nicht aufgefallen beim Lesen, aber du hast natürlich
recht, eigentlich würde man auch denken, dass jetzt wir haben
auch die letzten Folgen noch ganz, ganz viel über die.
Ja, Security Implikationen von Agents und so weiter gesprochen,
dass es da jetzt gar nicht dabei ist.
Aber es geht hier wirklich um, ja quasi Code, den wir schreiben
und wie malte gerade schon sagt, das wird auch häufig so als
Referenzliste einfach hinzugezogen, wenn man sie die
eigene Applikation überprüft oder auch wenn man irgendwie
externe beauftragt, irgendwie so einen Pen Test zu machen, dann
wird auch oft zumindest erstmal diese Top ten Liste abgearbeitet
und. Und die wird immer so etwa alle
4 Jahre aktualisiert. Das letztes Mal war eben im Jahr
2021 und jetzt vor wenigen Tagen, am 6.
November ist der Release Candidate von der neuen OVAS top
10 2025 auf dieser Global App SEC Conference vorgestellt
worden und in der Regel heißt das auch, dass das quasi die
fast finale Version ist. Also man rechnet da nicht mehr
mit irgendwelchen großen. Änderungen im Ranking oft ist
das so, dass so ein Release Candidate gegenüber der finalen
Version dann vielleicht noch irgendwie ein bisschen die
Formulierung geschärft wird oder sowas.
Aber das Ranking sollte irgendwie gleich bleiben.
Deswegen haben wir gedacht, das ist doch irgendwie eine schöne
Idee, da mal eine Folge zuzumachen zu diesem Update.
Und was sich genau geändert hat und was das für uns bedeutet,
das schauen wir uns heute im Detail an.
Und du hattest gerade gesagt, ein paar Dinge sind gleich
geblieben, einige haben sich verändert und einfach noch mal.
Also re Cap, Wir hatten schon mal eine Folge über die gesamten
Overs top ten, aber als re Cap haben wir uns überlegt, wir
gehen einmal noch. Die ganze Liste durch, also die
kompletten 10 und erwähne kurz, was sich da verschoben hat, was
bisher auch auf dem gleichen Platz war und was sich jeweils
hinter den einzelnen Begriffen verbirgt.
Und ich denke mal, wir machen es vielleicht ein bisschen
abwechselnd, dann fang du einfach mal an und ich mach dann
das zweite. Ja, Platz 1 unangefochten
tatsächlich ist Broken Access Control deswegen unangefochtet,
weil es auch schon im Jahr 2021, die Platz 1 war.
Der Platz 1 glaube ich, der Platz 1 war da, hat sich also
nicht so viel geändert und darunter versteht man eben
einfach schwache Zugriffskontrollen, die es
erlauben, Angreifern auf Daten oder Funktionen zuzugreifen, auf
die sie keine Berechtigung haben.
Das kann 2 Dimensionen annehmen, das kann so ein bisschen Social
Engineering annehmen, dass ich wirklich irgendjemandem
versuche, irgendwie aufzuquatschen, dass ich da
jetzt ganz dringend Berechtigungen brauche, also
dass man jemandem was falsches gibt, das können aber auch
schwache Passwörter, fehlende 2. Faktor Authentifizierung.
Das klassische Passwort auf dem Posted Zettel auf den Laptop
geklebt sein und es ist eigentlich schon sehr
alarmierend, dass das nach wie vor auf Platz 1 ist, aber eben
unverändert Broken Access Control auf dem ersten Platz.
Auf Platz 2 haben wir Security Miss Configuration und hier
sehen wir die erste große Veränderung.
Das war 2021 noch auf Platz 5, jetzt auf Platz 2 und das
bedeutet im Wesentlichen, dass Systeme falsch konfiguriert sind
und damit ungewollt. Lücken geschaffen werden, die
halt Zugriffe ermöglichen, zum Beispiel über offene Ports oder
nicht geänderte Standardpasswörter, werden auch
in der Vergangenheit mal darüber gesprochen, dass bestimmte
Funktionalitäten nicht deaktiviert wurden, zum Beispiel
in einem Webserver irgendwelche Default configurations.
Nicht geändert wurden und damit Angreifern Zugriff auf meine
Systeme ermöglicht werden. Platz 3 ist ein ganz neuer
Platz, also eine ganz neue Kategorie.
Die gab es vorher noch nicht in der Liste und die kommt dafür
zumindest die regelmäßigen Hörerinnen und Hörer von diesem
Podcast nicht überraschend. Es ist die Software Supply Chain
Failures Kategorie und das sind eben Sicherheitsprobleme, die
entstehen, wenn schädliche oder fehlerhafte Komponenten aus
externen Quellen. In unsere eigene Software
gelangen und spätestens seit dem großen Chai Hulut Angriff.
Das ist dieser Wurm, der diese NPM Supply Chain, haben wir mal
eine eigene Folge auch zugemacht.
Wer das Nachhören möchte, quasi die ganze npm Welt da in
Strecken versetzt hat, gibt es eigentlich immer mehr Angriffe
die gar nicht mehr auf mich direkt, sondern auf irgendeine
Software die ich irgendwo indirekt verwende passieren und
deswegen hat es auch diese neue Kategorie auf Platz 3 geschafft.
Das schauen wir uns ja gleich noch mal im Detail an.
Aber zunächst Platz 4 cryptographic fadeers, das war
auf Platz 2. Jetzt auf Platz 4.
Das heißt nicht, dass das Thema weniger wichtig ist, sondern die
anderen sind einfach. Relevanter und wichtiger
geworden und hier geht es darum, dass wir entweder unsichere,
veraltete, falsch implementierte Verschlüsselung verwenden und
damit natürlich sensible Daten für Angreifer zugreifbar.
Werden eine erfreuliche Sache. Auf Platz 5 ist das Thema
Injection, das bedeutet einfach generell, dass Angreifer durch
irgendwelche manipulierten Eingaben schädliche Befehle an
mich einschleusen können, die dann von meinem System
ausgeführt werden. Das prominenteste Beispiel ist
da wahrscheinlich die SQL Injection.
Wo ich irgendwie in einen Suchschlitz statt einem
eigentlichen Suchwort einen ganz, ganz in einen SQL Befehl
Eintippe, in der Hoffnung, dass der einfach so übernommen wird
vom Server. Das ist immer noch auf der
Liste, ist aber weniger geworden, das war im Jahr davor
eben auf Platz 3 beziehungsweise in der Version davor nicht im
Jahr davor, das ist in der 2021 er Version auf Platz 3.
Ist jetzt ein bisschen runtergerutscht auf Platz 5,
also nach wie vor relevant, aber da scheinen wir uns wie
allgemein als Industrie etwas verbessert zu haben, das.
Auf Platz 6 finden wir jetzt in Secure Design.
Das war vorher auf Platz 4 und da geht es einfach um
Sicherheitslücken, die schon in der Architektur und der
Konzeption der Anwendung angelegt sind.
Das heißt, man hat sich nicht Gedanken darüber gemacht, wie
man die Anwendung entsprechend absichert oder hat einfach in
der Planung bestimmte Dinge vergessen, das jetzt auf Platz
6. Unverändert auf Platz 7 sind
Authentication failiers. Das sind Fehler in der die halt
in der Authentifizierung es mir erlauben als Angreifer, dass ich
mich als ein anderer Benutzer ausgebe oder dass ich ein Login
System vielleicht komplett umgehen kann, also üblicherweise
falsch konfigurierte Authentication Server, falsch
konfigurierte Ohr auf Protokolle gibt immer noch Leute die sowas
selber bauen und wahrscheinlich vielleicht sich dann, da diese
Fehler ein deswegen Authentication failiers auf
Platz 7. Auf Platz 8 auch unverändert und
ich komme mir so ein bisschen vor, wieso ein Radiomoderator
oder die Charts vorliest, sehen wir Software or data Integrity
failors, also eine Anwendung vertraut ungeprüft auf externe
und manipulierte Daten und damit kann ich zum Beispiel Schadcode
ausführen oder die Anwendung manipulieren und damit Zugriff
auf Informationen erlangen, die ich eigentlich nicht bekommen
sollte. Platz 9 ist auch unverändert,
deswegen gehen wir da auch schnell drüber.
Die Kategorie heißt Logging und Alerting Failiers, das ist eben,
wenn Angriffe nicht erkannt oder gemeldet werden, dann fehlt oft
die Grundlage für schnelle Reaktionen oder eben für eine
nachfolgende forensische Analyse von diesem Problem.
Das kann natürlich dann auch zu Sicherheitslücken führen, die
einfach länger offen sind, weil ich sie erst spät bemerke oder
wenn ich sie bemerke, nicht wirklich weiß, wo ich suchen
muss, deswegen ist das auch relevant.
Und auf Platz 10. Und das ist eine neue Kategorie
in den Top ten ist misshandling of exceptional conditions und
dahinter verbirgt sich fehlerhafte Behandlung von
Fehlersituationen von ungewöhnlichen Situationen wir
alle kennen. In der Softwareentwicklung
Exception Handling, aber das wird immer relevanter, weil wir
natürlich immer mehr auch Drittanbietersysteme einbinden
und auch immer mehr Fehlverhalten auftreten kann.
Und hier geht es darum, dass man bestimmte Fehlersituationen
nicht abfängt und damit ein Fehlverhalten auslösen kann, was
Angreifern erlaubt, die Anwendung zu manipulieren oder
auf Daten zuzugreifen, und das ist eine neue Kategorie, über
die sprechen wir auch gleich noch mal ein bisschen im Detail.
Genau also kann man, glaube ich zusammenfassend sagen.
Also die meisten Sachen, wie wir die Ovas Top Ten schon kennt,
der wird jetzt hier bei 50% dieser Themen nur gegähnt haben,
aber insgesamt, es gibt 2 neue Kategorien, das sind eigentlich
die spannende Sachen, die wir jetzt auch in der Podcast Folge
uns angucken, nämlich einmal Platz 3.
Die Software Supply Chain Failious und den Platz 10, den
malte gerade vorgelesen hat, Misshandling of Exception und
exceptional conditions und. Und es gibt einige wirklich
bemerkenswerte Rankingverschiebungen und
deswegen noch mal hier als Betonung.
Das ist jetzt nicht einfach nur eine neu Nummerierung von dieser
Liste, sondern eigentlich ein Spiegel der neuen oder sich
verändernden Bedrohungslandschaft, also so
ein bisschen kann man daran auch eigentlich mal ganz kurz sehen,
was uns so für Security Themen die letzten Jahre eigentlich
begleitet haben, worauf wir jetzt heute ein bisschen mehr
Fokus legen müssen, deswegen würde ich sagen, schauen wir uns
doch mal diese Neuzugänge an und.
Weil das ist ja wirklich so ein strategischer Schwenk von dieser
Liste und fokussieren uns jetzt mal auf Platz 3 und Platz 10 als
quasi Kern der Aktualisierung von dieser Liste.
Genau. Du hattest ja vorhin schon ein
bisschen was gesagt zum Thema Software, Supply Chain und dass
wir das ja in den letzten Folgen schon auch mehrfach als Thema
hatten und hiermit dabei handelt es sich um eine Erweiterung
einer bisherigen Kategorie Wolmirobland outdated
Components. Und jetzt geht es tatsächlich so
ein bisschen um so einen Perspektivenwechsel, weil wir
natürlich in der Vergangenheit häufig auf die eigenen
Komponenten geschaut haben. Wir haben ganz viel Software
selber geschrieben, und wenn ich sage früher, dann schauen wir da
natürlich 10 und mehr Jahre zurück als das ganze Projekt in
die ins Leben gerufen wurde, und da wurden natürlich ganz viele
Bibliotheken auch selber geschrieben, oder wir haben aus
irgendwelchen großen Frameworks, irgendwie aus der Java net was
auch immer Welt Bibliotheken verwendet, die irgendwie vom
Anbieter kein. Haben und in den letzten Jahren
ist es ja immer häufiger geworden, dass wir diverse
Drittanbieter Komponenten verwenden, die aus der Open
Source Community kommen oder wie wir auch letztes Mal besprochen
haben, aus einem ganz großen Fundus, zum Beispiel von mpm
Packages. Genau dabei muss.
Man jetzt natürlich heute sagen auch schon 2021, also in der
vorherigen Liste waren unter dieser Kategorie Audated
Components auch halt externe Pakete, die aber dann oft
einfach nur in der Versionsnummer verwaltet waren,
das heißt? Da ist dann irgendwo eine
Sicherheitslücke entstanden und ich habe die halt, die jahrelang
nicht gepatcht und das wurde dann eben da beleuchtet.
Jetzt merkt man aber, dass die neuen Gefahren so eigentlich den
gesamten Prozess vom Erstellen über das Verteilen auch und bis
hin zum Aktualisieren von meiner Software ja abdecken, wie malte
schon ganz richtig gerade gesagt hat, da sind natürlich ganz,
ganz viele oder viel, viel mehr Third Patrick Komponenten als
früher drin, aber. Aber auch hier noch mal der
Augenmerk, eben nicht nur in meinem Code, sondern vielleicht
auch irgendwo auf dem Bildserver, der ein Tool
verwendet, um irgendwie einen Helmchart zu bauen oder weil ich
vielleicht in meiner github Action irgendwo ein Tool
verwende, was ich lange nicht geupdatet habe, was dann
wiederum eine Referenz oder eine Abhängigkeit auf irgendwas
anderes hat, wo jetzt versucht wurde, dann irgendwie.
Schadcode einzufügen und so was. Also wir müssen uns jetzt eben
nicht mehr nur noch unsere eigene Software und dessen Third
Party Libraries angucken, sondern die komplette Supply
Chain und ich glaube, das ist so ein bisschen hier, dieser große,
diese große Änderung davon, deswegen auch diese Umbenennung
in Supply Chain Failers also es kann sein, dass ich die beste
Software schreibe, aber in der Art und Weise, wie ich sie
Update, wie ich Sie ausliefere, der letzten News folge jetzt
auch das Github zum Beispiel jetzt auch gerade hingeht.
Man diese unveränderbaren Releases baut, weil ich da ja
sonst vielleicht sage, vielleicht glaube ich, dass ich
die Version xy von der Software herunterlade, die war auch
jahrelang war die Version 1 512 war das genau dieser Code und
heute ist irgendwie jemandem gelungen auf den Feed vom vom
Herausgeber oder Herausgeberin von dieser Software zuzugreifen.
Und auf einmal ist die Version 1 512.
Zwar noch die mit der gleichen Versionsnummer, aber auf einmal
die mit anderem Code und all so Dinge.
Und wie gesagt, vielleicht nutze ich den Code ja gar nicht in
meinem Source Code, sondern irgendwo in meiner Supply Chain
und ich glaube darauf wird hier gerade so ein so ein großer
Fokus drauf gelegt, also auf manipulierte Bildprozesse, auf
unsichere Abhängigkeiten irgendwo in meiner gesamten
Software auslieferungskette. Ja, und das finde ich ganz
interessant. Diese Erweiterung, dass es jetzt
nicht nur um wirklich Komponenten geht im Sinne von
Packages, sondern auch wirklich Tools, die ich einsetze,
irgendwo in meinem Prozess oder vielleicht auch Drittanbieter
Komponenten, die ich über AP is anbinde, die irgendwie
manipuliert sein können, wie sich die dann meine Anwendung
verändern, das heißt, alles, was irgendwie von dritten Teil
meiner Lieferkette ist und ein Teil meiner Software ist, ist
jetzt die. Enthalten.
Und wir sehen ja, dass Anwendungen immer komplexer
werden und immer mehr dieser Abhängigkeiten haben.
Ich glaube, wir hatten gerade auch in einer der letzten Folgen
auch darüber gesprochen, dass man hier auch immer mehr Dinge
aufbaut, die von anderen gebaut sind und die sich nicht auch
nicht nur statisch als Code in sein Projekt reinholt, sondern
teilweise auch dynamisch so bestimmte Dinge abgerufen werden
über AP is und damit haben wir natürlich eine immer größer
werdende oder wachsende Angriffsfläche und.
Und damit wird es natürlich auch immer schwieriger, solche Supply
Chain Schwachstellen zu identifizieren, weil wir auch
nicht mehr einfach nur auf klassische Supply Chain Security
Tools zurückgreifen können, die irgendwie gucken, welche
Dependencies habe ich irgendwie in meinen.
In meinem Projekt drin und dann, wie du gerade gesagt hattest,
sind irgendwelche Vulnerability databases.
Schaut ob diese vielleicht irgendwie outdatet vulnerable
sind und ich mehr ein Update ziehen muss, sondern es gibt
ganz viele andere Abhängigkeiten die ich habe und die muss ich
natürlich mit betrachten. Ja, auch den zweiten Neuzugang
fand ich eigentlich ziemlich spannend.
Also das Thema Misshandling of acceptional Conditions und das
ist jetzt das erste Mal, dass eigentlich das Thema Resilienz
so ein bisschen Einzug in die ovas top 10 findet.
Was meint man damit? Damit machen wir eigentlich so
ein bisschen dieses Prepair to Fail, bereite dich darauf vor,
dass irgendwas schief gehen wird, denn in komplexen
Systemen, wie wir sie heutzutage bauen, wird immer irgendwas
passieren und wie du damit umgehst, darauf kommt es
eigentlich an, wir haben ja sogar schon mal eine eigene
Folge zu dem Thema Chaos Engineering gemacht, da haben
wir in Folge 94 mal darüber gesprochen, dass manche Firmen
wie zum Beispiel Netflix, die haben das Wissen ins Leben
gerufen, ganz. Quasi konstant sogar die eigenen
Systeme selber manipulieren, dass sich ja niemand an den
Zustand gewöhnt, dass immer alles glatt läuft und dadurch so
ein bisschen erzwingen, dass die Developer von bestimmten
Subkomponenten quasi von vornherein irgendwelche
Resilienz Features einbauen. Und hier kommt es eben darauf
an, dass die Overs besagt, dass es auch eine
Sicherheitsschwachstelle sein kann, wenn ich dein System eben
durch einen Angriff von außen in eine bestimmte Fehlersituation
versetzen kann und es dann an. Anders reagiert als es sollte
und deswegen ganz klar, wie du mit so einem mit so einem
Failure umgehst. Das ist wichtig, dass er in
einem hochkomplexen System passiert, ist fast schon nicht
zu vermeiden und darauf wird es hier in diesem neuen Punkt auf
Platz 10 noch mal einen extra Fokus und eine extra augenmerke
legt. Wir gehen dann nachher noch mal
ein bisschen tiefer drauf ein, was das auch für uns als
Organisation oder als vielleicht als Firma bedeutet.
Stichwort Thread Modeling, aber ich glaube ganz simpel
gesprochen lässt sich sagen, wir bereiten uns auf das Schlimmste
vor und wir verhindern nicht nur, dass dann, wenn etwas
passiert. Unsere Anwendung irgendwie
angreifbar ist, sondern wir gehen irgendwie dreischrittig
vor. Wir investieren in Prävention,
damit solche Situationen möglichst nicht auftreten.
Wir stellen sicher, dass wir erkennen, wenn Fehlverhalten
auftritt, und dann können wir entsprechend darauf reagieren,
auf diese Fehler, um halt diese Probleme abzufangen und sind
dann halt wirklich aufs Schlimmste vorbereitet.
Ja genau, also ganz klar nicht nur diesen Happy Path absichern.
Sondern ganz klar, dass sowas wie fehlervermeidung,
fehlererkennung, Reaktion auf Fehler einfach ein integraler
Teil von meinem Design wird. Das heißt, natürlich will ich
irgendwie vermeiden, dass meine Software abstürzt, ich will aber
viel mehr vermeiden, dass wenn vielleicht irgendwie eine third
Komponente nicht mehr erreichbar ist oder irgendein Teil meiner
Software unter einer so großen Last steht, dass er langsam oder
gar nicht mehr antwortet oder meine Software vielleicht sogar
selber an einer bestimmten Stelle crasht.
Dass sie dann nicht in einen Zustand verfällt, in dem sich
neue Sicherheitslücken auftun. Es gibt Anwendungen, die im
Fehlerfall sehr, sehr chatty werden, die dann irgendwie viele
internas oder sogar sensible Daten in ihren Logs oder gar in
ihren Fehlermeldungen preisgeben, das ist ganz oft gut
gemeint von den Entwicklerinnen und Entwicklern, du willst ja
vielleicht im Fehlerfall auch möglichst viele Informationen
haben. Die du dann wieder nutzen
kannst, um nachher herauszufinden, warum ist das
passiert, wann ist das passiert, wie kann ich, wie kann ich das
für den Zustand möglichst schnell wieder wiederherstellen.
Das kann aber auch oft einfach ein ungewollter Data League sein
und das finde ich ganz spannend, weil es gibt ja eine andere, ein
anderer Bereich von diesen ovas top ten war ja nämlich genau der
Platz 9, also allein schon der vorherige Platz mit diesen
Logging und alerting failers, wo es vielleicht auch darum geht,
dass ich zu wenig logge oder vielleicht gar nicht mitbekomme,
wenn ich Zum Beispiel angegriffen werde.
Und hier geht es jetzt darum, dass ich natürlich irgendwie in
einem Fehlerfall ja loggen will, aber dass dort auch ganz oft
dann eben zustande kommt, dass ich da eben ein bisschen
überlogge oder dass ich sage, ich habe eine Fehlermeldung, die
irgendwo passiert, das ist eine interne Fehlermeldung und ich
gebe die aber über den http 500 er Fehler vielleicht sogar nach
draußen weiter und das sind dann Informationen, die ein Angreifer
wieder verwenden kann um einfach sensible Daten über mein System
zu erfahren. Und die man sich dann natürlich
nutzen kann. Und deswegen versuchen Angreifer
heute auch vermehrt Anwendungen in einen Fehlerzustand zu
versetzen, in dem vielleicht irgendwo von außen einen einen
Zugang abgeschnitten oder vielleicht auch attackiert wird,
um dann zu gucken, wie verhält sich dann meine meine Anwendung
und kann ich da vielleicht irgendwie dann sensible
Informationen mehr daraus erhaschen?
Und. Bevor wir jetzt gleich darauf
eingehen, was das Ganze für uns bedeutet, müssen wir glaube ich,
noch einmal ein bisschen zurückspringen, weil ich glaube,
vielleicht ist den ovas Top 10 Nerds unter euch aufgefallen,
dass ein Punkt, der bisher in der Liste war, nämlich Server
Site request Forgery, jetzt plötzlich verschwunden ist.
Und es ist nicht unwichtig geworden, sondern es wurde
lediglich in einen anderen Punkt integriert, und zwar in Broken.
Access Control und vielleicht für diejenigen, die denen das
jetzt nicht sagt. Wir mussten auch selber noch mal
nachschlagen, wann und wie das Ganze auch vorkommen kann,
vielleicht ganz kurz das Thema Server Side Request Forgery
bedeutet, dass ich es einem System aufzwingen kann, dass es
mir Zugriff auf Systeme unter Systeme gibt, zum Beispiel
vielleicht einen Storage Account oder eine Datenbank auf.
Auf die ich eigentlich keinen Zugriff haben sollte.
Das heißt, ich greife zum Beispiel auf eine API zu und
gebe da bestimmte Informationen mit, die am Ende auf der
Applikationslogik dazu führen, dass ich Informationen
zurückbekomme aus einem dritten System, auf das ich
normalerweise keinen Zugriff habe.
Das heißt, ich habe auf der Server Seite dafür gesorgt, dass
mein Request ein anderes System geht, aber du hast glaube ich
noch ein ganz gutes Beispiel, was man vielleicht auch aus.
Den Bereich der Webentwicklung gut nachvollziehen kann.
Ja, ist eine ganz, ganz fiese Sache, diese ssrf attacks.
Einfach ein klassisches Beispiel.
Ich habe selber schon mal irgendwie einen aus Versehen
eingebaut, da kannst du einfach meiner API einen JSON schicken,
über einen über ein user Objekt was du updaten konntest und da
kannst du einfach sagen Hey pass auf mein Profilbild findest du
übrigens unter dieser URL, weil ich habe einfach gesagt ich habe
gar keine Lust, dass man selber irgendwelche Profilbilder bei
mir hochladen kann, viel zu kompliziert wollte ich nicht
einbauen, kann es einfach irgendeine URL angeben und.
Und dann kann es natürlich passieren, dass mir jemand einen
json schickt und aber sagt, EY, Mein Profilbild liegt unter http
localhost, port 8080 admin und mein Server hätte dann ja
einfach, wäre dann hingegangen, hätte dieses Bild, egal von
welcher Quelle das ist irgendwie runtergeladen, also einen Get
request an diese URL geschickt und wenn ich die vorher nicht
überprüfe, dann wird mein Server eben der ja vielleicht auf
localhost Port 8080 Admin Zugriff hat mein Client
natürlich nicht, aber der Server macht das dann und dann kann man
natürlich dadurch erwirken. Dass mein Server irgendwo eine
Anfrage hinschickt, also weil es irgendwie als klassisches
Beispiel in dieser Image URL und genau das ist nicht weniger
wichtig geworden, das war früher, es war ein eigener
Punkt, früher auf Platz 10 und jetzt ist er eben in Platz 1,
also in dieses Broken Access Control mit Reingeflossen.
Dieser Platz 1 wurde eh so ein bisschen aufgebläht, weil es,
wie man jetzt dadurch mit diesem Beispiel vielleicht so ein
bisschen merkt, nicht nur um User Access geht, sondern
einfach auch darum, dass ich den.
Ja, dass ich einem Server irgendwas unterjubeln kann.
Also ich finde es relativ nah an so einer SQL Injection, wo ich
versuche so eine SQL Queery mitzugeben, gebe ich halt hier
irgendwelche Sachen mit oder versuche, dass der Server, wenn
ich rausfinde wie er eh arbeitet oder welchen Ur Ls erfolgt,
vielleicht Dinge tut, die der Server zwar tun kann, ich selber
aber nicht tun kann. Das heißt es ist eigentlich ein
Spezialfall von so fehlerhafter Zugriffskontrolle und sorgt
eigentlich dafür, dass mein Server Requests ausführt, die er
eigentlich in diesem Kontext nicht ausführen dürfte.
Letzten Endes kann man sagen, dass jetzt mit der neuen Overs
top 10 so ein bisschen so ein ganzheitlicher Ansatz gefahren
wird. Es wird weniger wirklich auf
einzelne klassische Security Bugs, sondern mehr auf das große
Ganze geschaut, dementsprechend werden bestimmte Kategorien
zusammengelegt und andere Kategorien werden etwas
verbreitert. Wir schauen jetzt auf den
gesamten Softwareentwicklungsprozess
inklusive du hast es gerade gesagt, zum Beispiel den
Buildserver, das Deployment. Und wir schauen nicht nur mehr
auf unseren eigenen Code, sondern alles, was im Betrieb
einer komplexen Applikation heute eine Rolle spielt.
Ja, das war so ein bisschen. Vorher war das eigentlich so,
klassische Bugs, auf die man irgendwie gucken konnte, so
okay. Also dieser SQL Injection, das
war so einer der ganz ganz frühen Overs blisten mal
irgendwann drauf so diese ganz klassischen Dinge, die man halt
irgendwann auch benennen kann, die man aber auch ganz gut
identifizieren kann, wenn man sie sieht, die vielleicht auch
heute eine KI ganz gut identifizieren kann.
Wir haben ja, wir wollen ja keine Folge ohne KI machen,
deswegen möchte ich ja doch noch mal erwähnen, dass es auch ein
paar Agenten gibt, die ja durchaus in der Lage sind,
einfach meinen Code nach so. Gängigen
Sicherheitsschwachstellen zu überprüfen.
Und natürlich können das nicht nur KI s, sondern auch Menschen
sein, die das tun, indem man diese Listen abarbeitet.
Und jetzt sehen wir schon, dass wir eigentlich immer immer
weiter rauszoomen und der Fokus eigentlich mehr so diesen
gesamten Software Development Lifecycle abdeckt und eigentlich
Kontext statt nur Code, also auch betriebsmodelle, und dass
Dinge von vornherein mit geplant werden müssen und wie ich auf
welche Zustandsänderungen reagiere.
Das heißt also aber auch irgendwie für mich so ein
bisschen, dass es auch komplexer oder komplizierter geworden ist,
sichere Anwendungen zu schreiben.
Wenn das jetzt so diese top 10 Thread Vektoren sind, die Ovas
herausgibt, da war das ja früher vielleicht eine Sache von ein
paar Stunden, dass ich mich da durchwühle und gucke, ob meine
Anwendungen denen jetzt entspricht oder nicht, und heute
muss ich ja viel, viel mehr Komponenten machen, also.
Muss ich mich ja schon irgendwie fragen, was bedeutet das denn
jetzt ganz konkret für meine tägliche Arbeit oder für die
Sicherheitsprogramme, die ich vielleicht irgendwie meinem
Unternehmen ausgerufen habe, weil das ja doch jetzt irgendwie
nach deutlich mehr Arbeit aussieht, die sich ja vielleicht
auch gar nicht mehr jeder leisten kann zu tun.
Und die Frage ist, kann ich mir leisten, es mir nicht zu
leisten, es zu tun, also das müssen wir sich ja schon
eigentlich noch mal angucken, was hat das eigentlich für
Auswirkungen jetzt auf die Praxis?
Dass diese Liste also deutlich breiter geworden ist, sie ja gar
nicht länger geworden. Aber sie ist auf jeden Fall in
meiner Wahrnehmung komplizierter geworden.
Ja, lass uns das in 2 Teile aufteilen.
Einmal. Was bedeutet das für uns als
Developer, die wir tagtäglich Software schreiben, entwickeln
und was bedeutet das für Unternehmen oder allgemein so
die Security, die wir rund um unsere Anwendung stricken und
vielleicht bei den Sachen, die wir als Entwickler uns anschauen
müssen, starten wir am besten Mal bei den neuen Kategorien
oder den. Den erweiterten Kategorien und
wir hatten gerade schon ein bisschen länger über Supply
Chain Security, also Platz 3 in der Liste, gesprochen und ich
glaube, da müssen wir gar nicht jetzt so tiefgehend darauf
eingehen, sondern wir können hier auch eigentlich auf unsere
Folge 133 zu shygo Loot verweisen und alle diese Dinge,
die wir da besprochen haben, dass wir sicherstellen müssen,
dass Drittanbietercode sicher ist, dass wir sichergehen, dass
die Abhängigkeiten, die wir reinziehen, tatsächlich.
Den Code enthalten, der vorgegeben hinter einer
entsprechenden Versionsnummer steht.
Wir müssen checken, welche Abhängigkeiten wir eigentlich
haben, über welchen Package Manager, und wir müssen
natürlich sicherstellen, welche Build tools haben wir eigentlich
im Einsatz, also was läuft zum Beispiel in unseren Pipelines,
was läuft und auf unseren Jenkins oder in unseren github
actions letzten Endes, um unsere Anwendung zu bauen und zu
Deployen und alle diese Dinge müssen wir natürlich im Blick
auf. Unterhalten.
Ja, eigentlich wird jedes npm install oder was auch immer ich
für Package Manager benutze, eine sicherheitskritische
Entscheidung, die ich treffen muss, die ich auch hinterfragen
muss. Ich glaube, wir müssen wegkommen
von dieser Zeit, wo ich einfach Sold, Party, Pakete installiere
und früher hat es vielleicht so ein bisschen gereicht, dass ich
mir mal angeguckt habe, okay, was steckt vielleicht mehr als
einen Mentainer dahinter und nutzen das auch andere.
Und ich mache einmal die Woche npm Audit passt schon.
Ja, so in der Art. Genau da muss ich mich wirklich
fragen. Ist das also, ist das nötig und
wo in meiner Software Supply Chain führe ich das dort auf?
Wie oft wird das Auditiert, da gibt es ja auch Automatismen
mittlerweile zum Glück, die mich da regelmäßig dran daran
erinnern, macht es vielleicht Sinn, dass ich das Paket auf
meinem in meiner eigenen Registry Zwischenlager und das
sind ja alles große Fragen, die vielleicht und gar nicht alle in
jedem Unternehmen sinnvoll sind, haben wir wie gesagt ja auch in
Tiefe in Folge 133 zu diesem shyhood Wurm schon besprochen,
deswegen gehen wir da jetzt nicht noch mal drauf rein, aber.
Aber für mich bleibt so ein bisschen die Frage, ob das
eigentlich praktisch, also praxisnah ist für jetzt.
Wenn ich jetzt irgendwie die Deutsche Telekom bin, dann kann
ich mir das bestimmt leisten, da irgendwie für jedes mpm Paket da
meinen eigenen Feedback mit eigenen Pipelines für
aufzubauen, in eigenen Audits. Aber wenn ich jetzt einfach
irgendwie als Startup ein bisschen Code schreibe, dann ist
das ja wahrscheinlich mindestens mal eine Vollzeitstelle, meine
ganze meine ganze supply chain. Permanent zu überprüfen.
Ja, ich glaube, ich muss vor allen Dingen mir immer
Bewusstsein, dass das alles auch Security Entscheidungen sind.
Ich kann auch dann kostenfreie Tools wie irgendwie depender
Board oder Renovate verwenden, um halt sicherzustellen, dass
meine Pakete immer aktuell sind und ich glaube in der
Kombination zwischen Bewusstsein und Tools, die ich im Einsatz
habe, bin ich da schon auf dem richtigen Weg, selbst wenn ich
jetzt nicht das Maximum an Security erreichen kann, was
vielleicht große Konzerne sich über eigene.
Repositories für ihre Packages dann leisten können.
Ein bisschen einfacher finde ich, so ein bisschen.
Wie gehe ich mit dem mit dem neuen Platz 10 um, also mit
diesem Exception Handling hatte ich ja vorhin schon so ein
bisschen das, was erzählt das eigentlich ich mir Bewusstsein
muss, dass jeder Trike Hatch Blog auch eine
Sicherheitsentscheidung ist. Und was hat das jetzt denn für
Auswirkungen und wie hoch babbelt denn jetzt vielleicht
diese Exception, die hier die hier schmeiße und.
Und dass ich mir dann natürlich auch beim Logging und bei den
Fallbacks, die ich dann vielleicht auch im Fehlerfall
gehe, einfach immer wieder diese Frage stelle.
Okay Moment mal, ist das, was wäre denn, wenn so locker an die
Außenwelt kommt oder was? Was bedeutet denn jetzt mein
Fallback? Ist der vielleicht irgendwie
angreifbar und dass einfach fehlerbehandlung so ein
bisschen? Eher von vornherein mitgedacht
werden, Design Thema sind und nicht irgendwie im Nachgang
herauskommen wie. Ja, was ist denn, wenn jetzt
irgendwie dieser API nicht erreichbar ist?
Wie reagiert er, mein System, sondern ich es von vornherein
immer mitdenke, wenn ich darüber nachdenke eine API einzubauen,
denke ich auch darüber nach, was heißt es, wenn sie nicht
erreichbar ist? Wie reagiert mein System,
vielleicht schaffe ich irgendwo konsistente Arten und weisen,
wie ich in meiner Firma oder in meinem Team Fehler behandle, wie
ich logge, wie ich sicherstelle, dass in den Logs keine sensiblen
Informationen sind. Dass wir wirklich testen, welche
Exceptions bleiben intern und welche Bubble vielleicht hoch
und sind dann irgendwie im Buddy von so einem 500 er Fehler auf
einmal zu lesen und ich glaube letzten Endes einfach dieses,
dass wir uns klar werden, Fehler werden passieren, die Frage ist
auch nur so ein bisschen wann und wie wir damit umgehen und
dass wir, dass wir dann nicht aufgeschmissen oder ganz
überrascht sind, wenn unser System, gerade wenn es komplex
wird, sich mal fehlerhaft verhält.
Und dann haben wir noch hier als dritten Punkt insecure Design
Nummer 6, was auch so ein bisschen unsere Überleitung ist
in die übergeordneten Funktionen, weil mit dem Design
einer Software beschäftigen nicht nur sich die einzelnen
Entwickler, sondern das ist meistens ein größeres Team.
Wir haben dort irgendwelche Architekten oder
Sicherheitsberater mit im Spiel, die sich gemeinsam die
Architektur anschauen und es ist da ganz wichtig natürlich, sich
zu überlegen. Schon beim Design der
Anwendungsarchitektur. Was muss ich dort
berücksichtigen, damit meine Anwendung nachher sicher ist?
Da kommen dann solche Bedrohungsmodellierungen mit
rein oder threadmodelling und all das muss ich im Hinterkopf
haben, wenn ich die Anwendung erstelle am Anfang oder die
Anwendungsarchitektur am Anfang erstelle.
Und viele Unternehmen haben mittlerweile so ein Security by
Design. Konzept als Pflicht eingeführt
und dann auch ganz viele solche Guidelines niedergeschrieben.
Das heißt, immer wenn ich irgendwie eine neue Anwendung
designe, was muss ich da auf jeden Fall in der Architektur
berücksichtigen? Ja, wenn sie niedergeschrieben
sind, dann ist ja alles gut. Dann kann ja nichts passieren.
Also wie scherzhaft gemeint niedergeschrieben heißt auch
nicht immer, dass sie, dass sie befolgt werden, aber.
Aber Checklisten sind auf jeden Fall nicht schlecht.
Das stimmt, das stimmt auf jeden Fall besser, als nichts
niederzuschreiben. Auf jeden Fall und auch wenn
irgendwas niedergeschrieben ist, kann man es ja trotzdem auch
wieder. Kann man das als Standard
nehmen, irgendwie in jedem Pull request automatisch darauf zu
verlinken oder darf ich noch mal KI sagen oder vielleicht sich
auch irgendwie mal eine KI zu schreiben, die einfach guckt, ob
sich jeder Pull request einfach kurz abgleicht mit Hey, das ist
ja da, das ist da dokumentiert worden, das ist der
Codeänderung, die ich hier gerade sehe.
Sich da vielleicht irgendwie eine Verletzung von diesen
Richtlinien. Vielmehr heißt das aber
eigentlich für mich, dass sich auch jeder oder jedem
Unternehmen, die irgendwo in den Softwareentwicklungsprozess
eingebunden sind, damit beschäftigen müssen, also dass
auch Product Manager und Product owner sich mit diesem Thema
auseinandersetzen müssen, weil es jetzt halt wirklich eben von.
Ja, von vornherein bei Design mitgedacht werden muss und keine
Ahnung. Schickt gerne euren PMS und Po
ist auch mal diese Folge, weil ich glaube das ist jetzt nichts
mehr was am letzten Ende der Entwickler nur entscheiden kann,
wenn er oder sie ein npm Paket installiert, sondern was man
eben von vornherein mit Eindenken und natürlich auch mit
einplanen muss, auch in die Kapazitätsplanung von so einem
Team mit einplanen muss, dass man auch diese Punkte besonders
8 gibt. Ja, und ganz häufig ist es ja
so, dass so Security so ein bisschen im Nachgang betrachtet
wird oder? Für viele Unternehmen ist das
ein zusätzliches Investment und dann wird man gefragt, ja, ihr
braucht jetzt so und so viel mehr Zeit, um bestimmte Dinge
vielleicht zusätzlich zu implementieren oder bestimmte
Dinge aktuell zu halten, lohnt sich das eigentlich und da finde
ich es ganz spannend, dass selbst aus Ovas heraus jetzt so
ein risikobasierender Ansatz reinkommt, dass.
Der halt solche Entscheidungen rund um Security so ein bisschen
an die Geschäftsrisiken koppelt, was aus meiner Sicht sehr
sinnvoll ist, weil man damit natürlich auch entsprechend dann
die Sensibilisierung in den Entscheiderkreisen bekommt, die
am Ende die Ressourcen zur Verfügung stellen und Ressourcen
können sein. Einfach, ich bekomme mehr Zeit
oder wir bekommen zusätzliche Leute im Team, die sich mit
diesen Sicherheitsthemen beschäftigen können.
Und diese Ressourcen bekomme ich meistens nur, wenn da eine
konkrete Zahl hinter steht. Wenn man weiß, hey, wenn da was
schief geht, kostet das unser Unternehmen so und so viel oder
kann uns vielleicht sogar in die Insolvenz führen und ich glaube
nur wenn das bis oben hin verstanden wird im Unternehmen
bekommt man auch die Zeit und Ressourcen dafür.
Ja, da muss man sich ja einfach ganz klar fragen, was ist denn
meine oder meine Risikotoleranz, die ich im Unternehmen habe,
weil. Ich werde gerade.
In die kleinen Unternehmen oder in sehr dynamisch schnell
wachsende Software? Lösungen, nicht mich gegen all
diese Sachen schützen können, aber ich muss mir dann natürlich
irgendwie auch die Frage stellen okay welche Sachen sind dann auf
jeden Fall besonders wichtig für mich oder für meine Software
oder was sind denn vielleicht auch irgendwie einfache Punkte
oder so quickwins womit ich schon mal so den Großteil davon
abdecken kann, also klassisches Beispiel einfach, dass ich nicht
einfach nicht selber baue, selbst wenn es irgendwie
günstiger wäre. Das ist eine sehr sicher
relevante Sache, das kaufe ich immer von irgendeinem Anbieter
ein, irgendwie so als klassisches Beispiel und dass
man sich dann auch so ein bisschen selber natürlich fragt,
wie. Kann ich mir das leisten hier
und da dann im Zweifel so und so auf einen solchen Angriff zu
reagieren und das ist oft auch eine Entscheidung, die eine
Entscheidung, die ein Developer gar nicht treffen kann, sondern
das muss natürlich ein Management treffen am Ende, und
dafür ist es, glaube ich, wichtig, dass man die mitnimmt
auf diese Reise und da hilft, finde ich das eigentlich eine
gute Idee, was du gerade gesagt hast.
Malte, das ist eigentlich hilft da so, Kennzahlen in Euros
hinterzuschreiben, das ist natürlich.
Immer. Das ist natürlich nicht einfach,
das ist natürlich wahnsinnig schwierig, aber dass man zum
Beispiel irgendwie sagt, diese bei dieser Schwachstelle kostet
das jetzt mein System x Euro, wenn sie davon betroffen ist
oder der Reputationsschaden würde y Euro weniger Umsatz
verursachen, das ist natürlich wirklich sehr, sehr schwer, da
eine Zahlen dazu schreiben. Aber das muss ja allein schon
dann gegen diese Zahl stehen. Zum Beispiel, Wir kaufen jetzt
dieses Tool für so und so viel Euro ein, oder wir führen jetzt,
oder wir skalieren jetzt auf mehrere Server, um uns vor x
oder Jemen zu schützen, oder wir upgraden jetzt hier auf den
höheren Pricing Tier, damit wir privates Netzwerk Features
irgendwie aktivieren können und sowas.
Das sind natürlich alles Entscheidungen wo auch Euros
hinter stehen, die man dann gegenrechnen muss und sollte und
ich glaube da hilft es auch gerade dann so Metriken und
Transparenz zu schaffen, die. Sich natürlich auch für eine
bessere Kommunikation dann zu stakeholdern, also zu Management
oder zu Fachbereichen schaffen. Und dann müssen wir das
natürlich auch in unsere etablierten Prozesse einbinden.
Also wir sollten jetzt nicht Security im Nachgang irgendwie
dran flanschen und die fertige Anwendung versuchen zu scannen,
sondern es soll ein Teil unseres Entwicklungsprozesses sein und
da spricht man ganz häufig ja über Shift Security Left.
Wir müssen möglichst früh im Softwareentwicklungsprozess.
Entsprechend über Tools unseren Developern die Möglichkeit
geben, sichere Anwendung zu schreiben.
Da kommt irgendwie statische Code Analyse ein saas Tool dazu,
wenn wir die Anwendung gebaut haben, vielleicht dynamische
Anwendungssicherheit über ein daas Tool und wir hatten auch
gerade darüber gesprochen, Dependency Scanning mit einem
Tool wie irgendwie renovate oder depender Board, was ich auch
kostenfrei nutzen kann und dementsprechend habe ich das in
meinem Prozess verankert und damit auch so ein bisschen.
Kognitive Last weggenommen, weil ich mir tatsächlich auch als
Developer jetzt nicht jedes Mal immer wieder die Gedanken machen
muss und die einzelnen Schritte manuell prüfen muss, sondern das
ist Teil. Des
Softwareentwicklungsprozesses der Großteil davon ist
automatisiert und ich weiß, wenn irgendwelche Findings
rauskommen, ist es meine Aufgabe, diese Probleme zu
fixen. Aber ich muss jetzt nicht immer
manuell dran denken okay was ist jetzt Schritt 1 in der
Checkliste Schritt 2 Schritt 3, sondern die Checkliste wird
quasi automatisiert durchgelaufen und ich muss nur
die Ergebnisse nachher behandeln und das ist natürlich dann auch
ein Teil. Der entsprechenden Ausbildung,
die ich bekommen muss für die einzelnen Leute bei uns im
Entwicklungsteam, also für die einzelnen Developer, die wissen
müssen, worauf muss ich achten rund um Application Security,
vielleicht einfach mal diese Podcast Folge empfehlen oder
eine der anderen Folgen, auf die wir verwiesen haben.
Wir haben mal in Folge 57 ein bisschen ausführlicher über das
Thema Application Security gesprochen, ist schon ein
bisschen länger her, ein paar Dinge sind vielleicht nicht mehr
topaktuell, aber durchaus noch mal als Überblick eine
Empfehlung. Da noch mal zurück zu springen
und das Ganze dann vielleicht einzubetten in ein Security
Training, was halt nicht nur vielleicht einzelne Entwickler
machen, sondern was dazu führt, dass wir auch in jedem
Entwicklungsteam Security Champions ausbilden, auf die
alle zurückgreifen können, weil wenn ich weiß, Robin Manuel ist
derjenige, der sich mit dem Thema Application Security
auskennt, dann kann ich immer wenn ich unsicher bin auf dich
zu gehen und sagen, hey, ich habe jetzt gerade folgendes
Szenario. Und ich bin mir da gerade
unsicher, welche designentscheidung soll ich
jetzt hier treffen oder ich habe hier folgendes finding was ist
denn der in unserem Unternehmen etablierte Weg mit einer
folgenden Schwachstelle umzugehen?
Also wie sollten wir das Ganze entsprechend implementieren,
dass wir dieses Problem nicht haben und das ist natürlich
super sinnvoll, weil wir dann nicht allein gelassen werden,
sondern wir haben die Tools und wir haben die Expertinnen und
Experten im Team. Daher würde ich mich aber glaube
ich auch nur so mittelwohl mitfühlen, wenn ich dann ja
jetzt irgendwie der weisheitsliste Schluss sein
muss. Also ich finde es auch gut so
Security Experten zu haben, auf der anderen Seite kann man sich
natürlich auch nicht darauf verlassen, weil die natürlich
auch nicht immer alles wissen und auch nicht wahrscheinlich
gar nicht die Kapazitäten haben, immer bei allem irgendwie to
Date zu bleiben und das bringt mich auch so ein bisschen so zu
dieser Frage ist dieser ganzheitliche Ansatz da
irgendwie wirklich praktikabel und.
Oder erzeugt ja nicht auch neue Spannungsfelder, wenn ich jetzt
irgendwie jeden Pull request ich noch mal mit drüber gucken muss,
weil ich bin ja hier für Security verantwortlich oder
wenn man halt irgendwie das ist das überhaupt realistisch, also
es ist, ist das überhaupt eine, habe ich überhaupt eine
realistische Umsetzbarkeit oder eine Chance, irgendwie für
kleine Teams oder Start ups? Ist denn wirklich der Anspruch
von jetzt in einem kleinen Developer Team die komplette
Supply Chain zu überwachen? Ist das nicht auch irgendwie
überfordernd und? Ich kann ja nicht extra jemanden
dafür einstellen, wahrscheinlich und können so kleinere Teams
überhaupt pragmatisch priorisieren, was sie jetzt von
dieser Top ten Liste und sowas abarbeiten und was sie
vielleicht irgendwie wo sie das Risiko eingehen, das ist für
mich noch nicht so ganz abschließend klar und das ist
glaube ich eine ja bestimmt eine Frage, die auch irgendwie die
Community länger beschäftigt, deswegen ist das auch ein Punkt
wo ich mich freuen würde, wenn wenn diejenigen, die jetzt hier
zuhören dann. Da vielleicht eine Meinung zu
haben oder vielleicht ein bisschen spielen können, wie das
bei euch im Unternehmen gelebt wird, das ist natürlich auch
was, wo man auch vorsichtig sein muss, wo man das überhaupt
teilen möchte oder darf oder kann, weil ich glaube, kein
Unternehmen stellt sich eigentlich hin und sagt Ja bei
uns, da ist aber eben so 3 Security aber noch einiges zu
tun. Ich glaube da einfacher kann man
sich nicht auf so eine Hackerliste setzen lassen, aber.
Aber vielleicht gibt es ja Leute, die das irgendwie
halbwegs anonym oder sowas vielleicht noch mal, die das
vielleicht gibt es ja positiv. Beispiel von Leuten, Hey, wir
sind ein kleines Team und wir schaffen es trotzdem, das zu
leben, dass es bei uns eine sehr hohe Priorisierung hat, dieses
ganze Thema Security, das würde mich interessieren, wie ihr das
umsetzt und was das denn für einen Impact auf die auf
Produktivität von Teams hat und ob es da trotzdem so so
Spannungsfelder im Team dann gibt oder dass sich da irgendwie
jemand dann auch darauf ausruht, weil jemand anders ja für die
Security verantwortlich ist oder sowas das.
Das fände ich mal spannend, wenn ihr da eine Meinung zu hättet.
Ja, ich glaube, das ist ein ganz wichtiger Punkt.
Man sagt ja immer, so das Prinzip von Death, SEC OPS und
wir sind alle Teil des Security Teams, ich glaube, wir müssen
uns alle Gedanken darüber machen, dass die Dinge, die wir
tagtäglich tun, Security Implikationen haben können, und
ich denke, gerade für kleine Teams sollte es dennoch
irgendwie so ein Mindestmaß auch an Automatisierung im
Softwareentwicklungsprozess geben, also aus meiner Sicht.
Ist halt ein SARS Tool, also eine starke Code Analyse und ein
Tool um meine Software Supply Chain zu überwachen.
Pflicht also das sollte man auf jeden Fall haben, darüber hinaus
muss man diskutieren welche Tools man dann vielleicht noch
reinbringt und wenn man das dann ergänzt mit diesem Bewusstsein,
dass jedes zusätzliche Package was ich hinzufügen eine
potenzielle Schwachstelle ist oder jedes Tool, was ich
vielleicht auf meinem Bildserver laufen lasse und eine
potenzielle Schwachstelle ist. Hat man glaube ich schon ganz
viel abgedeckt und dazu so ein paar Best Practices, die du
gerade so in so Nebensätzen auch erwähnt hattest.
Vielleicht bestimmte Dinge einfach zuzukaufen oder als
Third Party dann doch zu nutzen, weil sie so komplex sind, dass
man, wenn man sie selber macht, potenziell eigentlich immer
irgendwo was vergisst. Ja, die Frage ist natürlich.
Auch irgendwie ist das, das ist die Tatsache, dass diese Liste
nicht mehr so konkret ist, und das haben wir ganz am Anfang mal
gesagt, dass diese Oberst Pop ten so viel breiter wird.
Ist das nicht einfach ein? Zu hoher Abstraktionsgrad für
Junior Developer das war nämlich auch so ein bisschen so.
Früher war das ja viel greifbarer.
Früher haben wir ganz konkrete Kategorien irgendwie gehabt,
keine Ahnung hier Cross Side Scripting oder SQL injections,
da musst du aufpassen und jetzt verlangt das ja schon sehr viel
von allem ab, wenn wir über misshandling of exceptional
conditions irgendwie sprechen oder insecure Design und sowas.
Das ist natürlich auch sehr unkonkret, da muss man natürlich
auch schauen, dass man da alle ein Team mit an die Hand nimmt.
Und gerade wenn wir jetzt irgendwie sagen, dass eine
unserer Fazit ist, dass man Security von von der Designphase
an Mitdenkt, dann muss man natürlich auch alle mitnehmen.
Und da meine ich jetzt auch nicht nur Junior developer,
sondern vielleicht auch irgendwie Leute, die gar nicht
so tief in diesem Thema drin sind.
Wir haben eben über PM, s oder sowas gesprochen, für die es
natürlich auch wichtig sein muss, das zu verstehen, was da
eigentlich hinter steckt, das genau finde ich glaube ich auch
noch so eine Sache, die jetzt durch diese Veränderung von
dieser Liste zumindest noch mal irgendwie einen Impact hat, weil
sie eben ein bisschen unkonkreter ist.
Und natürlich. Die Tatsache, dass wir ja auch.
Wir sagen alle okay wir müssen unser System resilient bauen,
aber das ist auch ganz schwer zu messen, da muss man ja auch
irgendwie, also ohne klare KP is verfällt das Halt zu so einem
Buzzword, und da gibt es halt einfach einen Bedarf an
irgendwelchen Benchmarks und dass ich das regelmäßig teste,
da möchte ich auch gerne noch mal auf die Chaos Engineering
Folge verweisen, aber auch auf die Low Testing Folge, die wir
mal gemacht haben, da haben wir schon mal, nämlich so ein
bisschen darüber gesprochen, dass man eigentlich auch sein
System immer mal wieder unter Stress setzen sollte aus
verschiedenen Perspektiven dann bei diesen beiden folgen.
Aber ich glaube schon, dass das Fragen sind, auch hier, die
unsere Community in den nächsten Monaten oder sogar Jahren noch
weiter begleiten werden. Dann lass uns zum Abschluss das
Ganze noch mal ein bisschen zusammenfassen.
Also was dieses Ovas Top 10 Update für uns als Development
Teams bedeutet. Und zwar sehen wir da 3 Themen,
einmal den Perspektivwechsel von der Fehlerbehebung hinzu, einem
ganzheitlichen Ansatz und mehr proaktiv als reaktiv.
Dann haben wir auch so neue Bereiche wie das ganze Thema
Software, Supply Chain und Resilienz, die wir uns
anschauen. Wir haben immer komplexere
Systeme und dementsprechend auch komplexere Risiken und
dementsprechend kommt hier das ganze Thema Appsac besonders zu
tragen, weil wir natürlich dort auch immer mehr Angriffsvektoren
auch sehen. Und der dritte Punkt ist, dass
die Verantwortung auch natürlich geteilt ist in Zukunft oder auch
heute sein sollte. Das heißt, wir alle sind für
Security verantwortlich, es gibt nicht nur das Security Team, was
sich mit den Themen beschäftigt, sondern Security sollte in der
Ausbildung, in den Prozessen und der Kultur des Unternehmens eine
wichtige Rolle spielen und dementsprechend über alle diese
Aspekte hinweg auch Pflicht werden.
Genau. Ich glaube das Security Team ist
nach wie vor super wichtig, aber.
Aber das ist dafür da, eben diese Kultur über die ganze
Company am besten hinweg zu schaffen und klare Vorgaben zu
machen und dabei zu helfen, dass wir uns dahin zu entwickeln.
Ich sehe dieses Overs Top 10 Update zum Beispiel als als
Riesenchance, also natürlich einmal als Chance, die
Einzelnen, die eigenen Prozesse, Tools, wissensstände auch.
Kritisch zu überprüfen, aber auch als Chance, so die
Sicherheitskultur weiterzuentwickeln.
Und ich glaube, das ist was, das sehe ich schon bei so einem
Security Team mal. Irgendjemand muss für diesen
Culture Shift ja auch verantwortlich sein und den
Treiben und da auch die Vorweggehen und die Expertise
aufbauen und das finde ich so eine coole Chance, dass man sich
das jetzt irgendwie noch mal nimmt und sagt, Hey guck mal.
Hier hat sich jetzt mehr oder weniger offiziell so ein
bisschen die Bedrohungslandschaft verändert.
Wir müssen das ganzheitlich machen, es gibt bestimmt auch
tolle Teams, die das schon machen und bestimmt auch Teams,
wo es dann auch ein bisschen Bedarf gibt, weil es ist nichts,
wo ich einfach Code oder Binary über den Sound schmeiße ins
Security Team irgendwas abcheckt und ich glaube da kann man, wenn
man jetzt so eine Kultur richtig aufbauen und sich dann auch für
die nächste overs top 10, die wir dann die ihr dann in diesem
dem To do Cast im Jahr 2029 hört.
Wenn wir die da besprechen. Wir haben diese
Sicherheitskultur aufgebaut, dann ist es wahrscheinlich auch
deutlich einfacher, auf eine veränderte Bedrohungslage zu
reagieren, weil man ja ohnehin Security schon in allen
Bereichen mitdenkt. Ja, und am Anfang sah es so aus,
als gibt es gar nicht so viele Änderungen, aber letzten Endes
war es doch so viel Stoff, dass wir hier über eine
Dreiviertelstunde uns zu dem Thema ausgetauscht haben.
Ich fand es wieder extrem spannend, da tiefer reinzugehen
und ich hoffe, euch hat die Folge genauso gut gefallen wie
mir jetzt nach dem aufnehmen. Und falls das so ist, lasst uns
gerne eine positive Bewertung da.
Das könnt ihr auf Apple Podcast oder Spotify machen und wir
freuen uns natürlich auch immer über eine positive Bewertung
über den Daumen nach oben auf Youtube oder vielleicht ein
Abonnement, falls ihr uns dort hört, wir.
Freuen uns natürlich auch immer über Kaffee, also freuen uns
sehr, wenn ihr uns da einen Kaffee ausgeben möchtet.
Findet ihr einen Link zu bei mir Coffee unten in den Shownotes
oder wenn ihr zu eurem eigenen Coffee.
Die passende Nerd Tasse haben wollt, dann schaut auch gern in
unserem kleinen Fanshop vorbei. Links zu allem, was wir
besprochen haben und so auch den Sachen findet ihr natürlich
unten und bis dahin bleibt uns eigentlich gar nicht mehr viel
zu sagen, als bis nächste Woche, wir hören uns nächsten Montag zu
einer neuen Folge wieder, bis dahin schreibt viel sicheren
Code, das ist glaube ich ganz wichtig, das ist das Call to
Action von dieser Folge schaut euch diese overs top 10 mal an,
wir verlinken auch einen einen Blog Post der das ganze ganz gut
noch mal irgendwie zusammenfasst.
Wenn man jetzt irgendwie dem Chef nicht die ganze 45 Minuten
folge hier schicken will, ist dann das war irgendwie eine
kurze Zusammenfassung, aber schickt auch gern die Folge
weiter. Freuen wir uns auch und
ansonsten bis bald bis nächste Woche hat eine gute Zeit.
Bis dann.