Security scanners are useful, but a single successful scan in CI only tells you that the dependencies looked acceptable at that moment. If a new CVE is published days later for a package already in your main branch, nothing changes unless your setup rescans existing code, artifacts, or images when vulnerability data is updated. The build can remain green while production continues running with a newly known issue.
Scanning only the production image also leaves out development and build-time dependencies. Those packages may still run on developer machines or in CI, where a compromised dependency could access credentials or tamper with the build before the production image is created.
There is also an ownership problem: once a scanner produces a finding, who is responsible for fixing it, and how do you verify that the fix actually reached production? What should happen when a CVE is published a week after a merge, and what system or person is expected to respond?
4 Answers
For production, build images exclusively in CI from versioned, immutable inputs. Avoid using locally built images in staging or production, and use automation such as dependency or image update tools to keep base images and packages current. A finding is only useful if the affected dependency can actually be upgraded and the resulting image is rebuilt and deployed.
The important part is turning findings into owned work. A scheduled scan can create or update tickets for the team responsible for the repository, service, or artifact, with severity and due dates attached. Run the scan during normal CI as well, but keep the scheduled job so a new CVE is found without requiring another commit. The workflow should track the issue through remediation and confirm that the rebuilt artifact was deployed.
Development dependencies deserve separate controls because they may never appear in the runtime image. Treat developer and CI credentials as disposable or heavily restricted, and make sure they cannot access production or higher-trust environments. That limits the damage if a package used during development or the build process is compromised.
Exactly. Assuming local credentials could eventually leak is a useful design exercise. If those credentials have no access to test, staging, or production systems, the compromise is much easier to contain.
The usual answer is a scheduled scan, not just a scan triggered by code changes. Run vulnerability checks daily or on another regular cadence so newly published advisories are detected even when the repository is idle. The scanner database also needs to be updated reliably, since delayed vulnerability data can create a detection gap.
That is the part many teams skip: discovering a vulnerability is not the same as being able to remediate it. The process needs a path for testing updates, handling blocked upgrades, and documenting an accepted risk when no fix is available.