When Cloudflare pointed Mythos at their own infrastructure, one particular finding stood out: the model's ability to chain several low-severity vulnerabilities together into a single, larger exploit. Findings that you would have safely deprioritized under any standard triage model suddenly became something else entirely.
This means you can no longer look at a severity score and make a confident call. The question every security team now needs to answer when a vulnerability drops is both "how serious is this?" and, more importantly, "are we exposed?" And according to Mandiant's M-Trends 2026, with mean time to exploit now at negative seven days, how fast you can answer that question is paramount to strong security posture.
Here's how to think about measuring it, and how we built an App in Tines to do exactly that.
Why the old model is broken
In 2025, roughly 50,000 CVEs were published - that’s 130 new vulnerabilities every single day. Mythos and tools like it are accelerating discovery further, but the more unsettling development is that Mythos can connect the dots between low-severity findings that would never have been treated as urgent in isolation, creating exploit chains that traditional triage models aren't built to catch. A CVSS score of 4 stops being a reason to deprioritize when it's one link in a chain that gets an attacker to something critical.
So suddenly, organizations triaging by severity score and patching by schedule are operating on an outdated model. Severity scores paint a wholly incomplete picture of your environment.
The questions that matter now are: do you have this software running, and can an attacker reach it?
Until you can answer both, you're working with information that is necessary, but insufficient.
Time to answer is how long it takes to get from disclosure to a confident answer to that question. It matters more than patching speed because patching speed only matters if you're patching the right things. Teams that can't answer quickly default to vendor advisories and severity scores. They patch things that pose little risk. They miss things that matter. And with mean time to exploit now measured in negative days, the window for getting this wrong keeps shrinking.
What a complete exposure assessment looks like
Answering "are we exposed?" properly means working through four questions:
Do we run the affected software today, in a version that's actually affected?
Is it in an internet-facing environment, or would reaching it require chained exploits?
What's required to exploit it? Specific authentication, local access, particular configurations?
And do we have any compensating controls already in place?
Most security teams have the data to answer all four. The problem is that it lives across asset inventories, EDR telemetry, cloud infrastructure dashboards, CMDBs, and device trackers, each speaking a slightly different language with different coverage gaps. Pulling it together takes hours, sometimes days.
According to Tines' 2026 Voices of Security report, 76% of security professionals already report emotional exhaustion or mental fatigue frequently or occasionally. A slow time to answer compounds that, turning every disclosure into a firefight. New disclosures pile on top of unresolved assessments, the backlog grows, and the team never gets ahead.
How we built a Tines App to answer this question
I believe that "are we exposed?" is a data collection and aggregation problem. The data exists, it's just siloed across systems that don't talk to each other. Pulling it together, normalizing it, and surfacing it in a usable form is exactly what deterministic workflows are built to do.
We built our exposure assessment dashboard using Tines Apps, a new capability that lets teams build fully custom, interactive interfaces directly within Tines. Apps are dynamic. You can search, filter, and interact with live data pulled from across your stack. An AI assistant helps you build and customize the interface, but what you end up with is specific to your environment, your tools, and how your team thinks about risk. Every customer's version will look different, connecting to their systems and surfacing the information that matters most to them.
Our dashboard is built around four modules.
Software Bill of Materials Search. Search for a package name or version number and instantly surface every repository, container, or user workstation running it across ecosystems including Python, JavaScript, Ruby, and Rust. This is where supply chain attack response starts. When a compromised package is identified, you can search across all your npm packages for that specific version and know your exposure in seconds, with direct links to the affected repositories and hosts.
Installed Apps. Search for any endpoint application and return every installed version across the fleet - which employees are running it, on which machines, and when they last opened it. When a vulnerability hits widely-used software, this tells you exactly who is exposed and how actively they're using it.
Cloud Resource Lookup. Search by any identifier (name, ARN, IP address, or CVE) and surface matching cloud resources by type, region, account, and provider, showing internet exposure, EDR sensor coverage, known vulnerabilities, and a direct link into your CNAPP for deeper investigation.
CVE Search. Search by CVE across cloud resources, container vulnerability scans, and Mac workstations and get a single view of your complete exposure across infrastructure, code, and endpoints in one place. This is where the "are we exposed?" question really gets answered. You can scope the blast radius, understand what's affected, and prioritize remediation without pivoting between tools. Given how fast Mythos-era vulnerabilities are being weaponized, having that view available immediately when a CVE drops is key.
Together, these four modules map onto the four exposure assessment questions. When a vulnerability drops, the team has a clear picture in minutes rather than hours, without queuing up multiple tools or manually reconciling data from systems that were never designed to talk to each other.
Mean time to patch will always matter, but it's a lagging indicator, telling you how fast you moved after you'd already decided what to act on. Time to answer, meanwhile, determines whether that decision is based on solid data about your environment or a severity score with no bearing on your actual exposure.
We've been using this dashboard internally for a while now and it's changed how we respond to new disclosures. We're genuinely excited to get it into the hands of customers through Tines Apps, and we can't wait to see what teams build with it.
Want to see how Tines can help you adapt? Book a demo today.