Hey. Hi zusammen und herzlich
Willkommen zu einer neuen Folge vom to Cast, dem Podcast für
Entwickler und Entwicklerinnen SCASASTDASTIAST.
Heute sind eine ganze Menge Abkürzungen hier in unseren
Notizen, von denen ich noch nie gehört habe und das macht mir
ein bisschen Sorge, denn malte du hast den Titel gewählt.
Für diese Folge und der heißt Application Security ist meine
Anmeldung unsicher. Woher kommt dieser Titel?
Woher kommt dieses Thema hol uns doch mal kurz ab, ob deine
Anwendungen sicher oder unsicher sind, kann ich dir nicht sagen
und ich glaube, das ist die große Gefahr, dass du selber
nicht weißt, ob deine Anwendung sicher sind.
Du hoffst es zwar, aber kannst du sicher sein.
Das weiß ich nicht, aber da können die richtigen Tools bei
helfen. Ich beschäftige mich mit diesem
Thema Application Security seit einiger Zeit, da ich in meinem
Job bei github im Moment sehr viel mit dem Thema Application
Security zu tun habe, damit vielen Kunden genau über diese
Themen auch Rede. Und ich dachte, es ist
vielleicht ein Thema, über das viele Leute aktuell reden und wo
man vielleicht auch die Hintergründe zu diesen
Abkürzungen, die du gerade genannt hast, einfach mal besser
verstehen möchte und dementsprechend dachte ich wir.
Wir schauen heute mal was kann ich machen, um meine eigene
Anwendung sicher zu machen und herauszufinden, ob ich
vielleicht verwundbarkeiten in meiner Anwendung hab, ob meine
Anwendung alles Security Best Practices erfüllt und welche
Arten von Tools mit dabei helfen können, genau dieses Wissen zu
bekommen und da gibt es natürlich verschiedene
Kategorien, in die ich mal reinschauen kann und häufig
fangen Developer ja dann an, auf ihren eigenen Code zu schauen,
sprechen mit Kolleginnen und Kollegen darüber.
Wie kann ich meinen Code entsprechend sicher machen?
Und da hatten wir in der Vergangenheit schon mal über das
Thema Oberst Top Ten gesprochen und das hilft mir dann schon
mal, wenn ich dort mich eingelesen habe meinen eigenen
Code. Gegen die üblichen Angriffs
Sektoren abzusichern. Dafür brauche ich natürlich das
Wissen und ich brauche die Kolleginnen und Kollegen, die
mir helfen, in den entsprechenden Code Reviews
genau diese Dinge abzuklopfen und da wäre es natürlich super,
wenn man da auch Tools hätte, die mir genau in diesen
Bereichen helfen und das Ganze automatisiert durchführen und
damit kommen wir jetzt in den Bereich der Security Tools, mit
denen viele einsteigen und das sind die SAS t sast Tools, das
ist static application security testing.
Und da gibt es eine Reihe von Tools, die mir helfen, meinen
eigenen Sourcecode zu scannen auf übliche Wunder Abilities
wäre das nochmal. Nachhören möchte die Folge mit
der owasp top ten. Das ist so eine Top ten Liste,
auf die man seine Anwendungen prüfen sollte, was Security
flaws und so Common Security flaws angeht, war Folge 30 von
unserem Podcast. Und auch 2 Folgen davor, nämlich
folge 2928 wo über die J Sicherheitslücke Look for Shell
und darüber den Fall Color JS und Fake JS gesprochen haben.
Das könnte spannend sein. Wer sich für das Thema generell
interessiert. Wir hatten das Thema Security ja
schon häufiger in unserem Podcast, deswegen freue ich
mich, dass wir wissen D einsteigen und ein paar Tools
vorstellt, mit denen ich quasi nicht nur diese diese Liste
durchgehen kann, sondern dass sie auch wirklich testen kann.
Wahrscheinlich automatisiert testen kann.
Was ist denn überhaupt Static application Security Testing
oder was ist denn generell statisches Testing und kannst du
vielleicht kurz mal abholen? Static application security
testing tools und Tools, die meine Anwendung auf Basis des
Quellcodes testen. Das heißt, ich habe ein Tool,
das sich in der Regel entweder lokal auf meiner Maschine
ausführen kann oder im Rahmen meiner CI Pipelines laufen lasse
und dieses Tool scannt meinen Sourcecode mithilfe von
bestimmten Patterns und Queries. Auf übliche oder häufige
Verwundbarkeiten im Code das können so einfache Sachen sein
wie sequence, Action oder Cross Side Scripting Attacken für die
meine Anwendung anfällig sein kann.
Dieses statische Scanning funktioniert wunderbar, wenn ich
den Code meiner Anwendung verfügbar hab ne Anwendung wird.
Über den kompletten Source Code gescannt, was natürlich vor und
Nachteile hat, das heißt, es werden auch nicht erreichbare
Bereiche des Quellcodes gescannt, das heißt, während der
Ausführung würde eine potenzielle Verwundbarkeit in
diesem nicht erreichbaren Bereich kein Problem darstellen,
aber diese werden auch mitgescannt.
Das heißt, ich kann komplett durch meine Anwendung durch
Scannen und kann das während der Entwicklung tun und das ist
natürlich super, weil ich es relativ früh im
Entwicklungszyklus machen kann. Das heißt, meine Anwendung ist
an dieser Stelle. Noch gar nicht tatsächlich
irgendwo im Betrieb, sondern während der Entwicklungszeit
kann ich automatisiert auf genau diese Kriterien prüfen, die wir
auch schon in der Vergangenheit diskutiert haben.
Alles natürlich streiten darüber, ob man nicht erreichbar
n Code überhaupt in seinem Produkt haben möchte oder
sollte. Aber generell ist es nicht
verkehrt. Das heißt aber, dass hier nicht
nur dependencies oder irgendwas gescannt werden.
Ja, hier wird nicht irgendwie geschaut benutze ich vielleicht
irgendeine Party Library, eine bekannte Sicherheitslücke und
hier werden wirklich Coding Patterns von meinen
Entwicklerinnen und Entwicklern angeschaut.
Und wie gesagt ich schau mal, das ist vielleicht ein Fehler,
der häufig gemacht wird oder hast du hier checkst du gar
nicht, ob da ne SQL Injection vielleicht möglich ist oder hier
vertraust du einfach irgend ne user Input irgendwo ohne
irgendwelche Checks, oder hier gibt es irgendwie ein Part den
du einfach offen lässt oder hier gibts ne PI, die nicht
abgesichert ist oder hier machst du vielleicht auch einen Unsafe
Call, weil du reflection benutzt oder was auch immer?
Solche Dinge werden dort getestet ja, das heißt ich lade
irgendwo in South hin. Oder vielleicht lokalen Tool?
Was meinen Sourcecode scannt auf diese ja eigentlich antipatterns
versteh ich genau das Thema dependencies, da kommen wir
nachher nochmal zu. Das ist ein separates Thema,
hier reden wir tatsächlich über den selbstgeschriebenen Code,
den Code, den du und deine Kolleginnen und Kollegen
geschrieben haben. Der letzten Endes von diesem
Tool gescannt wird. Auf Basis von Security Best
Practices und dort dieses Security Best Practices in.
Bestimmten Patterns hinterlegt oder einen bestimmten Queries je
nach Technologie hinterlegt wird meine Anwendung dann auf diese
hin untersucht. Das hat den Vorteil, dass ich
hier extrem zuverlässig genau auf diese Pattern scannen kann,
hat aber auch gegebenenfalls den Nachteil, dass wir da relativ
viele Positive bekommen können, weil wir da natürlich nicht
qualifiziert in die Anwendung und in die Ausführung der
Anwendung reinschauen, sondern wirklich nur mit ganz groben
Mustern oder Queries arbeiten, die sehr generisch sind und da
kann ich natürlich relativ viel Beifang bekommen und muss dann
letzten Endes als Developer durch alle diese findings.
Durchgehen und schauen ist das etwas, was wirklich eine Gefahr
darstellt oder ist das etwas, was vielleicht gar nicht ein
Problem darstellt? Das hängt natürlich ein bisschen
von Tool ab. Manche Tools haben mehr false
Positives, manche weniger. Aber grundsätzlich lässt sich
sagen bei dieser statischen Analyse habe ich häufig auch mit
vielen Volks Positives zu kämpfen.
Das ist aber ein Zweifel, was ich mir nur einmal irgendwie
machen muss und dann zentrale verwalten.
Ne also ich kenne da so ein bisschen so Security Scanning
Tools, die dann schauen, wo ich in meinen Repository vielleicht
versehentlich eingesteckt. Aber wenn es dann falls Positive
gibt, also die, die guten Tools haben alle irgendwo ne zentral
gemanagte Verwaltung, wo ich dann einmal zentral sage Nein,
in dieser Datei in Zeile 15 - 17 das ist nur ein Test n testkey
oder irgendwas ist da eingecheckt is und so kenne ich
das auch von diesen Tools. Ich habe selber in einem Projekt
mal mit Sonar Cloud gearbeitet, das fällt ja unter dem unter.
Die Kategorie Statische Analyse dann und dort war es zumindest
so, dass ein zentrales Dashboard gab, wo dann diese diese Dinge
gepflegt wurden. Unter anderem auch technische
Schulden gemessen wurden. Das war sehr wichtig.
Und dort konnte man dann aber quasi an einer Stelle zentral
sowohl erstmal regeln für das Projekt legen festlegen ist
generell für alle meine Projekte oder für dieses Projekt dann
aber in Ordnung und aber auch diese Findings Flaggen, in dem
man sagen könnte ja, weiß ich. Mache ich aber eine Ausnahme aus
den Gründen und dann wird quasi diese Informationen an alle
Decks verteilt, die dieses Tool vielleicht lokal laufen lassen
oder wenn ich das Tool nur im Rahmen der Pipeline ablaufen
lasse, dann zieht sich sowieso noch einmal die Informationen
und diese Findings kommen nicht jedes Mal wieder hoch, sondern
ne wenn ich als zentral gemanagt habe, kann ich natürlich sagen,
dass nur neue Findings hoch babbeln sollen.
Und also ich hab ich hab die Erfahrung gemacht, dass schon
die Qualität drastisch verbessert, natürlich deutlich
verbessert die Geschwindigkeit nicht ab, weil natürlich am
Anfang erst mal viele Findings wahrscheinlich anfallen, die man
einmal durcharbeiten muss. Und diese Dinger hat Tage sehr
picky, sind aber wenn ich mich drauf einlasse, die Qualität
meines Codes aber auch sehr, sehr, sehr, sehr gut werden kann
bisschen abhängig davon wahrscheinlich, welche
Programmiersprache ich verwende und wie viele Peter und regeln
diese Tools dann mitbringen? Aber ich sag mal so, die
gängigsten Sprachen also wir haben damals eingesetzt bei dem
Projekt oder machen diesen Sommer habe ich wisconsins sehr
gut und soweit ich weiß kommt sogar aus der Java Welt, das
heißt, da wird wahrscheinlich sehr wichtig sein genau das
hängt dann von der Sprache und Technologie ab, die du
verwendest wenn du irgendwelche neuen oder einer
Nischentechnologien verwendest, funktionieren solche Tools
natürlich nicht so gut und tatsächlich auch wie diese Tools
zu handeln sind und wie viele positive sie haben, hängt auch
ein bisschen vom Tool ab. Manche Tools konzentrieren sich
ausschließlich auf den Bereich Security, manche Tools ergänzen
das noch um solche Themen wie und wie Codes, Mels oder Linking
oder andere Best Practices hängt ein bisschen davon ab, welchen
welches Tool man für welchen Use Case dort einführt und die guten
Tools, die lassen sich natürlich auch in den ganzen Pool request
Flow einbinden und scannen auch letzten Endes nur auf die
Deltas, die ich dann in meinem Feature Branch in meinem Pool
request habe und ich als Developer bekomme dann letzten
Endes auch nur die Findings. Die entweder sich auf meinen
Code beziehen oder wo ich durch meinen Code jetzt zum ersten Mal
anderen Code aufrufe der letzten Endes nobility mit sich bringt.
Das heißt ich hab den zwar nicht selber geschrieben hat n Kollege
geschrieben und durch meinen Code dieser Code jetzt
aufgerufen und wird dadurch zur Gefahr und die guten Tools
bilden natürlich so ne Art Ablauf Graph und wissen, dass
diese Funktion jetzt aufgerufen wird, durch zum Beispiel den
Code den ich geschrieben habe und sagen mir das dann Impuls.
Und geben wir im Idealfall auch noch Informationen?
Warum das eine Gefahr ist und wie ich dieses Problem fixen
kann und das fällt unter diesen ganzen Themenbereich Shift
Security Left, das heißt, Wir wollen in unseren Software
Development Lifecycle möglichst früh, also auf der linken Seite
solche Security Tests durchführen, damit zum einen wir
als Developer diese Probleme möglichst früh erkennen und auch
fixen können und letzten Endes das ganze nie wirklich zu einem
Problem wird, zum Beispiel in der Produktionsphase oder
vielleicht sogar die Produktion verzögert.
Weil wir vielleicht das Testing erst relativ am Ende machen,
wenn die ganze Anwendung fertiggestellt ist und dann das
Security Team einmal draufschaut und wir dann die entsprechenden
Probleme finden, ja Shift Security Left ist glaube ich so
n Termin muss mal kurz erklären, weil man irgendwie oft hört.
In der in der Branche. Das wird schon gesagt davon oder
heißt es, dass man sich sehr früh um das Thema Security
kümmert und Left eben weil n Zeitstrahl ist.
Man kennt ja schon mal diesen, ich wär so gesehen hab ich die
einfach mal unten als Link in die von den Podcast, dass dann
so ein Zeitstrahl der links anfängt, dann halt irgendwann so
ne so, ne Loop macht was dann so n bisschen diese agilen
Iterationen sein soll und da möchte man natürlich möglichst
früh in diesem Zeitstrahl die Verantwortung.
In dem Fall auf die Entwicklerinnen legen und da
nicht quasi erst ganz am Ende, wenn das Produkt fertig gebaut
und gechipt ist, auf solche Security Mobility dies testen,
weil es dann häufig zu spät ist, das noch ohne großen
zeitverzögerungs Aufwand zu fixen, sondern möglichst früh
wie gesagt am besten direkt, wenn ich den Code schreiben,
vielleicht sogar auch im Rahmen von einem automatisierten
Preview direkt zu sagen Ey, da hast du Code geschrieben, den
den du gerade. In Form eines Podcasts
vorschlägst, der potenziell unsicher ist, genau und dadurch
haben wir entsprechende Findings, die im Kontext gegeben
werden, also während du wirklich noch an deinem Feature
arbeitest, die für dich relevant sind und die entsprechend auch
mit den entsprechenden Hinweisen kommen, die dir helfen dieses
Problem dann auch zu adressieren und dementsprechend sehr früh in
der Entwicklung gefixt werden können.
Man sagt generell umso später ein Sicherheitsproblem in dem
Lebenszyklus der Applikation gefunden wird.
Umso teurer wird es am Ende, wenn ich als Developer, das,
während ich an diesem Feature arbeite, schnell fixen kann, ist
es sehr günstig, wenn das Ganze erst nachdem die ganze Software
fertiggestellt ist, gefunden wird, wird schon komplizierter.
Wir müssen halt dann nochmal gezielt bestimmte Dinge
überarbeiten, wenn es nachher erst in Produktion auftaucht,
ist es natürlich das große größtmögliche Desaster, was
natürlich immense Kosten für einen selber und für das
Unternehmen mitbringen kann. Das heißt die statische
Codeanalyse. Befindet sehr früh in der
Entwicklung statt. Natürlich können wir auch auf
unserer gesamten Codebase scannen, aber im Idealfall mache
ich das Ganze möglichst früh schon während der
Entwicklungsphase. Jetzt steht hier noch ein paar
andere Begriffe aus auf dem Zettel, also SAST hab ich
verstanden. Static application security
testing statische Codeanalyse bin ich ganz froh, das habe ich
zumindest schon mal gehört, habe ich schon eingesetzt.
Wahrscheinlich jetzt auch das, was man am ich am schnellsten in
so einem Projekt integriert bekommt.
Man sucht sich irgendein Anbieter aus und setzt auf
konfiguriert und wenn ich das Halt automatisiert in Form
meiner oder meines. Ulrich Reviews anwenden kann,
ist eigentlich immer gleich, was ich.
Das ist immer sehr schnell starten kann, wie gesagt, aus
der Erfahrung beim ersten Mal einsetzen, klar kommen ganz
viele Findings, aber wenn man dann einmal bearbeitet hat, habe
ich glaube ich, ein guter hochqualitativen Code zu
schreiben. Jetzt stehen aber noch andere
Begriffe wie DAST und IST was heißt denn damit auf sich genau
fangen wir mit DAST Dust an. Das ist dynamisches Application
Security Testing. Da nehmen wir eine lauffähige
Applikation und testen diese Applikationen durch
entsprechenden Input. Das heißt, es kann Input sein,
der automatisiert durch das Tool über automatisch generierten
User Input erzeugt wird. Das heißt.
Die Anwendung geht dann durchschaut wo gibts input,
Felder zum Beispiel in einer Web Applikation oder in einer
Desktop Applikation und versucht dann dort durch entsprechende
Eingaben dann Security wollen Abilities zu finden.
Typisches Beispiel sind wieder actions.
Aber das kann natürlich auch bei Web Applikationen über eine
Modifikation der UL sein UL Parameter und gerade für
Webapplikationen sehr praktisch kann ich natürlich auch den
gesamten Network Traffic. Abfangen, mitschneiden und damit
kann dieses Application Security Testing Tool letzten Endes auch
sehen, wie mein Frontend mit der Backend kommuniziert, wie welche
Informationen dort fließen und kann dann versuchen, diese
Informationen zu modifizieren, genauso wie ein potentieller
Angreifer das tun kann und kann natürlich dann jenseits der
Eingaben, die über das User Interface möglich sind,
versuchen, Inputs zu liefern, die zu einer wunderbar bility
oder einer Ausnutzung einer Variability in meiner Backend
Applikationen führen können. Das heißt häufig ist das
Aufsetzen eines solchen Dust Tools so, dass entweder das Tool
Anwendungen. Passt Spider wie in Web
Applikationen? Wir haben das ja häufig bei
irgendwelchen Search Engines, die klettern dann einmal durch
meine Applikation durch folgenden allen Links und
schauen wo gibts input, Felder und dann wird entsprechende
Datenbank aufgebaut, wo diese Eingaben erfolgen können und
dann legt das Tool los und spielt halt.
Eingaben in diese Eingaben Felder und gleichzeitig können
wir einen Proxy zwischen unserer Frontend, unser Backend bei
einer Applikation hängen, um den entsprechenden Traffic
mitzuschneiden, um dann nachher auch auf dieser Netzwerkebene.
Eingaben an das Backend zu schicken und damit versuchen,
potenzielle Sicherheitslücken zu identifizieren, dann natürlich
diese Anwendung als closed Box oder Black Box betrachtet wird
und das Tool keinerlei Wissen über unseren Anwendungscode hat
und auch keinerlei Wissen darüber hat, was letzten Endes
unsere Anwendungen in Sinne der Businesslogik tut, kann es
natürlich dazu führen, dass wir auch hier häufig Positives
bekommen, weil irgendeine Eingabe generiert wird, die dann
zu einem Fehler in meiner Applikation führt.
Und dann werde ich als Developer darauf aufmerksam gemacht, sehe,
dass dort ein Fehlverhalten vorliegt.
Aber ist es wirklich eine Security rabilität also ist es
ein Sicherheitsproblem? Kann ich damit zum Beispiel
Daten aus der Datenbank auslesen oder wenn ich irgendwelche
bösartigen Daten dort eingebe, führt das einfach nur zu einer
Fehlermeldung in der Applikation, was nicht schön
ist, aber nicht kritisch und von daher muss man bei diesen Tools
auch nachher auch noch mal wirklich im Detail durch alles
durchgehen und schauen, welche User Eingaben aber es gibt
einen. Wirklich ein sehr gutes Gefühl,
in welche Bereiche man schauen muss und wo ist potentiell zu
Eingaben kommt und natürlich gegenüber einer manuellen
Testvariante, wo ich genau diese Angriffsvektoren manuell
händisch teste, ist es natürlich absolut automatisiert.
Wir haben extrem große Anzahl von Angriffsvektoren, die dann
automatisiert durchgeführt werden können, und ich bekomme
am Ende einen Test report kann dann genau sehen, an welchen
Bereichen ich nochmal nachschärfen muss.
Nachteil ist hier. Auf der anderen Seite, dass die
Anwendung funktionsfähig lauffähig sein muss und dieses
Testing dementsprechend relativ spät in der
Anwendungsentwicklung stattfindet.
Das heißt, ich muss zumindest meinen, in sich geschlossenen
Service irgendwie lauffähig haben, um so ein Tool darauf
loslassen zu können und ich kann jetzt nicht während der
Entwicklung schon meinen Sourcecode nutzen, um dort zu
einem dynamisches Applications Security Testing zu machen.
Ja gut aber je nachdem, wie dynamisch ich wie agil nicht
dynamisch ich entwickeln. Es ist vielleicht ohnehin mein
Ziel, möglichst früh ein Minimum valuable product irgendwas
kleines Lauffähiges zu haben, sich dann immer wieder
erweitere, daher kann ich natürlich nicht so früh wie
schicke Analyse, aber ja und mein Ziel sollte generell
möglichst früh irgendwas lauffähiges irgendwas kippbare s
zu haben und das dann zu testen. Spannend finde ich aber auch,
dass automatisiert läuft, ne, das heißt, das bedeutet ja auch
ich muss ja fast schon machen, weil natürlich jeder Angreifer
wenn das voll automatisiert ist theoretisch einfach gegen meine
Applikation laufen lassen. Also ich kann mir irgendeine
Webseite draußen jetzt raussuchen Tool nehmen und sagen
OK liebes Tool klick mal auf alle Links geht mein alle
Eingabemasken irgendwie election und überall wo du durchkommst
keine Fehler bekommst sag mal Bescheid, dann weiß ich dann
weiß ich nicht wo die Mobilität von anderen Tools sind ne also
das ist, wenn ich da bin ich wenn Blackbox Test und nichts
über die über die den Code wissen muss.
Dann kann das ja jeder auch gegen meine Anmeldung machen,
das weil ich allein in dem Moment, wo ich mir dessen
bewusst werde führt eigentlich kein Weg vorbei sein, zumindest
mal auszumisten auszuführen. Am besten natürlich auch wieder
ständig. Aber zumindest irgendwie hin und
wieder im großen Release, wenn neue Features dazu kommen oder
was weiß ich genau und solche Tools sind auch relativ einfach
einzusetzen, wenn ich solche webapplikationen schreibe.
Weniger einfach wird es dann, wenn ich Applikationen hab, wo
das Tool nicht automatisch alle user Interfaces passen kann
gucken kann, wo es Nutzereingaben gibt es besonders
herausfordernd natürlich mit mobile Apps, weil ich da mit
Emulatoren arbeiten muss mit physikalischen Endgeräten.
Und genau diese Automatismen dort nicht ganz so einfach
durchführen kann also je nachdem welche Art von Applikationen ich
entwickele, ist es einfacher, so ein dynamisches Analyse Tool
einzusetzen oder schwieriger, aber immer wenn ich im Bereich
Web Applikationen unterwegs bin, sollte ich eigentlich schauen,
dass ich so ein Tool möglichst früh möglichst automatisiert in
meine Softwareentwicklung einbinde haben wir da was wir
nennen können kennst du da irgendwie ein cooles Tool?
Lass mich nicht lügen? Sepp ist eines der bekanntesten,
was auch noch auf unserer Todoliste steht dann packen wir
das auf jeden Fall mal unten in die Shownotes und hoffen, dass
wir wirklich bald eine Podcast Folge nachliefern können.
Aber dann ist da auf jeden Fall was was, was ihr euch schon mal
anschauen könnt, wenn ihr jetzt gesagt was er sagt, ergibt
absolut Sinn, wir müssen sofort auch so Tests einführen, dann
Overs Sepp, befinden wir uns noch in den Show Notes?
Und dann hattest du vorher noch dieses IAST genannt ja, auch
nur, weil du auf die Liste gepackt hast, nicht weil ich
davon irgendwie ahnung hätte genau das ist etwas was ein
bisschen neuer ist, ein bisschen aus dem Bereich zwischen
statischer und dynamischer Code. Analyse Integration Application
Security Testing dafür steht IST dort habe ich mit dem Wissen des
Source Codes die Möglichkeit, meiner Anwendung auszuführen,
das funktioniert am besten mit Sprachen, die eigene Runtime
mitbringen. Dann kann sich das Security
Testing Tool entsprechend in diese Runtime einhängen und dann
mit dem Wissen des Anwendungscodes eine
automatisierte Testsuite laufen lassen, die auf Basis von User
Eingaben oder einem Agent passiert.
Das heißt, ich kann dort bestimmte Dinge automatisieren,
wie es in der dynamischen Analyse möglich ist, aber mit
Wissen des Quellcodes, das heißt, ich habe Tool was letzten
Endes in die Code Execution. Ich reinschauen kann und dann
ein bisschen beide Welten auch miteinander kombinieren kann, da
ist dementsprechend noch ein jüngerer Bereich, der versucht,
die Vorteile der dynamischen Applikationsanalyse mit den
Vorteilen der statischen Code Analyse zu kombinieren, wenn das
interessiert gerne mal auf youtube nach IST suchen.
Dort gibt es einige Videos, die einem einen tieferen Einblick
auch in dieses Thema bieten. Das ist ganz spannend.
Das also ist natürlich nicht genau dasselbe.
Ich n bisschen aus der Container Security und Communities Welt,
wo es auch Tools gibt, die man ins ins eigene Cluster rein
installieren kann, die dann die dort laufenden Container und
Applikationen Monitoren. Ob die sich verdächtig
verhalten, das finde ich gar nicht so n bisschen in diese
Richtung, dass ich sage ich ich beobachte überwache ne
Anwendung. In dem Fall von EST jetzt sogar
mit Kenntnis vom Coder drin läuft.
Das ist bei diesen Container Scanning Tools nicht so, aber
wenn jetzt der Container da monatelang rum.
Und auf einmal anfängt, sich mit der internen Qualitäts API zu
reden oder Irgendsowas. Und das kommt dann kann das
sein, dass du diesen Scannern auch verdächtig vorkommt und
die, die dann auch irgendwie melden, oder auch die dann diese
Container Quarantäne nehmen können und sowas und das finde
ich immer ganz spannend, wenn es so diese Runtime Verständnis
dieser Runtime in dem Fall Klarheit absolvierte, konnte in
dem Fall natürlich Application Runtime, aber dann verständnisse
Tools, die davon Verständnis mitbringen, das überwachen und
darauf so educated Decisions treffen können, dass dann
meistens so die Königsklasse und dieses Verschmelzen von diesen
beiden Welten. Die letzte Kategorie von Tools,
über die wir heute noch sprechen wollen, ist Software Composition
Analysis oder SCA und das sind genau die Tools, die du ganz am
Anfang schon mal kurz angesprochen hattest, nämlich
die Tools, die deine Dependencies untersuchen, auf
Bekannte von Abilities sprich hier gehts nicht mehr um den
Code, den wir beide schreiben, sondern um den Code den andere
geschrieben haben, den andere Paketiert haben, die wir in Form
von Open Source Libraries oder irgendwelchen Packages
verwenden. Und mittlerweile sind natürlich
die meisten Anwendungen auf Basis solcher Open Source
Technologien gebaut je nach Quelle irgendwie zwischen 7080%
des Anwendungscodes ist mittlerweile auf Basis von Open
Source Code entwickelt. Und dann nutze ich natürlich
diverse Package Manager und Libraries, die aus der Community
oder von anderen geschrieben werden und solche SCA Tools
helfen mir dann auf bekannte Wunder Abilities in meinen
Dependencies. Aufmerksam zu werden, das heißt,
das Tool schaut sich an, welche Dependencies ich verwende da je
nach Technologie gibt es meistens dort einen eine Datei,
in der Halt die entsprechenden Dependencies für meine
Anwendungen hinterlegt sind. Diese Datei wird untersucht und
auf Basis einer von Ability Database, wie wir sie zum
Beispiel auf github finden. Kann dann das Tool mich auf
Wunder bitis in den von mir verwendeten Libraries und
Packages in der entsprechenden Version aufmerksam machen kann.
Dann auch direkt Informationen geben, auf welche Version ich
upgraden müsste, wenn es mittlerweile eine Version gibt,
die entsprechend gefixt ist und damit kann ich meine Software
Supply Chain absichern, weil ich nutze natürlich andere Tools und
möchte sichergehen, dass die Tools, die ich verwende oder die
Libres, die ich verwende, zumindest keine bekannten Wunder
Abilities hat und das ist natürlich eine gewisse Schwäche
dieses Ansatzes, dass ich natürlich nicht oder nie
hundertprozentig sicher sein kann, dass diese Dependencies,
die ich verwende, keine Wohnung abilities.
Haben aber ich kann zumindest sichergehen, dass ich keine
Dependencies verwendet. Die Bekannte wurden Abilities
haben und damit habe ich aber glaube ich schon mal einen
großen Sicherheitsgewinn in der Verwendung solcher Libraries und
diese Sachen sind mittlerweile sehr einfach einzusetzen.
Da gibt es diverse Tools am Markt.
Das bekannteste Glaube ich ist auf github die Pandaboard, aber
die funktioniert auch mit anderen Plattformen jenseits von
github, nutzt aber immer die entsprechende Woite Database auf
github. Und kann dort von mir als
Developer eingesetzt werden, auch lokal auf meiner Maschine,
um Halt zu schauen sind die Dependencies, die ich verwende.
Frei von Bekannten wollen Abilities.
Ich kann vielleicht davon ausgehen, dass alle Party
dependency ich dich benutze generell frei von Variability
sind von bekannten ja, aber das kann ich ja bei meinem eigenen
Code auch nicht, wenn ich da keine Analysen fahren, selbst
wenn ich statische Code Analyse mache, kann ich auch nicht
hundert Prozent sicher sein, dass da diesen Tools nichts
durchgerutscht ist finde ich das ein vertretbares Risiko.
Auch nochmal Probst, auf jeden Fall an Independent Board nutzen
auch und der stellt mir sogar Pull Requests automatisch, wo er
dann diese Versionsnummer hoch zählt.
Das heißt, das ist wirklich also da wirklich niemand mehr eine
Ausrede auf einer veralteten Version zu sein?
Dann ist es meine Ausrede, dass ich keine anständigen Tests habe
und die sollte mir unangenehm sein diese Ausrede denn wenn ich
gute testabdeckung habe, dann kann ich ja diesen
automatisierten Request Depended, stellt mit der neuen
Version Nummer einfach. Einmal durchtesten, wenn es nach
wie vor Grün sind, kann ich ja mehr oder weniger automatisiert
fast schon rein Märchen also das Problem sehe ich eigentlich als
gelöst an mit so Tools wie die Pendler bot.
Man muss dann halt nutzen. Eine gewisse Schwäche hat man
natürlich mit solchen Tools, weil mir diese Tools natürlich
nicht natürlich nicht sagen, ob ich die verwundbaren
Methodenaufrufe oder Komponenten einer Library auch wirklich
verwende. Ich glaube, ein gutes Beispiel
ist log for J was wir auch schon diskutiert haben, dass natürlich
eine große Sicherheitslücke darstellen konnte.
Aber je nachdem wie ich diese Library eingesetzt habe.
Könnte es auch sein, dass meine Anwendung trotzdem weiterhin
sicher ist? Natürlich fahre ich sicher, wenn
ein Upgrade gibt, was für mich nicht ein Breaking Change
bedeutet, wenn ich dann trotzdem diese Bibliothek auf die neueste
Version bringe, auch wenn ich diese potenziell verwundbare
Funktion nicht verwende, aber nur weil ich jetzt eine
Vulnerability zum Beispiel durch die Board in meine Dependencies
angezeigt bekomme heißt es nicht, dass sofort meine
Anwendung unsicher ist, sondern ich muss vielleicht auch noch
mal in die Details gucken. In die Dokumentation in.
Der entsprechenden Datenbank, ob letzten Endes die Dinge, die
dort gefunden wurden, in dieser Bibliothek auch wirklich Dinge
sind, die ich verwende, um dann zu wissen, ob durch diese
Dependency auch wirklich meine Anwendung potentiell verwundbar
ist, aber wie du gesagt hast meistens ist der Aufwand die
neueste Version, die dort einen fix mitbringt, einfach mal zu
testen, nicht allzu groß. Von daher gibt es kaum Ausreden,
dass zumindest automatisiert mitlaufen zu lassen und dann
möglichst schnell auf die neueste Version zu gehen, auch
wenn man vielleicht diese. Verwundbarkeit in der eigenen
Anwendung gar nicht ausnutzen könnt.
Ja, spannend also Security immer n, bisschen so leidiges Thema,
aber man merkt schon auch irgendwie innerhalb der letzten
Jahre, wenn sich so ein bisschen die die Tech News anschaut, dass
ein immer wichtigeres Thema wird und dann ist doch cool, wenn s
Tools gibt, die uns so ein bisschen die Arbeit abnehmen und
das ist für uns ein bisschen leichter machen also ich fand
das so immer cool, dass mir soeben nicht nur wie gesagt hat
meine Schwächen, sondern auch n bisschen Smells und Technical
debt und sowas aufgezeichnet oder so zu Gamification.
Mäßiger Sicht Lust hatte diesen Score.
Nach oben zu treiben, und ich glaube, das wird super.
Es wird immer wichtiger, gerade weil Angriffe auf Software nicht
weniger spannend oder interessant werden oder
attraktiv werden für potentielle Angreifer.
Und ich habe auf jeden Fall gelernt, wir haben.ca gehabt.
Software Composition Analysis haben wir gerade darüber
gesprochen ich n bisschen was meine Supply Chain woher kommen
denn eigentlich meine ganzen Dependencies und sind diese
verwundbar? Dann SAST static application
security testing. Statische Code Analyse der
Quellcode, den ich geschrieben habe, wird automatisiert
gescannt auf irgendwelche Anti patterns, dann das ganze als
dynamische Codeanalyse fand ich sehr spannend hattest du
erzählt? Es gibt Tools.
Die automatische Anwendung durchgehen, schauen, ob
irgendwelche die auf Button klicken, gucken, ob irgendwelche
Eingaben Felder gibt, wo sie vielleicht auch Attacken
hinschicken können. Während meiner wäre eine
Anwendung läuft und dann die Vermischung beider Welten n
bisschen mit IRST oder IAST Integration Application Security
Testing. Oder wirklich auch mit der
Verständnis von der Runtime und Verständnis von meinem Code zur
Laufzeit überprüft wird, ob meine Anwendungen verwundbar
sind. Also auf jeden Fall was also ich
glaub ne Gute infolge auch mal ein bisschen nachschlagen kann.
Wir versuchen auch relativ viel von dem Content nochmal unten in
die in die Shows zu packen. Ich habe auf jeden Fall n
Hausaufgaben mitgenommen für meine Projekte, diese zumindest
mal zu untersuchen, ob wir nicht das eine oder andere noch in
unsere automatisierte Pipeline mit aufnehmen sollten und da
gibt es mittlerweile extrem viele Tools am Markt und du hast
gerade schon einen Hersteller genannt Sona.
Da gibt es auch noch andere mit. Check Marks mit sneak mit
Advanced Security das heißt, der Markt wächst immer weiter, und
wir merken auch einfach in unserem Alltag, dass das Thema
absolut heiß ist, dass immer mehr unternehmen sich wirklich
dort weiterentwickeln wollen, weil natürlich die Angriffe
immer mehr zunehmen. Hackerangriffe werden immer
häufiger, und da möchte ich natürlich meine Anwendung
bestmöglich absichern, von daher schaut euch auf jeden Fall die
verschiedenen Bereiche an und schaut euch an, welches Tool am
besten in euren Dev ops. Protest reinpasst mittlerweile
spricht man ja eigentlich fast kaum noch über DVB, sondern über
d sec OPS also wie kriegt ihr den Security Teil in eure
Anwendungsentwicklung rein, möglichst automatisiert und
schaut euch da mal die verschiedenen Tools an, auf
jeden Fall extrem heißes Thema im Moment und wir packen da auch
die entsprechenden Informationen nochmal in die Shownotes rein
werde ich auf jeden Fall mit meinem Team bei meinen Kaffee
mal besprechen. Apropos Kaffee wenn ihr Lust
habt, uns einen Kaffee zu spendieren.
Sagte er. Das war ne coole Folge, ich hab
was gelernt. Ich gebe den beiden Jungs meinen
Kaffee aus, dann freuen wir uns aber sehr drüber könnt ihr
machen über den Link unten in den Shownotes, da haben wir so n
bei mir coffee Link. Wenn ihr da n Flat White da
lassen wollt, dann freuen wir uns da sehr drüber.
Außerdem freuen wir uns über Bewertungen und Sternchen auf
den gängigen Podcast. Plattformen wie Apple Podcasts
oder Spotify. Wer dieser Podcast also gefallen
hat, dann hört gerne ab und zu mal rein alle 2 Wochen erscheint
eine neue Folge und wir freuen uns natürlich immer, wenn ihr
auch irgendwo Feedback hinterlasst sowie auch wenn ihr
uns privat Feedback hinterlassen wollt ihr das ist ein bisschen
länger, ist allgemeines Feedback zur Folge?
Das passt vielleicht irgendwie ne n Kommentar auf itunes, dann
findet ihr auch immer eine Email, wo wir uns gerne auch ne
Mail hinschicken könnt. Auch für Themenvorschläge oder
allgemeine Diskussionen mit uns. Auch da freuen wir uns immer
sehr, von daher würde ich sagen wir hören uns in 2 Wochen wieder
alles gute und schreibt viel Code bis bald ciao.