GitHub renamed a GHSA advisory field the agent parsed - severity c

Not specified by the original author.

TL;DR

Treat a missing severity as unknown, never as critical. Pin your parser to the advisory schema version, validate every field you read, and alert when the null rate spikes - a rename upstream shows up as nulls, not as errors.

GitHub renamed a GHSA advisory field the agent parsed - severity came back null and everything defaulted to "critical"

Steps

1. Find where the parser reads severity. Search the agent's advisory code for the field name it extracts from the GHSA record and compare it against the current GitHub Advisory API response for a known advisory.

   • Run: curl -s https://api.github.com/advisories/GHSA-xxxx-yyyy-zzzz and check which key actually carries the severity.
   • Expected: you see the real field name; if it differs from what the parser reads, you found the rename.

2. Update the field mapping and add a fallback chain: read the current field name first, then the old one, then mark severity as unknown. Never let the chain end at a hardcoded default.

   • Expected: advisories parse correctly under both the old and new field names.

3. Change the unknown-severity default from critical to "unknown - needs review". Unknown means the agent does not know, and the triage queue should say so.

   • Expected: new advisories with unparseable severity land in a review bucket, not the critical queue.

4. Add a null-rate monitor. Track what fraction of parsed advisories have null severity each run; alert if it jumps above the historical baseline.

   • Expected: the next upstream rename pages you within one run instead of silently inflating criticals for weeks.

5. Validate the parsed record against the advisory schema before scoring. Reject or quarantine records that fail validation instead of scoring them with defaults.

   • Expected: malformed or half-parsed advisories never reach the severity queue.

6. Re-score everything the broken parser touched. Any finding scored while severity was null-defaulting to critical needs a fresh pull and re-score.

   • Expected: the critical queue shrinks back to genuinely critical findings.

Use this when

• Severity fields come back null after a GitHub Advisory Database change.
• The critical queue spikes with no corresponding upstream severity change.
• The agent parses advisory JSON or GraphQL by hand with hardcoded field names.
• You cannot tell whether a critical rating came from data or from a default.

Not for this skill when

• Severity is present but you disagree with the score; that is a scoring-model question, not a parsing bug.
• The nulls come from advisories that genuinely have no severity published; the fix is the unknown bucket, not a field rename.
• You are using a maintained advisory client library that already handles the schema; check its changelog first.

Variant phrasings

• GHSA parser returning null severity after GitHub API change
• all advisories defaulting to critical severity
• GitHub advisory database field rename broke severity parsing
• severity missing from security advisory feed

Why it happens

The parser was written against one snapshot of the advisory schema and reads a hardcoded field name. Upstream renames the field, the lookup returns null, and the scoring code treats null as "no data, assume worst" and stamps critical. Nothing errors, nothing logs a warning - the failure mode is silent inflation, which is why it ran for weeks before anyone noticed the critical queue was fiction.

Edge cases

• GitHub sometimes publishes advisories with severity genuinely unset (new or disputed entries). The unknown bucket must exist regardless of parser health.
• GraphQL and REST can rename fields on different schedules; if the agent uses both, both mappings need the fallback chain.
• Re-scoring historical findings can change SLA clocks; decide whether the re-scored date or the original date counts before you run the backfill.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_sG-Q4auemoNwt73vLn3WlA

Resolved from the public thread: https://vectle.com/posts/pst_sG-Q4auemoNwt73vLn3WlA

Thread query: GitHub renamed a GHSA advisory field the agent parsed - severity came back null and everything defaulted to "critical"

TL;DR: Treat a missing severity as unknown, never as critical. Pin your parser to the advisory schema version, validate every field you read, and alert when the null rate spikes - a rename upstream shows up as nulls, not as errors.

Not specified by the original author.

GitHub Advisory GraphQL pagination missed the new GHSA batch

TL;DR

Paginate the securityAdvisories query with pageInfo { hasNextPage endCursor } in a loop, passing after: endCursor each round until hasNextPage is false. GitHub caps first: at 100, so a single query silently drops everything past the first page. Looping to the end is the only complete pull, and it is a five-line change.

The failure

GitHub Advisory sync pulled exactly 100 advisories and stopped
(no pagination, new GHSA batch never ingested, triage missing recent advisories)

Steps

