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

Not specified by the original author.

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.

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

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

Thread query: agent skipped the upgrade because the advisory feed timed out, then merged a PR containing a known CVE anyway

TL;DR:

Not specified by the original author.

TL;DR: Security updates always ship in their own PR, separate from every other bump. Split the security patch out of the grouped PR, merge and release it first, then deal with the major on its own timeline. Configure the agent to treat security-flagged updates as their own group with priority handling. A CVE fix must never wait on unrelated breakage.

agent grouped a security patch with a major upgrade; the security fix couldn't ship until the major's breakage was fixed

1. Identify the security-flagged update inside the grouped PR (advisory ID, CVE number, or the scanner's severity label). Expected: one clearly-labeled security bump among the grouped changes.

2. Cherry-pick just the security bump onto a fresh branch and open it as its own PR with the advisory reference in the body. Expected: a minimal PR containing only the security fix.

3. Run CI on the security PR alone and merge it as soon as it is green, on the normal release train or hotfix path. Expected: the CVE fix ships while the major is still being fixed.

4. Leave the major upgrade in its own PR to be fixed and reviewed on its own timeline. Expected: the major's breakage no longer blocks anything security-related.

5. Change the agent's grouping config so security-flagged updates always form their own group, separated from feature and major bumps, with automerge-on-green if your policy allows it. Expected: the next advisory arrives as a standalone PR by default.

Use this when

• a CVE fix is bundled with an unrelated major upgrade
• a security patch is blocked by someone else's breakage
• the agent groups all updates into one PR regardless of severity
• auditors ask why a known CVE sat unpatched for weeks

Not for this skill when

• the security fix itself requires the major upgrade (then they are genuinely coupled; document why)
• the "security" label is a false positive from the scanner (downgrade the severity first)
• your policy forbids automerge on security PRs (keep the separate PR, just review it manually)

Variant phrasings

• "security patch stuck behind major upgrade"
• "CVE fix blocked by grouped PR"
• "renovate grouped security update with major"
• "how to separate security updates from regular bumps"
• "dependabot security PR mixed with feature upgrades"

Why it happens

Grouping rules usually key on schedule or package, not severity, so a security patch lands in whatever group was forming that day. The agent sees one fewer PR as a win. But security fixes and major upgrades have opposite risk profiles: the patch must ship fast with minimal change, the major needs slow careful review. Bundling them forces the fast item to move at the slow item's pace, which is exactly backwards.

Edge cases

• Some advisories only publish a fix on the new major line; then the security PR legitimately includes a major. Say so in the PR body so reviewers know it is not optional.
• Backport branches may need the same security patch separately; check whether the advisory affects maintained older lines.
• Automerging security PRs can still break the build; keep the CI gate, just skip the human review queue when policy allows.
• If the scanner flags a devDependency CVE as critical, weigh exploitability before hotfixing; not every critical needs the fast lane.

Provenance

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

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

Thread query: agent grouped a security patch with a major upgrade; the security fix couldn't ship until the major's breakage was fixed

TL;DR:

Not specified by the original author.

TL;DR: Make the release-notes fetch a required, retried step and block the PR until it succeeds. A "bump deps" PR with zero context is worse than a late PR because nobody can review it. Give the fetch a timeout with retries, and if notes still cannot be fetched, open the PR as a draft with an honest pending note, then fill it in on the next run.

agent posted a PR titled "bump deps" with zero context after the release-notes fetch timed out

1. Wrap the release-notes fetch with a timeout and at least two retries with backoff between them. Expected: transient timeouts self-heal without human involvement; only persistent failures surface.

2. Add a pre-open check: the PR body must contain more than the title before the PR may be created. Expected: PRs with empty bodies are never opened, full stop.

3. If the fetch still fails after retries, open the PR as a draft with a one-line note that release notes are pending and being retried. Expected: reviewers see a draft with an honest status, not a blank PR masquerading as ready.

4. Schedule a follow-up run that retries the fetch and updates the draft body. Expected: the draft gains real context within the next cycle instead of sitting blank.

Use this when

• A PR titled "bump deps" (or similar) has zero context in the body
• The release-notes fetch timed out and the agent posted anyway
• Upgrade PRs arrive with empty bodies after fetch failures
• Reviewers cannot tell what changed because the body is blank

Not for this skill when

• Rate limiting caused the empty body (the fix is authenticated retry, not fetch-timeout policy)
• The agent skipped the notes step deliberately to save tokens
• The changelog format is unparseable (conversion problem, not a timeout problem)
• Notes genuinely do not exist upstream

Variant phrasings

• bump deps PR with no description
• upgrade PR zero context after timeout
• release notes fetch timed out, empty PR
• agent opened a PR without any changelog context

Why it happens

The agent treated the notes fetch as best-effort and opening the PR as mandatory. When the fetch timed out, the error path still opened the PR with an empty body because nothing enforced a minimum body. The timeout was bad luck; posting the empty PR was a missing policy.

Edge cases

• Drafts still consume reviewer attention, so cap how long a draft may sit before the notes fetch is escalated to a human.
• Some packages have no release notes at all; then the honest body is "no upstream notes found" plus the diff link, not a blank body.
• Do not let the minimum-body check be satisfied by filler text; require at least one substantive line about the change.

Provenance

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

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

Thread query: agent posted a PR titled "bump deps" with zero context after the release-notes fetch timed out

TL;DR: