Add support for user-specified local advisory DB

[funnelfiasco]

Right now, the offline mode falls back to the builtin advisory DB. However, there are two use cases where the user might want to reference their own DB separately from either the GitHub or builtin DB:

1. Internally-maintained DB that may be supplemented with confidential information or used in an environment with restricted network access
2. Testing proposed changes to the public advisory DB

This might be best implemented by treating the user-provided DB as supplemental and adding an option like --additional-db <LOCATION>. In the ideal case, it could be either an HTTPS URL or a filesystem path, although if that gets too complicated, I think a filesystem path is sufficient. The other option would be to ignore both of the GitHub and builtin DBs when a user supplies a DB location. In that case, it might be better to make it an optional argument to --offline (or have --offline builtin be a special case that uses the builtin DB before looking on the filesystem)

[TooFastTooCurious]

This is a good idea. The two approaches you outlined both have merit:

1. --additional-db <path> as supplemental (layer on top of the public DB)
2. Override via --offline (replace the public DB entirely)

My initial instinct is option 1 — users get their private advisories without losing public coverage. But I could see cases where someone wants a fully self-contained DB with no external dependency. Do you have a preference, or see a way to support both cleanly?

Filesystem path is probably enough for v1. URL support can come later if there's demand.

This would also be useful for testing changes to the advisory DB before submitting a PR — you could point it at a local checkout of abom-advisories.

Open to anyone who wants to pick this up — the loading logic in pkg/advisory/advisory.go is pretty contained so it should be a clean change.

[funnelfiasco]

I think option 1 is a good starting point. Since we're starting for filesystem-only, it can be used with --offline to achieve the "fully self-contained DB with no external dependency" hypothetical, should someone want that.

I think the "testing changes to the DB" option would be better covered by adding the tooling we discussed in JulietSecurity/abom-advisories#1 but this could be a use case. My only question is how we'd handle duplicate IDs. I think "the additional DB wins in case of a name collision" is probably the best approach, but I'm open to arguments for another way.

I'd be happy to take this, but I'd want to prioritize JulietSecurity/abom-advisories#1 because I think it solves a more immediate problem (making it easier for folks to contribute new advisories)

[TooFastTooCurious]

Additional DB wins on collision, agreed — that matches how people will actually use it (private/local as intentional overrides). If it ever turns into a footgun we can add a warning or a strict mode, but no reason to preempt.

Sequencing behind advisories#1 makes sense. No rush on this one — unblocking contributions is the bigger lift right now.