Detect manually installed Node.js runtimes and report Node.js core vulnerabilities

[jetersen]

Description

Problem

Trivy does not currently identify the Node.js runtime version in container images when Node.js was installed outside an OS package manager. This includes the official node images:

NODE_VERSION=26.5.0
/usr/local/include/node/node_version.h
node --version: v26.5.0

The analyzers under pkg/fanal/analyzer/language/nodejs parse package.json and lockfiles, so they report npm ecosystem package versions—not the Node.js runtime version. apk, dpkg, and rpm metadata only covers distribution-packaged Node.js. The executable analyzer hashes an unpackaged node binary but does not extract its version.

As a result, Trivy cannot match manually installed Node.js runtimes against Node.js core CVEs.

A related broader report exists in #9759, but its Node.js example concerns an npm dependency (minimist) rather than Node.js core/runtime advisories.

Proposed behavior

1. Detect the runtime version from the standard installed header include/node/node_version.h using:
   • NODE_MAJOR_VERSION
   • NODE_MINOR_VERSION
   • NODE_PATCH_VERSION
2. Represent the detected runtime as node@<version>.
3. Ingest Node.js core advisories from nodejs/security-wg/vuln/core/*.json and match their vulnerable/patched semver ranges.
4. Report matching Node.js runtime CVEs in normal vulnerability results.

The Node.js Security Working Group currently contains 183 core advisories. trivy-db already walks this source, but has intentionally skipped entries without module_name since the initial importer implementation in 2019. The existing test explicitly described this as node.js core is skipped.

Questions for maintainers

• Is reporting Node.js core/runtime vulnerabilities desired?
• Should the runtime use package node in the existing npm bucket and npm semver comparer, or should it have a dedicated Node.js runtime ecosystem?
• Should runtime CVE matching be enabled by default or require an opt-in?
• Should NODE_VERSION from image ENV be a fallback when the installed header is absent? The header is proposed as authoritative because image metadata can become stale.

Prototype PRs

These are draft implementations intended to make the proposal concrete and can be changed based on maintainer direction:

• Trivy runtime detection: feat(nodejs): detect Node.js runtime version from header #10951
• Node.js core advisory ingestion: feat(node): ingest Node.js runtime advisories trivy-db#683

Target

Container Image

Scanner

Vulnerability

[jetersen]

Follow-up after reviewing the --detection-priority comprehensive guidance in #9759:

That flag does not currently extract a Node.js runtime version or add Node.js core advisories. Its relevant behavior is to retain language/application findings from files owned by an OS package manager; default precise filtering removes those findings in favor of vendor OS-package advisories.

The proposed changes would fit that existing model:

• Manually installed Node.js (for example, official node images): the header is not OS-package-owned, so runtime core CVEs would be reported with the default precise priority.
• Distribution-packaged Node.js: default precise would filter the header-derived runtime component and retain vendor advisories; comprehensive would additionally retain upstream Node.js core matching, accepting its documented false-positive risk from vendor backports.

So comprehensive can provide the opt-in behavior for OS-managed runtimes, but it does not replace either proposed PR.