When VulnOps Meets the Vendor Blind Spot: Why Post-Mythos Modernization Needs to Include TPRM

The security world has a new focus: VulnOps. In response to Mythos, Daybreak, and the other frontier models that are sure to follow, organizations are racing to build permanent vulnerability operations functions that combine vulnerability management with more robust automation.

The need for this discipline was always there. But now that AI can discover and help weaponize vulnerabilities at machine speed, the old quarterly-scan-and-patch approach is becoming less viable.

The problem is that most VulnOps conversations focus on internally managed systems. Meanwhile, a significant share of an organization’s actual risk sits outside its own infrastructure, in the software and services it buys from third parties.

TPRM programs are the closest thing organizations have to coverage here. But they were not built for this, at least not in a way that matches how VulnOps needs to work.

If organizations want to get the full value from their VulnOps investments, they need to modernize how they think about third-party risk. That means bringing third-party risk management into the same operational rhythm.

VulnOps as a Mythos-ready strategy

VulnOps may be a new label, but the underlying idea is not. Security teams have been moving toward continuous, intelligence-driven vulnerability management for years. What has changed is the sense of urgency driven by frontier AI models. And, of course, the catchy new name.

“VulnOps” was coined in October 2025 by Heather Adkins, Gadi Evron, and Bruce Schneier, a month after they issued an industry warning that AI-led vulnerability discovery had reached an inflection point. As they framed it, VulnOps should not be a project or a quarterly exercise. It should be a permanent, continuously staffed organizational function.

This April, the Cloud Security Alliance (CSA) released an emergency strategy briefing titled "The AI Vulnerability Storm: Building a Mythos-Ready Security Program,” which calls on organizations to stand up a permanent VulnOps function within 12 months.

The message was clear: point-in-time assessments can't keep pace with AI-accelerated vulnerability discovery. 

The CSA briefing defines VulnOps around four core principles.

The CSA briefing also makes clear that VulnOps shouldn't stop with first-party software. It specifically calls for stronger dependency management to reduce vulnerabilities in third-party components and for vendor governance that can keep pace with AI-accelerated threat timelines.

What it does not spell out is how that third-party work gets done. The briefing establishes the mandate but leaves implementation to practitioners. That is where many organizations get stuck, because extending VulnOps to the vendor ecosystem requires them to rethink how TPRM works in practice.

The TPRM-VulnOps mismatch

Most TPRM programs today are not built to operate at VulnOps speed.

Looking at them through the lens of the NIST Cybersecurity Framework helps explain why. Traditional TPRM work is concentrated in governance, identification, and protection. The tasks most people associate with third-party risk management are front-end activities such as building vendor inventories, running risk assessments, collecting questionnaires, and validating controls.

All of those activities are important for governance, but they do not necessarily change the resilience outcome when an organization needs to act. When a vendor is compromised, this work alone does not tell the organization what to do next.

Security leaders should think about it as an investment portfolio problem. Most TPRM spending goes toward identifying and assessing risk. Far less goes toward detecting changes, responding to incidents, or supporting recovery.

That is where investment needs to increase if organizations want to reduce the risk created by Mythos-level exploitation speed.

An internal team may be able to patch a critical vulnerability in days, but that same organization may have no idea whether a key vendor is running unpatched infrastructure or whether the vendor’s credentials appeared for sale on a dark web forum last week.

Most organizations do not have enough third-party visibility to tell them what requires action right now.

And the risk does not stop with direct vendors. There is a compounding effect when it comes to nth-party exposure. Concentration risk extends beyond immediate relationships and tier-one vendors into the organizations and technologies behind them.

VulnOps shows what is possible when vulnerability management operates continuously. TPRM now needs the same upgrade.

TPRMOps? How things need to change

Call it TPRMOps, or just call it modern third-party risk management. The label matters less than the work: synchronizing TPRM workflows with the operational cadence of VulnOps.

Getting there requires programs to expand how they monitor, prioritize, and act on vendor risk. Here's what that looks like in practice.

