Anwendungssicherheit: Der Guide

Welche Herausforderungen bestehen im AppSec-Kontext 2023, welche Konzepte stehen dahinter, welche Best Practices sind derzeit aktuell? Das alles erfahren Sie in diesem Guide.

Anwendungssicherheit als Kernprämisse

Anwendungen gehören schon von Natur aus zu den wichtigsten Angriffsvektoren für böswillige Akteure. Noch mehr gilt dies für cloudnative Anwendungen, sind diese doch ununterbrochen an Netzwerke und Server und damit die primären Ziele dieser Akteure angebunden. Immer perfider werden zudem die Methoden, mit denen sie Angriffe gegen Software-Systeme fahren. Umso wichtiger sind daher Security-Prozesse, die bereits in der Entwicklung konsequent und umfassend greifen, damit Schwachstellen bestmöglich geschlossen werden, bevor sie zum Einfallstor in Netzwerke und Datenbestände werden können. Dies gilt insbesondere auch für Daten innerhalb von Anwendungen, die sensible Informationen etwa zu Kunden beinhalten.

Denn entstehen können Einfallstore bereits durch scheinbar unbedeutende Konfigurationsfehler oder Software-Komponenten, die bekannte Schwachstellen aufweisen. Was zudem nicht gerade selten ist: Untersuchungen von Snyk im Rahmen des State of Cloud Native Application Security Report 2021 zufolge waren Security Incidents im Zusammenhang mit cloudnativen Anwendungen bei 56 % der Unternehmen auf entsprechende Probleme zurückzuführen. Dabei muss zwar nicht von jeder Schwachstelle direkt auch höchste Gefahr ausgehen. Zugleich aber loten Hacker immer neue Wege aus, wie sie sie für ihre Zwecke nutzen können.

Häufigste Ursache für Security Incidents: Konfigurationsfehler und bekannte, nicht behobene Schwachstellen

Konfigurationsfehler sind daher keinesfalls zu unterschätzen – erst recht, da die damit verbundenen Risiken Unternehmen aller Größen betreffen. Gerade auch solche aus Geschäftsfeldern wie dem Finanzsektor, in denen besonders sensible Daten verarbeitet werden. Zudem dürften die Risiken in Zukunft nicht unbedingt weniger werden. Dies jedenfalls legen Untersuchungen von Forrester nahe, denen zufolge Anwendungssicherheit als Markt bis 2025 auf 12,9 Milliarden US-Dollar anwachsen wird. Was ihre Stärkung anbetrifft, so empfiehlt sich eine zweigleisige Strategie:

• Einmal gilt es, Prozessstrukturen rund um einen Shift Left aufzubauen, bei dem Sicherheit als Thema tiefer in die Software-Entwicklung und somit in die DevOps-Kultur hineingetragen wird.

• Begleitet werden muss dies von einer umfassenden Tooling-Strategie, die beispielsweise auch Security-Scans direkt in Dev-Tools und -Workflows integriert.

Neben den passenden Tools und Prozessen benötigen Security- wie Dev-Teams zudem Klarheit über jeweils aktuelle Entwicklungen im Sicherheitskontext. Hervorragende Anlaufstellen hierfür bieten Nonprofit-Organisationen wie das Open Web Application Security Project (OWASP), das mit der Vulnerability Top 10 einmal pro Jahr eine Liste der häufigsten Schwachstellen in Web-Anwendungen veröffentlicht. Daneben bietet aber etwa auch Snyk nützliche Ressourcen in diesem Zusammenhang, mit dem bereits genannten State of Cloud Native Application Security Report zudem auch ganz spezifisch im Kontext aktueller Trends rund um die Sicherheit cloudnativer Anwendungen.

AppSec-Trends 2023

Prägend für das Jahr 2022 war eine enorme Entwicklungsdynamik im Hinblick auf Bedrohungen im Cyber-Kontext, infolge derer Security als Thema deutlich stärker ins Blickfeld gerückt ist:

• Die Rolle des CISO nimmt eine zunehmend tragende Rolle innerhalb von Leadership-Strukturen ein, dies nicht zuletzt auch aufgrund deutlicher Signale aus der Politik. In den USA etwa ist Cybersicherheit inzwischen zur Angelegenheit der nationalen Sicherheit geworden: Im Februar 2022 erließ Präsident Joe Biden eine Verfügung zum Schutz der Lieferketten des Landes, die ausdrücklich auch die Stärkung der Cybersicherheit in kritischen Bereichen des ITK-Sektors vorsieht. Verschärft wurde die Bedrohungslage zudem infolge des Ukraine-Konflikts, der die Sorge um potenzielle Cyber-Angriffe eingesteuert durch Russland wieder stärker hat aufflammen lassen.

