feat(ospkg): add Docker Hardened Images support

[aubm]

Description

Add first-class vulnerability scanning support for Docker Hardened Images (DHI) after images begin identifying themselves with ID=dhi.

This change:

• detects DHI from /etc/os-release and keeps that identity when inherited Alpine or Debian release files are also present;
• generates pkg:apk/dhi or pkg:deb/dhi PURLs according to the native package analyzer;
• introduces a DHI OS-package detector using APK or Debian version semantics;
• queries lineage- and release-specific advisory buckets such as dhi alpine 3.24 and dhi debian 13;
• filters architecture-specific advisories and does not fall back to upstream Alpine or Debian advisory feeds.

The corresponding DHI feed acquisition and database ingestion changes are being prepared separately in aquasecurity/vuln-list-update and aquasecurity/trivy-db. Those database changes must be available before this scanner support is released.

Related issues

None yet.

Checklist

• I've read the guidelines for contributing to this repository.
• I've followed the conventions in the PR title.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).

Testing

GOEXPERIMENT=jsonv2 go test ./pkg/fanal/types ./pkg/fanal/analyzer/os/release ./pkg/detector/ospkg/dhi ./pkg/detector/ospkg ./pkg/purl

[CLAassistant]

All committers have signed the CLA.

[aubm]

Hello @knqyf263, @DmitriyLewen, apologies for reaching out to both of you directly.

I opened this PR because we at Docker are changing how vulnerability scanning works for Docker Hardened Images.

The upcoming images will identify themselves with ID=dhi, while retaining ID_LIKE=alpine or ID_LIKE=debian to describe their package-manager lineage. DHI OS packages will also have pkg:apk/dhi/... or pkg:deb/dhi/... identities, with Docker publishing the corresponding advisories.

Without first-class DHI support, Trivy detects the inherited Alpine or Debian release markers and evaluate these packages against upstream advisories, even though DHI packages have a distinct identity and advisory source. This PR introduces:

• first-class detection of ID=dhi, with precedence over inherited Alpine or Debian release files;
• DHI package PURLs that retain the native package type (apk or deb);
• a DHI OS-package detector that applies the appropriate APK or Debian version semantics;
• lineage- and release-specific advisory lookups such as dhi alpine 3.24 and dhi debian 13;
• release and architecture isolation, without falling back to upstream Alpine or Debian advisories.

The proposed scanner-facing contract is described here if you want or need more context: https://github.com/docker-hardened-images/advisories/blob/main/integration/dhi-scanner-integration-upcoming-changes.md

The source-ingestion work is intentionally separate: we plan to contribute a vuln-list-update source that mirrors the OSV records from Docker's advisory repository, and a dedicated trivy-db provider that validates those records and builds the lineage- and release-specific DHI buckets consumed by this detector. I will link those PRs once they are ready for review.

I would especially appreciate your feedback on whether representing DHI as one OS family with its native package type selected from the package analyzer, and using lineage-aware database buckets, fit Trivy's intended architecture. Feedback on how you would prefer the scanner and database changes to be sequenced would also be very helpful.

Thank you!