owasp/sbom-vex-taint-analysisAutomatisierte SBOM-zu-VEX-Pipeline unter Verwendung eines sicheren Multi-Agenten-KI-Systems, um CVEs zu analysieren, Ausnutzbarkeit zu bewerten und signierte CycloneDX VEX-Dokumente in Übereinstimmung mit OWASP GenAI guidelines zu generieren
Generieren Sie automatisch signierte CycloneDX-VEX-Dokumente aus SBOMs mittels einer sicheren Multi-Agenten-KI-Pipeline, entwickelt gemäß den Richtlinien des OWASP GenAI Security Projects.
Die Erstellung eines SBOMs fördert hunderte CVEs zutage. In der Praxis sind über 90 % in der Laufzeitumgebung eines bestimmten Produkts nicht ausnutzbar. Ohne ein Vulnerability Exploitability eXchange (VEX)-Dokument ertrinken alle nachgelagerten Tools – Dependency-Track, Release-Gates, Beschaffungschecklisten – in Fehlalarmen.
Weitere technische Details und Testergebnisse entnehmen Sie bitte dem WIKI.
Die manuelle VEX-Erstellung ist zeitaufwändig und skaliert nicht. Ein erfahrener Analyst kann Stunden mit der Bewertung einer einzigen Komponente verbringen. Ein produktives SBOM kann 500–2.000 Komponenten enthalten.
Dieses Projekt automatisiert diese Argumentationspipeline – sicher, ohne Vendor-Lock-in, wobei alle Daten in Ihrer Infrastruktur verbleiben.
Motivation aus der Praxis: Im Jahr 2024 dokumentierte die Sicherheitsforscherin Johanna Curiel genau dieses Problem bei der Analyse des Kubernetes Java Client (LinkedIn-Artikel). Der OSV-Scanner identifizierte in Sekundenschnelle ein hohes CVE-Risiko in
com.diffplug.spotless:spotless-maven-plugin 1.17.0. Die Feststellung, dass esnot_affectedsei (Build-Zeit-Plugin, wird zur Laufzeit nie ausgeführt), erforderte Stunden manueller Analyse. Dieses Projekt automatisiert diesen Argumentationsschritt.
Vier Sicherheitszonen. Nichts überschreitet eine Grenze ohne explizite Validierung.
┌─────────────────────────────────────────────────────────────────┐
│ ZONE 1 — Eingabe (kein LLM) │
│ SBOM-Upload → Schema validieren → Bereinigen → SHA-256-Prüfhash │
└────────────────────────────┬────────────────────────────────────┘
│
┌────────────────────────────▼────────────────────────────────────┐
│ ZONE 2 — OWASP-Guardrail-Middleware │
│ Prompt Guard (LLM01) · Output-Filter (LLM02/05) │
│ Agency-Limiter (LLM06) · Token-Budget (LLM10) │
└────────────────────────────┬────────────────────────────────────┘
│
┌────────────────────────────▼────────────────────────────────────┐
│ ZONE 3 — Multi-Agenten-Pipeline (AutoGen AgentChat) │
│ │
│ Orchestrator │
│ ├── CVE-Analyst NVD v2 + OSV + EPSS pro Komponente │
│ ├── Exploit-Reasoner Call-Graph · LLM-Reasoning · RAG │
│ └── VEX-Autor CycloneDX 1.6 schema-validiert │
│ │
│ Vektor-Store (Qdrant) — signierte frühere VEX-Entscheidungen │
└────────────────────────────┬────────────────────────────────────┘
│
┌────────────────────────────▼────────────────────────────────────┐
│ ZONE 4 — Ausgabe, Signierung, Audit │
│ Human-in-the-Loop-Gate → cosign/GPG signieren → Audit-Log │
└─────────────────────────────────────────────────────────────────┘
Dieses Projekt ist in Anlehnung an den OWASP Top 10 for LLM Applications 2025 und den OWASP Top 10 for Agentic Applications 2026 konzipiert.
| OWASP-Risiko | ID | Gegenmaßnahme in diesem Projekt |
|---|---|---|
| Prompt Injection | LLM01 | Alle SBOM-Felder vor der LLM-Eingabe bereinigt; Injizierungsmuster-Blocklist |
| Offenlegung sensibler Informationen | LLM02 | PII-Scrubber auf allen Agentenausgaben; interner Pfadfilter |
| Unsachgemäße Ausgabehandhabung | LLM05 | CycloneDX-Schemavalidierung vor der Signierung; Wiederholung bei Fehlschlag |
| Übermäßige Agency | LLM06 | Schreibgeschützte Tools während der Analyse; HITL-Gate für alle Entscheidungen mit CVSS ≥ 7.0 |
| Leckage von System-Prompts | LLM07 | Interne Richtlinien vom System-Prompt getrennt |
| Schwäche von Vektoren/Embeddings | LLM08 | Gespeicherte Vektoren signiert; Herkunft vor Kontexteinspritzung geprüft |
| Unbegrenzter Verbrauch | LLM10 | MaxMessageTermination(20); Token-Budget pro Komponente; NVD-Timeout |
Human-in-the-loop ist obligatorisch. Eine VEX-Aussage
not_affectedfür ein schwerwiegendes CVE ist eine rechtlich relevante Behauptung. Keine VEX wird ohne Genehmigung eines menschlichen Prüfers signiert. Dies ist nicht konfigurierbar.
| Komponente | Tool | Anmerkungen |
|---|---|---|
| Agenten-Orchestrierung | AutoGen AgentChat v0.4 | Multi-Agent, Tool-Nutzung, Message Hooks |
| LLM (empfohlen) | Qwen2.5-Coder-32B | Bestes strukturiertes JSON + Security-Reasoning |
| LLM-Server | vLLM (Produktion) / Ollama (Entwicklung) | OpenAI-kompatible API |
| CVE-Daten | NVD v2 API + OSV.dev + EPSS | Alle kostenlos, kein API-Key erforderlich |
| Vektor-Store | Qdrant | Selbst gehostet, vergangene VEX-Entscheidungen |
| Embeddings | all-MiniLM-L6-v2 (sentence-transformers) | Vollständig lokal |
| SBOM-Formate | CycloneDX 1.4–1.7 (JSON/XML), SPDX 2.3/3.0 | Schema-validiert bei Aufnahme |
| VEX-Ausgabe | CycloneDX 1.6 VEX | Schema-validiert vor Signierung |
| Signierung | cosign (Sigstore keyless) | Zeitgestempelt, audit-logged |
| Audit-Log | PostgreSQL (append-only, pgaudit) | Jede Agentenentscheidung aufgezeichnet |
Alles läuft vor Ort. Keine Daten verlassen Ihre Infrastruktur.
Hardware (Produktion):
Hardware (Entwicklung / kleine SBOMs):
llama3.1:8b über OllamaSoftware:
git clone https://github.com/your-org/sbom-vex-agent
cd sbom-vex-agent
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
# Entwicklung — Ollama (CPU/GPU, jedes Notebook)
ollama pull llama3.1
ollama serve
# Produktion — vLLM (GPU erforderlich)
python -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen2.5-Coder-32B-Instruct \
--gpu-memory-utilization 0.90 \
--host 0.0.0.0 --port 8000
docker compose up -d # startet Qdrant + PostgreSQL
python -m vex_agent analyse \
--sbom path/to/your-sbom.cdx.json \
--output path/to/output.vex.json
Die Pipeline wird:
Kopieren Sie .env.example nach .env und setzen Sie: