❌

Reading view

Three Gartner Reports. One Emerging Direction for Exposure Management.

In a short period, Check Point has appeared across three new Gartner research publications examining autonomous remediation, exposure assessment, and the future of preemptive cybersecurity. These three reports ask very different questions. But how do they connect? One examines how organizations can trust autonomous remediation. Another looks at the growing exposure management market and the increasing importance of exploitability. The third looks further ahead at the technologies Gartner believes will shape preemptive cybersecurity. Taken together, the reports capture a broader change already underway across the industry. Exposure management is expanding from identifying risk toward understanding exploitability and enabling action. Exploitability […]

The post Three Gartner Reports. One Emerging Direction for Exposure Management. appeared first on Check Point Blog.

  •  

The Missing Layer in Vulnerability Prioritization: Full Visibility Into Your Attack Surface

Security teams have more vulnerability data at their disposal than ever. But even the best intelligence has limited value if teams can’t determine where those vulnerabilities exist within their own environment.

For many organizations, that visibility remains a challenge. Asset inventories, scanners, and ticketing systems provide valuable information, but connecting those insights with real-world exploit activity isn’t always straightforward. And as environments evolve, undocumented assets, forgotten infrastructure, and newly exposed systems can introduce risks that traditional inventories may miss.

Flashpoint External Attack Surface Management (EASM) helps close that gap by connecting continuous discovery of internet-facing assets with Flashpoint’s threat-informed Vulnerability Intelligence. With coverage of more than 480,000 vulnerabilities, including over 105,000 not found in NVD or CVE, Flashpoint provides context on active exploitation, exploit maturity, and ransomware risk through its patented Ransomware Risk model. Together, these capabilities help teams identify which exposures warrant the most immediate attention.

What is EASM? External Attack Surface Management (EASM) is the continuous discovery and monitoring of an organization’s internet-facing assets, including domains, subdomains, IPs, and infrastructure that isn’t formally tracked. It gives security teams visibility into what’s exposed to the internet, whether or not that infrastructure was deliberately set up or documented.

How EASM Extends Vulnerability Prioritization to Your Full Environment

EASM continuously discovers internet-facing assets associated with an organization, including domains, subdomains, IP addresses, and infrastructure that may not appear in existing inventories. This could include a subsidiary’s infrastructure following an acquisition, a forgotten staging environment, or a cloud instance that remains active long after a project ends.

With Flashpoint EASM, discovered assets enter a triage queue organized by relevance, helping teams focus on assets that warrant further investigation. Once ownership is confirmed, Flashpoint maps those assets against its Vulnerability Intelligence to identify vulnerabilities associated with the software versions running on them.

Findings are prioritized using Flashpoint KEV, EPSS, and Ransomware Risk scores. Asset-level details also show the products and versions responsible for identified exposures, along with potentially high-risk open ports such as RDP and SSH. This gives teams the context they need to assess risk and determine where remediation should begin.

Example Scenario

Consider a development team that deploys a staging server running an outdated web framework. The project ends, but the server remains online and is never added to the organization’s asset inventory.

Flashpoint EASM discovers the server and shows how it connects to the organization’s infrastructure. Once the team confirms ownership, Flashpoint Vulnerability Intelligence identifies an actively exploited CVE affecting the framework version.

The team can now investigate an exposure that might otherwise have gone unnoticed and prioritize remediation based on evidence of active exploitation.

Why This Matters More in Regulated Industries

For organizations in heavily regulated industries such as financial services and healthcare, incomplete asset visibility can introduce additional compliance and security risks. Requirements under frameworks and regulations such as GLBA and HIPAA make maintaining appropriate safeguards especially important. An unknown, internet-facing asset with an exploitable vulnerability can create exposure regardless of whether it appears in the organization’s CMDB.

Mergers and acquisitions can complicate this further. Acquired organizations bring infrastructure that security teams may have limited visibility into, including assets that have not yet been incorporated into existing monitoring processes.

Continuous external asset discovery helps teams identify and assess that infrastructure earlier, reducing reliance on periodic audits or manual inventory updates to uncover potential exposures.

Discovery and Prioritization, Built Into One Platform

When attack surface discovery and vulnerability intelligence operate in separate systems, security teams may need to manually correlate asset inventories with vulnerability findings. That process becomes increasingly difficult as infrastructure changes and new vulnerabilities emerge.

Flashpoint brings these capabilities together in one platform, an approach we call attack surface intelligence. Newly discovered assets can be evaluated against Flashpoint’s Vulnerability Intelligence, giving teams access to threat-informed prioritization within the same workflow.

For teams already using Flashpoint Vulnerability Intelligence, EASM can be added as a module within the existing Ignite platform, with no separate console to manage. Contact your account team to learn more about adding EASM to your deployment. New to Flashpoint? Schedule a demo to explore how Vulnerability Intelligence and EASM work together to help your team identify and prioritize external exposures.

Frequently Asked Questions

How is EASM different from a vulnerability scanner? 

Traditional vulnerability scanners scan assets you already know about and tell them to check, typically from inside the network perimeter. EASM continuously discovers internet-facing assets from the outside, including unknown infrastructure like forgotten test environments and acquired systems, then enriches them with vulnerability intelligence beyond public sources like NVD and CVE. The two are complementary: scanners provide depth on known internal assets, while EASM extends that visibility to what’s exposed externally.

Can EASM help identify compound risk on a single asset? 

Yes. The Vulnerable Assets view surfaces how many vulnerabilities are tied to a given asset, so teams can quickly spot assets carrying disproportionate risk and prioritize accordingly, rather than treating every finding as an isolated issue.

If we’re already running Flashpoint Vulnerability Intelligence, do we need a new implementation to add EASM? 

No. EASM is a module inside the platform you’re already using. It appears inside the same Ignite workflows your team relies on today, with no separate console or parallel rollout required.

How is EASM priced?

EASM is priced based on company size rather than asset count or seats, so costs are predictable and don’t scale up just because the attack surface grows.

See Flashpoint in Action

The post The Missing Layer in Vulnerability Prioritization: Full Visibility Into Your Attack Surface appeared first on Flashpoint.

  •  

Rethinking Vulnerability Management: “If It’s Not in the Scanner, It Didn’t Happen” Needs to Go

Recently, somebody from a fairly mature security team told me something I did not want to hear: if software vendors run “Mythos-class” models on their own code and fix what they find, they must publish a CVE for every fixed vulnerability.

CVE art

My first reaction (vendor hat firmly on, since I now work at Cisco) was: huh? Why? These bugs were found by the vendor, fixed by the vendor and were never public. A vast majority (but not all!) are not exploited. CVE CNA rules make assignment a SHOULD, not a MUST, and whether a quietly shipped fix even counts as “publicly disclosed” is something considered debatable. Why would anybody want it?

My second reaction, a bit later in the conversation was: oh, that!

They have a point. Sort of. They were simply describing how their vulnerability management program works. And, I suspect, how many of yours work too. Their problem is about to become everybody’s problem; they just noticed it first.

The Problem In One Sentence

Many VM programs start with a vulnerability scan, not with a patch, a vendor release or … a news headline about a new terrible security issue.

The chain looks like this:

old sad VM

Note what is not on this list: the vendor advisory. It is not an input in their case.

Before anybody snickers or ROFLs about it: this was a sound design for about 20 years. In the 2000s and 2010s, an issue that mattered usually got a CVE (yes, before the “vuln-purists” tear me to shreds, there were some exceptions to this even back then!). And a CVE got a check from your vulnerability scanner vendor, usually within days (in my Gartner days, we called them “Q/R/T” for the reasons you can easily guess…). Auditors want evidence, ticketing systems need an ID, and SLAs need an event that starts the clock. A “scan-first” program is what you get when you optimize for all of that at scale. It is a property of the pipeline, not a failure of the people running it.

So a software or an OS vendor can shout “URGENT, upgrade now!” all it wants. If the fix has no CVE, the scanner (usually) has no finding, there is no ticket, no SLA clock, no change request, and no patch (at the companies that follow that model).

Here are the two paths side by side:

Paths table

Why This Matters Now: Hello, Vulnerability Apocalypse

I hate the “post-Mythos” label as much as the next person, but these numbers are not marketing. (BTW, every time you say “post-Mythos” for marketing purposes, Claude kills a kitten.)

In Patch Sound Barrier Part 2 I defined the “vulnerability apocalypse” as four things arriving together: massive vulnerability volume, fast exploit development, exploitation at scale and resulting incident damage. Factor #1 is no longer theoretical: high and critical CVEs from notable vendors ran at roughly 3.5x the prior monthly record in June 2026, and at about 5x in July.

Now the twist: those charts only count the fixes that got a CVE. The pile of internally found, internally fixed, never-CVE’d bugs is not on any chart. For scale: Anthropic said in May that Mythos Preview had been used to find more than 10,000 high- or critical-severity bugs, not all of them publicly reported.

That is the part of the iceberg your scanner cannot see (usually). So a big chunk of the AI era’s fixes may be exactly the ones that scan-first programs miss! Your patch SLA dashboard stays green while your actual exposure grows. Green-but-wrong is worse than red.

BTW, “internally found” does not mean “nobody else knows.” Attackers have access to capable models too, AI makes patch diffing cheap, and some vendor advisories now list “internally discovered” bug classes that also contain actively exploited bugs. Found internally means “we found it too,” not “we found it first and only.” Yes, I know, Captain Obvious strikes again, but a scan-first program behaves as if this were not obvious at all.

Timing makes it worse. Here is one real example (via X post): CVE-2026–72529, a remote, unauthenticated script execution bug in TrueConf Server. The issue was found in June, the patch was also released in June, exploitation was spotted in July, and the CVE was assigned in August, by Kaspersky as a third-party CNA, not by the vendor. For a scan-first program, that bug did not exist for about two months, including the month it was being exploited. Note that even the “exploited bugs get a CVE” metric ran a month behind the exploitation here — away too slow. (Yes, it is a niche product. Niche is exactly where scanner coverage is thinnest.)

Who Taught Us to Think This Way?

Naturally, I also asked on X, and I got my share of thoughtful responses like “ask if adversaries will delay exploitation until a CVE and severity score exist”, “FYI, vulnerabilities without CVEs, or with low scores, regularly cause damage” and a reminder that “a CVE reflects severity after discovery, not exploit probability.” All true, all ignored by scan-first vulnerability management programs…

The best answer IMHO was this point: somewhere along the way, “a lookup key [CVE] became a proxy for risk.” Indeed, how did that happen?

“Scan-first” did not appear out of nowhere. Scanner vendors taught the market to think this way, and the market went along happily.

Some of the blame here is well deserved:

  • Coverage was sold in CVEs. For years, the headline number in every bake-off was how many CVEs a product detects and how fast a new check ships. Many customers learned that the CVE list is the threat model.
  • The CVE became the unit of work. Dashboards, risk scores, SLA reports and ticketing integrations were all built around CVE IDs. Anything without one is a second-class citizen in the product, and therefore in the program.
  • “Clean scan” became audit evidence. Compliance scanning made “the scan report is clean” the proof that auditors still ask for. In PCI DSS ASV scanning, pass or fail is largely decided by the CVSS scores of the findings. (Yes, I co-wrote a book on PCI, so I am not innocent here either.)
  • Non-CVE coverage exists, but nobody marketed and sold it. Many scanners do have checks keyed to vendor bulletins, and most flag outdated or unsupported versions. In practice, those often land as low-priority findings that no SLA tracks. They were never the thing on the slide…

And before you say “just use KEV and EPSS”: both are keyed on … CVE IDs. KEV only lists vulnerabilities that have an assigned CVE, and EPSS only scores CVEs. “Risk-based” Vulnerability Management built on CVE-keyed inputs inherits the exact same blind spot. Not very risk-aware, that is.

To be fair, all of this was once rational. A CVE is a clean, shared, countable unit, and you can build a product (and a business) on countable units. This worked kinda OK in 2015, worked poorly in 2021, and really, really does not work in 2026.

So a market that was essentially taught “if it’s not in the scanner, it didn’t happen” now needs to learn something new, and the people who taught the first lesson are best placed to teach the next one.

The Three Obvious Fixes Are Suboptimal

CVEs are not only a scanner input; they are also a public accountability ledger. This industry has a long and not very proud history of silent patching, and “trust us, we fixed it, this matters to you” has earned all the skepticism it gets.

At the same time, the vendor-side point also stands. Defenders at software companies will use those models to fix their code, and their code is getting better and more secure. Flooding the market with huge piles of CVEs will not help anybody. Both things are true at once, and that is what makes this problem interesting.

So, the quick fixes, each with a catch:

  • Option 1: A CVE for every internally found bug. At AI scale, this floods scanner queues with hundreds of findings that a single upgrade closes. We have actually run this experiment: after the Linux kernel became a CNA in 2024, it started assigning CVEs for thousands of backported fixes, and people have complained about the noise ever since. Even Epoch had to footnote it as noise in their CVE charts.
  • Option 2: Bundled CVEs. Cisco now ships scheduled security releases with CVEs bundled by weakness type (CWE), and still assigns an individual CVE when a bug is exploited or needs a compensating control. It is a pragmatic middle path. If a bundle is scored by its worst member, it also pushes you toward handling exceptions per release rather than per CVE, which, as you will see below, is exactly where I think you should end up anyway…
  • Option 3: Read vendor advisories manually. Ah, the good old days! Mapping advisories from hundreds of vendors onto thousands of assets by hand does not scale, and frankly never did.

