Using AI to Identify Vulnerable Software You Actually Have Deployed

A new advisory comes out for a widely used library. Within minutes, dependency scanning lights up across dozens of repositories. Some are active services. Some are archived experiments. Some are forks nobody has touched in years. A few container images in the registry include the library too, though nobody is sure which ones are still running.

The question remediation needs answered is narrow: where is this vulnerable software actually deployed?

Repository noise

Source repositories are a noisy signal for deployed risk.

• Archived or abandoned repositories still appear in scans.
• Forks and examples include dependencies that never ship.
• Development and test dependencies are declared but excluded from production builds.
• Multiple branches may have different dependency versions, only one of which deploys.
• Monorepos may contain many services, some active and some not.

Registries add their own noise: old image tags, unused builds, and images for environments that no longer exist.

None of these findings are wrong. They describe software that exists. They just don't all describe software that is running.

The data that answers the question

Identifying deployed vulnerable software requires connecting a few sources.

SBOMs tied to specific build artifacts tell you what a particular image or release contains.

Runtime inventory tells you which artifacts are running: image digests in Kubernetes clusters, versions on hosts from endpoint management, functions and services from cloud APIs.

Asset inventory and service catalogs tell you what each running workload is, who owns it, and how critical and exposed it is.

Build provenance connects artifacts back to repositories and commits.

Put together, these let you answer: this advisory affects these packages; they appear in these artifacts; these artifacts run in these places; these teams own them.

Where AI fits

The core matching, advisory to package to artifact to workload, should be deterministic. It depends on identifiers like package URLs and image digests, and it should be done with queries, not inference.

AI helps with the parts that are messy.

Reconciling inconsistent data

Real inventories have gaps. Workloads lack ownership tags. Image names don't match repository names. Some hosts report software versions in nonstandard formats. A model can suggest probable matches, such as linking a workload to a repository based on labels, image names, and deployment configuration. These suggestions should be marked as inferred and confirmed before they drive remediation.

Triaging repository findings

For repository-only findings, a model can help classify them: is this repository archived, a fork, a library consumed by other services, or a deployed application? It can read README files, CI configuration, and deployment manifests to suggest an answer. Again, treat this as a recommendation for review.

Explaining the result

Once matching is done, a model can produce a clear summary: the advisory affects four running services, two internet-facing, owned by these teams; the remaining findings are in archived repositories and unused images.

Answering questions

Engineers and analysts can ask questions about the data, such as which production workloads run images built from this repository, and get answers based on actual inventory queries.

Limits

AI can't create inventory that doesn't exist. If runtime data is missing for part of the environment, the model can't see what's running there, and it shouldn't guess.

Watch for:

• Stale runtime data that describes workloads already replaced
• Coverage gaps where no tool reports what's running
• Confident inferences that turn out wrong
• Prompt injection in repository content or labels

Require the model to distinguish confirmed from inferred matches and to name the data sources it used.

Don't ignore the noise entirely

Deprioritizing repository-only findings isn't the same as ignoring them. Archived repositories should be archived properly and excluded from scanning. Unused images should be deleted under a retention policy. Development dependencies still matter for developer machines and CI. Cleaning up the noise reduces future confusion.

A practical sequence

1. Generate SBOMs for deployed artifacts and store them by digest.
2. Collect runtime inventory of what's running and where.
3. Match advisories to deployed artifacts deterministically.
4. Use AI to reconcile gaps and classify repository-only findings, with human confirmation.
5. Route deployed findings to owners with context.
6. Clean up archived repositories and stale images.

The outcome

Remediation effort goes to software that's actually running and actually exposed. AI makes the matching and the explanation faster. Inventory is still what makes it right.