• Trotz ihrer immer komplexeren Herausforderungen müssen CISOs mit den gleichen Ressourcen auskommen. Umso mehr sind daher innovative Konzepte gefragt, die Teams, Technologie und Prozesse zielführender miteinander verbinden.

• Sicherheit in der Software-Lieferkettekommt angesichts aufsehenerregender Security Incidents etwa im Zusammenhang mit Log4J eine Schlüsselrolle zu. Anfällige Open-Source-Repositories, die bei diesem Fall als Einfallstor dienten, sowie andere schwache Glieder in der Software-Lieferkette bleiben auch weiterhin ein häufiges Angriffsziel. Als Reaktion darauf richtet sich der Blick nun zunehmend darauf, die verschiedenen Elemente der Lieferkette besser abzusichern.

• Angesichts der immer ausgedehnteren Nutzung cloudnativer Anwendungen wird es zur Kernfrage, wie es um die Sicherheit und Compliance von Cloud-Infrastruktur und Infrastructure as Code (IaC) bestellt ist. Antworten hierauf können Strukturen liefern, die Security-Checks durchgängig in den Entwicklungsprozess von Anwendungen einsteuern und so auch insgesamt zur Stärkung des Cloud-Sicherheitsstatus beitragen. Zentral ist hierbei die Abdeckung sämtlicher Ebenen, die die Sicherheit von Anwendungen ausmachen – vom eigenen, proprietären Code über Abhängigkeiten bis hin zur Konfiguration der zugrunde liegenden Cloud-Infrastruktur.

Security-Herausforderungen moderner Anwendungen

Zur Herausforderung macht die Absicherung moderner Anwendungen die enorme Breite und Komplexität der Thematik. Im Allgemeinen sind dabei fünf Punkte zu nennen:

1. Anfällige „Altlasten“ im Anwendungscode

2. Schwachstellen in Drittlösungen und Open-Source-Elementen

3. Umsetzung einer DevSecOps-Methodik

4. Aufbau bzw. Akquise kompetenter Fachkräfte

5. Fragmentiertes Management-Tooling

Im Folgenden ein Blick darauf, worum es dabei im Speziellen geht:

Anfällige „Altlasten“ im Anwendungscode

Ein Auge auf Schwachstellen, die sich im Coding-Prozess einschleichen können, ist zwar unabdingbar für Entwickler. Darüber hinaus weisen moderne Anwendungen aber schon per se eine Reihe von Schwachstellen auf. Die Gründe hierfür sind vielfältig:

1. Software-Systeme unterliegen einem hohen Maß an Entropie. Sprich: Sie sind alles andere als statisch, werden doch laufend Änderungen und damit zusätzliche Komplexitäten in sie eingesteuert, dies im Zuge von Updates ebenso wie zur Optimierung bestehender Features.

2. Prioritäten von Korrekturen, Updates und Wartungsarbeiten müssen laufend neu bewertet werden. Ein entscheidendes Element im Lifecycle einer Anwendung, infolge dessen aber unweigerlich auch immer bestimmte Schwachstellen im Code verbleiben.

3. Altlasten in Form von Legacy-Code sind ein anhaltendes Problem innerhalb der Umgebung vieler Unternehmen. Security-Teams können diese zwar durchaus anhand von Scans aufdecken, ihre Abarbeitung lässt sich jedoch ebenfalls nur priorisiert nach Schweregrad sinnvoll umsetzen. Gegenüber der Programmierung neuer Anwendungselemente gilt die Arbeit an Legacy-Code zudem als wenig spannend. Das mag zwar zutreffen, ist aus Security-Perspektive jedoch wenig zielführend.

4. Häufig fehlt es aktuellen Security-Tools an Lizenzen zur Abdeckung von Legacy-Code. Wird dieser jedoch nicht weiter auf seine Sicherheit hin bearbeitet, bauen sich sukzessive immer größere Problemfelder auf.

Schwachstellen in Drittlösungen und Open-Source-Elementen