Note that Option 3 is wrong about the how, not the what. The advisory does need to reach your program. A human with a browser and 200 vendor websites just cannot be the delivery mechanism.

So What Would Actually Work? Make the Advisory an Input

In my strictly private opinion, the vendor advisory must become a first-class input to vulnerability management, next to the scan, not behind it. Not “instead of the scan,” and not “if the scanner vendor gets around to it.”

The chain should look like this:

new cooler VM

Obviously, better programs do this today, so for a decent percentage of this blog’s readers this should really not be news. This blog is not for you.

Getting there needs three parties to move, not one (plus your auditor):

  • Vendors: publish machine-readable advisories (CSAF much?) with fixed versions, urgency and exploitation status. And keep the accountability ledger honest: assign an individual CVE the moment a bug is exploited or needs a compensating control. (Yes, this is close to what my employer committed to in June. This is the easy part; the next bullets are the hard ones.)
  • Scanner vendors: you taught the market that the scanner is the source of truth, so you get the first job. Ingest those feeds and create findings under your own IDs, no CVE required, at real severity rather than as an informational footnote. You already flag “outdated version”; this is the same idea, driven by vendor data. (Yes, the risk is that coverage follows market share. Niche OT vendors, I am looking at you.)
  • VM programs: add a currency metric next to CVE closure, e.g., percent of assets within N releases of the vendor’s latest security release. In other words, patch the release, not just the CVE. If your remediation speed is capped by the patch sound barrier, spend that limited throughput on upgrades, not on ticket accounting.
  • Your auditor: if audit accepts only CVE closure as evidence, nothing above will change. Bring them in early and show them the currency metric before it shows up in an audit finding.

What To Do This Week

Run the 30-minute self-test:

  1. Pick your top vendor by asset count (or by internet exposure).
  2. Pull their last three security releases and count the security fixes vs. the CVEs. (If the release notes just say “multiple security fixes” with no count, congrats, that is a finding too.)
  3. Check what your scanner flagged for those releases.

The difference between what the vendor fixed and what your scanner flagged is your blind spot, in numbers.

Ask your scanner vendor:

  • What do you do with a vendor advisory that has no CVE?
  • Do you ingest CSAF advisories, and from which vendors?
  • What is your median lag from a vendor advisory to a detection?
  • Can you show me every asset more than N releases behind the vendor’s latest security release, and at what severity?

Change your program:

  • For edge and crown-jewel asset classes, start the SLA clock at the vendor security release, not at the scanner finding.
  • Grant exceptions per release, not per CVE.
  • Report a currency metric next to CVE closure, e.g., “percent of internet-facing assets on the vendor’s latest security release within 30 days.”
  • Put it in contracts: vendors provide machine-readable advisories with fixed versions and exploitation status, and scanner vendors cover non-CVE vendor fixes at real severity.

So?

With my vendor hat on, I still don’t think every internally found bug needs its own CVE. With my VM hat on, it should not matter: your program should not need one to act. Patch the release, not just the CVE. If the gap is zero, congrats, and please tell me how you did it. If it is not, you have found your blind spot… have fun!

Related blogs:


Rethinking Vulnerability Management: “If It’s Not in the Scanner, It Didn’t Happen” Needs to Go was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

  •  

Ransomware Risk Model: Flashpoint’s Patented Scoring Method to Inform Vulnerability Prioritization

Vulnerability and exposure management (VM) teams need critical metadata and context that clearly show which issues pose an immediate risk to their organization. While traditional VM frameworks tell defenders how severe a vulnerability may be, they do not provide visibility into how likely threat actors are to exploit it. This leaves security teams overwhelmed in patch backlogs without a clear strategy for prioritization.

Nowhere is this prioritization gap more dangerous than with ransomware. Ransomware-as-a-Service (RaaS) groups no longer choose targets at random. They look for specific technical conditions that make vulnerability exploitation easy, fast, and repeatable. With RaaS attacks rising by 45% period-over-period in H1 2026, organizations need a way to identify the specific traits that make a vulnerability attractive to ransomware operators before an attack occurs.

Flashpoint built the Ransomware Risk score into Flashpoint Vulnerability Intelligence to solve exactly this problem. Since 2022, it has rated newly discovered vulnerabilities based on how closely they resemble those known to be used in ransomware attacks. With the grant of the U.S. Patent No. 12,705,360 on August 11, 2026, the methodology behind the score is now formally patented. This milestone formalizes Flashpoint’s ability to cut through the noise with a proven, threat-informed signal that gives defenders the clarity they need to act on Day Zero.

“As vulnerability disclosures surge, prioritization is more important than ever for security teams. A severity score alone can’t tell you which vulnerabilities pose the greatest real-world risk of exploitation by ransomware actors.

Our patented Ransomware Risk model applies years of threat intelligence to that problem, giving customers an earlier signal and helping them prioritize based on how attackers actually operate.”

josh lefkowitz, co-founder and ceo at flashpoint

Under the Hood: How Flashpoint’s Patented Ransomware Vulnerability Model Works

The patented system evaluates newly disclosed vulnerabilities against the patterns shared by vulnerabilities ransomware groups have exploited. Rather than trying to predict what threat actors will do next, the model learns what past ransomware-exploited vulnerabilities have in common and compares each new flaw against those patterns.

Flashpoint Ransomware Risk Model

The Four Step Process

Multi-Factor Fingerprinting

Every vulnerability ingested into Flashpoint Vulnerability Intelligence is profiled against more than 60 distinct technical factors. This “fingerprinting” links the vulnerability to key inputs including whether the flaw is remotely exploitable without authentication, whether it affects SCADA or Operational Technology (OT) systems, and its potential impact on data availability, which is central to extortion schemes.

Coordinate Mapping

The model turns each multi-factor fingerprint into a set of values that place it as a single point on a map, so vulnerabilities with similar profiles land close together.

Identifying the Ransomware Neighborhood (Cluster Check)

Flashpoint overlays historical threat data onto the map to establish neighborhoods where vulnerabilities previously exploited in real-world ransomware attacks aggregate.

Similarity and Likelihood Rating

When a new vulnerability is ingested, its coordinates are checked against these neighborhoods. The scoring system calculates its spatial proximity to known ransomware vectors and assigns a clear rating: Low, Medium, High, or Critical.

