feat: add Hex advisory source

[dl-alexandre]

Summary

• add hex_core as an advisory source alongside the existing Mirego YAML advisory repo
• normalize Hex/OSV aliases so duplicate records for the same CVE/GHSA are collapsed before mapping to MixAudit.Advisory
• de-duplicate combined YAML + Hex advisories by {package, id} so Hex only supplements gaps in the mirrored advisory repo
• add focused mapper regression tests that do not depend on live Hex responses

Why this helps

The Mirego advisory repo mirrors GitHub Advisories, while Hex exposes package advisory metadata from Hex/OSV. Most current entries overlap after alias normalization, but live data currently includes Hex-only coverage for phoenix_storybook (GHSA-mrhx-6pw9-q5fh, GHSA-55hg-8qxv-qj4p, and GHSA-833p-95jq-929q). This change keeps the existing YAML source as the primary source and uses Hex to fill those gaps without double-counting aliased records such as EEF-CVE-* + GHSA-* entries for the same vulnerability.

Verification

• MIX_ENV=prod mix test
• MIX_ENV=prod mix compile --warnings-as-errors
• MIX_ENV=prod mix run -e 'advisories = MixAudit.Repo.advisories(); IO.inspect(length(advisories)); IO.inspect(Enum.filter(advisories, &(&1.package == "phoenix_storybook")) |> Enum.map(&{&1.id, &1.title}), limit: :infinity)'

[remi]

Hi @dl-alexandre,

add hex_core as an advisory source alongside the existing Mirego YAML advisory repo

I’m not sure I understand the difference between those two sources. Our elixir-security-advisories repo is a copy of GitHub’s Advisory Database.

Is there a usecase where one advisory would be in one source but not the other?

[dl-alexandre]

Thanks, that is a fair question. I dug into the live data and tightened the implementation in dada26a before replying.

The sources mostly overlap after alias normalization. Hex/OSV currently returns 94 raw advisory records, but several are duplicate aliases for the same vulnerability (EEF-CVE-* and GHSA-*). After collapsing aliases, that becomes 66 advisory groups; 63 of those are already covered by the mirrored GitHub advisory repo.

The concrete gap I found today is 3 Hex-only phoenix_storybook advisories:

• GHSA-mrhx-6pw9-q5fh
• GHSA-55hg-8qxv-qj4p
• GHSA-833p-95jq-929q

So the intended use case is not to replace the Mirego/GitHub mirror, but to supplement it when Hex exposes package advisory metadata that has not landed in the mirror yet. I also changed the PR so the combined list is de-duplicated by {package, id} and aliased Hex records are collapsed before mapping, which avoids double-counting the overlapping data.

[maennchen]

@remi OSV.dev (currently the primary source of hex.pm) aggregates multiple sources, one of them is the EEF CNA. GitHub has longer delays since it propagates EEF CNA => CVE.org => NVD => GitHub and includes multiple manual steps.

[dl-alexandre]

Thanks for the pointer to hex_core#188 and the group_for_display discussion.

The change adds Hex (via hex_core/OSV) as a supplementary source alongside the existing Mirego/GitHub mirror. After alias normalization and de-dup by {package, id}, it fills specific gaps that haven't propagated yet (e.g. the three phoenix_storybook advisories that were in Hex but not the mirror at the time of the PR).

Happy to adjust the merging logic, prefer hex_core's grouping, or make the hex source optional if preferred. Let me know the direction you'd like.

[dl-alexandre]

Review thread from @maennchen noted from history. The Hex advisory source addition is ready (action_required is fork CI gate). Any additional feedback welcome.