Skip to content
NeuralSkills
Bereitstellung

Container-Sicherheitsscanner

Container vor dem Produktionseinsatz auf Schwachstellen scannen — von Base-Image-CVEs bis zu fehlkonfigurierten Berechtigungen.

Fortgeschritten Kostenlos Veroeffentlicht: 15. April 2026
Kompatible Tools claude-codechatgptgeminicopilotcursorwindsurfuniversal

Das Problem

Ihr Container sieht in der CI gut aus, wird aber mit einem Base-Image ausgeliefert, das 47 bekannte CVEs enthaelt, als Root laeuft und Secrets in Umgebungsvariablen exponiert. Container-Sicherheit ist unsichtbar, bis ein Angreifer eine Schwachstelle in einer veralteten Bibliothek Ihres Base-Images ausnutzt. Die meisten Teams entdecken diese Probleme erst nach einem Sicherheitsaudit oder schlimmer — einem Sicherheitsvorfall.

Der Prompt

Du bist ein Container-Sicherheitsexperte. Hilf mir umfassendes Container-Scanning fuer mein Projekt einzurichten.

CONTAINER-DETAILS:
- Base-Image: [z.B. node:20, python:3.12-slim, golang:1.22-alpine]
- Registry: [z.B. Docker Hub, ECR, GCR, GitHub Container Registry]
- CI-Plattform: [z.B. GitHub Actions, GitLab CI, Jenkins]
- Aktuelles Scanning: [z.B. keines, Snyk, Trivy, Docker Scout]

Entwirf eine Container-Sicherheitsstrategie:
1. **Image-Scanning**: Schwachstellen-Scanning in CI einrichten — welches Tool, bei welchem Schweregrad blockieren, Umgang mit False Positives.
2. **Base-Image-Auswahl**: Das sicherste Base-Image fuer meine Runtime mit minimaler Angriffsflaeche empfehlen.
3. **Dockerfile-Sicherheitsaudit**: Gaengige Dockerfile-Sicherheits-Antimuster pruefen (Root-User, ADD vs. COPY, Secrets in Layern).
4. **Runtime-Sicherheit**: Was beim Deployment erzwungen werden sollte (Read-Only-Dateisystem, keine Privilege Escalation, Seccomp-Profile).
5. **Secret-Management**: Wie Secrets behandelt werden ohne sie ins Image einzubacken.
6. **Supply Chain**: Wie Image-Herkunft und -Integritaet verifiziert werden (Signierung, Attestierungen).
7. **CI-Integration**: Den exakten CI-Pipeline-Schritt zum Scannen von Images vor dem Push liefern.

Beispielausgabe

Scanning-Setup (GitHub Actions + Trivy):
- name: Container-Image scannen
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: myapp:${{ github.sha }}
    severity: CRITICAL,HIGH
    exit-code: 1  # Deployment bei kritischen/hohen CVEs blockieren

Base-Image: node:20-alpine (143 MB, 2 CVEs) vs. node:20 (1,1 GB, 47 CVEs)
Sicherheit: USER node, COPY statt ADD, keine Secrets in ENV, Read-Only Root-Dateisystem

Wann einsetzen

Verwenden Sie diesen Skill beim erstmaligen Einrichten von Container-Builds, bei der Integration von Sicherheitsscanning in Ihre CI-Pipeline oder nach einem Schwachstellenbericht zu Ihrem Base-Image.

Profi-Tipps

  • Scannen Sie sowohl beim Build als auch in der Registry — neue CVEs werden taeglich veroeffentlicht. Ein Image das gestern sauber war, kann heute kritische Schwachstellen haben.
  • Ignorieren Sie HIGH-Severity nicht — nur CRITICAL zu blockieren uebersieht ausnutzbare Schwachstellen. Setzen Sie Ihre CI auf Fehlschlag bei HIGH und hoeher.
  • Distroless-Images haben die kleinste Angriffsflaeche — Googles Distroless-Images enthalten nur Ihre App und deren Runtime, keine Shell, keinen Paketmanager, keine Werkzeuge fuer Angreifer.
  • Verwenden Sie nie den latest-Tag in Produktion — pinnen Sie auf spezifische Digests fuer Reproduzierbarkeit und zum Schutz vor Supply-Chain-Angriffen.