This four-step method, developed by Flashpoint’s Ben Haynes and Jacob Kouns, is the basis of U.S. Patent No. 12,705,360.

What It Means for Vulnerability Management Teams

By translating complex structural attributes into a single risk score, the patented model delivers four key operational advantages:

  1. Prioritize Beyond CVSS: Leveraging the Ransomware Risk model, security teams can confidently prioritize 1.0 to 6.9 CVSS issues if its structural profile lands it in a “High” or “Critical” ransomware cluster.
  2. Act on Day Zero: Because the Flashpoint model rates all vulnerabilities on disclosure, security teams gain actionable guidance immediately, eliminating the need to wait weeks for external exploitation reports.
  3. Effectively Communicate Risk: CISOs can present clear, business-centric risk statements rather than abstract numerical scores.
  4. Adaptive Ratings: Scores update in near real time as vulnerability details change, and the model keeps adjusting as new vulnerabilities join the set it compares against.

Comprehensive Vulnerability Intelligence Integration

Flashpoint’s Ransomware Risk model is built to enhance, not replace the vulnerability management frameworks organizations already rely on. In fact, it provides even greater value for security teams as our Ransomware Risk model provides clarity for every vulnerability detailed by Flashpoint Vulnerability Intelligence, including over 105,000 issues missed by CVE and NVD.

Within Flashpoint Ignite, security teams have a complete view of vulnerability risk, seeing the score alongside CVSS (v3 and v4), EPSS, Social Risk, and exploit maturity.

Patented Ransomware Risk Score sits beside CVSS and EPSS on every vulnerability record in Flashpoint Ignite

Protect Against Vulnerability and Ransomware Risk Using Flashpoint

Vulnerability management requires more than cataloging. It demands threat-informed prioritization that aligns security operations with real-world business risk. Flashpoint’s patented Ransomware Risk model eliminates guesswork by surfacing the flaws that match the profile of known ransomware targets, allowing security teams to patch what matters most, first. 

By combining proprietary knowledge of vulnerability architecture and ransomware attacks, Flashpoint bridges the gap between theoretical and active exposure. Request a demo today to see how our Ransomware Risk model provides the definitive signal needed to stay ahead of extortion groups.

Ransomware Risk FAQs (Frequently Asked Questions)

What is the Ransomware Risk score? 

The Ransomware Risk score is a rating in Flashpoint Vulnerability Intelligence that shows how closely a vulnerability resembles those known to be used in ransomware attacks. Each vulnerability is rated Low, Medium, High, or Critical, so security teams can see which ones to patch first to reduce their ransomware exposure.

How is Ransomware Risk different from CVSS and EPSS?

CVSS measures how severe a vulnerability could be, and EPSS estimates how likely it is to be exploited in general. Ransomware Risk adds a ransomware-specific signal that works alongside both, showing how closely a vulnerability matches those ransomware groups have used. In Flashpoint Ignite, all three scores appear together.

What does Flashpoint’s ransomware patent cover?

U.S. Patent No. 12,705,360, granted August 11, 2026, covers Flashpoint’s method for rating how likely a vulnerability is to be used in a ransomware event. Each vulnerability is profiled on more than 60 factors, compared with vulnerabilities used in past ransomware attacks, and rated by similarity. The patent formalizes the model behind the Ransomware Risk score, live since 2022.

How often are Ransomware Risk scores updated?

Ransomware Risk scores update in near real time, so new vulnerabilities are rated as soon as they’re disclosed. The model also keeps adjusting as new vulnerabilities join the body it compares against, so ratings reflect the ransomware landscape as it stands today.

See Flashpoint in Action

The post Ransomware Risk Model: Flashpoint’s Patented Scoring Method to Inform Vulnerability Prioritization appeared first on Flashpoint.

  •  

Cybercrime at Machine Speed: Key Takeaways from Flashpoint’s 2026 Midyear Threat Intelligence Briefing

Blogs

Blog

Cybercrime at Machine Speed: Key Takeaways from Flashpoint’s 2026 Midyear Threat Intelligence Briefing

Threat actors are no longer just using automation to execute tasks, they are leveraging prepackaged, safeguard-free AI, weaponizing stolen session data, and directly targeting defenders’ security stacks.

SHARE THIS:
Default Author Image
September 1, 2026

In our latest webinar, Flashpoint Vice President of Intelligence, Ian Gray, briefed security leaders on the evolving threat environment, providing critical insights from the Flashpoint Global Threat Intelligence Report (GTIR): 2026 Midyear Edition.

The threat landscape has developed at a striking pace with Flashpoint tracking over 22 million illicit AI discussions, 7.4 million compromised hosts yielding 1.7 billion stolen credentials, and over 21,600 disclosed vulnerabilities in just six months. Beyond these staggering numbers, the on-demand session detailed something even more alarming: a fundamental shift in adversary operational tradecraft.

Here are the five critical shifts every cyber threat intelligence (CTI), Vulnerability Management, and SOC team needs to know.

The Death of Signal: Threat Actors are Shifting to “Private AI”

The public discussion surrounding criminal artificial intelligence (AI) has reached a critical inflection point. Early in the AI boom, Flashpoint observed threat actors collaboratively experiment across underground forums, jailbreaking commercial frontier models or advertising surface-level tools like WormGPT and DarkGPT.

Today, adversaries are shifting from public forums to running fine-tuned, open-source models locally on private servers, which greatly hampers traditional signature-based detection. Flashpoint analysts are now seeing attackers generate unique, highly tailored malware variants, flawless phishing lures, and custom exploit scripts at extremely low costs—completely offline and shielded from public monitoring.

“A few months ago, a lot of this was collaborative… public outsourcing. Now what we’re seeing is scarier: pre-packaged cybercrime models run locally on private infrastructure. Malicious code, exploit scripts, and targeted phishing are all being generated inside closed environments.”

Ian Gray, VP of Intelligence, Flashpoint

Weaponizing the Defender’s Own Tooling

Another eye-opening tactical insight shared during the session was how threat actors are repurposing defender infrastructure for automated initial access and extortion. In the webinar, we pointed to recent campaigns where adversaries specifically targeted misconfigurations and zero-day vulnerabilities inside open-source vulnerability scanners, secrets-detection tools, Kubernetes clusters, and Infrastructure-as-Code(IaC) environments.

What this means for defenders is that the attack surface is no longer bounded by traditional enterprise network boundaries: it extends directly into CI/CD pipelines, security orchestration tooling, and third-party SaaS integrations. Security teams are finding themselves in a race against attackers who use automated scanning scripts to weaponize vulnerabilities in the security tools themselves.

The Global Infostealer Threat and Identity-First Attacks

