<!-- This issue template can be used as a great starting point for feature requests. Learn more about the process: https://handbook.gitlab.com/handbook/product/how-to-engage/#customer-feature-requests. The section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated using the release post item generator: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator. The remaining sections are the backbone for every feature in GitLab. The goal of this template is brevity for quick/smaller iterations. For a more thorough list of considerations for larger features or feature sets, you can leverage the detailed [feature proposal](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md). --> ### Problem to solve <!-- What is the user problem you are trying to solve with this issue? --> GitLab increasingly has useful information about security advisories, for the purpose of enriching vulnerability detections/findings. Currently the main way this is accessed is via the GitLab UI when viewing vulnerability reports, or via the GraphQL API when retrieving details about vulnerability findings. It would be useful for integration purposes to be able to query information about advisories GitLab knows about, via the GraphQL API, by advisory ID (i.e. CVE, GHSA), without needing a vulnerability finding to query against, but this is not currently possible. ### Proposal A GraphQL endpoint could be added, such as `Query.advisory()` for a singular advisory, with an "identifier" key for the identifier (such as CVE or GHSA identifier), returning data GitLab knows about a given advisory ID. One key area which would be useful is for returning EPSS data (and eventually KEV) as well as scoring information, severity, description and other information from the advisory database. This would naturally be limited to advisories we currently have data about, but should not be artificially limited to only return advisories about GitLab itself, as data about 3rd party/vendor advisories is also extremely useful for integration purposes. ### Intended users Personas are described at https://handbook.gitlab.com/handbook/product/personas/ * [Amy (Application Security Engineer)](https://handbook.gitlab.com/handbook/product/personas/#amy-application-security-engineer) * [Alex (Security Operations Engineer)](https://handbook.gitlab.com/handbook/product/personas/#alex-security-operations-engineer) ### Feature Usage Metrics <!-- How are you going to track usage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it? Explore (../../doc/development/internal_analytics/internal_event_instrumentation/quick_start.md) for a guide. --> ### Does this feature require an audit event? <!--- Checkout these docs to know more https://docs.gitlab.com/ee/development/audit_event_guide/#what-are-audit-events https://docs.gitlab.com/ee/administration/audit_events.html ---> ### Refinement First we split this into two: 1. querying advisory information and 2. attaching CVE enrichment data to this query. #### Querying advisories - [ ] Create `ee/app/graphql/types/package_metadata/advisory_type.rb` - [ ] Include all advisory fields - [ ] Do we need to touch on authorization at all since this should be agnostic? - [ ] Create `ee/app/graphql/resolvers/package_metadata/advisory_resolver.rb` - [ ] Are there any must-have filters? - [ ] Implement batch loading - [ ] Add new advisory type to `ee/app/graphql/types/query_type.rb` #### Questions 1. How do we query advisories? Identifiers are stored in a json format making them very inaccessible. Using CVEs as a first step may be okay but otherwise this would be complicated.