⚙️ This Week Was (Is*) a Vulnpocalypse. 3 Ways GRC Can Help.

Your security feeds spent the week reading like an incident channel. GitLab patched a CVSS 10 flaw reaching back to 2014, PHP shipped emergency fixes while the NSA advised taking unpatched systems offline, and a record Patch Tuesday was still being absorbed.

*Is, because it's still going as you read this.

That's fifteen headlines in ten days. Most came through a door someone had approved, and most of the breaches started with a stolen or long-lived credential.

The security team is the one living through this. GRC works on different things, like passing audits and holding the programme to its remediation timelines, and that's where it can help this week: compliance, third-party risk and the risk register.

Two numbers worth keeping

Microsoft's October 13 Patch Tuesday fixed more than 1,400 CVEs, a record. One of them, a Windows Shell Mark-of-the-Web bypass, was actively exploited, and CISA gave US federal agencies three days to fix it.

The second number comes from Google Threat Intelligence Group, reported by Help Net Security. Monthly vulnerability disclosures rose from 5,045 in January to 10,740 in August 2026.

Of all the vulnerabilities disclosed in 2026, only 0.23% were observed exploited in the wild. That is about one in 431.

Put the two numbers side by side, then look at your remediation SLA. Monthly disclosures more than doubled between January and August, and only a small share of them has been seen in use against anyone.

At this volume, a flat SLA for every critical will be missed, and every miss is risk you're carrying without a decision behind it.

GRC owns that SLA. If your policy says 14 days for every critical, it was probably set before monthly disclosures doubled.

This month, that SLA's evidence will mostly be a list of misses, and it won't tell anyone which miss was the exploited Patch Tuesday flaw. Rank by exploitation first, starting with CISA's Known Exploited Vulnerabilities list, and the SLA tracks the flaws that actually matter.

Your week, in one scroll

Official releases, package registries, a vendor's own app identity and a certificate authority are the channels your controls are built to trust. This month attackers came through several of them, and two more, a certificate authority and npm's publishing trust, turned out to be breakable.

The vulnpocalypse phrasebook

Every incident week produces the same sentences in the meetings GRC sits in. Keep this open for the ones you'll hear next week.

GRC can help in those meetings without running the patching, through three lanes it already owns.

From incident week to something the security team can use, one lane at a time.

Compliance: would your controls have seen it?

Start with the controls whose assets and scope match the components in this week's table. If PHP or Node.js runs inside your certification scope, some control already claims to cover it. In the infrastructure-as-code guide, I showed how a resource can vanish from drift detection while it keeps running, so check what runs as well as what the repo declares.

Then ask: would that control, as designed, have found this?

If your continuous control monitoring works, it should be showing you a failing control right now. The other possibility is that another team saw it first and fed it back to you.

If GRC learned last, ask two follow-up questions: should you have been aware, and is this something you need to track?

If you found out from Slack, the control didn't do its job.

In the issue on certification scope, I walked through a team shipping 100 times a day, where the auditor samples 25 of roughly 36,000 pull requests, about 0.07%, while the certification covers all of them. Weeks like this one are when you find out how the rest are doing.

Then do GRC's part, which sits one level up from the flaw: the commitments your programme has made.

Give back remediation timelines in the terms those framework commitments use. That means the vulnerability management control in your SOC 2 or ISO 27001 programme, and FedRAMP 20x if you run one. For each in-scope component, write one line: the finding, the SLA your policy commits to, the due date, and the exception if you will miss it.

TPRM: map your vendor exposure

When vendors have a week like this, think about every vendor you have, beyond the names in the table.

Check your own company first. Do you use any of these libraries, frameworks, languages or services directly? If the answer is yes, that component goes to your security team and back into the scope check from the compliance lane.

For vendors, check the subprocessor lists on their trust centres. Then read their DNS records to see which services they rely on, and work out from both whether you have exposure.

A verification record in TXT or a mail provider in MX shows some of the SaaS and hosting a vendor relies on before you send a single email. DNS won't show which runtime or package they run, which is what the outreach is for. It is the same habit as reading a config with a GRC question in hand.

# generic DNS check, example.com only
# TXT verification records and MX/CNAME targets often reveal which SaaS services a domain relies on
dig +short TXT example.com
dig +short MX example.com
dig +short CNAME status.example.com   # vendor subdomains like status or help are where CNAMEs show up

Then reach out. Weigh how strong the risk is by how much of your data each vendor holds and what access they have to your internal systems.

Decide the best way forward for each one. Ideally, build an automated way to run the outreach and triage the answers as they come back. Next time, you start from this list.

# illustrative vendor response triage
- vendor: vendor-a
  data_held: customer records
  internal_access: SSO app with directory read
  exposed_component: Node.js
  response: mitigated
  follow_up_by: 2026-10-29
- vendor: vendor-b
  data_held: marketing contacts
  internal_access: none
  exposed_component: PHP
  response: patched
  follow_up_by: none
- vendor: vendor-c
  data_held: source code
  internal_access: CI integration
  exposed_component: LiteLLM
  response: no_response
  follow_up_by: 2026-10-23
- vendor: vendor-d
  data_held: support tickets
  internal_access: Microsoft 365 app identity
  exposed_component: none found
  response: not_affected
  follow_up_by: 2026-10-29   # verify: same access path as this week's app-identity incident

Then read the replies as a set. Count who answered and who didn't, who said they mitigated, who said they patched and who said they had acted before the news broke.

Chase the vendors with internal access who haven't answered first. A patched from a vendor holding marketing data can wait.

Risk: the dependency you cannot hot-patch

Look for one scenario in your register. A core dependency used by software in production carries a critical vulnerability, and you cannot hot-patch it fast.

Sometimes the patch exists and still needs proper regression testing before it ships. A language runtime like PHP or Node.js is the example from this week's table.

You need to understand that scenario and have it in the register, with an owner, the interim mitigation and the date the decision gets revisited.

At one in 431, much of the queue can wait. The few flaws that cannot wait and also cannot be patched quickly are the risk register's job. Every interim mitigation on them needs an expiry, either a date or an exposure trigger.

In the risk register issue, I wrote that every row in a register is a photograph of its inputs on one date. This week changed that photograph for any row that depends on PHP or Node.js.

Writing the scenario down is the easy part. Getting it fixed is where GRC's stakeholder management helps the security team most.

Security has to collaborate with many stakeholders to get a remediation moving. GRC can open those doors for them.

You know the right point of contact in each team and who is most likely to get a change through. You also know who has been the security team's biggest ally in the past.

In the vendor dinners issue, I argued that the biggest security decisions still run on gut feel, vendor dinners and whatever leadership read last week. Knowing who actually says yes is how you work with that.

You've built those relationships over the years. This is the week to use them to turn a register entry into a fix in production.

Your security team knows what needs fixing. You can tell them who will get it through.

For the runtime scenario, the list can be this short:

Hand that table to your security team before they need it, and make the introduction to the ally yourself.

Your starter toolkit

Before the next one

You don't need the whole playbook this week. Pick the lane where your programme is weakest and do that one before next Thursday.

Try this week

• Compliance: pick the control whose scope covers one component in the table and check whether it would have flagged it.

• TPRM: list your vendors with the most internal access and check their subprocessor lists for this week's names.

• Risk: write the scenario for one production dependency you could not patch within your SLA without regression testing.

• Risk: name the people who can get one remediation moving fastest, and introduce your security team to them.

Reply with the phrase you heard most this week haha.

Ayoub