Flashpoint tracked 7.4 million hosts compromised by infostealers in H1 2026—a 27% increase period-over-period—harvesting 1.7 billion credentials and identity information.

While the top infostealer strains remain familiar, law enforcement operations have created vacuums that competitors rapidly fill.

map visualization

Threat actors are leveraging drive-by downloads, watering holes, and pirated software packages to plant stealers. Once a machine is compromised, the logs capture corporate SSO credentials, active browser cookies, VPN keys, and SaaS session tokens. This enables adversaries to simply log in without having to leverage complex technical exploits.

The Structural Failure of CVE/NVD and the Importance of KEV

The Common Vulnerabilities and Exposures (CVE) and National Vulnerability Database (NVD) have failed to keep pace with the velocity of AI-assisted vulnerability discovery. As such, vulnerability management teams are facing significant operational delays.

MetricFlashpoint GTIR Midyear H1 2026 DataOperational Impact
Total Disclosures21,667Remediation volume exceeds defender bandwidth.
Exploit Availability19% (4,015 CVEs)Functional code is ready before patches are deployed.
Public Catalog LagGrowing Backlog (NVD/KEV)Delay in official scoring leaves teams blind to active risk.

Therefore, waiting for NVD enrichment before prioritizing a patch is a dangerous strategy. To compensate, security teams require Vulnerability Intelligence (VI) that provides primary-source confirmation of weaponization, exploit availability, and actionable mitigation guidance long before public databases update.

Ransomware Evolution: From Encryption to Cloud Extortion

Ransomware-as-a-Service (RaaS) activity surged by 45% period-over-period, reaching 6,256 verified victim postings on data leak sites. However, total on-chain payout revenue dropped by 8% to $820 million, with victim pay-rates hitting a record low of 28%.

Faced with declining payouts and resilient enterprise backups, extortion syndicates are adapting. Rather than relying exclusively on technical file-encrypting malware, groups are executing pure data extortion campaigns—frequently targeting cloud platforms or extracting data through third-party vendor access.

Protect Your Organization Using Flashpoint

Defending against machine-speed attacks requires moving beyond reactive, post-incident telemetry. Flashpoint arms security, CTI, and vulnerability management teams with the primary-source intelligence required to preempt adversary operations:

  • Unrivaled Deep & Dark Web Visibility: Flashpoint’s Primary Source Collection actively monitors closed criminal communities, illicit Telegram channels, and private forums, giving you early warning when threat actors build custom AI toolkits or trade credentials targeting your organization.
  • Comprehensive Vulnerability Intelligence (VI): Flashpoint tracks zero-days and vulnerability disclosures independently, delivering immediate exploit availability data and threat-informed prioritization so you patch what actually matters.
  • Continuous Compromised Credential Monitoring: Instantly surface exposed enterprise credentials, active session tokens, and stealer logs tied to your domain or third-party supply chain before they lead to an account takeover (ATO).

Request a demo, or watch the full on-demand webinar to explore the data shaping today’s risk landscape.

See Flashpoint in Action

The post Cybercrime at Machine Speed: Key Takeaways from Flashpoint’s 2026 Midyear Threat Intelligence Briefing appeared first on Flashpoint.

  •  

Navigating AI-Driven Cyber Threats: Insights from Flashpoint’s 2026 GTIR Midyear Edition

Blogs

Blog

Navigating AI-Driven Cyber Threats: Insights from Flashpoint’s 2026 GTIR Midyear Edition

In this post, we preview the critical findings of Flashpoint’s Global Threat Intelligence Report: 2026 Midyear Edition.

SHARE THIS:
Default Author Image
August 13, 2026

In the first half of 2026, the global threat landscape reached a clear operational inflection point: threat operations have fundamentally transitioned from human-led campaigns to machine-speed, AI-driven exploitation. As threat actors gain commoditized access to open-source AI technologies and actively deploy automated, safeguard-free tooling locally on private infrastructure, organizations face an accelerating hybrid risk environment.

Flashpoint’s Global Threat Intelligence Report: 2026 Midyear Edition

The Flashpoint Global Threat Intelligence Report: 2026 Midyear Edition anchors security leaders—from threat intelligence, vulnerability management, to executive leadership—in the data required to navigate this evolving threat landscape. Covering the period from January 1 to June 30, 2026, the report delivers timely insights backed by Flashpoint’s proprietary primary-source collection from over 3.9 petabytes of continuously monitored illicit sources.

Our midyear findings reveal several key metrics that highlight the speed and scale of the H1 2026 threat landscape:

  • 22M+ threat actor posts discussed, shared, or advertised artificial intelligence toolkits for criminal deployment.
  • 1.7B credentials and identity data points extracted across more than 7.4M unique compromised hosts globally.
  • Nearly one-in-five (19%) of all vulnerability disclosures dropped with ready-made, functional exploit code.
  • 45% period-over-period surge in Ransomware-as-a-Service (RaaS), with total victim volume reaching 6,256 even as victim payout rates dropped to a historic low of 28%.

Download the Flashpoint Global Threat Intelligence Report: 2026 Midyear Edition to gain:

  1. A Clear Understanding of the Convergence Between AI and Cyber Threats
    From generating flawless phishing campaigns to automating vulnerability scanning and code obfuscation, discover how adversaries are optimizing for speed and cost-efficiency — utilizing AI as a force multiplier in their various illicit campaigns.
  2. A Comprehensive Top-Down View of the Evolving Threat Landscape
    Gain full visibility of the threat landscape with Flashpoint’s primary-source collections and real-time threat intelligence.
  3. Strategies for Proactive Defense and Risk Mitigation
    Move your organization beyond reactive incident response by leveraging Flashpoint’s comprehensive threat intelligence. Gain the foresight needed to strengthen defenses and optimize your security posture.

“AI is compressing the time between opportunity and exploitation. Capabilities that once took significant expertise, coordination, and time to develop are becoming faster to build, easier to scale, and harder to detect. Security teams are facing an adversary ecosystem that can use AI to iterate at unprecedented speed — the only way to keep pace is with primary-source intelligence that surfaces adversary behavior before attacks unfold.”

Josh Lefkowitz, Flashpoint Co-Founder & CEO

The Four Driving Themes Shaping the 2026 Threat Landscape

Artificial Intelligence (AI) Threats

During the first half of 2026, Flashpoint captured over 22M illicit posts discussing or advertising AI for criminal-related activities. By stripping ethical safeguards, custom malicious LLMs allow unsophisticated threat actors to automate complex phases of the attack lifecycle, including target profiling, malware evasion script creation, and zero-day exploit generation.

chart visualization

Information-Stealing Malware Threats

