Security Checks That Keep Up With AI Coding

An agent can finish a change and pass its tests while a dependency has a newly disclosed vulnerability. Security information changes independently of your code, and the next agent needs evidence it can inspect without reconstructing the previous conversation.

Our workflow needed repeatable checks that connect dependency versions to current advisories, preserve the supporting records, and show what could not be checked. That gives remediation and audit work a shared starting point.

Make findings traceable

OSV-Scanner connects a project's dependencies with known vulnerability advisories. For an agent pipeline, those results become more useful when they retain the scanned source's fingerprint, the advisory data used, and the locations of affected packages. Grouping records that explicitly identify the same issue reduces duplicate investigation while preserving each source's claims.

Security feeds can provide additional context, including maintenance notices and emerging reports. An article mentioning a package is a lead to review; it does not establish that your version is affected. Keeping those mentions separate from version-specific advisory matches helps agents avoid treating every search result as a vulnerability.

That is the role of icu-security-mcp in our workflow. It makes dependency scans, retained RSS/Atom reports, and preserved advisory evidence available through tools a coding agent can call. Results stay tied to a frozen source snapshot, with incomplete coverage visible to the next task.

A match starts an investigation

Suppose a locked dependency matches an advisory. The next step is to examine the affected feature and how the application uses it. A compatible fix may be appropriate; an automatic upgrade based only on a package mention may introduce unnecessary changes.

The practical sequence is to scan, triage, make suitable fixes, run meaningful application checks, and rescan. Then audit the intended final tree with the remaining findings and unresolved questions attached. Dependency changes made afterward may require further verification.

Missing versions, unresolved Git dependencies, unsupported ecosystems, and stale advisory or feed data leave gaps. Feed collection is also limited to retained content. A source scan does not verify deployed dependency versions, and a finished scan does not establish exploitability or prove the application safe.

Keep the broader audit

Strix audits can investigate affected code paths alongside authorization, injection, and business-logic flaws that dependency matching cannot establish. Their coverage still depends on the target, scope, tools, model, and available time.

You can combine both strategies with the security-audit skill in agent-skills. It guides dependency scanning, preliminary fixes and rescanning, followed by an independent Strix audit and verification of final fixes. Ask your coding agent to follow the skill's security protocol for your repository.