Vulnerabilities API
See original GitHub issueOne of the proposed responsibilities of this group is “owning and publishing the base dataset of disclosures.” I think the ideal way to publish this data would be to make it available via a public, documented HTTP API.
The prime use case for such an API would be for tools and services to programmatically check for vulnerabilities alongside their main task; I suspect that’s in fact how nsp works today. For example, npm might check for vulnerabilities on npm outdated
.
Other uses would be to send notifications (e.g. via webhook) when new vulnerabilities are added, and to serve as a backend API for a human-readable website for searching and listing vulnerabilities.
I think we should host this API service on our “own” infrastructure as managed by the @nodejs/build team - “own” in quotes because most of it is backed by public cloud resources and not a private datacenter. In fact, I’m not sure what other options we have; any additional cloud resources needed by this service would likely be added to the Build group’s responsibility too.
The conversation in #16 on how to store vulnerability data is loosely coupled to this conversation on a public API, in that we should be able to easily abstract the storage implementation from the API service.
In summary, this issue is to gather thoughts on:
- Providing a public Vulnerabilities HTTP API.
- How to build and host such an API service.
Issue Analytics
- State:
- Created 7 years ago
- Comments:7 (6 by maintainers)
I’m in the same position of @mcollina, no time to implement this, but after we have some data stored, if someone wanted to do this, I can’t think of any objects right now (though I don’t think we want to get in the business of competing with the APIs behind any of the providers of security tools, we would want to be careful about that).
This functionality is currently offered by several providers, and what we discussed in person at NINA to not have an API to query the dataset, but just providing the dataset to be downloaded, or something similar. If someone wants an API, they should build their own.
I am neutral to this, as I will not have any bandwidth to contribute to the development of this service.