2.0 KiB
vuln-builder – CVE-Referenzimplementierung
Erstellt master.db.zst, manifest.json und (wenn --previous existiert) delta.jsonl.zst aus dem Repository vuln-cve. Das SQLite-Schema hält CVE-ID, Status, Aktualisierungsdatum und verlustfrei die originale CNA-affected-Liste vor. Es ist ein kompakter CVE-Index, kein fertiger Scanner: CNA-affected-Angaben sind nicht allein ausreichend für genaue CPE-, PURL-, Vendor- oder Distro-Versionsabgleiche; diese benötigen quellenspezifische Parser und AND/OR/NOT-Bedingungen.
Lokal
python3 -m pip install -r requirements.txt
python3 scripts/build.py --source ../vuln-cve/data --output dist
# Später mit vorheriger Datei für Delta:
python3 scripts/build.py --source ../vuln-cve/data --previous /pfad/alte/master.db --output dist
# Delta auf vorhandene Kopie anwenden:
python3 scripts/apply_delta.py --database /pfad/alte/master.db --delta dist/delta.jsonl.zst
GitHub Actions
Die Build-Action checkt vuln-cve aus und lädt die vorherige veröffentlichte master.db.zst per gh release download. Sie erstellt eine neue GitHub Release mit Master und ggf. Delta. VULN_READ_TOKEN muss Leserechte auf vuln-cve haben (Fine-grained PAT oder GitHub-App-Token); der GITHUB_TOKEN des Builder-Repos braucht contents: write. Private Quellen, Branch-Schutzregeln und Self-hosted-Runner sind entsprechend einzurichten.
Grenzen für den Produktivbetrieb: Die GitHub-Release-Dateigrößen und Repo-Quotas müssen überprüft werden. Der Build erstellt bisher nur einen CVE-Datensatz-Index; NVD/OSV/Hersteller/KEV/EPSS-Adapter sowie die Zusammenführung von Advisories und Versionsbereichen sind noch nicht implementiert. Deltas müssen sequenziell und unverändert veröffentlicht werden; GitHub latest ersetzt keine versionierte Delta-Historie. Releases dürfen nicht überschrieben werden. Für größere Datenmengen sind ein persistenter Runner, inkrementelle Builds und Release-Retention-Strategie sinnvoll.