Rename this library? (and if so, alternative names wanted!)

[G-Rath]

Originally I called this osv-detector because I felt "auditor" and "scanner" were a bit overloaded, and I was considering if this was to be published as a package somewhere, osv-detector would be less likely to have already been taken.

However, I'm now thinking if it would be better to call it something else for a few reasons:

1. I'm thinking about additional checks we could be doing, like Support checking if things are approaching EOL with endoflife.date  #75 (I don't think this is probably worth it)
2. Go packages/binaries are not restricted to unique names, and osv-detector might not be as easy to find as say "security-auditor"
3. osv-detector is sort of wrong, as this tool isn't for "detecting OSVs"...

But the real blocker for me is what to actually call it instead - I'd prefer to not use "lockfile" (e.g lockfile-auditor) because that'd put us back in the same place if we start auditing more than them (but then maybe it's fine?)

[dp4rk]

What about renaming it to be an action instead of a noun?
`check-for-osvs' or something similar where "check" is the actionable word instead of the current "detect". It might give you more flexibility that way.

[G-Rath]

I'm not against that, but I think it's the "osv" part that I'm interested in replacing more than anything because that's the part that only makes sense if you know what osv stands for.

[zinderic]

What is the relationship with https://github.com/google/osv-scanner ? It has the "osv-scanner" name and I see both projects share code so deciding on the name should probably take that into account.

I find "osv" a bit unfriendly to folks not knowing what it stands for, I know I had to look it up. Maybe something around the more commonly used "oss" since all those dependencies it works with are mostly opensource dependencies that are public and therefore have vulnerability info in public databases?

[G-Rath]

The scanner is a project belonging to Google who also maintain the osv.dev API which backs both the scanner and the detector (for it's API database).

We're got very similar goals which lead to me "donating" the lockfile and semantic packages to the scanner as they were the next step for Google which I happened to build while they were working on the backend - since then, I'm now something of a core contributor to the scanner too.

The detector is still very much being maintained (especially as we're using it internally at Ackama), though one day the scanner might have enough parity with the detector to properly replace it in full.

I agree that "osv" is a bit of an obscure term, though I thought it was better than futher overloading terms like "audit-app", "security scanner", etc (which also tend to be published packages already).

oss-detector is an interesting idea 🤔