Infostealer malware harvested 1.7 billion credentials across 7.4 million compromised systems in H1 2026 alone, turning digital identity into the main entry point for enterprise intrusions.

chart visualization

Vulnerability Intelligence and Patching Management

19% (4,015) of all H1 2026 vulnerability disclosures arrived with ready-made exploit code. Adversaries deploy automated replication scripts almost immediately upon disclosure, eliminating manual remediation windows.

interactive diagram visualization

Ransomware Operations, Multi-Extortion Cartels, and Financial Risk

Despite a 45% surge in victim volume (6,256 overall), total on-chain revenue fell by 8% to $820M. Improved enterprise backups and incident response have driven payout rates down to 28%, prompting syndicates to demand larger sums from paying victims.

chart visualization

Proactive Security in 2026 and Beyond

The data shows that traditional enterprise security organizations are struggling to keep pace with modern threat cycles that are accelerated by illicit uses of AI. This continued convergence of AI engines and initial access vectors have further compressed attack timelines, making it nearly impossible for security teams to defend against them—especially if they are limited by traditional approaches to threat intelligence.

Equipping your team with primary-source threat intelligence is critical for protecting critical assets in 2026. Download the Flashpoint Global Threat Intelligence Report: 2026 Midyear Edition to gain the visibility and strategic clarity required to defend your organization.

See Flashpoint in Action

The post Navigating AI-Driven Cyber Threats: Insights from Flashpoint’s 2026 GTIR Midyear Edition appeared first on Flashpoint.

  •  

How a vulnerability scanner creates an illusion of protection | Kaspersky official blog

The number of vulnerabilities detected in code continues to rise. According to Kaspersky’s threat analysis, 5,200 critical vulnerabilities were found in the first half of this year alone — nearly 50% more than during the same period last year. At the same time, the average gap between the publication of information about a vulnerability and the first attempts to exploit it is shrinking. The rapid development of AI systems plays a significant role in this process: while helping companies find weaknesses in their code, AI simultaneously shows hackers how to exploit them quicker.

It would seem that solving the problem of security gaps is very easy. All you need do is set up a scanner, check the infrastructure more often, and update vulnerable systems. But statistics from the Kaspersky Incident Response service show the opposite: a significant number of cyberattacks begin precisely by exploiting a flaw — and these are often already known flaws, not zero-day vulnerabilities.

Using a scanner does not give you an effective vulnerability management process. A scanner merely finds flaws (not always promptly), and then the IT team is tasked with prioritizing and fixing them. These processes can drag on for weeks, and in the meantime an attacker can easily gain access to the given infrastructure.

Where time is lost

The first delay can occur immediately after information about a vulnerability appears in databases. In addition to monitoring for breaches, the information security team is normally handling a dozen-or-so other tasks, so it relies entirely on the scanner for monitoring. If the scanner is configured to run weekly, a new vulnerability will appear in the report in a few days. In a company where scans are conducted quarterly, this obviously happens much later. Attackers, on the other hand, actively monitor news feeds and learn about new vulnerabilities immediately.

When the report finally reaches the security team, it contains far more than just one issue, raising the question of where to start. Critical vulnerabilities are addressed first, but attackers might exploit more than just those. Meanwhile, prioritization decisions are rarely based on data: often, they’re based on the order of the errors in the report, the name of the vulnerable system (they start with the one everyone’s talking about), or increased activity from its owner. Because of this, the risk of overlooking a serious threat is very high. Finally, the IT department takes on the vulnerability, and… it ends up back in the queue: they need to check the update’s compatibility and wait for a maintenance window.

After installing the update, the specialists close the ticket with a clear conscience and mark the status as completed. But would anyone verify that the patch was applied to all affected machines? Even the one that was turned off at the time of installation? Probably not, and then the company would assume the vulnerability was fixed, even though it’ll actually remain in the infrastructure for an indefinite period. This is the worst possible outcome: the risk remains — yet it’s no longer visible.

Put it all together, and what we get is months passing between disclosure and actual resolution. There’s no one in particular to blame here: every participant in the chain did what they’re supposed to. It’s just that this chain itself is made up of links with gaps between them.

A recipe for vulnerability management

To give attackers as few opportunities to gain access to corporate infrastructure as possible, it’s important to ensure that an organization has four key processes clearly established:

1.       Inventory

It’s impossible to verify the security of a system that no one knows exists. At the same time, virtually any large infrastructure will contain things like having had a server set up “for a week” three years ago, a network device left over from previous business owners, or a workstation that was forgotten during an office move. And each of these assets can pose a serious threat.

The goal of inventory management is to ensure complete transparency of the IT infrastructure. To achieve this, an up-to-date list of assets is compiled.

2.       Prioritization

When analyzing vulnerabilities, a security specialist shouldn’t rely solely on ratings from public databases such as the NVD, for these don’t always rely the real severity of the actual potential damage caused by exploiting a vulnerability. The specific structure of an organization’s infrastructure will have a significant impact. For example, the same vulnerability in a server located in an isolated segment, and in a system accessible from the internet, represents two very different risks.

Effective prioritization takes into account not only the publicly reported severity level but also the role of the vulnerable asset within the infrastructure, the likelihood of exploitation, and actual attack trends.

3.       Configuration settings

Overly permissive access settings, disabled security mechanisms, and default accounts are not technically vulnerabilities, but they often serve as entry points for cybercriminals. To prevent an attacker from exploiting inadequate configuration settings, security teams should follow several basic security best practices:

4.       Confirmation

Blind spots are particularly common at the last stage of the vulnerability management process. Typically, once the IT department formally installs an update, the vulnerability is considered patched. However, before breathing a final sigh of relief, it’s important to at least verify that the patch has been successfully applied to all affected systems and has actually resolved the vulnerability.

Five tasks — one solution

Our solution, the Kaspersky Vulnerability Management module for Kaspersky Next Optimum helps information security specialists establish centralized management of vulnerabilities, assets, and configuration errors. The product solves five key tasks:

  • It reduces the time between publication of vulnerability data and its detection in assets. The product automatically inventories the infrastructure — tracking even long-forgotten assets — and continuously scans it for vulnerabilities. Scanning is performed in two ways: agent-based and agentless. In the former, the solution runs on top of Kaspersky Endpoint Security, which allows for in-depth analysis of workstations and servers without transmitting service credentials over the network. In the latter, it analyzes ports and services where no agent is present. Both methods complement each other, enabling complete coverage of the company’s infrastructure.
  • Checks configurations. Compliance with security standards is verified using predefined profiles.
  • Prioritizes vulnerabilities. Priorities are assigned based on severity level, the characteristics of the specific asset, likelihood of exploitation, and other parameters.
  • Promptly fixes errors. This involves remediation recommendations and centralized patch management integrated into the familiar administration infrastructure.
  • Helps ensure that the vulnerability is fully patched. A remediation task is considered complete only after a follow-up verification.

