Sicherheit in der CI/CD-Pipeline

Die CI/CD-Pipeline ist die letzte Verteidigungslinie, bevor Code die Produktion erreicht. Jeder Commit, jeder Pull Request, jedes Deployment läuft durch sie. Das macht sie zum idealen Ort, um Sicherheitsprobleme abzufangen — Schwachstellen im Code, gefährliche Abhängigkeiten, Fehlkonfigurationen, durchgesickerte Geheimnisse.

Das Ziel ist nicht, jeden Build mit Sicherheitswarnungen zu blockieren. Es geht darum, kritische Probleme automatisch zu erkennen, Entwicklern schnelles Feedback zu geben und offensichtliche Fehler aufzuhalten, bevor sie ausgeliefert werden. Eine gut konfigurierte Pipeline findet SQL-Injection vor dem Code-Review, kennzeichnet anfällige Abhängigkeiten vor dem Merge und blockiert bekannte schlechte Muster, bevor sie die Produktion erreichen.

Dieses Kapitel behandelt die fünf Arten von Sicherheits-Scanning, die Sie in CI/CD benötigen: statische Analyse (SAST), Abhängigkeits-Scanning (SCA), Software-Stückliste (SBOM), Infrastructure-as-Code-Scanning (IaC) und dynamisches Testen (DAST). Alles mit kostenlosen Tools, die mit GitHub und GitLab funktionieren.

Warum das für kleine Unternehmen wichtig ist

Sicherheits-Scanning klingt nach Enterprise-Overhead. Ist es nicht. Für kleine Teams ist automatisches Scanning sogar noch wertvoller — Sie haben keine dedizierten Sicherheitsprüfer, also muss die Pipeline diese Arbeit übernehmen.

Sie können nicht alles manuell prüfen. Ein Team von fünf Entwicklern produziert vielleicht Dutzende von Commits pro Tag. Niemand hat Zeit, jede Änderung sicherheitstechnisch zu prüfen. Automatische Scanner fangen die offensichtlichen Probleme ab, damit sich Menschen auf Architektur und Logik konzentrieren können.

Schwachstellen werden in kleinen Teams schneller ausgeliefert. Keine Change Advisory Boards, keine mehrstufigen Genehmigungen, kein Warten. Code gelangt in Stunden vom Laptop in die Produktion. Diese Geschwindigkeit ist ein Vorteil, bedeutet aber auch, dass Schwachstellen schnell mitreisen. Scanning in CI/CD ist Ihr Sicherheitsnetz.

Abhängigkeitsrisiken sind real. Ihre Anwendung besteht vielleicht aus 10.000 selbst geschriebenen Codezeilen und 500.000 Zeilen Open-Source-Abhängigkeiten, die Sie nicht geschrieben haben. Ein anfälliges Paket in diesem Stack kann alles kompromittieren. Snyks Bericht 2024 stellte fest, dass 80 % der Anwendungen mindestens eine bekannte Schwachstelle in ihren Abhängigkeiten enthalten.

Kostenlose Tools sind produktionsreif. Semgrep, Trivy, Dependabot, npm audit — das sind keine Spielzeugprojekte. Sie werden von Tausenden von Unternehmen eingesetzt und finden echte Schwachstellen. Sie brauchen keine 50.000-Dollar-Sicherheitsplattform, um Ihren Code zu scannen.

Wonach Angreifer suchen

Wenn Angreifer eine Anwendung ins Visier nehmen, beginnen sie oft mit den einfachen Zielen:

Bekannte CVEs in Abhängigkeiten — öffentliche Exploits existieren, man muss nur ein Ziel finden, das die anfällige Version nutzt
Exponierte Geheimnisse — API-Schlüssel, Datenbankpasswörter, Cloud-Zugangsdaten im Code oder in CI-Logs
Injection-Schwachstellen — SQL-Injection, Command-Injection, XSS, die automatische Tools zuverlässig erkennen
Fehlkonfigurierte Infrastruktur — offene S3-Buckets, permissive CORS-Einstellungen, fehlende Sicherheitsheader

Automatisches Scanning erkennt die meisten dieser Probleme. Angreifer nutzen automatisierte Tools, um sie zu finden — Sie sollten automatisierte Tools einsetzen, um sie zuerst zu finden.

Arten von Sicherheits-Scanning

Fünf Kategorien decken das meiste ab, was Sie brauchen:

Typ	Was es tut	Wann es läuft	Beispiele
SAST (Static Application Security Testing)	Analysiert Quellcode auf Schwachstellen	Jeder Commit, PR	Semgrep, CodeQL, Bandit
SCA (Software Composition Analysis)	Findet anfällige Abhängigkeiten	Jeder Build	Dependabot, Snyk, Trivy
SBOM (Software Bill of Materials)	Inventarisiert alle Komponenten, verfolgt Lizenzen	Jedes Release	Syft, Grype, Dependency-Track
IaC-Scanning	Findet Fehlkonfigurationen in Infrastruktur-Code	Jeder Commit	Checkov, tfsec, KICS
DAST (Dynamic Application Security Testing)	Testet die laufende Anwendung auf Schwachstellen	Staging-Deployments	OWASP ZAP, Nuclei

Jedes erkennt andere Probleme:

SAST findet Probleme in Code, den Sie schreiben: SQL-Injection, XSS, unsichere Kryptografie
SCA findet Probleme in Code, den Sie importieren: anfällige Bibliotheken, veraltete Pakete
SBOM verfolgt, was in Ihrer Software steckt: Komponenteninventar, Lizenz-Compliance, Schwachstellen-Korrelation
IaC findet Probleme in der Infrastruktur: offene S3-Buckets, übermäßig permissive IAM-Rollen, unverschlüsselter Speicher
DAST findet Probleme im laufenden Betrieb: fehlkonfigurierte Server, exponierte Endpunkte, Authentifizierungsumgehungen

Sie brauchen alle fünf. Sie ergänzen sich, sind keine Alternativen.

SAST: statische Code-Analyse

SAST-Tools lesen Ihren Quellcode und suchen nach Mustern, die auf Schwachstellen hinweisen. Kein Laufzeitbetrieb, kein Deployment — nur Code-Analyse.

Was SAST erkennt

Schwachstelle	Wie SAST sie findet
SQL-Injection	String-Konkatenation in SQL-Abfragen
XSS	Unbereinigter Output in HTML-Templates
Command-Injection	Benutzereingaben in Shell-Befehlen
Pfad-Traversal	Benutzereingaben in Dateioperationen
Hartcodierte Geheimnisse	Muster, die zu API-Schlüsseln und Passwörtern passen
Unsichere Kryptografie	Verwendung von MD5, SHA1 für Passwörter, schwache Zufallszahlen

Tool: Semgrep

Semgrep ist das bevorzugte SAST-Tool für kleine Teams. Es ist schnell, hat gute Regeln direkt out-of-the-box und lässt sich in alles integrieren.

Lokale Installation:

# macOS
brew install semgrep

# pip
pip install semgrep

Scan ausführen:

# Scan mit Standard-Regeln
semgrep --config auto .

# Scan mit OWASP Top 10-Regeln
semgrep --config "p/owasp-top-ten" .

# Scan für eine bestimmte Sprache
semgrep --config "p/python" .

GitHub Actions-Integration:

name: Security Scan

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  semgrep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Semgrep
        uses: semgrep/semgrep-action@v1
        with:
          config: >-
            p/security-audit
            p/secrets

GitLab CI-Integration:

semgrep:
  stage: test
  image: semgrep/semgrep
  script:
    - semgrep ci --config auto
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Tool: CodeQL (nur GitHub)

GitHubs CodeQL ist leistungsstark, funktioniert aber nur auf GitHub. Für öffentliche Repositories kostenlos, in GitHub Advanced Security für private Repositories enthalten.

In Repository-Einstellungen aktivieren:

Gehen Sie zu Settings → Security → Code security and analysis
Aktivieren Sie „Code scanning"
Wählen Sie „CodeQL analysis"
Wählen Sie die zu scannenden Sprachen

Oder manuell konfigurieren:

name: CodeQL

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 6 * * 1'  # Weekly Monday 6 AM

jobs:
  analyze:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
    
    strategy:
      matrix:
        language: ['javascript', 'python']
    
    steps:
      - uses: actions/checkout@v4
      
      - name: Initialize CodeQL
        uses: github/codeql-action/init@v3
        with:
          languages: ${{ matrix.language }}
      
      - name: Perform CodeQL Analysis
        uses: github/codeql-action/analyze@v3

Sprachspezifische Tools

Sprache	Tool	Installation	Ausführung
Python	Bandit	`pip install bandit`	`bandit -r src/`
JavaScript	ESLint + security plugin	`npm i eslint-plugin-security`	`eslint --ext .js src/`
Go	gosec	`go install github.com/securego/gosec/v2/cmd/gosec@latest`	`gosec ./...`
Ruby	Brakeman	`gem install brakeman`	`brakeman`
PHP	Psalm	`composer require --dev vimeo/psalm`	`./vendor/bin/psalm`

Umgang mit SAST-Befunden

Nicht jeder Befund ist eine echte Schwachstelle. SAST-Tools haben Falsch-Positive. So gehen Sie damit um:

Nach Schweregrad priorisieren:

Schweregrad	Maßnahme	Zeitrahmen
Kritisch/Hoch	Merge blockieren, sofort beheben	Selber Tag
Mittel	Vor Release beheben	Dieser Sprint
Niedrig	Verfolgen, bei Gelegenheit beheben	Backlog

Falsch-Positive korrekt unterdrücken:

# Semgrep: inline ignore
password = get_from_vault()  # nosemgrep: hardcoded-password

# Bandit: inline ignore
subprocess.run(cmd, shell=True)  # nosec B602

Oder eine Konfigurationsdatei verwenden:

# .semgrep.yml
rules:
  - id: my-custom-rule
    # ... rule definition
    
# Ignore specific paths
exclude:
  - "tests/*"
  - "vendor/*"
  - "*.test.js"

Nicht alles unterdrücken. Wenn Sie mehr als 10 % der Befunde unterdrücken, hat Ihr Code entweder Probleme oder Sie verwenden das falsche Regelset.

SCA: Abhängigkeits-Scanning

Ihre Abhängigkeiten sind eine Angriffsfläche. SCA-Tools scannen Ihre Paketmanifeste (package.json, requirements.txt, go.mod) und markieren Pakete mit bekannten Schwachstellen.

