Tools like Trivy, Syft, and Grype are useful, but a single successful scan only tells you what was known at that moment. If a new CVE is published a week after a dependency is merged, nothing will happen unless your setup rescans existing repositories, artifacts, or images. Scanning only the production image also misses development dependencies that may have run on laptops or in CI and could potentially access credentials or tamper with builds. Beyond generating a report, someone needs to own each finding, prioritize it, apply the fix, and verify that the patched version reached production. How does your setup detect newly disclosed vulnerabilities, and who is responsible for handling them through remediation and deployment?
4 Answers
For images, automate rebuilding and dependency updates instead of waiting for someone to notice an old base image. Renovate, Dependabot, or similar tooling can open updates, while immutable image versions or digests make it possible to identify exactly what was built and deployed. Every source change should go through the same controlled CI build rather than relying on locally produced images in staging or production.
Development dependencies need their own controls because they may run before the production image exists. One defensive approach is to assume local credentials are already compromised: keep local credentials isolated from test and production environments, use short-lived access where possible, and make sure a developer machine cannot directly affect higher environments.
The usual solution is a scheduled scan in addition to scanning every build. Run it daily or on another regular cadence, then create tickets for findings and assign them to the team responsible for the repository, service, or artifact. The important part is tracking each issue until the fix is deployed, not stopping when the report is generated.
A scanner can tell you that something is vulnerable, but it cannot guarantee that the dependency is upgradeable or that the upgrade will be safe. Prioritize testing and automating version updates so fixes can move quickly. A large list of unremediated critical findings is not useful if the team has no process for resolving them.
Exactly. The useful metric is not just how many vulnerabilities were found, but how quickly the team can assess, fix, test, and deploy them.
That still depends on the vulnerability database being updated promptly, but scheduled rescans are the practical way to catch issues that appear after the original build.