Als zunehmend tragendes Element innerhalb moderner Anwendungen bilden Drittanbieter- und Open-Source-Bibliotheken einen äußerst attraktiven Angriffsvektor. Ein besonders großes Risiko geht dabei von transitiven bzw. indirekten Abhängigkeiten aus, über die potenzielle Schwachstellen von Entwicklern gänzlich unbemerkt in den Code geraten können.

Erst kürzlich haben unsere Experten über einen entsprechenden Fall berichtet, bei dem ein Programmpaket von seinem Maintainer manipuliert wurde: In das weit verbreitete Paket node-ipc baute dieser ein Modul namens peacenotwar ein, das die Geolocation eines Systems ausliest und dieser entsprechend bei allen Nutzern mit Standort in Russland und Belarus ein herzförmiges Symbol auf dem Bildschirm anzeigt. Dem Modul bescherte dies eine erhebliche Zunahme der Download-Zahlen – vor seinem Auftritt als Abhängigkeit in node-ipc waren diese kaum nennenswert gewesen.

In ähnlicher Weise von seinen Urhebern manipuliert wurde das npm-Paket colors. Risiken gehen bei Open-Source-Abhängigkeiten also nicht zwingend nur von externen Akteuren aus, teils bringen auch die Maintainer selbst Schadcode oder Schwachstellen in die Pakete ein.

Manuell ist es jedoch praktisch unmöglich, sämtliche potenziell in Open-Source-Abhängigkeiten vorhandenen Schwachstellen zu beheben. Vielmehr braucht es hierfür Tools, die Schwachstellen nicht nur direkt bei ihrem Bekanntwerden aufdecken, sondern auch Aufschluss darüber geben, wie und in welchen Fällen Updates vorzunehmen sind. Ergänzend hierzu sind zudem Policy-Strukturen hilfreich, anhand derer Sicherheit von vornherein Einzug in Entwicklungsprojekte hält. Ausgestaltet werden sollten diese auf Grundlage von Best Practices, die anhand passender Tools angewendet werden. Äußerst nützlich sind dabei etwa die Regelsätze für Open-Source-Projekte des OpenSSF-Frameworks. Unglücklicherweise werden sie längst nicht von der gesamten Community umgesetzt – so manches Security-Tool wäre dann etwas weniger dringend vonnöten.

Umsetzung einer DevSecOps-Methodik

Passend zum Tooling braucht es zudem den bereits genannten Shift Left, damit Sicherheit durchgängig im gesamten Lifecycle der Anwendungsentwicklung greifen kann. Denn bislang war dies erst in den Spätphasen des SDLC der Fall: Code-Scans wie auch die Einarbeitung der Ergebnisse durch das Dev-Team erfolgten erst im Nachgang. So geriet das Security-Team jedoch zum Hemmschuh für andere Bereiche der Software-Delivery – dies umso mehr angesichts der Unmengen an Falschmeldungen, die das dafür verwendete Tooling produzierte. Aus all den False Positives die tatsächlichen Probleme herauszufiltern und diese dann auch noch klar zu priorisieren, war für Entwickler also denkbar zeitaufwändig.

Gangbar war dies vielleicht noch in Zeiten, in denen Release-Cycles einer Wasserfall-Methodik folgten. Prägend für moderne Software-Entwicklung ist jedoch die Agilität innerhalb des SDLC. Eben dies muss sich also auch in einer frühzeitigen Erkennung und Behebung von Problemen widerspiegeln. Denn so können nicht nur Security-Teams effizienter agieren, sondern auch alle anderen im Prozess Involvierten.

Das Mittel hierzu ist ein Shift Left, bei dem Best Practices rund um Security-Tests bereits in den Frühphasen der CI/CD-Pipeline zur Anwendung kommen.

Das Mittel hierzu ist ein Shift Left, bei dem Best Practices rund um Security-Tests bereits in den Frühphasen der CI/CD-Pipeline zur Anwendung kommen.

Aufbau bzw. Akquise kompetenter Fachkräfte