Was SCA erkennt

Bekannte CVEs — veröffentlichte Schwachstellen in bestimmten Paketversionen
Lizenzprobleme — GPL-Abhängigkeiten in proprietärem Code, Lizenzkonflikte
Veraltete Pakete — alte Versionen ohne Sicherheitsfixes
Schädliche Pakete — Typosquatting, kompromittierte Maintainer

Tool: Dependabot (GitHub)

Dependabot ist in GitHub integriert. Es scannt Abhängigkeiten, öffnet PRs zum Aktualisieren anfälliger Pakete und hält alles aktuell.

Im Repository aktivieren:

Gehen Sie zu Settings → Security → Code security and analysis
Aktivieren Sie „Dependabot alerts"
Aktivieren Sie „Dependabot security updates"

Oder mit einer Datei konfigurieren:

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10
    
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"
    
  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "weekly"

Updates gruppieren, um PR-Lärm zu reduzieren:

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      development-dependencies:
        dependency-type: "development"
      production-dependencies:
        dependency-type: "production"
        update-types:
          - "minor"
          - "patch"

Tool: Snyk

Snyk funktioniert mit GitHub, GitLab, Bitbucket und eigenständig. Der kostenlose Tarif umfasst unbegrenzte Tests für Open-Source-Projekte und begrenzte Scans für private Repositories.

CLI installieren:

npm install -g snyk
snyk auth

Lokal scannen:

# Aktuelles Projekt testen
snyk test

# Testen und Behebung anzeigen
snyk test --show-vulnerable-paths=all

# Auf neue Schwachstellen überwachen
snyk monitor

GitHub Actions-Integration:

name: Snyk Security

on:
  push:
    branches: [main]
  pull_request:

jobs:
  snyk:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Snyk
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high

GitLab CI-Integration:

snyk:
  stage: test
  image: snyk/snyk:node
  script:
    - snyk auth $SNYK_TOKEN
    - snyk test --severity-threshold=high
  allow_failure: true  # Don't block on medium/low

Tool: Trivy

Trivy scannt alles — Container-Images, Dateisysteme, Git-Repositories, Kubernetes-Manifeste, Terraform. Es ist unglaublich vielseitig.

Installation:

# macOS
brew install trivy

# Linux
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin

Dateisystem scannen (Abhängigkeiten):

trivy fs --severity HIGH,CRITICAL .

Container-Image scannen:

trivy image --severity HIGH,CRITICAL myapp:latest

GitHub Actions für Container-Scanning:

name: Container Security

on:
  push:
    branches: [main]

jobs:
  trivy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .
      
      - name: Run Trivy
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: myapp:${{ github.sha }}
          severity: 'CRITICAL,HIGH'
          exit-code: '1'

Native Paketmanager-Audits

Die meisten Paketmanager haben eingebautes Schwachstellen-Scanning:

# npm
npm audit
npm audit fix

# yarn
yarn audit

# pip
pip-audit

# composer
composer audit

# bundler
bundle audit

# go
govulncheck ./...

Zur CI-Pipeline hinzufügen:

# GitHub Actions - npm audit
- name: Security audit
  run: npm audit --audit-level=high

Umgang mit Abhängigkeits-Schwachstellen

Wenn eine Schwachstelle einen Fix hat:

Auf die gepatchte Version aktualisieren
Tests ausführen
Deployen

Wenn kein Fix verfügbar ist:

Prüfen Sie, ob Sie die anfällige Funktion tatsächlich nutzen
Echtes Risiko bewerten — ist der anfällige Code-Pfad erreichbar?
Alternative Pakete in Betracht ziehen
Falls akzeptables Risiko, dokumentieren und überwachen

Wenn Updates etwas kaputt machen:

Prüfen, ob es ein Breaking Change ist, dem Sie sich anpassen können
Vorübergehend auf die aktuelle Version fixieren
Ein Ticket zur ordnungsgemäßen Behebung erstellen
Eine Frist setzen — nicht auf unbestimmte Zeit liegen lassen

SBOM: Software Bill of Materials

Eine SBOM ist ein vollständiges Inventar aller Komponenten in Ihrer Software — jede Bibliothek, jedes Framework, jede Abhängigkeit, mit Versionen und Herkunft. Stellen Sie sich das als Zutatenliste für Ihre Anwendung vor.

Warum SBOM wichtig ist

Schnelligkeit bei der Vorfallsreaktion. Als Log4Shell im Dezember 2021 auftauchte, wussten Organisationen mit SBOMs innerhalb von Stunden, welche Anwendungen betroffen waren. Diejenigen ohne verbrachten Tage oder Wochen mit manueller Untersuchung. Die U.S. Cybersecurity Executive Order 14028 verlangt jetzt SBOMs für Software, die an die Bundesregierung verkauft wird.

Sichtbarkeit der Lieferkette. Ihre App hängt von Paket A ab, das von B abhängt, das von C abhängt. Eine Schwachstelle in C betrifft Sie, aber Sie wissen vielleicht nicht, dass C ohne eine SBOM existiert. Transitive Abhängigkeiten sind ohne geeignetes Tooling unsichtbar.

Lizenz-Compliance. Das MIT-lizenzierte Paket, das Sie verwenden, könnte von einer GPL-Bibliothek abhängen. Ohne eine SBOM werden Sie es nicht wissen, bis der Rechtsabteilung anklopft. Lizenzanalyse erfordert die Kenntnis jeder Komponente in Ihrem Stack.

Kundenanforderungen. Enterprise-Kunden verlangen zunehmend SBOMs als Teil von Lieferanten-Sicherheitsbewertungen. Gesundheitswesen, Finanzwesen und öffentliche Stellen schreiben sie oft vor.

SBOM-Formate

Zwei Hauptformate dominieren:

Format	Betreiber	Am besten für	Link
SPDX	Linux Foundation	Lizenz-Compliance, breite Verbreitung	spdx.dev
CycloneDX	OWASP	Sicherheitsfokus, Schwachstellen-Tracking	cyclonedx.org

Beide sind maschinenlesbar (JSON, XML) und für die meisten Zwecke austauschbar. CycloneDX hat bessere Schwachstellen-Korrelation; SPDX hat breitere Branchenadoption für Lizenz-Compliance.

SBOMs generieren

Tool: Syft — der Standard für SBOM-Generierung

# Install
brew install syft
# or
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# Generate SBOM from directory
syft dir:. -o cyclonedx-json > sbom.json

# Generate from container image
syft myapp:latest -o spdx-json > sbom.spdx.json

# Generate from package lock files
syft dir:. -o cyclonedx-json --catalogers javascript

GitHub Actions:

- name: Generate SBOM
  uses: anchore/sbom-action@v0
  with:
    image: myapp:${{ github.sha }}
    format: cyclonedx-json
    output-file: sbom.json

- name: Upload SBOM
  uses: actions/upload-artifact@v4
  with:
    name: sbom
    path: sbom.json

GitLab CI:

generate_sbom:
  stage: build
  image: anchore/syft
  script:
    - syft dir:. -o cyclonedx-json > sbom.json
  artifacts:
    paths:
      - sbom.json

Weitere SBOM-Generatoren:

Tool	Typ	Am besten für	Link
Syft	CLI	Universelle Generierung	GitHub
Trivy	CLI	Kombiniertes Scanning + SBOM	trivy.dev
cdxgen	CLI	CycloneDX-nativ	GitHub
Microsoft SBOM Tool	CLI	.NET, allgemein	GitHub
SPDX SBOM Generator	CLI	SPDX-nativ	GitHub

SBOMs auf Schwachstellen analysieren

Wenn Sie eine SBOM haben, scannen Sie sie auf bekannte Schwachstellen:

Tool: Grype — Schwachstellen-Scanner, der SBOMs verarbeitet

# Install
brew install grype

# Scan SBOM for vulnerabilities
grype sbom:sbom.json

# Scan with severity filter
grype sbom:sbom.json --only-fixed --fail-on high

GitHub Actions:

- name: Generate SBOM
  uses: anchore/sbom-action@v0
  with:
    image: myapp:latest
    output-file: sbom.json

- name: Scan SBOM for vulnerabilities
  uses: anchore/scan-action@v3
  with:
    sbom: sbom.json
    fail-build: true
    severity-cutoff: high

Weitere Schwachstellen-Scanner für SBOMs:

Tool	Preis	Funktionen	Link
Grype	Kostenlos	Schnell, SBOM-nativ	GitHub
Trivy	Kostenlos	Universeller Scanner	trivy.dev
OSV-Scanner	Kostenlos	Googles OSV-Datenbank	GitHub
Snyk	Kostenloser Tarif	Beste Behebungshinweise	snyk.io
OWASP Dependency-Track	Kostenlos (selbst gehostet)	Vollständige SBOM-Verwaltungsplattform	dependencytrack.org
Anchore Enterprise	Kostenpflichtig	Policy-Engine, Compliance	anchore.com
Sonatype Nexus Lifecycle	Kostenpflichtig	Tiefgehende Analyse, Richtlinien	sonatype.com

SBOMs auf Lizenz-Compliance analysieren

Lizenzprobleme können genauso schädlich sein wie Sicherheitsschwachstellen — rechtliche Risiken, erzwungene Offenlegung von proprietärem Code oder die Unfähigkeit, an bestimmte Kunden zu liefern.

Häufige Lizenzbedenken:

Lizenztyp	Bedenken	Beispiellizenzen
Copyleft	Kann das Offenlegen Ihres Codes erfordern	GPL, AGPL, LGPL
Schwaches Copyleft	Erfordert Namensnennung, einige Einschränkungen	MPL, EPL
Permissiv	Im Allgemeinen sicher für kommerzielle Nutzung	MIT, Apache 2.0, BSD
Unbekannt	Keine Lizenz = alle Rechte vorbehalten	Unlizenzierte Pakete

Tool: OWASP Dependency-Track — vollständige SBOM-Verwaltung

Dependency-Track ist eine kostenlose, selbst gehostete Plattform, die SBOMs aufnimmt und Folgendes bietet:

Schwachstellen-Tracking über alle Projekte hinweg
Lizenz-Compliance-Analyse
Richtliniendurchsetzung
Historisches Tracking

# Run with Docker
docker run -d -p 8080:8080 dependencytrack/bundled

Dann SBOMs über API oder UI hochladen.

Kommerzielle Lizenz-Compliance-Tools:

