There is currently no way, in the Security Update Guide or in the CVRF API, to tell whether a given CVE was published as part of the monthly Patch Tuesday release or outside of it. I'd like to request this be surfaced in both places: a column on the Vulnerabilities tab, and a corresponding release-type field per vulnerability in the CVRF document.
The motivation is that most organizations run separate vulnerability management processes: a continuous one for CVEs as they arrive, and a distinct monthly cycle for the Patch Tuesday release, with its own testing, change windows and approvals.
Routing a CVE into the right one requires knowing which release it belongs to, and that's precisely what isn't published. Without it, Patch Tuesday CVEs leak into the continuous process, where they get worked, ticketed and chased separately from the monthly cycle that was already going to remediate them. The result is duplicated effort, SLA clocks running against the wrong process, and reconciliation work every month to sort out what was actually handled where.
This isn't something each consumer can reliably derive. Every vulnerability management platform, internal patch tool and reporting pipeline ends up reimplementing second-Tuesday arithmetic plus product-name heuristics to reconstruct something MSRC already knows at publication time, and they don't agree with each other, which is why published CVE counts for a single month routinely vary by 20+ depending on which categories a given vendor chose to include.
The problem is:
The monthly CVRF document (yyyy-mmm) is a calendar-month bucket, not a Patch Tuesday bucket. Anything published between the 1st and the end of the month lands in the same document, so document membership doesn't answer "did this ship on Patch Tuesday?" The same is true of the month groupings in the Update Guide UI.
Today the only way to approximate it is client-side: compute the second Tuesday of the month, then compare it against the earliest entry in each Vulnerability.RevisionHistory. That's fragile, and it still can't distinguish between categories that happen to share a date. In a typical month the off-cycle population is dominated by three very different things:
- Edge/Chromium republications, which follow Chrome's release cadence and generally require no customer action.
- Cloud-service CVEs, published continuously for transparency after Microsoft has already remediated server-side.
- Genuine out-of-band fixes, which are rare and are the one category that actually needs to interrupt a patch cycle.
A proposal could be:
A release-type indicator per vulnerability, with values along the lines of monthly, out-of-band, third-party-republication, and cloud-service, exposed in two places:
- CVRF API as a new Note Type, or as a field on the vulnerability if that's cleaner.
- Security Update Guide as a column on the Vulnerabilities tab, filterable like the existing ones.
A plain yes/no field would solve the immediate routing problem, but the four values map onto genuinely different handling and cost the same to publish: monthly goes to the monthly cycle, out-of-band should trigger the continuous process immediately rather than waiting for the next window, and cloud-service belongs to neither, there is nothing to deploy, so it's a record-keeping entry for compliance and risk tracking. A yes/no view remains a trivial derivation from the enum for anyone who only needs the binary.
Thank you for understanding.
There is currently no way, in the Security Update Guide or in the CVRF API, to tell whether a given CVE was published as part of the monthly Patch Tuesday release or outside of it. I'd like to request this be surfaced in both places: a column on the Vulnerabilities tab, and a corresponding release-type field per vulnerability in the CVRF document.
The motivation is that most organizations run separate vulnerability management processes: a continuous one for CVEs as they arrive, and a distinct monthly cycle for the Patch Tuesday release, with its own testing, change windows and approvals.
Routing a CVE into the right one requires knowing which release it belongs to, and that's precisely what isn't published. Without it, Patch Tuesday CVEs leak into the continuous process, where they get worked, ticketed and chased separately from the monthly cycle that was already going to remediate them. The result is duplicated effort, SLA clocks running against the wrong process, and reconciliation work every month to sort out what was actually handled where.
This isn't something each consumer can reliably derive. Every vulnerability management platform, internal patch tool and reporting pipeline ends up reimplementing second-Tuesday arithmetic plus product-name heuristics to reconstruct something MSRC already knows at publication time, and they don't agree with each other, which is why published CVE counts for a single month routinely vary by 20+ depending on which categories a given vendor chose to include.
The problem is:
The monthly CVRF document (
yyyy-mmm) is a calendar-month bucket, not a Patch Tuesday bucket. Anything published between the 1st and the end of the month lands in the same document, so document membership doesn't answer "did this ship on Patch Tuesday?" The same is true of the month groupings in the Update Guide UI.Today the only way to approximate it is client-side: compute the second Tuesday of the month, then compare it against the earliest entry in each
Vulnerability.RevisionHistory. That's fragile, and it still can't distinguish between categories that happen to share a date. In a typical month the off-cycle population is dominated by three very different things:A proposal could be:
A release-type indicator per vulnerability, with values along the lines of
monthly,out-of-band,third-party-republication, andcloud-service, exposed in two places:A plain yes/no field would solve the immediate routing problem, but the four values map onto genuinely different handling and cost the same to publish:
monthlygoes to the monthly cycle,out-of-bandshould trigger the continuous process immediately rather than waiting for the next window, andcloud-servicebelongs to neither, there is nothing to deploy, so it's a record-keeping entry for compliance and risk tracking. A yes/no view remains a trivial derivation from the enum for anyone who only needs the binary.Thank you for understanding.