Zudem gilt es, den Shift Left personell adäquat zu unterfüttern. Hierzu sind einmal kompetente Security-Fachkräfte entscheidend, außerdem muss das entsprechende Team laufend seine Kompetenzen schärfen, effiziente Prozesse implementieren und bestehende Tooling-Strukturen auf den Prüfstand stellen. Ziel ist eine integrierte Security-Methodik, in der Scans und CI/CD parallel ablaufen, sodass Entwickler die nötigen Fixes schnell und einfach einsteuern können. Umso wichtiger ist dies angesichts des Mangels an Cybersecurity-Fachkräften: Im Verhältnis zu Entwicklern beläuft sich ihre Personalstärke in der Regel nur auf rund 100:1. Unternehmen bleibt also kaum etwas anderes übrig, als Security-Aufgaben mehr an Dev-Teams zu übergeben. Umsetzbar ist dies freilich nur durch passendes Training und verstärkte Automatisierung.

Fragmentiertes Management-Tooling

Security ist immer auch eine Frage der Abwägung, zu welchem Grad Risiken für das Unternehmen tolerierbar sind. Denn die Annahme, dass sich diese komplett eliminieren ließen, ist allenfalls naiv, vor allem aber auch kontraproduktiv. Zielführendes Risikomanagement bedeutet vielmehr, den Umfang an bestehenden Schwachstellen in Anwendungen zu ermitteln und dann nach Priorität zu bestimmen, wann und wie diese adressiert werden.

Voraussetzung hierfür ist durchgängiges Monitoring: Security-Teams benötigen zu jeder Zeit ein umfassendes Gesamtbild zum Risikoprofil einer Anwendung – auf sämtlichen Ebenen, die für ihre Sicherheit relevant sind. Anhand dieser Daten können sie festgestellte Probleme dann in Prioritäten einordnen und darauf basierend einen Plan für ihre Abarbeitung im Rahmen des AppSec-Prozesses ausgestalten.

Entscheidend sind dabei zudem Reporting-Features, die dem Team Klarheit darüber liefern, ob Fixings korrekt und gemäß Plan erfolgen. Zielführende Tools ermöglichen dies anhand von Dashboards, die sämtliche hierzu nötigen Informationen für alle am Prozess Beteiligten zentral einsehbar zusammenführen.

Die OWASP Top 10 als AppSec-Kompass: Highlights im Jahr 2021

Mit der Vulnerability Top 10 liefert das OWASP alljährlich eine differenzierte Einschätzung dazu, welche Schwachstellen ganz besonderer Aufmerksamkeit bedürfen. Beim Blick auf die aktuelle Liste sind insbesondere zwei Punkte wichtig:

1. Im Vergleich zum Vorjahres-Ranking sind eine Reihe bedeutender Bewegungen festzustellen. Grund hierfür ist neben neuen Trends im Bedrohungskontext eine neue Bewertungsmethodik, die neben der Angreifbarkeit einer Schwachstelle auch ihre potenziellen Auswirkungen berücksichtigt. So ist etwa „Fehlerhafte Zugangssteuerung“ von Platz 5 an die Spitze gerückt, Fehler bei der Authentifizierung finden sich dagegen nur noch auf dem 7. Rang – eine deutliche Herabstufung gegenüber dem letztjährigen Platz 2\. Ein Faktor hierfür könnte die zunehmende Verfügbarkeit standardisierter Frameworks sein.

2. Die Liste reicht von Sicherheitsmängeln im Design über kryptografische Sicherheitslücken bis hin zur unzureichenden Gewährleistung von Daten- und Pipeline-Integrität. Ein äußerst breites Spektrum also, das sich mit einem Shift Left allein nicht abdecken lässt. Hierfür nötig ist es vielmehr, dass Sicherheitsaspekte sämtliche Facetten einer Anwendung lückenlos durchziehen.

Die in der OWASP Top 10 2021 aufgeführten Schwachstellen und ihr Risikoprofil liegen einer Auswertung von Daten aus mehr als 500.000 Anwendungen zugrunde. Dies bestätigt nicht nur ihre Aussagekraft, sondern macht sie auch zu einer hervorragenden Baseline, wenn es um die Evaluierung der Feature-Stärke von Security-Tools geht.

So etwa im Hinblick auf fehlerhafte Zugangssteuerung, dem bereits genannten Spitzenreiter der aktuellen Top 10: Snyk adressiert diese Problematik im Rahmen seines Toolsets für IaC-Sicherheit. Bei der Erkennung von Injection-Angriffen und damit dem Drittplatzierten im aktuellen Ranking hilft Snyk Code durch Features zur Analyse von Daten-Flows. Für anfällige und veraltete Komponenten, die sich in der Liste auf Platz 6 einordnen, stehen im Rahmen von Snyk Open Source die passenden Tools zur Verfügung.