Tool	Preis	Funktionen	Link
OWASP Dependency-Track	Kostenlos (selbst gehostet)	Vollständige SBOM-Plattform	dependencytrack.org
FOSSA	Kostenloser Tarif, kostenpflichtige Pläne	Tiefe Lizenzanalyse	fossa.com
Snyk	Kostenloser Tarif	Lizenz-Scanning enthalten	snyk.io
Mend (WhiteSource)	Kostenpflichtig	Enterprise-Compliance	mend.io
Black Duck	Enterprise	Tiefe Lizenz-Intelligenz	synopsys.com
Sonatype Nexus	Kostenpflichtig	Lizenzrichtlinien	sonatype.com
Snyk	Kostenloser Tarif	Vereinheitlichte Sicherheit + Lizenz	snyk.io

Schneller Lizenz-Scan mit Trivy:

# Scan for licenses
trivy fs --scanners license .

# Check for specific problematic licenses
trivy fs --scanners license --license-full .

GitHub Actions für Lizenz-Compliance:

- name: License check
  uses: fossas/fossa-action@main
  with:
    api-key: ${{ secrets.FOSSA_API_KEY }}

SBOM im CI/CD-Workflow

SBOM-Generierung und -Analyse in Ihre Pipeline integrieren:

# Complete SBOM workflow
name: SBOM Pipeline

on:
  push:
    branches: [main]
  release:
    types: [published]

jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .
      
      # Generate SBOM
      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          image: myapp:${{ github.sha }}
          format: cyclonedx-json
          output-file: sbom.json
      
      # Scan for vulnerabilities
      - name: Vulnerability scan
        uses: anchore/scan-action@v3
        with:
          sbom: sbom.json
          fail-build: true
          severity-cutoff: high
      
      # Check licenses
      - name: License scan
        run: |
          trivy fs --scanners license --severity HIGH,CRITICAL . \
            --exit-code 1
      
      # Store SBOM with release
      - name: Upload SBOM to release
        if: github.event_name == 'release'
        uses: softprops/action-gh-release@v1
        with:
          files: sbom.json

Best Practices für SBOMs

Mit jedem Build generieren. SBOMs sollten Artefakte sein, die zusammen mit Ihren Releases versioniert werden.
SBOMs mit Releases speichern. An GitHub-Releases anhängen, in einer Artefakt-Registry speichern oder in Dependency-Track hochladen.
Schwachstellen-Scanning automatisieren. Nicht nur generieren — analysieren. Benachrichtigungen für neue CVEs einrichten, die Ihre Komponenten betreffen.
Lizenzrichtlinien definieren. Entscheiden Sie, welche Lizenzen für Ihren Anwendungsfall akzeptabel sind. Builds blockieren, die problematische Lizenzen einführen.
Mit Kunden teilen. Wenn Kunden SBOMs benötigen, die Lieferung automatisieren. Daraus keinen manuellen Prozess machen.
Kontinuierlich überwachen. Neue Schwachstellen werden täglich entdeckt. Gespeicherte SBOMs gegen aktualisierte Schwachstellen-Datenbanken scannen.

DAST: dynamisches Testen

DAST-Tools testen laufende Anwendungen, indem sie Anfragen senden und Antworten analysieren. Sie finden Probleme, die statische Analyse nicht sehen kann — Laufzeit-Fehlkonfigurationen, Authentifizierungsumgehungen, Probleme mit Antwort-Headern.

Was DAST erkennt

Problem	Wie DAST es findet
Fehlende Sicherheitsheader	Prüft Antwort-Header
XSS	Injiziert Payloads, prüft auf Reflexion
SQL-Injection	Injiziert SQL, prüft auf Fehler/Verhaltensänderungen
Authentifizierungsumgehung	Testet Zugriff ohne gültige Zugangsdaten
CORS-Fehlkonfiguration	Testet Cross-Origin-Anfragen
SSL/TLS-Probleme	Testet Zertifikat, Protokollversionen

Tool: OWASP ZAP

ZAP (Zed Attack Proxy) ist das Standard-Open-Source-DAST-Tool. Es kann automatische Scans durchführen oder als abfangender Proxy für manuelle Tests verwendet werden.

Docker-basierter CI-Scan:

# GitHub Actions
name: DAST Scan

on:
  push:
    branches: [main]

jobs:
  zap:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Start application
        run: |
          docker compose up -d
          sleep 30  # Wait for app to start
      
      - name: ZAP Baseline Scan
        uses: zaproxy/action-[email protected]
        with:
          target: 'http://localhost:3000'
          rules_file_name: '.zap/rules.tsv'
          allow_issue_writing: false

GitLab CI-Integration:

dast:
  stage: test
  image: ghcr.io/zaproxy/zaproxy:stable
  script:
    - mkdir -p /zap/wrk
    - zap-baseline.py -t $STAGING_URL -r report.html -I
  artifacts:
    paths:
      - report.html
  only:
    - main

Baseline- vs. vollständiger Scan:

Scan-Typ	Dauer	Abdeckung	Anwendungsfall
Baseline	1–5 Minuten	Passive Prüfungen, keine Angriffe	Jedes Deployment
Vollständig	30–60+ Minuten	Aktive Angriffe, gründlich	Wöchentlich, vor Releases

Tool: Nuclei

Nuclei ist schnell, Template-basiert und ideal für spezifische Schwachstellen-Prüfungen.

Installation:

# macOS/Linux
brew install nuclei

# or
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

Scans ausführen:

# Default templates
nuclei -u https://staging.example.com

# Specific severity
nuclei -u https://staging.example.com -severity high,critical

# Specific templates
nuclei -u https://staging.example.com -t cves/ -t misconfigurations/

CI-Integration:

nuclei:
  stage: test
  image: projectdiscovery/nuclei
  script:
    - nuclei -u $STAGING_URL -severity high,critical -o results.txt
  artifacts:
    paths:
      - results.txt

Wann DAST ausführen

DAST braucht eine laufende Anwendung, was die CI/CD-Integration verkompliziert:

Option 1: Staging nach dem Deployment testen

deploy_staging:
  stage: deploy
  script:
    - ./deploy-staging.sh

dast_scan:
  stage: test
  needs: [deploy_staging]
  script:
    - zap-baseline.py -t $STAGING_URL

Option 2: Kurzlebige Umgebung hochfahren

dast:
  stage: test
  services:
    - docker:dind
  script:
    - docker compose up -d
    - sleep 30
    - nuclei -u http://docker:3000 -severity critical
    - docker compose down

Option 3: Geplante Scans (nicht in der PR-Pipeline)

# Run weekly, not on every commit
dast_weekly:
  stage: security
  script:
    - zap-full-scan.py -t $PRODUCTION_URL -r report.html
  only:
    - schedules

IaC-Scanning: Infrastructure as Code

Wenn Sie Terraform, CloudFormation oder Kubernetes-Manifeste verwenden, brauchen Sie IaC-Scanning. Fehlkonfigurationen in Infrastruktur-Code sind genauso gefährlich wie Anwendungs-Schwachstellen — offene S3-Buckets, übermäßig permissive IAM-Rollen, unverschlüsselte Datenbanken.

Was IaC-Scanning erkennt

Problem	Beispiel
Öffentliche S3-Buckets	`acl = "public-read"`
Übermäßig permissives IAM	`Action: ""`, `Resource: ""`
Unverschlüsselter Speicher	Fehlendes `encrypted = true`
Offene Security-Groups	`0.0.0.0/0` Ingress
Fehlende Protokollierung	CloudTrail, VPC-Flow-Logs deaktiviert
Hartcodierte Geheimnisse	API-Schlüssel in Terraform-Variablen

Tool: Checkov

Checkov ist der umfassendste kostenlose IaC-Scanner. Er unterstützt Terraform, CloudFormation, Kubernetes, Helm, ARM und mehr.

Installation:

pip install checkov

Lokal scannen:

# Scan Terraform directory
checkov -d terraform/

# Scan specific file
checkov -f main.tf

# Output as JSON for CI
checkov -d terraform/ -o json

GitHub Actions:

- name: Checkov
  uses: bridgecrewio/checkov-action@master
  with:
    directory: terraform/
    soft_fail: false
    skip_check: CKV_AWS_18,CKV_AWS_21  # Skip specific checks if needed

GitLab CI:

checkov:
  stage: test
  image: bridgecrew/checkov
  script:
    - checkov -d terraform/ --output cli --output junitxml --output-file-path console,results.xml
  artifacts:
    reports:
      junit: results.xml

Tool: tfsec (Terraform-spezifisch)

Wenn Sie nur Terraform verwenden, ist tfsec schneller und Terraform-fokussiert.

Installation:

brew install tfsec

Scannen:

tfsec terraform/
tfsec terraform/ --severity-override=HIGH,CRITICAL

GitHub Actions:

- name: tfsec
  uses: aquasecurity/tfsec-[email protected]
  with:
    working_directory: terraform/

Umgang mit IaC-Befunden

IaC-Befunde erfordern oft Kontext. Ein „öffentlicher S3-Bucket" kann absichtlich sein (Hosting einer statischen Website) oder ein kritisches Problem (Speicherung von Kundendaten).

Beabsichtigte Konfigurationen unterdrücken:

# tfsec:ignore:aws-s3-no-public-access
resource "aws_s3_bucket" "website" {
  # This bucket intentionally hosts public website
  bucket = "company-website-assets"
}

# Checkov skip
resource "aws_s3_bucket" "website" {
  #checkov:skip=CKV_AWS_18:This bucket hosts public website
  bucket = "company-website-assets"
}

Alles zusammensetzen

Ein vollständiges Sicherheits-Scanning-Setup für eine typische Webanwendung:

GitHub Actions-Beispiel

name: Security Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  # SAST - runs on every commit
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Semgrep
        uses: semgrep/semgrep-action@v1
        with:
          config: p/security-audit p/secrets

  # SCA - runs on every commit
  sca:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      
      - name: Install dependencies
        run: npm ci
      
      - name: npm audit
        run: npm audit --audit-level=high
      
      - name: Snyk test
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high
        continue-on-error: true  # Alert but don't block

  # Container scanning - if building images
  container:
    runs-on: ubuntu-latest
    if: github.event_name == 'push'
    steps:
      - uses: actions/checkout@v4
      
      - name: Build image
        run: docker build -t app:${{ github.sha }} .
      
      - name: Trivy scan
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: app:${{ github.sha }}
          severity: 'CRITICAL,HIGH'
          exit-code: '1'

  # DAST - only on main branch after deploy
  dast:
    runs-on: ubuntu-latest
    needs: [sast, sca]
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
      
      - name: Deploy to staging
        run: ./deploy-staging.sh
      
      - name: ZAP Baseline
        uses: zaproxy/action-[email protected]
        with:
          target: ${{ secrets.STAGING_URL }}

