Vulnerability scanning
Automated checks that look for known security weaknesses in your code, packages, container images, servers, settings, and running app.
See it
What it is
Vulnerability scanning is automated searching for known weaknesses in dependencies, container images, hosts, configurations, and running web applications. Software composition analysis matches package versions to advisories; host scanners inspect services and missing patches; dynamic scanners probe a deployed app. Tools such as Trivy and OWASP ZAP cover different slices, not one interchangeable job.
Run fast dependency and image scans on every change, then schedule broader authenticated scans against owned staging systems. Keep the advisory database fresh, record the exact artifact scanned, and send findings into a workflow with an owner and deadline. Authentication matters because an anonymous web scan cannot see most account and admin paths.
A scan report is not a verdict. A CVE can be present but unreachable in your build, while a custom authorization flaw may have no signature for a scanner to find. Confirm exploitability, patch or mitigate the real path, and document evidence for suppressions. A quiet scan can mean good security, the wrong target, stale data, or missing credentials.
Ask AI for it
Add layered vulnerability scanning to this project. In CI, run Trivy against the repository, lockfile, built container image, and infrastructure configuration; refresh its advisory database and fail on fixable HIGH or CRITICAL findings. Generate a CycloneDX SBOM and store both the SBOM and scan report with the build artifact. On a schedule, run the OWASP ZAP Baseline Scan against the owned staging URL with a dedicated low-privilege test account. Create an allowlist file that requires a finding ID, evidence, owner, and expiry date for every suppression, and add tests proving the scanner covers authenticated routes without sending destructive requests.