Tatsächlich bieten die Technologien von Snyk adäquate Lösungen für sämtliche Vertreter der Top 10, bei denen die Erkennung bzw. Behebung via AppSec-Testing möglich ist. Mehr dazu sowie detaillierte Analysen zur gesamten Liste finden Sie in unserem Artikel zur OWASP Top 10.

3 Ebenen als Grundgerüst der AppSec-Architektur

Dem Konzept moderner Anwendungen liegt eine Architektur zugrunde, die sich in drei Ebenen unterteilt. Aus Security-Perspektive ist dies entscheidend, denn jede von ihnen ist mit spezifischen Risiken verbunden, die es entsprechend zu adressieren gilt. Deutlich macht dies ein Blick auf ihren Aufbau und die potenziell mit ihnen verbundenen Angriffsvektoren:

Der Client als oberste Ebene

Auf dieser Ebene ist das Frontend verortet, über das Anwendungen für Web, Internet of Things (IoT) oder Mobilgeräte mit ihren Nutzern interagieren. Ein besonderer Fokus gilt hier einer hohen Performance und ansprechenden UX, zugleich ist jedoch auch das je nach Frontend-Typ spezifische Bedrohungsprofil zu beachten. Denn Angriffe auf diese Ebene sind in verschiedenster Art möglich, die von Injections bis hin zu Denial of Service (DoS) reichen.

Die Anwendung in der Mitte

Separat vom Frontend werden hier die nutzerseitigen Dateneingaben verarbeitet. Architekturseitig besteht also bereits ein gewisser Schutz vor Angriffen, da diese Unterteilung quasi als Firewall zwischen Endnutzern und Daten fungiert. Dennoch sind auch hier zusätzliche Sicherheitsmaßnahmen zu empfehlen, dies etwa in Form differenzierter Zugriffskontrollen.

Das Backend am unteren Ende

Mit Cloud-Infrastruktur, Containern etc. finden sich auf der unteren Ebene alle Elemente, die zur Ausführung von Anwendungen und der Speicherung von Daten vonnöten sind. Ziel der meisten Angriffe ist der Einbruch in diese Ebene, daher sind sichere Konfigurationen, korrekte Netzwerkdefinitionen und starke Verschlüsselung am Backend unabdingbar.

Architektur moderner Anwendungen im Gesamtbild

Plastischer wird der Aufbau moderner Anwendungsarchitekturen anhand des nachfolgenden Schaubilds. Wie darin zu sehen, steht hinter dem Frontend eine Ebene für Business Logic und Daten. Umgesetzt wird diese über eine API, die in der Cloud (also etwa auf AWS, Azure oder Google Cloud) ausgeführt wird.

Im Block auf der linken Seite findet sich der Quellcode. Darin definiert sind Client und Business Logic, Programmpakete bzw. Abhängigkeiten, Cloud-Konfigurationen (via IaC) und Container-Files zur Definition der Container, in denen die Anwendung ausgeführt wird.

Im rechten Block findet sich die Management-Ebene der aktiven Produktionsumgebung. Die hier verorteten Konsolen für das Cloud-Management sind ein besonders attraktives Angriffsziel: Gelingt es Hackern, Kontrolle über diese zu erlangen, können sie die Systeme etwa für Crypto-Mining und andere schädliche Zwecke missbrauchen.

Diagramm zur AppSec-Architektur

Ausgehend von dieser Struktur gilt es nun, die verschiedenen Security-Maßnahmen ebenenübergreifend miteinander zu verzahnen. So wird es möglich, die zugehörigen Prozesse präzise auszusteuern und zu operationalisieren. Damit einher geht zudem eine Reihe äußerst nützlicher Nebeneffekte. So lässt sich etwa Klickbetrug und damit eine der Ursachen für eine übermäßige Nutzung von Cloud-Ressourcen aufdecken.

Die 3 Kernsäulen der Anwendungssicherheit

Zentral für effektive Anwendungssicherheit ist ein solides Fundament, das sich auf drei Kernsäulen stützt:

• Technologie – Tools zur Prozesssteuerung und Vermittlung von Know-how

• Prozesse – Policies, Coding-Grundsätze und Kontrollen

• Teams – Security-Aufklärung und -Training (z. B. zur Prävention von Phishing)

