Malicious package detection Dynatrace: find and triage CWE-506

Picture the 3 a.m. page: a library nobody picked on purpose, pulled in three levels down the dependency tree, has just been declared booby-trapped. The first question is whether it runs on your estate, and where. Since Dynatrace SaaS 1.344, malicious package detection Dynatrace-side lands in Runtime Vulnerability Analytics (RVA), in the same list as your CVEs. Here is how to get ready, and what to do when a row appears.

The difference from a repository scanner: the scanner describes what you are about to ship, while RVA describes what monitored processes have actually loaded. For whoever is on call, that is the only answer that matters first.

A word on scope. The Dynatrace SaaS 1.344 release notes (rollout from 29 July 2026) announce the feature. Nothing I read confirms it for Dynatrace Managed, so I do not claim it, and I never blend the two offerings. I have not run this on a live environment: everything below rests on the official documentation, and practice-based passages are flagged as such.

Malicious package detection Dynatrace: spotting the finding at a glance

A malicious package is not a flaw to patch; it is hostile code that is already there. Dynatrace still models it as a vulnerability, which is handy: your filters, dashboards and remediation flow apply untouched. The tell-tale signs:

• a title starting with Malicious code;
• the CWE-506 tag (Embedded Malicious Code);
• critical severity out of the box, CVSS 4.0 of 9.3;
• six ecosystems: Java, JavaScript, Python, Go, .NET and PHP;
• continuous re-evaluation, with the documentation mentioning a check every minute.

Before the incident: find your blind spots

A detector that cannot see a process says nothing, and silence reads as good news. I would start by listing the holes, before hunting for any package.

What the RVA page requires

• Deep monitoring of process groups. For .NET, Go and Python it does not switch on by itself: enable it by hand, host by host.
• A recent enough OneAgent for third-party detection: Java 1.221, Node.js 1.231, PHP 1.231, .NET 1.233, Go 1.245, Python 1.309. For Python, turn on « Monitor Python » and « Python software component reporting », then restart the processes.
• Read access in the Vulnerabilities app: the Read Entities and Read Security Events IAM policies, plus an Admin, Pro or Standard user policy, for the group reaching vulnerability-service.

Coverage gaps to hunt down

• A host without OneAgent will never report anything.
• A process group set to « Do not monitor » is invisible, a booby-trapped package included: review those exceptions.
• Webpack and other bundlers can confuse automatic detection: only externally deployed packages are caught.
• Java on z/OS is not supported.

Switching on third-party monitoring

One honest point: I found no toggle specific to malicious packages. The documentation presents them as an extension of the Dynatrace Vulnerability Feed, so they follow the RVA setup for third-party components.

1. In the Vulnerabilities app, look for the « Vulnerability analytics enabled » banner. Missing? Enable Third-party Vulnerability Analytics in the Application Security settings.
2. Pick the default behaviour, Monitor or Do not monitor, then add rules based on resource attributes or Kubernetes labels if needed.
3. Restart processes when the page asks for it (Python, Java vulnerable functions).

Caution: the RVA page still describes the older interface, deprecated in favour of the Vulnerabilities app. Compare the labels with what you see before quoting them to your team.

Source : docs.dynatrace.com

Screenshot taken from docs.dynatrace.com (Vulnerabilities page); the rows shown are sample data from the documentation.

When the row lands: read before acting

Filter on Malicious code or CWE-506. For each row, four questions, in this order:

1. Which package, version and ecosystem? Cross-check the repository lock file to see who introduced it.
2. Who runs it? A third-party finding lists the linked applications, services, hosts, databases and Kubernetes workloads, with a process count. That is your map of owners to warn.
3. Since when? The evolution tab keeps 365 days of status, risk and score changes.
4. In what state? Open, Resolved (closed automatically once the cause is gone) or Muted. Never mute such a finding without a written reason and a security review.

On severity: it is critical by default, and nothing I read says it adapts to exposure. Do not downgrade it because the service is internal. For classic CVE prioritisation logic, see runtime vulnerabilities and process exposure; here we step outside that frame.

The response plan I would apply

What follows is operator practice, not a Dynatrace procedure; fit it to your own security process.

1. Contain. Pull the workloads from traffic or cut their outbound network, and rotate any secret those processes could read. Tell security before deleting anything: the traces are investigation material.
2. Replace. Drop the package or pin a clean version, rebuild the image, redeploy. A blind version bump proves nothing: read what the new release actually contains.
3. Confirm. Restart the processes (the documentation asks for it after a library change), wait for the next evaluation, then check the finding flips to Resolved.
4. Record. Detection time, fix time, affected services: those two durations feed your MTTR.

To know what an image held before it shipped, an SBOM inventory helps: Syft and image SBOMs, then Trivy for Kubernetes as a pre-production check.

What the documentation does not say

• According to the FAQ, malicious code comes exclusively from the Dynatrace Vulnerability Feed. No coverage or false-positive rate is published; I will not invent one.
• I found no DQL query or documented API for these specific findings, so I offer none.
• No confirmation for Managed.

Habits that pay off

• A dedicated alert channel for Malicious code, with a named on-call owner, rather than the shared CVE queue.
• Repository analysis alongside: one sees what runs, the other what is about to ship.
• Pinned versions and verified checksums in CI.
• A quarterly review of « Do not monitor » rules.
• The broader picture in Dynatrace Application Security.

Frequently asked questions

Do malicious packages need a special licence or setting?

The pages I read describe none: the feature extends RVA. RVA billing is covered in the licensing page (GiB-hours with the Dynatrace Platform Subscription, Application Security units on classic licensing). Check your contract.

Is a « Malicious code » finding always a real compromise?

No false-positive rate is documented. Act as for an incident, then confirm by analysing the package.

Does Dynatrace Managed detect malicious packages too?

Not confirmed: the announcement I read targets Dynatrace SaaS 1.344.

Conclusion

The real value is answering « who runs it? » fast. That means fixing your monitoring blind spots before the day it matters, then following contain, replace, confirm. Reference source: the 1.344 release notes.

This blog is independent and not affiliated with Dynatrace LLC. Information comes from public documentation and may change; verify it in your own environment.

---

Originally published on span.observer. French version: https://span.observer/fr/paquets-malveillants-dynatrace-rva/.