GitHub GraphQL Security Advisory API Adds CVE Metadata and Severity Filters

What the new fields expose​

The SecurityAdvisory object gains these fields, according to GitHub’s changelog:

GitHub’s REST documentation already includes corresponding properties: cve_id, source_code_location, github_reviewed_at, nvd_published_at, and repository_advisory_url. The concrete improvement is therefore access to these metadata through GraphQL—not the creation of five entirely new advisory concepts. That comparison does not establish identical field types or nullability across the two APIs.

For integration maintainers, that distinction matters: this is an opportunity to simplify data retrieval, not a requirement to redesign the advisory database.

Filtering moves to the server​

The securityAdvisories query now accepts severities and isWithdrawn. GitHub says these work alongside existing classification, identifier, EPSS, publication-time and update-time filters. Its suggested applications include severity-based triage feeds and withdrawn-advisory audits.

There is a useful migration detail in GitHub’s documentation: GraphQL’s SecurityAdvisorySeverity enum uses CRITICAL, HIGH, LOW, MODERATE, and UNKNOWN, whereas the REST severity parameter uses lowercase values and medium rather than MODERATE. Developers moving filter configuration between APIs should map those labels deliberately instead of copying them verbatim.

The GraphQL reference also retains withdrawnAt, which records when an advisory was withdrawn. Pairing a withdrawal filter with that timestamp can support an audit that records both status and timing; withdrawal should not be confused with deletion.

Check schema details before changing production queries​

The documentation retrieved for this report does not yet list the five new fields or the two new arguments under securityAdvisories. The changelog establishes the announcement, but the inspected reference does not settle their exact input types or nullability. Validate those details against the schema exposed by your target endpoint before updating generated clients or production queries.

As implementation guidance, retain cursor pagination and test records with missing metadata. GitHub’s reference documents pagination for advisory connections, while the announcement does not promise that every advisory contains both new timestamps.

Likewise, treat a comparison between NVD publication and GitHub review as a descriptive timing metric—not automatically a measure of remediation speed or a service-level commitment. The existing publishedAt and updatedAt fields describe separate GitHub advisory milestones.

The practical payoff​

GitHub presents the benefit as fewer requests, one authentication path and one rate-limit budget for integrations that can consolidate retrieval into GraphQL. It does not announce a larger numeric allowance or quantify performance gains.

The sensible next step is a targeted migration: identify REST calls used only to supply these metadata, validate equivalent GraphQL responses, and remove redundant calls only after checking completeness. Less API plumbing is useful—but only if the vulnerability feed still delivers the information its readers need.