GitHub’s update can give organisations a more coherent route to advisory data for internal software-risk reporting. It may reduce the need to combine GraphQL and REST calls for the newly exposed information, but it does not by itself improve security decisions, prioritisation or accountability.
What changed
GitHub has added five fields to the SecurityAdvisory GraphQL object: a CVE identifier, a relevant source-code location, the time GitHub reviewed an advisory, the time the National Vulnerability Database published its record, and a linked repository advisory URL where one exists. The securityAdvisories query can also filter results by severity and withdrawn status. GitHub describes the changes as additive and read-only, meaning existing queries should continue to work.
Why this matters to reporting teams
For organisations that already use GitHub advisory data, the change may make it easier to align technical feeds with management reporting. Severity filtering can support views focused on the risk levels a business has chosen to monitor, while withdrawn-status data can help prevent a report from treating superseded or withdrawn information as an open issue.
The added timestamps may also improve the context around an advisory. A report can distinguish between external publication and GitHub review timing, rather than presenting a single date as though it represented the whole lifecycle. That distinction is useful for operational discussions, but it should not be mistaken for a measure of exposure, remediation quality or business impact.
The business decision is about reporting quality, not merely API access
A simpler data path can reduce friction in an integration, particularly where a team previously needed separate API approaches for related advisory information. However, reducing requests or consolidating authentication does not automatically make a dashboard more trustworthy. The value depends on whether the resulting information answers a defined business question and has a clear owner.
- Which audiences need advisory information: engineering teams, product leaders, operational leadership or supplier-risk reviewers.
- Whether severity is sufficient for prioritisation, or whether the organisation also needs context about affected products, ownership and business criticality.
- How withdrawn advisories will be labelled and treated in historic reporting, trend views and management summaries.
- Which timestamps are meaningful for internal review, and what conclusions should not be drawn from them.
- Who is accountable for reviewing exceptions, data gaps and changes to reporting logic.
Avoid misleading signals
Severity-based feeds can be useful for focus, yet severity is not a complete risk decision. A high-severity advisory may have limited relevance to a particular product, while a lower-severity issue may matter more in a business-critical context. Similarly, a source-code link or CVE identifier improves traceability but does not establish that an organisation’s own software is affected.
What a good outcome looks like
The strongest outcome is a reporting view that makes the status and provenance of advisory information understandable, separates external advisory signals from internal exposure decisions, and directs attention to the risks that matter to the organisation. Teams should be able to explain what a figure represents, what it excludes and who acts on it.
For organisations planning to revise dashboards or software-risk workflows, professional implementation is appropriate where advisory data needs to be connected to a broader product, operational or governance view. The priority is a dependable decision product, rather than simply displaying more API fields.
OUROPT can help teams assess how advisory data should support product and web application risk reporting, then design the reporting experience around clear ownership and decision-making needs.
Explore our services →Sources and references
- New fields for SecurityAdvisory GraphQL APIGitHub Changelog · 2 October 2026