The Kaspersky Vulnerability Management Module helps transform vulnerability management from a series of disjointed actions into a well-thought-out cycle. Details about licensing can be found on the Kaspersky Next Optimum for small and mid-sized businesses offering page and more about Vulnerability Management Module — on the module's home page.

  •  

Ransomware Risk Model: Flashpoint’s Patented Scoring Method to Inform Vulnerability Prioritization

Blogs

Blog

Ransomware Risk Model: Flashpoint’s Patented Scoring Method to Inform Vulnerability Prioritization

Flashpoint was awarded U.S. Patent No. 12,705,360 for its Ransomware Risk model, which rates how closely new vulnerabilities match those used in ransomware attacks.

SHARE THIS:
Default Author Image
October 1, 2026

Vulnerability and exposure management (VM) teams need critical metadata and context that clearly show which issues pose an immediate risk to their organization. While traditional VM frameworks tell defenders how severe a vulnerability may be, they do not provide visibility into how likely threat actors are to exploit it. This leaves security teams overwhelmed in patch backlogs without a clear strategy for prioritization.

Nowhere is this prioritization gap more dangerous than with ransomware. Ransomware-as-a-Service (RaaS) groups no longer choose targets at random. They look for specific technical conditions that make vulnerability exploitation easy, fast, and repeatable. With RaaS attacks rising by 45% period-over-period in H1 2026, organizations need a way to identify the specific traits that make a vulnerability attractive to ransomware operators before an attack occurs.

Flashpoint built the Ransomware Risk score into Flashpoint Vulnerability Intelligence to solve exactly this problem. Since 2022, it has rated newly discovered vulnerabilities based on how closely they resemble those known to be used in ransomware attacks. With the grant of the U.S. Patent No. 12,705,360 on August 11, 2026, the methodology behind the score is now formally patented. This milestone formalizes Flashpoint’s ability to cut through the noise with a proven, threat-informed signal that gives defenders the clarity they need to act on Day Zero.

“As vulnerability disclosures surge, prioritization is more important than ever for security teams. A severity score alone can’t tell you which vulnerabilities pose the greatest real-world risk of exploitation by ransomware actors.

Our patented Ransomware Risk model applies years of threat intelligence to that problem, giving customers an earlier signal and helping them prioritize based on how attackers actually operate.”

josh lefkowitz, co-founder and ceo at flashpoint

Under the Hood: How Flashpoint’s Patented Ransomware Vulnerability Model Works

The patented system evaluates newly disclosed vulnerabilities against the patterns shared by vulnerabilities ransomware groups have exploited. Rather than trying to predict what threat actors will do next, the model learns what past ransomware-exploited vulnerabilities have in common and compares each new flaw against those patterns.

Flashpoint Ransomware Risk Model

The Four Step Process

Multi-Factor Fingerprinting

Every vulnerability ingested into Flashpoint Vulnerability Intelligence is profiled against more than 60 distinct technical factors. This “fingerprinting” links the vulnerability to key inputs including whether the flaw is remotely exploitable without authentication, whether it affects SCADA or Operational Technology (OT) systems, and its potential impact on data availability, which is central to extortion schemes.

Coordinate Mapping

The model turns each multi-factor fingerprint into a set of values that place it as a single point on a map, so vulnerabilities with similar profiles land close together.

Identifying the Ransomware Neighborhood (Cluster Check)

Flashpoint overlays historical threat data onto the map to establish neighborhoods where vulnerabilities previously exploited in real-world ransomware attacks aggregate.

Similarity and Likelihood Rating

When a new vulnerability is ingested, its coordinates are checked against these neighborhoods. The scoring system calculates its spatial proximity to known ransomware vectors and assigns a clear rating: Low, Medium, High, or Critical.

This four-step method, developed by Flashpoint’s Ben Haynes and Jacob Kouns, is the basis of U.S. Patent No. 12,705,360.

What It Means for Vulnerability Management Teams

By translating complex structural attributes into a single risk score, the patented model delivers four key operational advantages:

  1. Prioritize Beyond CVSS: Leveraging the Ransomware Risk model, security teams can confidently prioritize 1.0 to 6.9 CVSS issues if its structural profile lands it in a “High” or “Critical” ransomware cluster.
  2. Act on Day Zero: Because the Flashpoint model rates all vulnerabilities on disclosure, security teams gain actionable guidance immediately, eliminating the need to wait weeks for external exploitation reports.
  3. Effectively Communicate Risk: CISOs can present clear, business-centric risk statements rather than abstract numerical scores.
  4. Adaptive Ratings: Scores update in near real time as vulnerability details change, and the model keeps adjusting as new vulnerabilities join the set it compares against.

Comprehensive Vulnerability Intelligence Integration

Flashpoint’s Ransomware Risk model is built to enhance, not replace the vulnerability management frameworks organizations already rely on. In fact, it provides even greater value for security teams as our Ransomware Risk model provides clarity for every vulnerability detailed by Flashpoint Vulnerability Intelligence, including over 105,000 issues missed by CVE and NVD.

Within Flashpoint Ignite, security teams have a complete view of vulnerability risk, seeing the score alongside CVSS (v3 and v4), EPSS, Social Risk, and exploit maturity.

Patented Ransomware Risk Score sits beside CVSS and EPSS on every vulnerability record in Flashpoint Ignite

Protect Against Vulnerability and Ransomware Risk Using Flashpoint

Vulnerability management requires more than cataloging. It demands threat-informed prioritization that aligns security operations with real-world business risk. Flashpoint’s patented Ransomware Risk model eliminates guesswork by surfacing the flaws that match the profile of known ransomware targets, allowing security teams to patch what matters most, first. 

By combining proprietary knowledge of vulnerability architecture and ransomware attacks, Flashpoint bridges the gap between theoretical and active exposure. Request a demo today to see how our Ransomware Risk model provides the definitive signal needed to stay ahead of extortion groups.

Ransomware Risk FAQs (Frequently Asked Questions)

What is the Ransomware Risk score? 

The Ransomware Risk score is a rating in Flashpoint Vulnerability Intelligence that shows how closely a vulnerability resembles those known to be used in ransomware attacks. Each vulnerability is rated Low, Medium, High, or Critical, so security teams can see which ones to patch first to reduce their ransomware exposure.

How is Ransomware Risk different from CVSS and EPSS?

