511 of 2658 assets (~19%) emitted with no occurrence_key on crypto-finder-integration-demo

[matiasdaloia]

What happened

crypto-finder 0.25.5 (image ghcr.io/scanoss/crypto-finder:0.25.5-deps), scanning crypto-finder-integration-demo with dependency scanning + callgraph export:

• interim v3: 2658 cryptographic_assets, of which 511 have an empty/missing occurrence_key
• callgraph export: 511 graphs also carry no occurrence_key

The counts match, so it looks like one code path produces both: a sighting the callgraph pass knows about but that never got a key.

Why it matters

Since #232 the occurrence_key is the sighting's identity. A consumer cannot join an unkeyed asset to its graph, cannot dedupe it across scans, and cannot track it over time. Earnie rejects such assets (counted as occurrence_key_missing, run drops to partial coverage), so ~19% of this repo's inventory is currently invisible downstream — and the reachability evidence in those 511 graphs is unusable.

Expected

Every emitted asset carries a key. If a sighting genuinely can't be anchored, it should still get a key derived from (file, line, rule) rather than none, so consumers can at least join it.

Repro

crypto-finder scan --deps --export-callgraph … <crypto-finder-integration-demo checkout>
jq '[.findings[].cryptographic_assets[] | select((.occurrence_key // "") == "")] | length' interim.json