Continuous monitoring has become the baseline

Point-in-time assessments cannot keep up when exploitation timelines compress from weeks to hours. Organizations need always-on visibility into vendor security posture.

When a vendor's exposure level changes, that signal should trigger a workflow. It should not wait for the next quarterly review.

Bitsight's 2025 State of Cyber Risk and Exposure Report found that continuous monitoring moved from the number-seven investment priority to number one among security leaders surveyed. The Mythos moment is reinforcing why.

What matters is what you monitor. To truly align TPRM to VulnOps, organizations need to address the full risk lifecycle across the vendor ecosystem:

• Govern: Define ownership, risk tolerance, escalation thresholds, and vendor security expectations.
• Identify: Use continuous external asset discovery and technology-stack fingerprinting, not just annual questionnaires.
• Protect: Connect compliance evidence and control validation with current threat posture.
• Detect: Monitor dark web activity, security rating alerts, leaked credentials, and exploit intelligence tied to vendor exposures.
• Respond: Establish escalation workflows, rapid access restrictions, and proactive vendor outreach when threat signals increase.
• Recover: Revalidate vendor posture after an incident and feed lessons back into vendor tiering and oversight.

Making this work will require changes to both the intelligence TPRM teams consume and the way they prioritize what they see.

Cyber threat intelligence needs to become a first-class input

TPRM teams have historically relied on questionnaires and attestations. But questionnaires cannot tell you that a vendor's admin credentials showed up for sale on a criminal forum last Thursday. They cannot tell you that threat actors are discussing a vendor’s unpatched infrastructure as a target. And they cannot alert you when ransomware groups shift their attention toward a sector where critical vendors operate.

The same threat intelligence that informs internal VulnOps should inform vendor risk decisions.

Ideally, TPRM programs should be able to use signals that show when a CVE affecting a vendor is being actively weaponized. Most TPRM programs do not have direct access to that intelligence today, and when they do, they are often waiting for SOC teams to pass it downstream.

That handoff creates delay. TPRM teams need access to threat intelligence configured around their specific vendor portfolio. That means connecting threat signals with vendor criticality, business context, and the workflows needed to act.

Prioritization has to shift from severity to exploitability

Traditional TPRM prioritizes vendor risk by tier, contract value, business criticality, or raw severity scores. Those factors still matter. But VulnOps-informed TPRM adds a more immediate question: which vulnerabilities are actually being exploited, or are most likely to be exploited next?

Many TPRM and exposure management programs struggle to answer that question because they remain anchored to CVSS scores. CVSS measures severity, or the potential impact if a vulnerability is exploited. But only a small percentage of vulnerabilities are ever exploited in practice, and closing that gap requires a different kind of signal.

Bitsight’s Dynamic Vulnerability Exploit score was built to help address that problem. DVE synthesizes threat actor chatter, exploit availability, malware toolkit updates, and attack behavior trends to estimate exploitation likelihood up to 90 days out.

A vulnerability with a CVSS of 10.0 and a DVE of 2.1 may be serious but not currently seeing meaningful attacker activity. A vulnerability with a CVSS of 7.4 and a DVE of 9.1 may be the more urgent problem.

Applied to third-party exposure, this changes what gets prioritized and when. It also changes the conversation with vendors. When DVE scores rise for a CVE affecting a vendor’s technology stack, TPRM teams can reach out proactively, before exploitation becomes widespread or the next assessment cycle begins.

That is a fundamentally different posture from waiting for the next questionnaire.

Use the Mythos effect to your advantage

Mythos did not create new problems. It compressed the timelines around existing ones.

The organizations that adapt fastest will be those that extend proven VulnOps principles to their vendor ecosystems.

The good news is that Mythos is also creating budget conversations that may not have happened otherwise. Organizations have an opportunity to invest in capabilities that improve visibility, prioritization, and response.

TPRM modernization should be part of that discussion.

VulnOps cannot stop at the enterprise boundary. Third-party risk needs to move at the same speed.