How a two-layer CVE scanning setup catches vulnerabilities CI pipelines routinely miss

A software team using GitHub Actions discovered that a single dependency scanner was insufficient because vulnerabilities exist in two distinct layers: application dependencies and the OS packages bundled inside base Docker images. Tools like pip-audit and pnpm audit cover the first layer by checking requirements.txt and package-lock files against advisory databases, while Trivy is needed to scan base images such as python:3.12-slim for OS-level libraries like openssl and glibc. A key pitfall identified is that Docker's build cache can silently reuse old apt-get upgrade layers, meaning OS patches never actually get applied even when a rebuild appears to succeed. The team configured dependency scans to block deployments on HIGH or CRITICAL runtime findings, while a separate weekly Trivy cron job flags only CRITICAL and fixed OS vulnerabilities to reduce noise. Separating dev dependencies from runtime ones and using explicit, justified ignore rules were highlighted as deliberate choices to keep the pipeline signal meaningful rather than cluttered with false positives.