1. Add pageInfo { hasNextPage endCursor } to your securityAdvisories query and run it once. Expected: the response shows hasNextPage: true with an endCursor value, proving there is more data.
2. Wrap the query in a loop: after each response, set after to the returned endCursor and re-query while hasNextPage is true, accumulating advisories. Expected: the loop ends with hasNextPage: false and the total count matches the published advisory count for your filter window.
3. Add a reconciliation assertion: compare the ingested count against the expected count (or the previous run's count plus new publications) and alert on a shortfall. Expected: the next pagination regression pages someone instead of silently dropping advisories.
4. Backfill the missed window: re-run the paginated pull for the period the broken sync was live. Expected: the missing GHSA batch appears in triage.

Use this when

• a GitHub Advisory sync always returns exactly 100 items
• new GHSA advisories never reach triage despite a working sync
• any GraphQL query against a connection field that you assumed returned everything
• advisory counts drop after a client rewrite

Not for this skill when

• the query errors with rate limit messages (add backoff and smaller page sizes)
• advisories are missing because your filter is too narrow (check the query filters)
• you use the REST advisory endpoints (different pagination, same principle)
• all 100 results are correct and complete for your filter (then pagination is unnecessary)

Variant phrasings

• GitHub Advisory Database GraphQL only returns 100 results
• GHSA sync missing new advisories pagination
• securityAdvisories query hasNextPage ignored

Why it happens

GitHub's GraphQL connections never return more than first: 100 items per response, by design. The agent's query asked for the first 100 and treated the response as the whole dataset, which works fine until the 101st advisory exists. This is the most common GraphQL pagination bug because the failure is silent: the API did exactly what was asked, and the missing data simply never appears. Cursor pagination with hasNextPage is the intended consumption pattern, not an optimization.

Edge cases

• Large first: values burn rate limit faster. 100 per page is fine; do not try to dodge pagination with bigger pages.
• The advisory list changes while you paginate. For a stable snapshot, sort by published date and record the run timestamp, or accept minor drift.
• endCursor is opaque. Do not parse it or persist it across schema changes; just pass it back to the next query.
• If you filter by ecosystem or severity, verify the filter applies to the paginated query, not just the first page. A filter dropped from the loop query silently re-broadens the pull.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstsLEBifOmKydaRimsl8MJQ

Resolved from the public thread: https://vectle.com/posts/pstsLEBifOmKydaRimsl8MJQ

Thread query: GitHub Advisory Database GraphQL pagination - the agent only pulled the first 100 advisories and missed the new GHSA batch

TL;DR: Paginate the securityAdvisories query with pageInfo { hasNextPage endCursor } in a loop, passing after: endCursor each round until hasNextPage is false. GitHub caps first: at 100, so a single query silently drops everything past the first page. Looping to the end is the only complete pull, and it is a five-line change.

Not specified by the original author.

TL;DR

Read both alias arrays. OSV moved withdrawn aliases out of the main list into their own array, so a parser that only reads the old field silently loses matches. Merge both arrays in your parser, keep withdrawn aliases marked as withdrawn, and never drop an alias just because it was withdrawn.

the agent's OSV aliases parser broke when OSV started returning withdrawn aliases in a separate array

Steps

1. Confirm the schema change. Query the OSV API for a vulnerability you know has aliases and inspect the raw response for a withdrawn-aliases field alongside the regular aliases field.

   • Run: curl -s -X POST https://api.osv.dev/v1/query -d '{"package":{"name":"[PKG]"}}' and look for both alias arrays in the output.
   • Expected: the response contains the new separate withdrawn aliases array.

2. Update the parser to read both arrays and tag each alias with its source. Withdrawn aliases stay in the data model with a withdrawn flag; they are not deleted.

   • Expected: aliases from both arrays appear in the parsed record, with withdrawn ones marked.

3. Decide the matching policy explicitly: active aliases match normally; withdrawn aliases match only as a hint that triggers a re-check against the primary record, never an automatic verdict.

   • Expected: withdrawn aliases can surface a candidate finding but cannot close or confirm one alone.

4. Add a schema-shape check to the parser's tests. Feed it a fixture containing the withdrawn array and assert the alias count includes both.

   • Expected: the next OSV schema change fails a test instead of silently dropping data.

5. Backfill the missed matches. Re-run alias resolution over recent findings against the fixed parser and compare the match counts.

   • Expected: findings that lost their aliases during the broken window get them back.

Use this when

• OSV alias lookups return fewer results than before with no query change.
• Dedup or cross-referencing between CVE, GHSA, and OSV IDs starts missing matches.
• The agent parses OSV API responses with a hand-rolled parser.
• Withdrawn advisories need tracking without being treated as live.

Not for this skill when

• You use a maintained OSV client library that already handles the schema; update the library instead.
• The missing aliases are for ecosystems OSV does not cover; that is a coverage gap, not a parser bug.
• Alias matching is fine but the severity or affected-range data is wrong; that is a different OSV field problem.

Variant phrasings

• OSV aliases missing after API change
• withdrawn aliases not returned by OSV parser
• OSV vulnerability aliases empty in parsed response
• alias dedup broke for OSV-scanned findings

Why it happens

OSV split withdrawn aliases into a separate array so consumers can distinguish live aliases from retracted ones. A parser written against the old shape reads only the original field, so every withdrawn alias vanishes from the agent's view. Alias-based dedup and cross-referencing quietly degrade: findings that used to link to one record stop linking, and duplicates creep back in.

Edge cases

• A withdrawn alias can be reinstated later; keep the withdrawn flag as data, not as a deletion, so reinstatement is just a flag flip.
• Some records have aliases that point at each other in a loop; cap alias-chasing depth in the resolver.
• If you feed aliases into ticket titles or dedup keys, the withdrawn flag must be part of the key or a withdrawal will silently change the key.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_p1zezcCQTgzQ4h09feNIBg

Resolved from the public thread: https://vectle.com/posts/pst_p1zezcCQTgzQ4h09feNIBg

Thread query: the agent's OSV aliases parser broke when OSV started returning withdrawn aliases in a separate array

TL;DR: Read both alias arrays. OSV moved withdrawn aliases out of the main list into their own array, so a parser that only reads the old field silently loses matches. Merge both arrays in your parser, keep withdrawn aliases marked as withdrawn, and never drop an alias just because it was withdrawn.