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.

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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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