Thursday, 5 pm: the CISO asks whether the platform’s AI services ship vulnerable libraries, and which of them actually run in production. A repository export will not settle it, because a listed dependency is not necessarily loaded. To find vulnerable AI services, Dynatrace crosses two building blocks: Runtime Vulnerability Analytics (RVA) and AI observability. Dynatrace ships a ready-made dashboard for it, introduced in its announcement post.
I start from an operations question rather than from the screen: before reading a single number, how do you know which AI services are really being examined? The dashboard only answers correctly if two separate chains are in place.
A word on method. I did not run this scenario on an environment: everything comes from the documentation pages and the post, read on 9 November 2026. Neither the post nor the pages I read say whether it applies to Dynatrace SaaS or Managed, so I claim it for neither. Anything I could not verify is flagged as we go.
Vulnerable AI services: the question to ask before the numbers
A vulnerability counter at zero is ambiguous. It can mean « all clean » or « nothing is scanned ». With AI services the second case is common: they are young, shipped fast, and sometimes sit outside the usual monitoring rules.
So the decision has two parts:
- which processes Dynatrace recognises as AI services;
- which of those processes RVA actually covers.
The post stresses the same thing: only covered processes feed the counters, and the others show as « Not covered » in a coverage section. Read that section first, not last.
What the dashboard actually combines
According to the post, the view shows GenAI entities only. AI processes come from GenAI entities in Smartscape, and each one is matched against an RVA vulnerability scan event. You do not write any DQL to populate it.
Four tiles summarise the state:
- the number of vulnerability-process pairs;
- the number of distinct vulnerabilities;
- the number of affected processes;
- the number of distinct affected packages.
Tables then break down severity, CVSS score and the number of affected processes. For a current snapshot, the post suggests a timeframe of about 30 minutes. It names LangChain and Hugging Face as typical dependencies but does not list the libraries actually covered. It gives no menu path and no specific CVE, and I will not invent either.
One more useful point from the RVA documentation: detection happens at runtime. A third-party component is reported only if it is in use, and the vulnerability resolves itself when the library is removed or the process stops. For the broader picture, see runtime vulnerabilities and process exposure.
Step 1: make the GenAI entities exist
Without AI observability the view stays empty. The post recommends OpenInference instrumentation. The OpenInference documentation gives an example .env file:
DT_ENDPOINT is the environment base URL, without the /api/v2/otlp path. A platform token needs the openpipeline:traces:ingest scope; with a classic token it is openTelemetryTrace.ingest. The values in the screenshot are templates, never real secrets. Message content is captured by default: the OPENINFERENCE_HIDE_* variables mask it, a trade-off to settle with your compliance team.
When the instrumentor does not emit every gen_ai.* attribute, the documentation goes through a local Collector. The application then sends plain spans to port 4318 and needs no Dynatrace credentials.
The details of that chain are in the article on OpenInference and the Collector.
Step 2: bring those processes under RVA
The second chain is independent of the first. The RVA documentation requires deep monitoring to be enabled in the process group monitoring settings. For .NET, Go and Python, when it is not automatic, you must enable it by hand on each host. Python also needs the « Python software component reporting » feature.
Check your OneAgent versions as well. These are the minimums for third-party detection:
A Python AI service therefore needs OneAgent 1.309 at least, while most other technologies accept older versions. It is the first suspect when your Python services are missing. The documentation also warns that bundlers such as Webpack can hide Node.js components.
Then come the monitoring rules. They can rely on resource attributes and Kubernetes labels, which the page recommends over legacy management zones. An overly broad « Do not monitor » rule silently excludes an AI service. The coverage page states that a host counts as covered if at least one of its processes is monitored: a « covered » host can therefore hide an ignored AI process. See the coverage assessment page for the setup.
Step 3: read the dashboard in the right order
- Set a 30-minute timeframe, then open the coverage section and note every « Not covered » process.
- For each one, look for the cause: technology not enabled, OneAgent too old, exclusion rule.
- Only then read the tiles, followed by vulnerabilities sorted by severity and CVSS.
- Look at the affected packages: one package often explains several rows.
The author’s own suggestion, not from the documentation: handle first whatever is critical and loaded in a service that receives external requests, then the rest in the normal update cycle. Malicious packages surface in the same list and deserve incident handling.
How to check it works
- AI services appear as GenAI entities; if not, go back to step 1 (the post says an empty view can also mean no AI process is running).
- Every AI process is listed in the coverage section, with no unexplained « Not covered ».
- The affected-process counter moves when you update a library: the vulnerability should resolve itself after a restart.
I have not observed this behaviour on a tenant: confirm it on a test service before turning it into an on-call check.
Good practice
- Put the dashboard in the weekly security review, with coverage at the top.
- After each new AI service, check within minutes that it is covered.
- Keep a dedicated ingest token with minimal scopes.
- Review « Do not monitor » rules every quarter.
- Tie AI workloads to your reliability requirements, as in this article on AI workloads.
Frequently asked questions
Does the dashboard replace a repository scanner?
No. It describes what monitored processes loaded at runtime, not everything installed. The two approaches complement each other.
Why does my AI service not show up?
Four causes to test in order: no AI observability instrumentation, deep monitoring off, OneAgent too old for the technology, or a monitoring rule that excludes the process.
Does it need a specific licence or Dynatrace SaaS?
The pages I read do not say for this dashboard: not verified. Check your contract and the RVA licensing page.
Conclusion
To keep watch on vulnerable AI services, prove coverage first, then read the counters. The two chains, GenAI entities and RVA, are independent: one can work without the other and give a misleading picture.
This blog is independent and not affiliated with Dynatrace LLC. The information comes from public documentation and may change; check it in your own environment.
Originally published on span.observer. French version: https://span.observer/fr/services-ia-vulnerables-dynatrace/.
