How do I install the Closing The Patch Gap skill?

Run npx skillmds@latest add uygnoey/closing-the-patch-gap in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Closing The Patch Gap safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Closing The Patch Gap?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Closing The Patch Gap free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Closing The Patch Gap?

uygnoey (@uygnoey) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Closing The Patch Gap by uygnoey — Agent Skill

Name: Closing The Patch Gap
Author: uygnoey

Closing The Patch Gap

Prioritizes and operationalizes software patching for an environment where AI models quickly reverse patches into exploits. Use when planning patch policy, reducing time-to-patch on internet-exposed systems, triaging large CVE backlogs with KEV and EPSS, or rolling out automated patch deployment.

uygnoey Updated Sep 21, 2026

File contents

Closing the patch gap

Applies the post's "close your patch gap" discipline as a reusable, prioritized rollout pattern. The goal is to shrink the window between a patch being published and an exploit being usable against your systems, given that AI can reliably reverse patches into working exploits.

Instructions

Treat the CISA KEV catalog as non-negotiable. Any vulnerability on the CISA Known Exploited Vulnerabilities catalog that is reachable from a network is an emergency. Patch these immediately, above every other security queue.
Prioritize the remainder with EPSS. Use the Exploit Prediction Scoring System to rank open CVEs by the daily-updated probability that they will be exploited in the next 30 days. Choose an EPSS threshold for "must patch soon" and apply it to everything not already on KEV.
Set explicit time-to-patch targets. Internet-facing applications: within 24 hours of an exploit becoming available. Other systems: within days of a patch being available.
Automate patch deployment and reboots where the risk of an automated update causing an outage is acceptable. Manual approval steps add delay, and delay is now the primary risk.
Use vendor-shipped automation first. Most cloud and OS vendors ship patch automation; enabling it is typically a single configuration change.
Wire KEV/EPSS metadata into CI. Run an open-source container-image or dependency-manifest scanner as a CI step and annotate CVEs with KEV and EPSS data so prioritization is automatic.
Define an emergency change procedure in advance. Decide, ahead of time, who can authorize an emergency patch rollout, a service take-down, a credential rotation, or a network block, and how fast. A two-week change-approval cycle for emergency patches is itself a security risk.
Measure outcomes, not activity. Track time-to-patch on internet-facing systems and time-to-patch on KEV entries. If either is sliding, your queue discipline is degrading regardless of how busy the patching team looks.

Examples

Queue for a typical Monday morning (ordered):

Any CVE newly added to KEV affecting a network-reachable asset → page the on-call patching role immediately.
CVEs above the chosen EPSS threshold on internet-facing services → assign a 24-hour SLA.
Remaining CVEs above EPSS threshold on internal systems → several-day SLA.
Everything below EPSS threshold → queued for the next routine cycle.

Example CI annotation output on a container image scan:

CVE-2026-10492 [KEV] [EPSS 0.97] → patch now; network-reachable
CVE-2026-10110 [EPSS 0.41] → patch within week; internal only
CVE-2024-99887 [EPSS 0.02] → backlog

Anti-patterns

Manual approval chains gating emergency patches — they turn "patch published" into "patch exploited before it lands".
Relying on CVSS severity alone; CVSS does not reflect active exploitation like KEV and EPSS do.
Patching on a fixed monthly cadence regardless of KEV additions.

Source

Distilled from Preparing your security program for AI-accelerated offense (published 2026-04-10).

---name: closing-the-patch-gapdescription: Prioritizes and operationalizes software patching for an environment where AI models quickly reverse patches into exploits. Use when planning patch policy, reducing time-to-patch on internet-exposed systems, triaging large CVE backlogs with KEV and EPSS, or rolling out automated patch deployment.---# Closing the patch gapApplies the post's "close your patch gap" discipline as a reusable, prioritized rollout pattern. The goal is to shrink the window between a patch being published and an exploit being usable against your systems, given that AI can reliably reverse patches into working exploits.## Instructions1. **Treat the CISA KEV catalog as non-negotiable.** Any vulnerability on the CISA Known Exploited Vulnerabilities catalog that is reachable from a network is an emergency. Patch these immediately, above every other security queue.2. **Prioritize the remainder with EPSS.** Use the Exploit Prediction Scoring System to rank open CVEs by the daily-updated probability that they will be exploited in the next 30 days. Choose an EPSS threshold for "must patch soon" and apply it to everything not already on KEV.3. **Set explicit time-to-patch targets.** Internet-facing applications: within 24 hours of an exploit becoming available. Other systems: within days of a patch being available.4. **Automate patch deployment and reboots** where the risk of an automated update causing an outage is acceptable. Manual approval steps add delay, and delay is now the primary risk.5. **Use vendor-shipped automation first.** Most cloud and OS vendors ship patch automation; enabling it is typically a single configuration change.6. **Wire KEV/EPSS metadata into CI.** Run an open-source container-image or dependency-manifest scanner as a CI step and annotate CVEs with KEV and EPSS data so prioritization is automatic.7. **Define an emergency change procedure in advance.** Decide, ahead of time, who can authorize an emergency patch rollout, a service take-down, a credential rotation, or a network block, and how fast. A two-week change-approval cycle for emergency patches is itself a security risk.8. **Measure outcomes, not activity.** Track time-to-patch on internet-facing systems and time-to-patch on KEV entries. If either is sliding, your queue discipline is degrading regardless of how busy the patching team looks.## ExamplesQueue for a typical Monday morning (ordered):1. Any CVE newly added to KEV affecting a network-reachable asset → page the on-call patching role immediately.2. CVEs above the chosen EPSS threshold on internet-facing services → assign a 24-hour SLA.3. Remaining CVEs above EPSS threshold on internal systems → several-day SLA.4. Everything below EPSS threshold → queued for the next routine cycle.Example CI annotation output on a container image scan:```CVE-2026-10492 [KEV] [EPSS 0.97] → patch now; network-reachableCVE-2026-10110 [EPSS 0.41] → patch within week; internal onlyCVE-2024-99887 [EPSS 0.02] → backlog```## Anti-patterns- Manual approval chains gating emergency patches — they turn "patch published" into "patch exploited before it lands".- Relying on CVSS severity alone; CVSS does not reflect active exploitation like KEV and EPSS do.- Patching on a fixed monthly cadence regardless of KEV additions.## SourceDistilled from [Preparing your security program for AI-accelerated offense](https://claude.com/blog/preparing-your-security-program-for-ai-accelerated-offense) (published 2026-04-10).

Frequently asked questions