Diese Elemente bilden den Ausgangspunkt für die strategische Umsetzung. Es gilt also, ausgehend vom eigenen Status quo zu bestimmen, an welchen Punkten jeweils Potenziale und Bedarf für Verbesserungen bestehen. Zu beachten ist dabei jedoch, dass diese Elemente ineinander greifen und sich gegenseitig stützen. Tools etwa nutzen wenig, wenn Teams sie nicht effektiv bedienen können. Entsprechend wichtig ist also adäquates Training. Umgekehrt wiederum gilt, dass Teams die Strategien für einen effektiven Einsatz dieser Tools erarbeiten können – ganz ähnlich, wie es sich auch mit Technologien für Sicherheit im physischen Kontext verhält. Noch detaillierter gehen wir auf die dazu nötigen Schritte in unserer Checkliste mit 15 Best Practices für starke Anwendungssicherheit ein.

Gestalten und verzahnen können Sie die einzelnen Elemente anhand des Dreigespanns aus folgenden Best Practices:

Evaluierung Ihrer Tooling-Anforderungen

1. Ermitteln Sie auf Grundlage Ihrer bestehenden Ressourcen und Ihrer budgetären Ausstattung, anhand welcher Tools Sie einen umfassend integrierten Tech-Stack aufbauen können. Wichtig dabei: Ihr Tooling sollte mit seinen Nutzern interagieren, ihnen also zielführendes Wissen etwa in Form von Security-Empfehlungen vermitteln und es ihnen dabei auch ermöglichen, es konkret umzusetzen.

2. Sondieren Sie den Markt auf Tools, anhand derer Sie bestehende Feature-Lücken schließen können.

3. Untersuchen Sie dabei, inwieweit sich die Tools Ihrer Wahl auch in Zukunft noch in Ihre Vision einfügen und mit Ihren Geschäftsanforderungen Schritt halten können.

Einrichtung klarer Prozessstrukturen

1. Evaluieren Sie Ihre bestehenden AppSec-Prozesse und bestimmen Sie auf dieser Basis einen Anforderungskatalog.

2. Führen Sie hierzu Tests anhand von praxisbezogenen Szenarien für den Ernstfall durch.

3. Halten Sie die so bestimmten Prozesse in einem zentralen, für alle einsehbaren Repository fest. So erleichtern Sie die teamübergreifende Umsetzung und vermeiden Überschneidungen.

Abbildung rollenspezifischer Anforderungen

1. In punkto Security-Know-how gilt das Gleiche wie für die Software, die es absichern soll: Nur durch regelmäßige Upgrades kann es mit aktuellen Entwicklungen Schritt halten. Die globale Community bietet hierzu verschiedenste Ressourcen, Trainingsmaterialien und Events, die Ihre Security- und Dev-Teams dabei unterstützen, ihre Kenntnisse rund um Bedrohungen und ihre Abwehr auf dem aktuellen Stand zu halten.

2. Sorgen Sie über diese Teams hinaus auch für Wissensaufbau und Aufklärung in sämtlichen anderen Unternehmensbereichen. Denn die Bedeutung von Sicherheit wie auch entsprechende Vorkehrungsmaßnahmen müssen ausnahmslos allen klar sein – von der Kantine bis zum CEO.

3. Lassen Sie dabei zudem keine Scheu aufkommen, Security-Probleme oder -Themen zu melden bzw. offen anzusprechen. Denn erst so lassen sie sich auch gezielt angehen und Verbesserungen anstoßen.

Die 6 Kategorien von Tools für AppSec-Scans

Bevor Entwickler ihre Anwendungen in die Produktion ausrollen, sollten sie – wenig überraschend – verschiedenen Tests zur Gewährleistung ihrer Sicherheit unterzogen werden. Hierzu stehen diverse Tools zur Verfügung, die von direkten Quellcode-Scans bis hin zu Prüfungen verschiedener Dateneingaben in die jeweilige Anwendung reichen. Am häufigsten zur Anwendung kommen dabei die folgenden sechs Verfahren:

• Static Application Security Testing (SAST): SAST ist ein sogenanntes Whitebox-Verfahren, bei dem der Quellcode ohne Ausführung der Anwendung auf Schwachpunkte getestet und in einem Report festgehalten wird, ob diese zu Sicherheitslücken in der Anwendung führen können.

