AI Security Landscape

AI Security Landscape

Von Benjamin Altmiks

KI in der Security: Die Frage ist nicht ob, sondern wo man anfängt

Wer ein altes Haus energetisch sanieren will, steht schnell vor einer entscheidenden Frage: Wo fängt man eigentlich an? Tauscht man zuerst die alte Ölheizung gegen eine Wärmepumpe? Oder lässt man besser erst eine Photovoltaikanlage aufs Dach bauen, die den Strom für ebenjene Wärmepumpe liefert? Beides ergibt Sinn, aber welcher der richtige erste Schritt ist, lässt sich ohne entsprechende Expertise oft nur schwer beurteilen.

Bei großen und mittelständischen Unternehmen sieht es gerade sehr ähnlich aus. KI? Ja gerne. Aber wo beginnen? Genau diese Unsicherheit beobachte ich seit längerem auch im Security-Bereich. Der naheliegende Einstieg ist meist ein vertrautes, alltägliches Thema. Viele lassen sich von einer KI zum Beispiel einfach lange Logfiles oder Reports zusammenfassen und auswerten. Und wenn ich der KI ohnehin schon solche Berichte vorlege, warum reiche ich ihr dann nicht gleich mehr Material, etwa den Source Code oder die Netzwerkinfrastruktur, und lasse beides direkt mitprüfen?

Schwierig ist dabei selten die Frage, ob KI hilft. Schwierig ist die Frage, wo man anfängt, ohne sich zu verzetteln.

Eine Karte, um sich zu orientieren

Aus genau diesem Grund haben wir den AI Security Landscape gebaut: eine offene Übersicht, die konkrete KI-Anwendungsfälle in der Cyber Security sortiert. Auf der einen Achse stehen die Security-Abteilungen, von Infrastruktur und AppSec über Security Operations bis hin zu GRC und Business Resilience. Auf der anderen Achse steht der jeweils passende Machine-Learning-Ansatz, von unüberwachtem Lernen bis zu Large Language Models.

Der wichtigste Gedanke dahinter: Ein LLM ist nicht immer die beste Wahl. Für viele Aufgaben passt ein klassischer ML-Ansatz schlicht besser, ist robuster und braucht weniger Aufsicht. Die Karte macht das sichtbar und hilft Teams zu erkennen, welcher Einstieg zu ihrer Datenlage und ihrem Reifegrad passt.

Ein Beispiel: der Weg zur KI-gestützten Code-Analyse

Nehmen wir ein Unternehmen, das künftig seine Code-Analysen von KI unterstützen lassen möchte. Dass LLMs dazu in der Lage sind, wurde zuletzt eindrucksvoll sichtbar, als ein Modell einen Bug in kritischer Software fand, der zuvor 27 Jahre lang von Sicherheitsexperten unentdeckt geblieben war. Im Alltag der Softwareentwicklung können LLMs auf dieselbe Weise Qualität und Sicherheit spürbar verbessern.

Nur: Ein LLM ohne Zusatzinformationen einfach blind über den Code laufen zu lassen, ist selten der beste Ansatz. Genau hier setzt der AI Security Landscape an. Er zeigt, dass ein vorgelagertes Threat Modeling dem Scanner wertvollen Kontext liefert. Welche Komponenten und Klassen sind besonders kritisch? Wie hängen die Teile zusammen? Mit diesen Antworten weiß die KI, worauf sie zuerst schauen muss, statt flach über die gesamte Codebasis zu scannen.

Das Schöne daran: Auch das Threat Modeling selbst lässt sich von KI vorbereiten. Wie mithilfe des Model Context Protocol (MCP) künftig automatisiert Threat Models erstellt werden können, ist ebenfalls Teil des AI Security Landscape. Damit wird ein KI-gestütztes Threat Modeling oft zum besseren Startpunkt für die erste KI-Umsetzung im Unternehmen, weil es allen folgenden Schritten eine solide Grundlage gibt.

Wenn die Grundlagen schon stehen

Und wenn ein Unternehmen bereits erfolgreich Threat Modeling betreibt und darauf aufbauend ein LLM zur Schwachstellen-Identifikation im Source Code nutzt? Dann hört der AI Security Landscape nicht auf. Er zeigt, welche Ansätze sich parallel oder anschließend lohnen.

Ein gutes Beispiel ist die RAG-based Vulnerability Triage & FP Reduction. Hier laufen die verschiedenen Informationsquellen zusammen, das Threat Model, die Scan-Ergebnisse und ergänzende Kontexte wie Architekturbeschreibungen. Sie werden strukturiert in eine Vektordatenbank überführt, also eine Art zentrale Wissensplattform, auf die ein LLM gezielt zugreifen kann. Auf dieser Basis lässt sich jede gefundene Schwachstelle fundiert bewerten. Das Modell kann mit dem vollen Kontext deutlich verlässlicher einschätzen, was ein echter Befund ist, was vermutlich ein False Positive bleibt und ob eine Schwachstelle überhaupt erreichbar ist.

