Ursprünglich veröffentlicht auf LinkedIn am 2025-10-22.
Vulnerability-Scans können trickreich sein, und es gibt verschiedene Strategien. Es beginnt bereits bei den Datensätzen, die von den verschiedenen Betriebssystemen bereitgestellt werden, und wie diese von den Scan-Tools implementiert werden. Nehmen wir zum Beispiel Alpine. Viele Ingenieure denken, dass es sicher ist, weil Tools wie Trivy 0 Vulnerabilities anzeigen.
Aber es gibt security.alpinelinux.org und Informationen über potenzielle CVEs innerhalb von Alpine-Paketen.
Und Alpine bietet auch Informationen über CVEs, die bereits über den secdb.alpinelinux.org-Dienst behoben wurden.
Die Informationen, die ein Vulnerability-Scanner zur Erkennung von Common Vulnerabilities and Exposures (CVEs) während des Scannens von Artefakten wie Container-Images verwendet, sind hochrelevant. Beispielsweise bedeutet ein Trivy-Scan eines auf Alpine basierenden Container-Images, der null Vulnerabilities meldet, oft, dass derzeit keine Sicherheitskorrekturen (secfixes) für die aufgeführten Alpine-Pakete verfügbar sind. Dieser Ansatz ergibt Sinn, insbesondere wenn Paketversionen im Containerfile festgezurrt sind, da der Fokus auf bekannten, behebbaren Problemen liegt. Die Integration dieser Scanning-Strategie früh im CI/CD-Pipeline ist sehr vorteilhaft, da behebbare CVEs während des Build-Prozesses erkannt werden und sofortige Aufmerksamkeit erregen. Dementsprechend unterstützt Trivy nicht die Erkennung von tatsächlich unbehobenen CVEs beim Scannen von Alpine. Ein Detail, das nicht überraschend ist, wenn die Dokumentation richtig gelesen wurde.
Siehe: https://trivy.dev/v0.67/docs/coverage/os/alpine/
Im Gegensatz dazu verfolgt Debian eine andere Strategie. Es pflegt eine Datenbank offener, bekannter CVEs für seine Pakete (www.debian.org/security/), und Trivy verwendet diese Informationen für seine Scans. Das Ergebnis ist völlig anders: Mit denselben Tools im selben Workflow wird die Erkennung unbehobener CVEs unterstützt.
Details in der Trivy-Dokumentation: https://trivy.dev/v0.67/docs/coverage/os/debian/
Die entscheidende Implikation dieser gegensätzlichen Strategien ist sofort in der Wartung der Vulnerability-Basislinie erkennbar: der .trivyignore-Datei. Für ein auf Alpine basierendes Image wird die .trivyignore-Datei deutlich weniger Einträge enthalten und nur Ausnahmen für Probleme dokumentieren, für die eine Lösung existiert, die aber verschoben wird. Der Debian-Ansatz erfordert hingegen eine .trivyignore-Datei mit deutlich mehr Einträgen, da er den Benutzer zwingt, bekannte, aber noch nicht behebbare (durch einfache Paketaktualisierungen) CVEs, die vom Scanner gemeldet werden, manuell zu unterdrücken oder zu akzeptieren.
Letztendlich müssen Teams entscheiden, welche Vulnerability-Reporting-Strategie am besten zu ihrer Risikotoleranz und Pipeline-Metriken passt. Dieser Unterschied ist für effektive DevSecOps- und Security-Praktiken relevant und unterstreicht die Bedeutung, seine Tools und deren Grenzen zu kennen. Vielleicht sollten Sie auch mehrere Tools verwenden, aber bewerten, ob es verschiedene Strategien gibt, um das zu erkennen, was erwartet wird.