GitLab CI-Beispiel

stages:
  - test
  - build
  - security
  - deploy

variables:
  DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

# SAST
semgrep:
  stage: test
  image: semgrep/semgrep
  script:
    - semgrep ci --config auto
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

# SCA - dependencies
dependency_scan:
  stage: test
  image: node:20
  script:
    - npm ci
    - npm audit --audit-level=high
  allow_failure: true

# SCA - Snyk
snyk:
  stage: test
  image: snyk/snyk:node
  script:
    - snyk auth $SNYK_TOKEN
    - snyk test --severity-threshold=high
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

# Build container
build:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker build -t $DOCKER_IMAGE .
    - docker push $DOCKER_IMAGE

# Container scanning
trivy:
  stage: security
  image: aquasec/trivy
  script:
    - trivy image --exit-code 1 --severity HIGH,CRITICAL $DOCKER_IMAGE
  needs: [build]

# DAST on staging
dast:
  stage: security
  image: ghcr.io/zaproxy/zaproxy:stable
  script:
    - zap-baseline.py -t $STAGING_URL -I
  needs: [deploy_staging]
  only:
    - main

Wenn Scanner Probleme finden: Playbook für Security Champions

Ihre Pipeline hat einen Merge-Request blockiert. Oder schlimmer — sie hat etwas in Code markiert, der bereits in der Produktion ist. Was jetzt?

Dieser Abschnitt bietet einen strukturierten Ansatz für Security Champions, um mit Sicherheitsbefunden umzugehen, von der ersten Triage bis zur Behebung. Der Prozess folgt modernen Schwachstellen-Management-Methoden, einschließlich CVSS, SSVC und VEX.

Schritt 1: Erste Triage (5–10 Minuten)

Bevor Sie tief einsteigen, bewerten Sie schnell, womit Sie es zu tun haben:

Grundlegende Informationen sammeln:

Frage	Wo zu finden
Welcher Scanner hat es gefunden?	Pipeline-Output, Tool-Name
Was ist der Befundtyp?	CVE-ID, CWE, Regel-ID
Wo ist es?	Datei, Zeilennummer, Abhängigkeit
Welchen Schweregrad meldet das Tool?	Kritisch/Hoch/Mittel/Niedrig
Ist dies neuer oder bestehender Code?	PR-Diff, git blame

Schnelle Klassifizierung:

Erste Triage-Fragen:

Ist dies ein bekanntes Falsch-Positiv? → Ja: dokumentieren und unterdrücken (Schritt 6). Nein: weiter zu Schritt 2.
Ist dies gerade in der Produktion? → Ja: paralleler Track — Produktionsexposition bewerten (Schritt 5). Nein: normalen Fluss fortsetzen.
Blockiert dies ein kritisches Deployment? → Ja: sofort eskalieren, mehr Augen hinzuziehen. Nein: methodisch fortfahren.

Schritt 2: Befund verifizieren (15–30 Minuten)

Nicht jede Scanner-Warnung ist eine echte Schwachstelle. Verifizieren Sie, bevor Sie mehr Zeit investieren.

Für SAST-Befunde (Code-Schwachstellen):

Den markierten Code lesen. Verstehen Sie, was er tut.
Den Datenfluss prüfen. Erreicht Benutzereingabe tatsächlich diesen Code?
Die Eingabequelle verfolgen. Wird sie vorher validiert/bereinigt?
Auf bestehende Schutzmaßnahmen prüfen. Framework-Sicherheitsfunktionen, WAF-Regeln, Eingabevalidierung.

# Example: Semgrep flags this as SQL injection
query = f"SELECT * FROM users WHERE id = {user_id}"

# Questions to answer:
# 1. Where does user_id come from? (request parameter? internal service?)
# 2. Is it validated before this line? (type check? allowlist?)
# 3. Is there a WAF or parameterization layer above?

Für SCA-Befunde (anfällige Abhängigkeiten):

Prüfen Sie, ob Sie die anfällige Funktion nutzen. Die meisten CVEs betreffen spezifische Features.
Die CVE-Beschreibung lesen. Was ist der Angriffsvektor?
Ihren Code prüfen. Rufen Sie die anfällige API auf?
Transitive Exposition prüfen. Nutzt eine andere Abhängigkeit das anfällige Feature?

# Find where a dependency is used
grep -r "require('vulnerable-package')" src/
grep -r "from vulnerable_package import" src/

# Check if specific vulnerable function is called
grep -r "vulnerableFunction(" src/

Für Container/IaC-Befunde:

Prüfen Sie, ob die Konfiguration beabsichtigt ist. Einige „unsichere" Konfigurationen sind für Ihren Anwendungsfall gültig.
Das tatsächliche Risiko verifizieren. Ist die Ressource exponiert? Gibt es eine kompensierende Kontrolle?
Laufzeit vs. Build prüfen. Einige Befunde sind nur in bestimmten Umgebungen relevant.

Verifizierungsergebnis:

Ergebnis	Maßnahme
Bestätigte Schwachstelle	Weiter zu Schritt 3
Falsch-Positiv	Dokumentieren und unterdrücken (Schritt 6)
Unsicher	Zweite Meinung einholen, standardmäßig als real behandeln

Schritt 3: Ausnutzbarkeit bewerten (15–45 Minuten)

Eine bestätigte Schwachstelle ist nicht unbedingt in Ihrem Kontext ausnutzbar. Bewerten Sie das reale Risiko.

Ausnutzbarkeitsfaktoren (basierend auf CVSS v4.0):

Faktor	Zu beantwortende Fragen
Angriffsvektor	Netzwerkzugriff? Nur lokal? Physischer Zugriff erforderlich?
Angriffskomplexität	Einfach auszunutzen? Erfordert spezifische Bedingungen?
Erforderliche Berechtigungen	Anonym? Authentifizierter Benutzer? Admin?
Benutzerinteraktion	Keine? Opfer muss auf Link klicken?

Kontextspezifische Bewertung:

Faktor	Zu beantwortende Fragen
Exposition	Ist dieser Code/diese Komponente aus dem Internet erreichbar?
Datensensibilität	Auf welche Daten könnte bei Ausnutzung zugegriffen werden?
Bestehende Kontrollen	WAF, Rate-Limiting, Authentifizierung, Netzwerksegmentierung?
Exploit-Verfügbarkeit	Öffentlicher Exploit? Metasploit-Modul? Nur theoretisch?

Schnelle Ausnutzbarkeitsprüfung:

# Check if a public exploit exists
searchsploit CVE-2024-XXXXX

# Check ExploitDB
curl -s "https://www.exploit-db.com/search?cve=2024-XXXXX"

# Check CISA KEV (Known Exploited Vulnerabilities)
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json | \
  jq '.vulnerabilities[] | select(.cveID=="CVE-2024-XXXXX")'

Ausnutzbarkeits-Matrix:

Exploit verfügbar	Extern erreichbar	Sensible Daten gefährdet	Priorität
Ja	Ja	Ja	KRITISCH — Sofortmaßnahme
Ja	Ja	Nein	HOCH — In diesem Sprint beheben
Ja	Nein	Ja	HOCH — In diesem Sprint beheben
Nein	Ja	Ja	MITTEL — Bald beheben
Nein	Nein	Nein	NIEDRIG — Verfolgen, bei Gelegenheit beheben

Schritt 4: Geschäftliche Auswirkungen bestimmen (10–20 Minuten)

Technischer Schweregrad ≠ geschäftliche Auswirkungen. Ein kritischer CVE in einem Entwicklungstool ist weniger bedeutsam als ein mittleres Problem in Ihrem Zahlungssystem.

Fragen zur Auswirkungsbewertung:

Kategorie	Fragen
Vertraulichkeit	Welche Daten könnten durchsickern? PII? Zugangsdaten? Geschäftsgeheimnisse?
Integrität	Könnten Daten verändert werden? Finanzunterlagen? Benutzerberechtigungen?
Verfügbarkeit	Könnte das System zum Absturz gebracht werden? Wie lange?
Compliance	Verstößt dies gegen Vorschriften? DSGVO, PCI DSS, HIPAA?
Reputation	Würde dies Schlagzeilen machen, wenn es ausgenutzt wird?

Priorität berechnen (SSVC-inspiriert):

Jeden Faktor bewerten und das Ergebnis summieren:

Ausnutzung — Aktiv in freier Wildbahn: +2 / PoC existiert: +1 / Keine bekannt: +0
Exposition — Internetfähig ohne Authentifizierung: +2 / Authentifiziert: +1 / Nur intern: +0
Auswirkung — Vollständige Systemkompromittierung: +2 / Datenzugriff oder -änderung: +1 / Begrenzt: +0

Gesamt: 5–6 → Sofort | 3–4 → Dringend | 1–2 → Geplant

Schritt 5: Produktionsexposition prüfen (paralleler Track)

Wenn der anfällige Code/die anfällige Komponente in der Produktion ist, müssen Sie das sofort wissen.

Zu beantwortende Fragen:

Ist die Schwachstelle in der Produktion?
- Eingesetzte Versionen prüfen
- Release-Geschichte prüfen
- Wann wurde sie eingeführt?
Wurde sie ausgenutzt?
- Anwendungslogs auf verdächtige Muster prüfen
- WAF-Logs auf Angriffssignaturen prüfen
- Zugriffslogs auf Anomalien prüfen
- SIEM-Warnungen prüfen
Was ist der Einflussbereich?
- Welche Umgebungen sind betroffen?
- Welche Kunden/Benutzer?
- Wie lange war es exponiert?

Checkliste für Produktionsuntersuchungen:

# Check if vulnerable version is deployed
kubectl get deployments -o jsonpath='{.items[*].spec.template.spec.containers[*].image}'