Aus einem einzelnen Werkzeug wird so Schritt für Schritt eine zusammenhängende Kette, in der jeder Baustein den nächsten besser macht. Genau das ist der Gedanke hinter der Karte: nicht überall gleichzeitig anfangen, sondern dort, wo der erste Schritt den größten Hebel für alle weiteren hat.

Mitmachen erwünscht

Der AI Security Landscape ist ein offenes Projekt. Er lebt davon, dass Praktikerinnen und Praktiker ihre Erfahrungen einbringen, neue Use Cases ergänzen und bestehende schärfen. Wer einen Anwendungsfall vermisst oder aus der eigenen Praxis etwas beitragen kann, ist herzlich eingeladen, mitzuwirken.

Einen Topic beizutragen ist bewusst einfach gehalten: eine Markdown-Datei kopieren, ausfüllen, Pull Request öffnen. Den Rest prüft die Pipeline automatisch. Jeder Beitrag macht die Karte ein Stück nützlicher für alle, die gerade vor derselben Frage stehen: KI in der Security, ja gerne, aber wo anfangen?

Securing your docker containers

Securing your docker containers

by Michael Wager

Containers have become an essential part in modern software development. The technology greatly simplifies and enhances the way software is developed and deployed to production. DevOps – the combination of development and operations would be hard without them. This success leads to a giant number of public container image repositories and unfortunately also potential issues regarding security. Most of these containers contain many components not needed in production (e.g. shells, package managers, binaries/files with special permissions etc) and these components often have high or even critical vulnerabilities which could be exploited by malicious attackers. This report from Sysdig claims „that 75% of containers have “high” or “critical” patchable vulnerabilities“.

This blogpost will give a quick introduction to container security best practises and also looks at an interesting approach to reduce the attack surface by removing not needed components. It does not matter if you are using Kubernetes (K8s) or running your containers inside a public or private cloud.

 

Best practises

Typical vulnerabilities related containers are for example related to older – and therefore vulnerable – versions of docker (e.g. directory traversal) or vulnerabilities related binaries installed inside the image (See this link from snyk for more information about Docker Security – Challenges & Best Practices.) Also, snyk is the default scanner used behind the scenes when executing `docker scan`.

snyk-critical-container-scan-finding

Example output of a critical container vulnerability affecting the curl package from executing `docker scan`

 

Standards and relevant documents explaining potential security concerns in containers and also mitigations against them are the OWASP Container Security Verification Standard, the Application Container Security Guide from NIST and the BSI Grundschutz module SYS.1.6  about Containerization.
Although container security is a complex topic, fortunately there are certain low hanging fruits which are very easy to implement and can have large impact on security. Let’s have a look at some of them.

1. Do not run your containers as root

Docker containers run as root by default. But by using the USER command in your Dockerfile it is quite simple to switch to a non-root user.

2. Use Secure Container Registries

Just like as described in our post about vulnerable components inside your software supply chain, there may be vulnerable container images in certain public registries. Therefore you should only use trusted registries or even better, your own private registry.

3. Use minimal base images

There are images like „slim“ or „alpine“ you may use as base. They contain way less components than the large full blown default images and are therefore reducing the attack surface. Canonical, for example, provides Ubuntu base images free from high or critical vulnerabilities in a timely manner – commercial support from other vendors might also be an option in your organisation. The less components an image contains, the lower the likelihood of severe vulnerabilities.

4. Scan your containers for vulnerabilities

There are tools which scan your images for known vulnerabilities. You should use them and consider to fail the pipeline, e.g. in case there are high or critical findings. Some tools you could consider:

  • Trivy (Open source, free)
  • Snyk (Free for 100 tests / month)
  • PrismaCloud and twistcli (Enterprise ready)

5. Monitor your containers in production

After your containers are running in production, new vulnerabilities may be found. That’s why you should also monitor your containers and get notified when new vulnerabilities are discovered.

Unfortunately, scanners often report a lot of findings and false positives (or vulnerabilities that aren’t actually a risk to your specific software or service). It can be hard to decide if vulnerable components are really an issue. A better approach would be not to install so many components in the first place. Enter „distroless“!

6. Consider „Distroless“ images

A very interesting concept is coming from google and is called „distroless„. What they mean by distroless are images that contain only the application code and its runtime dependencies. The open source project provides ready to use images for Java, Node.js, C# and Python. Others may be built using either their „static“ base images or using google’s build tool Bazel. So you get small, production-ready images with only the dependencies you need, but it is important to note that development teams have to have very good knowledge about the underlying functionality of a linux system when using distroless. For example, a node.js application with a dependency to a glic based binary needs the app team to make certain non-trivial changes to the image build process. Another example regarding the PHP runtime, it can get quite complex when it comes to building your own images using Bazel. Other projects like “Chisel” from Canonical, the open source project behind Ubuntu, are currently trying to take this appoach to the next level. We have consulted companies regarding this topic and brought secure distroless images to production.

Conclusion

Just because your applications are running in containers does not mean they are secure – but there are simple ways to add more security. For our customers, we are always looking for efficient solutions to automate as much as possible and to shift security left. Our security experts can consult you on the topic and also help you selecting and integrating container scanning tools into your development lifecycle.

If you have questions, contact us at cybersecurity@secure-io.de