Format fingerprinting misclassifies files: no match threshold, generic keys, and ties resolve by declaration order

[wdower]

libs/hdf-converters/src/utils/fingerprinting.ts scores each candidate format by counting truthy _.get() hits for that format's fingerprint keys, then takes the max via a reduce where a tie goes to the later-declared entry. Any nonzero count wins (if (fingerprinted.count !== 0)), so a single matching key is sufficient to classify a file.

Several fingerprint keys are highly generic. Both NIKTO and SNYK include vulnerabilities:

[INPUT_TYPES.NIKTO]: ['banner', 'host', 'ip', 'port', 'vulnerabilities'],
...
[INPUT_TYPES.SNYK]: ['projectName', 'policy', 'summary', 'vulnerabilities', 'vulnerabilities[0].identifiers'],

Consequence, as reported by a downstream user: an Anchore Enterprise (anchorectl) vulnerability report — a format no converter supports — contains a top-level vulnerabilities key, scores GRYPE 0 / NIKTO 1 / SNYK 1, and is confidently classified snyk because SNYK is declared after NIKTO. The user is then told, specifically and incorrectly, to run snyk2hdf. Note that an empty vulnerabilities: [] is truthy, so the key's mere presence is enough.

This is also a contributing cause of mitre/saf#1567 (generic saf convert misidentifying filetypes), alongside the dispatch bug filed separately in mitre/saf.