# Search logs for exploit patterns (example for SQL injection)
grep -E "(UNION|SELECT.*FROM|DROP TABLE|--|;)" /var/log/app/*.log

# Check for unusual error rates
grep "500\|502\|503" /var/log/nginx/access.log | wc -l

# Check authentication failures spike
grep "authentication failed" /var/log/app/*.log | \
  awk '{print $1}' | sort | uniq -c | sort -rn | head -20

Wenn Ausnutzung vermutet wird:

Sofort eindämmen — Betroffenes Feature deaktivieren, IPs blockieren, Zugangsdaten rotieren
Beweise sichern — Logs nicht löschen, Snapshots erstellen
Incident Response einleiten — Dies ist jetzt ein Sicherheitsvorfall, nicht nur eine Schwachstelle
Stakeholder benachrichtigen — Führungsebene, Rechtsabteilung, Compliance nach Bedarf

Schritt 6: Entscheiden und handeln

Wählen Sie basierend auf Ihrer Bewertung die geeignete Reaktion:

Reaktionsoptionen:

Priorität	Reaktion	Zeitrahmen	Entscheidung durch
Sofort	Merge blockieren, Hotfix für Produktion	Stunden	Security Champion + Lead
Dringend	Im aktuellen Sprint beheben, Produktions-Patch geplant	Tage	Security Champion
Geplant	Zum Backlog hinzufügen, in normaler Entwicklung beheben	Wochen	Security Champion
Risiko akzeptieren	Entscheidung dokumentieren, Überwachung implementieren	N/A	Security Champion + Management
Falsch-Positiv	Mit Dokumentation unterdrücken	Sofort	Security Champion

Für bestätigte Schwachstellen — Fix-Workflow:

┌─────────────┐     ┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   Ticket    │────►│    Fix      │────►│   Fix       │────►│ Deployment  │
│  erstellen  │     │ umsetzen    │     │ verifizieren│     │  + schließen│
└─────────────┘     └─────────────┘     └─────────────┘     └─────────────┘
       │                   │                   │                   │
       ▼                   ▼                   ▼                   ▼
  - CVE/CWE-ID        - Codeänderung       - Scanner          - In Prod deployen
  - Schweregrad        - Abhängigkeits-      ausführen          - Auf Probleme
  - Auswirkungs-         update            - Manuell            überwachen
    analyse           - Konfig-Fix           verifizieren      - SBOM aktualisieren
  - Betroffene                             - Regression-       - Ticket schließen
    Versionen                                tests

Für Falsch-Positive — Unterdrückungs-Workflow:

# 1. Document WHY it's a false positive
# semgrep: .semgrepignore or inline
def process_data(data):
    # nosemgrep: sql-injection
    # Reason: 'data' is validated UUID from internal service, not user input
    query = f"SELECT * FROM cache WHERE id = '{data}'"

# 2. Add to team knowledge base
# Create entry in security wiki explaining this pattern

# 3. Consider improving the rule
# Report to Semgrep community if rule has high false positive rate

Für akzeptierte Risiken:

## Risk Acceptance Record

**Vulnerability:** CVE-2024-XXXXX in package-name v1.2.3
**Date:** 2024-12-28
**Decided by:** [Name], approved by [Manager]

### Risk assessment
- Severity: HIGH (CVSS 8.1)
- Exploitability in our context: LOW
- Reason: Vulnerable function not used in our codebase

### Mitigating controls
- [ ] WAF rule blocks attack pattern
- [ ] Input validation in place
- [ ] Monitoring for exploitation attempts

### Review schedule
- Next review: 2025-03-28
- Trigger for re-review: New exploit published, or mitigating control removed

### Acceptance signature
Accepted by: _____________ Date: _____________

Schritt 7: Wiederholung verhindern

Nach der Behebung das gleiche Problem daran hindern, erneut aufzutauchen.

Maßnahmen:

Spezifische Scanner-Regeln hinzufügen — Bei benutzerdefiniertem Code-Muster eine Semgrep-Regel hinzufügen
Abhängigkeitsrichtlinie aktualisieren — Anfällige Versionen in der Lockfile blockieren
Zum Sicherheitstraining hinzufügen — Als Fallstudie mit dem Team teilen
Erkennung verbessern — Wenn spät erkannt, Scanning-Abdeckung verbessern

Beispiel: Zukünftige Verwendung des anfälligen Musters verhindern:

# .semgrep.yml - custom rule to prevent pattern
rules:
  - id: no-string-format-sql
    patterns:
      - pattern: f"SELECT ... {$VAR} ..."
    message: "Use parameterized queries, not string formatting"
    languages: [python]
    severity: ERROR

Reaktionszeitrichtlinien

Priorität	Erste Reaktion	Fix implementiert	Produktion gepatcht
Sofort (Aktiver Exploit, kritische Daten)	1 Stunde	4 Stunden	8 Stunden
Dringend (Öffentlicher Exploit, externe Exposition)	4 Stunden	24 Stunden	48 Stunden
Geplant (Kein Exploit, begrenzte Exposition)	24 Stunden	1–2 Wochen	Nächstes Release
Niedrig (Theoretisch, keine Exposition)	1 Woche	1–2 Monate	Bei Gelegenheit

Eskalationsmatrix

Situation	Eskalieren an	Methode
Aktive Ausnutzung im Gange	CTO, Incident Response, Rechtsabteilung	Telefonanruf
Kritische Schwachstelle in der Produktion	Engineering Lead, CTO	Slack + Anruf
Unsicher über Schweregrad/Ausnutzbarkeit	Senior Engineer, externer Berater	Slack
Risikoakzeptanz erforderlich	Engineering Manager	E-Mail mit Dokumentation
Hersteller-Patch erforderlich	Hersteller-Sicherheitskontakt	E-Mail, Support-Ticket

Dokumentationsvorlage

Diese Vorlage für jeden wesentlichen Befund verwenden:

## Security Finding Report

### Summary
- **Finding ID:** [JIRA/ticket number]
- **Scanner:** [Semgrep/Snyk/Trivy/etc]
- **Rule/CVE:** [Rule ID or CVE number]
- **Severity (tool):** [Critical/High/Medium/Low]
- **Severity (assessed):** [After your analysis]
- **Status:** [New/Investigating/Confirmed/Fixed/False Positive/Accepted]

### Technical details
- **Location:** [file:line or package:version]
- **Introduced:** [commit/date/PR]
- **In production:** [Yes/No, since when]

### Analysis
- **Verification result:** [Confirmed/False positive]
- **Exploitability:** [High/Medium/Low/None]
- **Attack vector:** [Description]
- **Existing controls:** [WAF/validation/etc]

### Impact
- **Confidentiality:** [None/Low/High]
- **Integrity:** [None/Low/High]
- **Availability:** [None/Low/High]
- **Business impact:** [Description]

### Resolution
- **Action taken:** [Fix/Accept/Suppress]
- **Fix PR:** [Link]
- **Deployed:** [Date]
- **Verified:** [How]

### Prevention
- **New scanner rule:** [Yes/No, link]
- **Training update:** [Yes/No]
- **Process change:** [Description]

Häufige Fehler

Alles blockieren

# BAD: Every finding blocks the build
- run: npm audit  # Fails on ANY vulnerability

Das führt zu ignorierten Pipelines, deaktivierten Prüfungen oder einer „später beheben"-Kultur.

# GOOD: Block on critical, warn on medium
- run: npm audit --audit-level=critical

Nichts blockieren

# BAD: Scan runs but never fails
- run: semgrep --config auto || true

Sicherheitsbefunde häufen sich an, niemand schaut sich Berichte an.

# GOOD: Block on high severity
- run: semgrep --config auto --error --severity=ERROR

DAST auf Produktion ausführen

# BAD: Attacking your own production
- run: zap-full-scan.py -t https://production.example.com

Vollständige DAST-Scans können Dinge kaputt machen. Verwenden Sie Staging.

# GOOD: Attack staging only
- run: zap-full-scan.py -t $STAGING_URL

Tool-Output ignorieren

Scanning einrichten ohne Prozess zur Handhabung der Befunde. Tools finden Probleme → niemand triagiert → Warnungen werden ignoriert → Tools werden deaktiviert.

Lösung: Verantwortung zuweisen. Jemand überprüft Befunde wöchentlich. Kritische Probleme erzeugen Tickets. Mittlere Probleme werden monatlich überprüft.

Zu viele Tools

Fünf verschiedene SAST-Tools, drei SCA-Scanner betreiben und hoffen, dass mehr besser ist. Ergebnis: Rauschen, doppelte Befunde, langsame Pipelines.

Lösung: Mit einem Tool pro Kategorie beginnen. Weitere nur hinzufügen, wenn Sie spezifische Lücken haben.

Nur auf main scannen

# BAD: Issues found after merge
only:
  - main

Probleme in PRs finden, nicht nachdem sie gemergt wurden.

# GOOD: Scan on every PR
on:
  push:
    branches: [main]
  pull_request:  # This is key

Reale Vorfälle

Codecov Supply-Chain-Angriff (2021). Angreifer kompromittierten Codecovs Bash-Uploader-Skript, das in Tausenden von CI/CD-Pipelines verwendet wurde. Über zwei Monate lang exfiltierte das modifizierte Skript Umgebungsvariablen — einschließlich CI-Geheimnisse, API-Token und Zugangsdaten — aus jeder Pipeline, die es nutzte. Unternehmen wie Twilio, HashiCorp und Confluent waren betroffen.

ua-parser-js-Hijack (2021). Ein beliebtes npm-Paket (8 Millionen wöchentliche Downloads) wurde entführt, als ein Angreifer das npm-Konto des Maintainers kompromittierte. Schädliche Versionen schürften Kryptowährungen und stahlen Passwörter. Projekte mit SCA-Scanning erkannten das Problem innerhalb von Stunden; diejenigen ohne lieferten kompromittierte Builds aus.

Log4Shell (2021). CVE-2021-44228 in Log4j betraf praktisch jede Java-Anwendung. Organisationen mit SCA-Scanning kannten ihre Exposition innerhalb von Stunden. Diejenigen ohne verbrachten Tage damit herauszufinden, welche Anwendungen Log4j verwendeten und in welchen Versionen. Der Unterschied zwischen „wir sind gepatcht" und „wir untersuchen noch" war automatisches Abhängigkeits-Scanning.

Diese Vorfälle teilen ein Muster: Organisationen mit automatischem Scanning erkannten Probleme schneller und reagierten besser. Diejenigen ohne mussten improvisieren.

Workshop: Ihre Pipeline absichern

Reservieren Sie 2–3 Stunden für diese Übung.

Teil 1: SAST-Scanning hinzufügen (30 Minuten)

Für GitHub:

.github/workflows/security.yml erstellen:

name: Security Scan

on:
  push:
    branches: [main]
  pull_request:

jobs:
  semgrep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: semgrep/semgrep-action@v1
        with:
          config: p/security-audit p/secrets

Committen und pushen
Einen Test-PR erstellen und prüfen, ob der Scan läuft
Alle Befunde überprüfen

Für GitLab:

Zu .gitlab-ci.yml hinzufügen:

semgrep:
  stage: test
  image: semgrep/semgrep
  script:
    - semgrep ci --config auto

Committen und pushen
Prüfen, ob der Scan in der Pipeline läuft
Befunde im Pipeline-Output überprüfen

Lieferergebnis: Funktionierender SAST-Scan in CI

Teil 2: Dependabot oder Snyk konfigurieren (30 Minuten)

Option A — Dependabot (GitHub):

.github/dependabot.yml erstellen:

version: 2
updates:
  - package-ecosystem: "npm"  # or pip, bundler, etc.
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 5

Zu Settings → Security → Dependabot-Warnungen und Sicherheitsupdates aktivieren
Vorhandene Warnungen im Security-Tab überprüfen

Option B — Snyk:

Bei snyk.io anmelden (kostenloser Tarif)
CLI installieren: npm install -g snyk
Authentifizieren: snyk auth
Ersten Scan ausführen: snyk test
Zu CI hinzufügen (siehe obige Beispiele)

Lieferergebnis: Abhängigkeits-Scanning aktiviert mit überprüften ersten Befunden

Teil 3: Container-Scanning hinzufügen (30 Minuten)

Wenn Sie Docker verwenden:

Trivy zu Ihrem Workflow hinzufügen:

container-scan:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - run: docker build -t myapp:test .
    - uses: aquasecurity/trivy-action@master
      with:
        image-ref: myapp:test
        severity: 'CRITICAL,HIGH'

Ihr Image lokal bauen und scannen:

docker build -t myapp:test .
trivy image myapp:test

Befunde überprüfen und kritische Probleme beheben

Lieferergebnis: Container-Scanning in CI mit dokumentierten Basis-Image-Schwachstellen

Teil 4: DAST-Baseline einrichten (30 Minuten)

Ihre App in einer Staging-Umgebung deployen (oder lokal ausführen)
ZAP-Baseline-Scan ausführen:

docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py \
  -t http://your-staging-url

Den Output überprüfen — prüfen auf:
- Fehlende Sicherheitsheader
- Cookie-Sicherheitsprobleme
- Informationsoffenlegung
Baseline-Scan zur CI-Pipeline hinzufügen (nur Staging)

Lieferergebnis: DAST-Baseline-Scan für Staging konfiguriert

Teil 5: IaC-Scanning hinzufügen (20 Minuten)

Wenn Sie Terraform, CloudFormation oder Kubernetes verwenden:

Checkov installieren:

pip install checkov

Ihren Infrastruktur-Code scannen:

checkov -d terraform/  # or cloudformation/, k8s/

Zu CI hinzufügen:

# GitHub Actions
- name: Checkov
  uses: bridgecrewio/checkov-action@master
  with:
    directory: terraform/
    soft_fail: false

Befunde überprüfen und kritische Fehlkonfigurationen beheben

Lieferergebnis: IaC-Scanning in CI mit dokumentierten wesentlichen Problemen

Teil 6: SBOM-Generierung einrichten (20 Minuten)

Syft installieren:

brew install syft
# or
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

SBOM für Ihr Projekt generieren:

syft dir:. -o cyclonedx-json > sbom.json

SBOM auf Schwachstellen scannen:

brew install grype
grype sbom:sbom.json

Zu CI hinzufügen:

# GitHub Actions
- name: Generate SBOM
  uses: anchore/sbom-action@v0
  with:
    path: .
    format: cyclonedx-json
    output-file: sbom.json

- name: Scan SBOM
  uses: anchore/scan-action@v3
  with:
    sbom: sbom.json
    fail-build: true
    severity-cutoff: high

Lizenzinformationen in der SBOM überprüfen

Lieferergebnis: SBOM-Generierung und -Scanning in CI

Teil 7: Triage-Prozess erstellen (30 Minuten)

Ein einfaches Dokument erstellen:

# Security Findings Triage Process

## Severity levels
- **Critical/High**: Block merge, fix immediately
- **Medium**: Fix in current sprint  
- **Low**: Add to backlog, fix when convenient

## Who triages
- [Name] reviews findings weekly
- Critical findings notify #security-alerts channel

## False positives
- Document in `.semgrep.yml` or tool config
- Require approval from [Name] to suppress

## Metrics tracked
- Open findings by severity
- Time from finding to fix
- Findings per deployment

Lieferergebnis: Dokumentierter Triage-Prozess

Ergebnisse dieses Kapitels

Am Ende dieses Kapitels sollten Sie haben:

SAST-Scanner konfiguriert — Semgrep oder CodeQL läuft bei jedem PR
Dependabot/Snyk aktiviert — Abhängigkeits-Scanning mit konfigurierten Warnungen
Container-Scanning — Trivy scannt Docker-Images (falls zutreffend)
IaC-Scanning — Checkov oder tfsec scannt Infrastruktur-Code (falls zutreffend)
SBOM-Generierung — Syft generiert SBOMs mit jedem Build
DAST-Baseline — ZAP oder Nuclei läuft bei Staging-Deployments
Sicherheits-Workflow-Datei — Vollständige CI/CD-Sicherheits-Pipeline-Konfiguration
Befunds-Reaktions-Playbook — Schrittweiser Prozess für den Umgang mit Scanner-Befunden
Eskalationsmatrix — Wen man für verschiedene Schweregrade kontaktiert
Triage-Prozess-Dokument — Wie Befunde priorisiert und zugewiesen werden

Gespräch mit der Führungsebene

Wenn jemand fragt, warum Sie Sicherheits-Scanning zur CI/CD hinzufügen:

„Ich füge unserer Deployment-Pipeline automatische Sicherheitsprüfungen hinzu. Diese Tools scannen unseren Code auf Schwachstellen, prüfen unsere Abhängigkeiten auf bekannte Sicherheitsprobleme und testen die laufende Anwendung auf häufige Angriffsvektoren. Das fängt Probleme ab, bevor sie die Produktion erreichen — SQL-Injection, anfällige Bibliotheken, fehlkonfigurierte Server. Die Tools sind kostenlos und fügen unserer Pipeline vielleicht 2–3 Minuten hinzu. Die Alternative ist, diese Probleme nach einem Sicherheitsvorfall zu finden, was sowohl finanziell als auch reputationsmäßig deutlich teurer ist."

Kurze Version: „Ich füge automatische Sicherheitsprüfungen hinzu, damit wir Schwachstellen vor Angreifern finden."

Selbstprüfung

Statische Analyse (SAST)

Semgrep oder CodeQL läuft bei jedem PR
Hochschwere Befunde blockieren den Merge
Falsch-Positiv-Unterdrückungs-Prozess dokumentiert
Team weiß, wie SAST-Befunde gelesen werden

Abhängigkeits-Scanning (SCA)

Dependabot oder Snyk aktiviert
Warnungen konfiguriert und werden überprüft
Kritische Abhängigkeits-Schwachstellen behoben
Prozess für den Umgang mit nicht behebbaren Schwachstellen

Container-Scanning

Trivy scannt Images vor dem Push zur Registry
Basis-Images aktualisiert, um kritische Schwachstellen zu beheben
Scanning in Build-Pipeline integriert

Infrastructure as Code (IaC)

Checkov oder tfsec läuft bei Infrastrukturänderungen
Kritische Fehlkonfigurationen (öffentliche Buckets, offene Security-Groups) blockiert
Beabsichtigte Ausnahmen mit Skip-Kommentaren dokumentiert

SBOM (Software Bill of Materials)

SBOM für jedes Release generiert
SBOMs auf Schwachstellen gescannt
Lizenzrichtlinie definiert (akzeptable/blockierte Lizenzen)
SBOMs mit Release-Artefakten gespeichert

Dynamisches Testen (DAST)

Baseline-Scan läuft auf Staging
Sicherheitsheader geprüft
Vollständiger Scan geplant (wöchentlich oder vor Release)

Befunds-Reaktionsprozess

Befunds-Reaktions-Playbook dokumentiert
Eskalationsmatrix definiert
Risikoakzeptanz-Prozess etabliert
Befunds-Dokumentationsvorlage in Verwendung

Prozess

Jemand besitzt die Sicherheitsbefunds-Triage
Schweregrad-Schwellenwerte definiert
Metriken werden verfolgt

Mindestens 18 von 28 Punkten abhaken, bevor Sie weitermachen.

Referenz: Sicherheits-Scanning-Tools

Dieser Abschnitt bietet eine umfassende Liste von Sicherheits-Scanning-Tools, geordnet von kostenlos/einfach bis Enterprise/komplex. Mit dem kostenlosen Tarif beginnen — er deckt die meisten Anforderungen ab. Zu kostenpflichtigen Tools wechseln, wenn Sie spezifische Features, besseren Support oder Enterprise-Compliance benötigen.

SAST-Tools (statische Code-Analyse)

Tool	Preis	Sprachen	Am besten für	Link
Semgrep	Kostenlos (Open Source)	30+ Sprachen	Allzweck, benutzerdefinierte Regeln	semgrep.dev
Bandit	Kostenlos (Open Source)	Python	Python-spezifische Sicherheit	GitHub
gosec	Kostenlos (Open Source)	Go	Go-spezifische Sicherheit	GitHub
Brakeman	Kostenlos (Open Source)	Ruby/Rails	Rails-Anwendungen	brakemanscanner.org
ESLint security	Kostenlos (Open Source)	JavaScript	JS/Node.js-Sicherheitsregeln	GitHub
Psalm	Kostenlos (Open Source)	PHP	PHP-Typprüfung + Sicherheit	psalm.dev
PHPStan	Kostenlos (Open Source)	PHP	PHP-statische Analyse	phpstan.org
CodeQL	Kostenlos für öffentliche Repos	10+ Sprachen	Tiefe semantische Analyse	GitHub
SonarQube Community	Kostenlos (selbst gehostet)	30+ Sprachen	Code-Qualität + Sicherheit	sonarsource.com
Semgrep Pro	Kostenpflichtig	30+ Sprachen	Erweiterte Regeln, Team-Features	semgrep.dev
SonarCloud	Kostenlos für öffentlich, kostenpflichtig für privat	30+ Sprachen	Cloud-gehostetes SonarQube	sonarcloud.io
Snyk Code	Kostenloser Tarif, kostenpflichtige Pläne	10+ Sprachen	KI-gestützt, schnell	snyk.io
Checkmarx	Enterprise	30+ Sprachen	Enterprise-Compliance	checkmarx.com
Veracode	Enterprise	30+ Sprachen	Enterprise, Binäranalyse	veracode.com
Fortify	Enterprise	30+ Sprachen	Enterprise, On-Premise	microfocus.com

Empfehlung für kleine Teams: Mit Semgrep beginnen (kostenlos, schnell, gute Regeln). CodeQL hinzufügen, wenn Sie auf GitHub sind. Snyk Code in Betracht ziehen, wenn Sie mehr Abdeckung benötigen.

SCA-Tools (Abhängigkeits-Scanning)

Tool	Preis	Ökosysteme	Am besten für	Link
npm audit	Kostenlos (eingebaut)	npm	Node.js-Projekte	docs.npmjs.com
pip-audit	Kostenlos (Open Source)	pip	Python-Projekte	GitHub
bundle-audit	Kostenlos (Open Source)	bundler	Ruby-Projekte	GitHub
govulncheck	Kostenlos (offiziell)	Go modules	Go-Projekte	pkg.go.dev
composer audit	Kostenlos (eingebaut)	Composer	PHP-Projekte	getcomposer.org
Dependabot	Kostenlos (GitHub eingebaut)	15+ Ökosysteme	GitHub-Repos	GitHub
Trivy	Kostenlos (Open Source)	Alle großen + Container	Universeller Scanner	trivy.dev
Grype	Kostenlos (Open Source)	Alle großen + Container	Schnell, SBOM-Unterstützung	GitHub
OSV-Scanner	Kostenlos (Google)	Alle großen	Googles OSV-Datenbank	GitHub
OWASP Dependency-Check	Kostenlos (Open Source)	Java, .NET, JS, Ruby	OWASP-Projekt	owasp.org
Renovate	Kostenlos (Open Source)	50+ Ökosysteme	Abhängigkeits-Updates	GitHub
Snyk Open Source	Kostenloser Tarif, kostenpflichtige Pläne	Alle großen	Beste Fix-Vorschläge	snyk.io
Mend (WhiteSource)	Kostenpflichtig	Alle großen	Lizenz-Compliance	mend.io
Black Duck	Enterprise	Alle großen	Enterprise-Compliance	synopsys.com
JFrog Xray	Kostenpflichtig	Alle großen	Artefakt-Repository-Integration	jfrog.com

Empfehlung für kleine Teams: Dependabot verwenden (kostenlos auf GitHub) oder Renovate. Trivy für Container hinzufügen. Snyk kostenloser Tarif ist gut, wenn Sie mehr Sichtbarkeit benötigen.

DAST-Tools (dynamisches Testen)

Tool	Preis	Typ	Am besten für	Link
OWASP ZAP	Kostenlos (Open Source)	Vollständiges DAST	Allgemeines Webanwendungs-Testen	zaproxy.org
Nuclei	Kostenlos (Open Source)	Template-basiert	Schnell, spezifische CVE-Prüfungen	nuclei.projectdiscovery.io
Nikto	Kostenlos (Open Source)	Web-Server-Scanner	Server-Fehlkonfigurationen	GitHub
wapiti	Kostenlos (Open Source)	Web-App-Scanner	Black-Box-Testen	GitHub
Arachni	Kostenlos (Open Source)	Vollständiges DAST	Funktionsreicher Scanner	GitHub
sqlmap	Kostenlos (Open Source)	SQL-Injection	SQL-Injection-Testen	sqlmap.org
StackHawk	Kostenloser Tarif, kostenpflichtige Pläne	API-fokussiert	Moderne APIs, CI/CD-nativ	stackhawk.com
Burp Suite Community	Kostenlos	Manuelles Testen	Manuelles Sicherheitstesten	portswigger.net
Burp Suite Pro	449 $/Jahr	Vollständiges DAST	Professionelles Penetration-Testing	portswigger.net
Acunetix	Kostenpflichtig	Vollständiges DAST	Automatisiertes Web-Scanning	acunetix.com
Invicti (Netsparker)	Enterprise	Vollständiges DAST	Enterprise-Webanwendungen	invicti.com
Qualys WAS	Enterprise	Vollständiges DAST	Enterprise, Compliance	qualys.com

Empfehlung für kleine Teams: Mit ZAP-Baseline-Scans in CI beginnen. Nuclei für CVE-spezifische Prüfungen hinzufügen. Burp Suite Community für manuelle Tests.

Container- und Image-Scanning

Tool	Am besten für	Lizenz	Link
Trivy	All-in-one-Scanning, einfache Einrichtung	Apache 2.0	trivy.dev
Grype	Schnelles CVE-Scanning, funktioniert mit Syft	Apache 2.0	github.com/anchore/grype
Clair	Registry-Integration, Enterprise-Skalierung	Apache 2.0	github.com/quay/clair
Docker Scout	Docker Hub-Integration, nativ	Kostenloser Tarif verfügbar	docker.com/products/docker-scout
Snyk Container	Entwicklerfreundlich, Behebungshinweise	Kostenloser Tarif verfügbar	snyk.io/product/container-security

Für kleine Teams ist Trivy die klare Wahl. Es ist kostenlos, schnell und erkennt die meisten Schwachstellen. Wenn Sie Docker Hub verwenden, ist Docker Scout praktisch, da es in das Docker CLI integriert ist (docker scout cves myimage:tag).

Infrastructure as Code (IaC)-Scanning

Tool	Preis	Unterstütztes IaC	Am besten für	Link
Checkov	Kostenlos (Open Source)	Terraform, CloudFormation, K8s, ARM	Umfassendes IaC-Scanning	checkov.io
tfsec	Kostenlos (Open Source)	Terraform	Terraform-fokussiert	GitHub
Terrascan	Kostenlos (Open Source)	Terraform, K8s, Helm, Dockerfile	Policy as Code	GitHub
KICS	Kostenlos (Open Source)	15+ IaC-Plattformen	Breite Abdeckung	kics.io
cfn-lint	Kostenlos (AWS offiziell)	CloudFormation	AWS CloudFormation	GitHub
cfn_nag	Kostenlos (Open Source)	CloudFormation	CloudFormation-Sicherheit	GitHub
kubesec	Kostenlos (Open Source)	Kubernetes	K8s-Manifest-Sicherheit	kubesec.io
Trivy	Kostenlos (Open Source)	Terraform, K8s, Dockerfile	Universal (IaC + Container)	trivy.dev
Snyk IaC	Kostenloser Tarif, kostenpflichtige Pläne	Terraform, K8s, CloudFormation	Behebungshinweise	snyk.io
Bridgecrew	Kostenpflichtig (jetzt Prisma Cloud)	Alle großen	Enterprise, Checkov-Backend	paloaltonetworks.com

Empfehlung für kleine Teams: Mit Checkov beginnen — es ist umfassend und kostenlos. tfsec ist gut, wenn Sie nur Terraform verwenden.

IaC-Scanning in CI:

# GitHub Actions - Checkov
- name: Checkov
  uses: bridgecrewio/checkov-action@master
  with:
    directory: terraform/
    framework: terraform
    soft_fail: false

# GitLab CI - tfsec
tfsec:
  stage: test
  image: aquasec/tfsec:latest
  script:
    - tfsec terraform/ --severity-override=HIGH,CRITICAL

SBOM-Generierung und -Analyse

Tool	Preis	Typ	Am besten für	Link
Syft	Kostenlos (Open Source)	SBOM-Generierung	Universeller Generator	GitHub
cdxgen	Kostenlos (Open Source)	SBOM-Generierung	CycloneDX-Format	GitHub
Trivy	Kostenlos (Open Source)	SBOM + Scanning	All-in-one	trivy.dev
Grype	Kostenlos (Open Source)	SBOM-Schwachstellen-Scan	Schnelles Scanning	GitHub
OSV-Scanner	Kostenlos (Google)	SBOM-Schwachstellen-Scan	Googles Datenbank	GitHub
OWASP Dependency-Track	Kostenlos (selbst gehostet)	SBOM-Plattform	Vollständige Verwaltung	dependencytrack.org
FOSSA	Kostenloser Tarif, kostenpflichtige Pläne	Lizenz-Compliance	Tiefe Lizenzanalyse	fossa.com
Anchore Enterprise	Kostenpflichtig	SBOM-Plattform	Enterprise-Richtlinien	anchore.com
Sonatype Nexus	Kostenpflichtig	SBOM + Compliance	Repository-Integration	sonatype.com

Empfehlung für kleine Teams: Syft zur SBOM-Generierung verwenden, Grype zum Scannen auf Schwachstellen. OWASP Dependency-Track hinzufügen, wenn Sie zentralisiertes Tracking benötigen.

Secret-Scanning

Tool	Preis	Funktionen	Am besten für	Link
gitleaks	Kostenlos (Open Source)	Git-Historie, Pre-Commit	Schnell, konfigurierbar	gitleaks.io
truffleHog	Kostenlos (Open Source)	Git, S3, GCS, verifizierte Geheimnisse	Tiefes Scanning	GitHub
git-secrets	Kostenlos (AWS)	Pre-Commit-Hooks	AWS-Zugangsdaten	GitHub
detect-secrets	Kostenlos (Open Source)	Baseline-Ansatz	Yelps Tool	GitHub
GitHub Secret Scanning	Kostenlos (GitHub eingebaut)	Push-Schutz	GitHub-Repos	docs.github.com
GitLab Secret Detection	Kostenlos (GitLab eingebaut)	Pipeline-Integration	GitLab-Repos	docs.gitlab.com
GitGuardian	Kostenlos für Einzelpersonen	Echtzeit-Überwachung	Entwicklerfreundlich	gitguardian.com
Snyk	Kostenloser Tarif	Teil von Snyk Code	Einheitliche Plattform	snyk.io

Empfehlung für kleine Teams: Eingebautes GitHub/GitLab-Scanning aktivieren. gitleaks als Pre-Commit-Hook hinzufügen. Siehe das Kapitel zur Secrets-Verwaltung für detaillierte Einrichtung.

API-Sicherheitstesten

Tool	Preis	Typ	Am besten für	Link
OWASP ZAP	Kostenlos (Open Source)	OpenAPI/Swagger-Scanning	REST APIs	zaproxy.org
Nuclei	Kostenlos (Open Source)	Template-basiert	API-CVE-Prüfungen	nuclei.projectdiscovery.io
Postman	Kostenloser Tarif	API-Test-Plattform	Manuell + automatisiert	postman.com
StackHawk	Kostenloser Tarif, kostenpflichtige Pläne	API-first DAST	Moderne APIs, GraphQL	stackhawk.com
Akto	Kostenloser Tarif	API-Erkennung + Testen	API-Inventar	akto.io
42Crunch	Kostenpflichtig	OpenAPI-Sicherheit	API-Sicherheitsplattform	42crunch.com
Salt Security	Enterprise	Runtime-API-Schutz	API-Bedrohungserkennung	salt.security
Noname Security	Enterprise	Vollständige API-Sicherheit	Enterprise-APIs	nonamesecurity.com

Empfehlung für kleine Teams: ZAP mit OpenAPI-Import verwenden. StackHawk hinzufügen, wenn Sie bessere API-Unterstützung benötigen.

All-in-one-Plattformen

Diese Plattformen kombinieren mehrere Scanning-Typen in einer Lösung:

Plattform	Enthält	Preis	Am besten für	Link
GitHub Advanced Security	SAST (CodeQL), SCA, Secrets	49 $/Benutzer/Monat	GitHub-native Teams	github.com
GitLab Ultimate	SAST, SCA, DAST, Secrets, Container	99 $/Benutzer/Monat	GitLab-native Teams	gitlab.com
Snyk	SAST, SCA, Container, IaC	Kostenloser Tarif, kostenpflichtige Pläne	Entwicklerfreundlich	snyk.io
Sonar	SAST, Code-Qualität	Kostenloser Tarif (Cloud), kostenpflichtig	Code-Qualitätsfokus	sonarsource.com
Veracode	SAST, SCA, DAST	Enterprise	Große Unternehmen	veracode.com
Checkmarx One	SAST, SCA, DAST, IaC	Enterprise	Enterprise-Compliance	checkmarx.com
Synopsys	SAST, SCA, DAST	Enterprise	Enterprise, Legacy	synopsys.com

Empfehlung für kleine Teams: Wenn Sie auf GitHub sind, zuerst kostenlose Features aktivieren, dann GitHub Advanced Security in Betracht ziehen. Snyks kostenloser Tarif ist großzügig und deckt die meisten Anforderungen ab. Enterprise-Plattformen vermeiden, bis Sie tatsächlich Enterprise-Features brauchen.

Schnellstart: minimale lebensfähige Sicherheits-Pipeline

Wenn Sie gerade anfangen, hier ist die minimale Einrichtung mit ausschließlich kostenlosen Tools:

Kategorie	Tool	Warum
SAST	Semgrep	Schnell, gute Regeln, kostenlos
SCA	Dependabot oder Trivy	Eingebaut oder universell
Secrets	gitleaks	Pre-Commit + CI
Container	Trivy	Scannt alles
IaC	Checkov	Umfassend, kostenlos
SBOM	Syft + Grype	Generieren + scannen
DAST	ZAP Baseline	Standard, zuverlässig

Gesamtkosten: 0 €. Einrichtungszeit: 3–4 Stunden.

Weiterführende Ressourcen

Semgrep-Dokumentation
Snyk Learn — Kostenloses Sicherheitstraining
OWASP DevSecOps Guideline
GitHub-Sicherheitsfunktionen
GitLab-Sicherheits-Scanning
Trivy-Dokumentation
Checkov-Dokumentation
OWASP Testing Guide

Was kommt als Nächstes

Sie haben Sicherheits-Scanning in Ihre CI/CD-Pipeline integriert. Nächstes Kapitel: Container- und Cloud-Infrastruktur-Sicherheit — Docker-Images absichern, Cloud-Konfigurationen sichern und Infrastructure as Code.

Warum das für kleine Unternehmen wichtig ist​

Wonach Angreifer suchen​

Arten von Sicherheits-Scanning​

SAST: statische Code-Analyse​

Was SAST erkennt​

Tool: Semgrep​

Tool: CodeQL (nur GitHub)​

Sprachspezifische Tools​

Umgang mit SAST-Befunden​

SCA: Abhängigkeits-Scanning​

Was SCA erkennt​

Tool: Dependabot (GitHub)​

Tool: Snyk​

Tool: Trivy​

Native Paketmanager-Audits​

Umgang mit Abhängigkeits-Schwachstellen​

SBOM: Software Bill of Materials​

Warum SBOM wichtig ist​

SBOM-Formate​

SBOMs generieren​

SBOMs auf Schwachstellen analysieren​

SBOMs auf Lizenz-Compliance analysieren​

SBOM im CI/CD-Workflow​

Best Practices für SBOMs​

DAST: dynamisches Testen​

Was DAST erkennt​

Tool: OWASP ZAP​

Tool: Nuclei​

Wann DAST ausführen​

IaC-Scanning: Infrastructure as Code​

Was IaC-Scanning erkennt​

Tool: Checkov​

Tool: tfsec (Terraform-spezifisch)​

Umgang mit IaC-Befunden​

Alles zusammensetzen​

GitHub Actions-Beispiel​

GitLab CI-Beispiel​

Wenn Scanner Probleme finden: Playbook für Security Champions​

Schritt 1: Erste Triage (5–10 Minuten)​

Schritt 2: Befund verifizieren (15–30 Minuten)​

Schritt 3: Ausnutzbarkeit bewerten (15–45 Minuten)​

Schritt 4: Geschäftliche Auswirkungen bestimmen (10–20 Minuten)​

Schritt 5: Produktionsexposition prüfen (paralleler Track)​

Schritt 6: Entscheiden und handeln​

Schritt 7: Wiederholung verhindern​

Reaktionszeitrichtlinien​

Eskalationsmatrix​

Dokumentationsvorlage​

Häufige Fehler​

Alles blockieren​

Nichts blockieren​

DAST auf Produktion ausführen​

Tool-Output ignorieren​

Zu viele Tools​

Nur auf main scannen​

Reale Vorfälle​

Workshop: Ihre Pipeline absichern​

Teil 1: SAST-Scanning hinzufügen (30 Minuten)​

Teil 2: Dependabot oder Snyk konfigurieren (30 Minuten)​

Teil 3: Container-Scanning hinzufügen (30 Minuten)​

Teil 4: DAST-Baseline einrichten (30 Minuten)​

Teil 5: IaC-Scanning hinzufügen (20 Minuten)​

Teil 6: SBOM-Generierung einrichten (20 Minuten)​

Teil 7: Triage-Prozess erstellen (30 Minuten)​

Ergebnisse dieses Kapitels​

Gespräch mit der Führungsebene​

Selbstprüfung​

Statische Analyse (SAST)​

Abhängigkeits-Scanning (SCA)​

Container-Scanning​

Infrastructure as Code (IaC)​

SBOM (Software Bill of Materials)​

Dynamisches Testen (DAST)​

Befunds-Reaktionsprozess​

Prozess​

Referenz: Sicherheits-Scanning-Tools​

SAST-Tools (statische Code-Analyse)​

SCA-Tools (Abhängigkeits-Scanning)​

DAST-Tools (dynamisches Testen)​

Container- und Image-Scanning​

Warum das für kleine Unternehmen wichtig ist

Wonach Angreifer suchen

Arten von Sicherheits-Scanning

SAST: statische Code-Analyse

Was SAST erkennt

Tool: Semgrep

Tool: CodeQL (nur GitHub)

Sprachspezifische Tools

Umgang mit SAST-Befunden

SCA: Abhängigkeits-Scanning

Was SCA erkennt

Tool: Dependabot (GitHub)

Tool: Snyk

Tool: Trivy

Native Paketmanager-Audits

Umgang mit Abhängigkeits-Schwachstellen

SBOM: Software Bill of Materials

Warum SBOM wichtig ist

SBOM-Formate

SBOMs generieren

SBOMs auf Schwachstellen analysieren

SBOMs auf Lizenz-Compliance analysieren

SBOM im CI/CD-Workflow

Best Practices für SBOMs

DAST: dynamisches Testen

Was DAST erkennt

Tool: OWASP ZAP

Tool: Nuclei

Wann DAST ausführen

IaC-Scanning: Infrastructure as Code

Was IaC-Scanning erkennt

Tool: Checkov

Tool: tfsec (Terraform-spezifisch)

Umgang mit IaC-Befunden

Alles zusammensetzen

GitHub Actions-Beispiel

GitLab CI-Beispiel

Wenn Scanner Probleme finden: Playbook für Security Champions

Schritt 1: Erste Triage (5–10 Minuten)

Schritt 2: Befund verifizieren (15–30 Minuten)

Schritt 3: Ausnutzbarkeit bewerten (15–45 Minuten)

Schritt 4: Geschäftliche Auswirkungen bestimmen (10–20 Minuten)

Schritt 5: Produktionsexposition prüfen (paralleler Track)

Schritt 6: Entscheiden und handeln

Schritt 7: Wiederholung verhindern

Reaktionszeitrichtlinien

Eskalationsmatrix

Dokumentationsvorlage

Häufige Fehler

Alles blockieren

Nichts blockieren

DAST auf Produktion ausführen

Tool-Output ignorieren

Zu viele Tools

Nur auf main scannen

Reale Vorfälle

Workshop: Ihre Pipeline absichern

Teil 1: SAST-Scanning hinzufügen (30 Minuten)

Teil 2: Dependabot oder Snyk konfigurieren (30 Minuten)

Teil 3: Container-Scanning hinzufügen (30 Minuten)

Teil 4: DAST-Baseline einrichten (30 Minuten)

Teil 5: IaC-Scanning hinzufügen (20 Minuten)

Teil 6: SBOM-Generierung einrichten (20 Minuten)

Teil 7: Triage-Prozess erstellen (30 Minuten)

Ergebnisse dieses Kapitels

Gespräch mit der Führungsebene

Selbstprüfung

Statische Analyse (SAST)

Abhängigkeits-Scanning (SCA)

Container-Scanning

Infrastructure as Code (IaC)

SBOM (Software Bill of Materials)

Dynamisches Testen (DAST)

Befunds-Reaktionsprozess

Prozess

Referenz: Sicherheits-Scanning-Tools

SAST-Tools (statische Code-Analyse)

SCA-Tools (Abhängigkeits-Scanning)

DAST-Tools (dynamisches Testen)

Container- und Image-Scanning