GitHub has expanded the SecurityAdvisory object in its GraphQL API with five new read‑only fields and introduced two additional server‑side filters on the securityAdvisories query. This change lets AI, cloud, DevOps, and security engineers retrieve richer advisory data without falling back to the REST API, cutting request overhead and simplifying downstream processing.
New fields on SecurityAdvisory
- cveId: the advisory’s CVE identifier, enabling direct correlation with external vulnerability feeds.
- sourceCodeLocation: a URL pointing to the affected source code, useful for automated code‑review tooling.
- githubReviewedAt: timestamp of GitHub’s internal review, providing a reference point for internal triage timelines.
- nvdPublishedAt: timestamp when the National Vulnerability Database published the record, allowing measurement of lag between public disclosure and GitHub review.
- repositoryAdvisoryUrl: link to a repository‑specific security advisory when one exists, supporting per‑repo audit workflows.
Server‑side filtering improvements
The securityAdvisories query now accepts severities and isWithdrawn arguments. These filters can be combined with existing ones such as classification, identifier, epss, and date‑range filters. By narrowing results on the server, callers avoid downloading the full advisory set and performing client‑side pruning.
Operational impact
- Fewer HTTP round trips: a single GraphQL request can replace a REST call plus additional filtering logic.
- Unified authentication and rate‑limit consumption: one token and one rate‑limit bucket cover the entire advisory fetch.
- Simpler pipeline design: downstream services can request only the fields they need, reducing payload size and parsing effort.
- Enables new automation patterns such as severity‑based triage feeds, withdrawn‑advisory audits, and latency tracking from NVD publication to GitHub review.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
Update existing GraphQL queries to include the new fields where relevant, and replace any REST‑based advisory lookups with the enriched GraphQL endpoint. Leverage the severities and isWithdrawn filters to offload selection logic to GitHub, conserving rate‑limit headroom and reducing client‑side processing. Consider using githubReviewedAt and nvdPublishedAt timestamps to build internal SLAs around vulnerability response times. Finally, monitor your GraphQL usage to ensure the single‑endpoint approach aligns with your rate‑limit budgeting and authentication strategy.
