TL;DR: Never treat a failed security check as a pass. If the advisory feed times out, the upgrade run must block or retry - it must not proceed to merge. Quarantine the merged PR, check whether the CVE is reachable in your tree, remediate, and add a hard fail-closed rule: no advisory result, no merge.

```text
agent skipped the upgrade because the advisory feed timed out, then merged a PR containing a known CVE anyway
```

1. Confirm exposure: with the feed back up, audit the merged tree (`npm audit`, `pip audit`, or your ecosystem's equivalent). Expected: confirms whether the vulnerable package and version are actually in the dependency tree.
2. Assess reachability: trace whether the vulnerable code path is called by your application. Expected: a yes-or-no answer with the call chain, which sets the severity.
3. If reachable (or unsure), ship the fixed version immediately - upgrade or patch release. Expected: the lockfile no longer contains the vulnerable version and a fresh audit is clean.
4. Change the agent policy: advisory-feed timeout becomes a run failure, not a skip. Implement retries with backoff, then block the merge and alert a human. Expected: a simulated feed outage marks the run failed - it never merges.
5. Add an independent pre-merge gate: re-run the advisory check as a required CI check outside the agent's control. Expected: even if the agent skips its own check, CI blocks the merge.

## Use this when
- An agent skipped a security step after a timeout and merged anyway
- A known CVE shipped because a check was bypassed
- You need fail-closed policy for advisory checks
- A post-merge audit finds a CVE the pre-merge check should have caught

## Not for this skill when
- The advisory was checked and judged not applicable - that is triage, a different topic
- No fixed version exists for the CVE yet
- The issue is a stale database rather than a skipped check (see the stale advisory database skill)

## Variant phrasings
- Agent merged PR with known CVE after advisory timeout
- Security check skipped on timeout
- Fail-open advisory feed
- Merged without advisory result

## Why it happens
The agent's control flow treats the advisory step as informational: on timeout it logs a warning and continues the pipeline, and the merge step has no idea the check never completed. Fail-open defaults turn a transient outage into a shipped vulnerability - the pipeline optimizes for finishing the run, not for the security invariant.

## Edge cases
- The feed can be stale rather than down - pair this with a freshness bound on the advisory database
- Private registries need their own advisory source configured, or every check "times out" and blocks everything
- Rate-limited feeds need a cached fallback with a freshness bound, not a silent skip

## Provenance

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