• Interactive Application Security Testing (IAST): Dieses Verfahren ist dem vorgenannten ähnlich, allerdings erfolgt der Security-Test einer Anwendung unter Ausführung derselben. Dabei werden verschiedene Szenarien dazu simuliert, wie Nutzer in der Regel mit der jeweiligen Anwendung interagieren würden.

• Software Composition Analysis (SCA): Auch bekannt als Origin Analysis. Hier geht es darum, die innerhalb einer Anwendung genutzten Komponenten und Bibliotheken auszuleuchten und auf bekannte Schwachstellen zu analysieren. In diesem Fall erhalten die Entwickler dann auch Benachrichtigungen über ggf. für die betroffenen Elemente verfügbare Patches oder Updates.

• Dynamic Application Security Testing (DAST): Hierbei werden verschiedene Angriffstaktiken gegen eine Anwendung gefahren, während sie ausgeführt wird. Zugriff auf den Quellcode ist dabei nicht erforderlich, daher spricht man auch von einem Blackbox-Testverfahren.

• Application Security Testing as a Service (ASTaaS): Wie der Name schon vermuten lässt, übernimmt hier ein externer Dienstleister die Durchführung der Security-Tests. Angeboten wird dabei in der Regel eine Kombination aus statischen und dynamischen Verfahren sowie außerdem Penetrationstests und API-Checks.

• Fuzzing: Hierbei werden nach dem Zufallsprinzip generierte Daten in die Anwendung eingespeist, um so potenzielle Bugs aufzudecken. Angewandt wird Fuzzing in aller Regel ergänzend zu IAST, DAST, SAST und anderen Testverfahren.

SAST, DAST und SCA

Snyk: Ihr Partner für starke Anwendungssicherheit

Snyk implementiert Anwendungssicherheit nach einer Methodik, die sich von End-to-End-Monitoring bis zur Risikomitigierung nahtlos in die gewohnten Workflows von Entwicklern einfügt. Umgesetzt wird dies anhand folgender Toolsets:

1. Snyk Code implementiert SAST direkt in den Dev-Prozess und ermöglicht so eine ebenso effiziente wie unkomplizierte Behebung erkannter Probleme.

2. Snyk Open Source bietet ein Toolset für SCA-Analysen (Software Composition Analysis), mit dessen Hilfe sich Schwachstellen in Open-Source-Komponenten aufdecken und nach Priorität beheben lassen.

3. Snyk Container sorgt vom Base-Image bis zur Runtime für Sicherheit aller Aspekte der Container-Definition.

4. Snyk IaC unterstützt Entwickler dabei, IaC-Konfigurationen bereits im Dev-Prozess sicher zu machen.

5. Snyk Cloud ermöglicht die Umsetzung starker Cloud-Sicherheit anhand von Policy as Code.

Wie sich diese Technologien in den AppSec-Kontext einfügen, zeigt das nachfolgende Schaubild:

Prägend für die Technologien von Snyk ist es, Sicherheit nicht nur tief in die Anwendungsentwicklung einzubinden, sondern sie auch immer weiter zu automatisieren. Die hierzu nötigen Innovationen forcieren wir auf verschiedensten Ebenen. So auch über starke Partnerschaften etwa mit Sysdig, durch die es möglich wird, Anwendungen bereits in der Runtime absichern, oder auch über die jüngst bekannt gegebene Übernahme von Fugue. Das Ergebnis ist ein Verbund umfassend integrierter Tools, die Entwickler nahtlos in den gesamten AppSec-Lifecycle einbinden.

App-Security mit Snyk in der Praxis

Verschiedenste Unternehmen haben Snyk bereits im Einsatz, um Anwendungssicherheit entwicklerfreundlich in Dev-Workflows zu tragen. Lesen Sie in unseren Case Studies spannende Stories dazu, wie sie dadurch ihre AppSec-Prozesse ebenso stärken konnten wie den Security-Status ihrer Anwendungen.

„Gestützt auf Snyk gelang es dem Team von Glovo, kritische Schwachstellen in Abhängigkeiten und Code um 78 % zu reduzieren. Auch konnte das Team die Fixing-Zeit um 40 % verkürzen, dadurch entsprechend auch sicheren Code schneller ausliefern.“
Glovo

Passend zum Thema

15 Best Practices für starke Anwendungssicherheit 2022

Was genau sind App-Schwachstellen?

Die Top 10 der AppSec-Akronyme

FAQ