CVSS measures how severe a vulnerability could be, and EPSS estimates how likely it is to be exploited in general. Ransomware Risk adds a ransomware-specific signal that works alongside both, showing how closely a vulnerability matches those ransomware groups have used. In Flashpoint Ignite, all three scores appear together.

What does Flashpoint’s ransomware patent cover?

U.S. Patent No. 12,705,360, granted August 11, 2026, covers Flashpoint’s method for rating how likely a vulnerability is to be used in a ransomware event. Each vulnerability is profiled on more than 60 factors, compared with vulnerabilities used in past ransomware attacks, and rated by similarity. The patent formalizes the model behind the Ransomware Risk score, live since 2022.

How often are Ransomware Risk scores updated?

Ransomware Risk scores update in near real time, so new vulnerabilities are rated as soon as they’re disclosed. The model also keeps adjusting as new vulnerabilities join the body it compares against, so ratings reflect the ransomware landscape as it stands today.

See Flashpoint in Action

The post Ransomware Risk Model: Flashpoint’s Patented Scoring Method to Inform Vulnerability Prioritization appeared first on Flashpoint.

  •  

The 15-Minute Patch, Reverse-Engineered: What Had to Be True?

In Part 2 of the Patch Sound Barrier series, I shared a thought experiment from a talk in May 2026: imagine any vulnerability in your environment can be patched within 15 minutes of release. Now reverse-engineer that reality. What had to be true?

Gemini imagining this blog

Usman and I revisited this exercise in our “basics at AI scale” post. Readers asked: “How do I actually run this exercise with my team?”

So here’s how. Two ground rules first:

  • This is not a 15-minute patch SLA. If you take this post and write “all vulnerabilities remediated within 15 minutes” into a policy, I will find you… I utterly hated “30 days flat” policies as an analyst and “15 minutes flat” is the same mistake with more zeros. The number is a probe, not a target.
  • You will never get there across your whole environment. Legacy systems guarantee it. The point is the gap between the fantasy and your reality, because that gap is the most honest map of your program you will ever get. The Patch Sound Barrier is real; this exercise tells you where yours is and what it is made of.

Why 15 minutes, and not “fast”

“Fast” allows cheating. Some consider 90 days “fast” because they started at an annual cadence. “Patch faster” is generic advice everyone agrees with, but rarely acts on (or: barely acts on). An aggressive, specific number forces you to identify which pipeline steps physically cannot fit.

The Cloudflare quote from Part 2 summarizes this: demanding faster patching without redesigning the process leads to skipped steps. If regression testing takes a day, a two-hour SLA just skips testing. This exercise targets pipeline design, not raw speed. A 15-minute window leaves room only for automated steps. Everything else itemizes your sound barrier.

The 15 minutes, minute by minute

Assume a patch drops at T+0. At each stage, ask:

  1. What must be true for this stage to fit the timeframe?
  2. What is current reality, and what is the gap?

Details:

Process machinery 1

and

Process machinery 2

A 15-minute timeline leaves zero room for manual deliberation. In this model, humans define policies, build automation, and handle (rare!) exceptions. They do not manually approve or execute patches.

The five things the exercise refuses to let you skip

  1. Inventory as a live graph. If identifying affected systems takes hours, downstream automation cannot compensate. First move: measure how long it takes to locate a specific library or version today. That duration is your baseline gap. Most organizations are shocked. Log4j much?
  2. Rapid automated testing. Manual testing blocks rapid remediation. First move: time how long it takes to get from “patch available” to “confident it won’t break prod” on core systems, then work out what it would take to make that 5 minutes.
  3. Replaceable infrastructure. Rapid patching relies on redeploying updated templates rather than patching running instances. First move: determine your “replaceability ratio”: the percentage of systems that can be automatically rebuilt from source fast enough to fit the deploy window.
  4. Pipeline-level governance. Per-change approval gates prevent rapid execution. Approve the policy and the pipeline, not each patch. First move: transition low-risk change classes to pre-approved automated pipelines.
  5. Rehearsed rollback. Teams patch slowly because they fear breaking prod, and they fear it because they’ve never practiced un-breaking it. First move: execute and time an intentional rollback on a non-critical production system.

The cheat code: change the verb from “patched” to “non-exploitable”

For legacy systems, OT networks, or appliances you can’t modify, 15-minute patching is fiction. So change the verb: make the vulnerability non-exploitable or harmless within 15 minutes. That’s the Part 1 move: assume you can’t patch, then decide what you’ll do instead.

(source)

The difference (reminder for most, new for some...):

  • Patching eliminates the flaw. It requires vendor fixes, testing, deployment, and mutable target systems, factors largely outside your immediate operational control.
  • Mitigation reduces exposure risk. It relies on controls you own (network segmentation, identity policies, access gateways … at times an ax) without modifying target code, so actions can be pre-engineered and pre-approved easier.

The 15-minute mitigation exercise tests four capabilities:

  1. Can you isolate network paths immediately via automated policy?
  2. Can you revoke or scope down credentials in minutes?
  3. Do you know the blast radius well enough to isolate a component without breaking the business?
  4. Can you push a protection rule via API in minutes? (See API or Die.)

Your patch clock partly belongs to the vendor (partially). Your mitigation clock is all yours. For legacy, that’s the only 15-minute clock that matters.

But a segmentation diagram is not segmentation, and a kill switch nobody has pulled is a hypothesis. As I argued in Survival of the Basics, a mitigation counts only if it is a tested, operational control.

How to actually run this with your team

Book 90 minutes, a whiteboard, and the right people: platform/infra, an app owner, whoever runs change management, and QA. Security alone will find the gaps, but won’t own any of them.

  1. Select three specific target systems: modern (containerized service), median (standard application server), and legacy (high-risk core system).
  2. Map the clock for each system: document stage durations and identify the gaps.
  3. Identify the primary bottleneck stage.
  4. Define a single corrective move for that bottleneck: one bottleneck, fixed end to end (same logic as Baby ASO).
  5. Apply the mitigation model to legacy targets: establish rapid containment controls where patching is impossible.
  6. Track stage durations quarterly: progress shows up as shorter stages on your critical systems.

No time for a workshop? Pick a widely used component (a core library or agent) and time how long your team takes to find every active instance with high confidence. That’s your T+0 to T+1 baseline.

So, will you get to 15 minutes?

Containerized microservices can get there (yes, really, but provided some moons are aligned just right). Standard application servers can perhaps go from weeks to hours. Legacy systems need rapid mitigation (segmentation, credential scoping, containment) rather than patching.

What do you think? Is this totally crazy or what?

Related posts and resources:


The 15-Minute Patch, Reverse-Engineered: What Had to Be True? was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

  •  
❌