Implement standalone database API

[fraxken]

The goal of the task is to implement standalone database API like the OSV one for:

• GitHub
• Snyk
• Sonatype
• NVD

The main idea behind that is to use them to refactor strategy (for example in Snyk and Sonatype we kinda do the work ourself).

I created one issue but each of the require a separated PR.

[AntonioliBenjamin]

Hi @fraxken I have some questions for this issue

• When you mention 'database API,' do you mean that we should develop a set of libraries or an SDK to fetch data from GitHub, Snyk, Sonatype, and NVD? Or are we supposed to build a new REST API that will expose these vulnerability data to be consumed by other systems?

• Could you clarify the specific requirements for the standalone database APIs? For example, what should the data format and structure look like?

• Do we need to support any specific authentication or authorization mechanisms for these APIs?

• Are there any existing libraries or tools that the project is already using to interact with GitHub, Snyk, Sonatype, and NVD, or should we implement everything from scratch?

• Are there any specific guidelines or best practices we should follow while designing these APIs, such as naming conventions or error handling strategies?

• Should we implement these APIs as separate modules within the project, or should they be part of a single module?

[fraxken]

@AntonioliBenjamin

• Yes, the idea is to implement functions similar to an SDK to fetch data from each source, like what I've done with OSV here: OSV implementation.
• We should adhere to their respective formats, which we have in src/strategies.
• Yes and no. Currently, only Snyk and NVD require authentication. I think we should keep it simple and just add an option to provide a token for those databases.
• There are no existing tools; everything must be built from scratch.
• Nothing specific as of now. In OSV, I chose to use findOne and findMany, but this could change in the future. If you have opinions on that I would be happy to hear them.
• One module per database (like OSV) with exports in the root index.ts.

My idea is to start simple and reuse them when possible in the strategies. For example, take a look at Snyk: Snyk strategy implementation.

The same approach applies to Sonatype.

If you need help or talk do not hesitate to message me on Discord