GitHub announced additive, read-only changes to its SecurityAdvisory GraphQL API on October 2, 2026. The update adds five fields to the SecurityAdvisory object and two filters to the securityAdvisories query.
For teams that collect vulnerability intelligence, the change could make GraphQL integrations more useful. Applications may be able to retrieve CVE identifiers, advisory timestamps, source-code locations, and repository advisory links without relying on a separate REST request. The new filters are intended to narrow results on the server, rather than requiring clients to retrieve broad result sets and filter them locally.
What changed in the SecurityAdvisory API
According to GitHub’s changelog announcement, the SecurityAdvisory GraphQL object gained these fields:
cveId, which represents the advisory’s CVE identifier.sourceCodeLocation, which identifies affected source code relevant to the advisory.githubReviewedAt, which indicates when GitHub reviewed the advisory.nvdPublishedAt, which indicates when the National Vulnerability Database published its record.repositoryAdvisoryUrl, which links to the associated repository security advisory when one exists.
The securityAdvisories query also gained two filters: severities and isWithdrawn. These additions are intended to let clients request a narrower set of advisories directly from GitHub.
GitHub describes the changes as additive and read-only. Existing queries should continue to work, so the announcement does not require developers to rewrite queries simply to preserve existing behavior.
Why the additions matter to security integrations
Security automation often needs more than a title or identifier. The newly announced fields expose data that can help an integration connect an advisory to a CVE record, compare publication and review timing, locate affected source code, or send an operator to a related repository advisory.
The timestamp fields may also support workflows that compare when an advisory was published by the NVD with when GitHub reviewed it. That can help teams organize advisory triage and reporting, although GitHub’s announcement does not quantify any resulting improvement in latency, request volume, rate-limit usage, or operating cost.
The new filters are potentially useful for dashboards and scheduled jobs. A service concerned only with high-severity advisories, for example, may be able to express that requirement in the GraphQL request instead of downloading a larger collection and discarding unwanted records in application code. Similarly, the isWithdrawn filter may help workflows audit or exclude withdrawn advisories.
These are operational and data-access improvements. The change is not described as a vulnerability, security fix, exploit mitigation, or new security guarantee. The supplied announcement also does not establish new access-control or confidentiality behavior.
What is documented—and what is not
The GitHub GraphQL reference documents the security-advisory area, the securityAdvisories query, cursor-based pagination arguments, and the SecurityAdvisorySeverity enum. The documented enum values are CRITICAL, HIGH, LOW, MODERATE, and UNKNOWN.
However, the supplied GraphQL reference does not visibly list the five announced fields in its displayed SecurityAdvisory excerpt. It also does not show severities or isWithdrawn among the displayed securityAdvisories arguments. That creates an unresolved documentation or schema-availability discrepancy.
The discrepancy should not be treated as proof that the additions are unavailable. GitHub’s changelog says the additions were made, while the fetched reference text does not display them. Developers should therefore inspect the production schema and test the fields and arguments in their target environment before changing a production integration.
The supplied REST reference provides useful cross-API context. GitHub’s REST global advisories documentation describes corresponding concepts, including CVE ID, source-code location, GitHub review time, NVD publication time, repository advisory URL, severity values, and withdrawn-status filtering. That supports the general meaning of the data, but it does not establish the exact GraphQL scalar types, nullability, argument syntax, or runtime behavior.
Availability and compatibility considerations
The announcement was published on October 2, 2026. The supplied sources do not establish a staged rollout, regional availability, preview status, exact activation timing beyond the announcement, or support for GitHub Enterprise Server.
They also do not specify new authentication, account, permission, client-version, or API-version requirements. REST authentication behavior should not be generalized to these GraphQL additions. In particular, the REST documentation’s statement about unauthenticated access to public resources does not establish equivalent behavior for GraphQL.
Several implementation details remain undocumented in the supplied material, including whether each new field can be null, the precise GraphQL argument types, how missing values are returned, and how the new filters interact with pagination and existing query arguments. No complete migration query is provided by the available sources.
What you should do
- Review REST fallbacks. Identify advisory integrations that use REST only to obtain CVE data, source locations, timestamps, or repository advisory links. The announced GraphQL fields may provide an opportunity to simplify those workflows.
- Inspect the target GraphQL schema. Confirm that the five fields and two filters are present before deploying query changes. Do not infer availability solely from the announcement or from the absence of those items in the supplied reference excerpt.
- Test filter behavior. Validate the exact syntax and returned data for severity and withdrawn-status filtering, including how filtered results behave with cursor-based pagination.
- Handle missing data conservatively. Because nullability and field-specific response behavior are not documented in the supplied sources, clients should test advisory records with incomplete or unavailable values.
- Keep existing queries stable. GitHub characterizes the update as additive and read-only, so there is no stated need to change existing queries solely for compatibility.
For teams managing security-advisory data, the main opportunity is consolidation: more advisory context may become available through GraphQL, while server-side filters may reduce unnecessary result retrieval. The immediate next step is schema validation, since the supplied GraphQL reference does not yet visibly confirm the announced additions.
