Table Of Contents

Table of Contents

How EASM Extends Vulnerability Prioritization to Your Full Environment

Why This Matters More in Regulated Industries

Discovery and Prioritization, Built Into One Platform

Frequently Asked Questions

More

subscribe to our newsletter

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.

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

By Aparna Ash Himmatramka

A developer using an AI assistant can ship a feature in an afternoon. In many organizations, the security review for that feature can still take a week.

Believe it or not, most AppSec programs are still built this way. BSIMM16, which studied 111 organizations, found security feature review in 80.2% of them. Those reviews made sense when teams shipped quarterly. Today they’re the bottleneck. What this means is that teams only review their crown jewels, and everything else goes unexamined.

Having worked in the AppSec field for more than 8 years now, I see this problem repeated over and over again. Until I realized it’s not a technical problem, it’s a gap of how we measure success for these programs.

The usual response is to make reviews faster: better triage, more AI in the review queue, one more hire. It helps for a while, but it doesn’t fix the real problem. Any program that needs a human decision for every change will grow with engineering output, and engineering output is now growing faster than any security team can hire.

So the goal shouldn’t be faster reviews. It should be needing fewer of them.

The model: humans set policy, the environment enforces it

In this model, no security engineer approves or blocks a deployment. Instead, the security team builds the systems that make those decisions automatically. We need a couple of pillars established for this model to run smoothly:

• Secure defaults. Templates, libraries, and infrastructure modules make the safe choice the easy choice, so fewer vulnerabilities get written in the first place.
• Automatic risk scoring. Every change gets a risk score based on what it touches and how critical the asset is. Low-risk changes move fast. High-risk changes get a deeper look.
• AI-filtered findings. Models grounded in your own codebase remove false positives and suggest fixes that look like your developers wrote them.
• Assurance scores instead of approvals. Every service has a health score that the deployment pipeline reads directly. Healthy services ship freely. Unhealthy services face limits proportional to their risk.
• Feedback loops. Recurring findings become new secure defaults. When a security engineer makes a call on a new issue, that call becomes a rule, so nobody has to make it twice.

The last one is what makes everything else work. It’s surprising how many programs fix the same bug class over and over across different teams. A program that learns eliminates the class.

What this looks like in practice

Every piece of this model has already worked at scale somewhere. What’s new is putting them together, with AI connecting them.

Netflix replaced reviews with a paved road. Their AppSec team concluded that per-app security assessments didn’t scale anymore and invested in secure-by-default frameworks and self-service guidance instead. One example is Wall-E, a gateway that handles authentication for web applications. The team rewrote their checklists to push developers toward Wall-E as a pre-approved default. When a team couldn’t use it, the security team extended Wall-E instead of granting an exception. By 2021, Wall-E fronted over 350 applications, and its adoption rate was on every leader’s security risk dashboard. Notice that accountability came from a metric, not an approval.

Google shows what happens when you design a vulnerability class out instead of catching it earlier. This isn’t shift left. Shift left moves detection closer to the developer, but someone still has to find and fix every bug. Google moved responsibility for safety away from the developer and into its languages, libraries, and frameworks. Before 2012, frontends like Gmail had a few dozen XSS vulnerabilities a year. After refactoring onto safe-by-design frameworks, that dropped to near zero. This month, an internal Google AI agent found over 500 XSS vulnerabilities across Google’s broader web applications, and only two across the hundreds built on its hardened frameworks.

And this isn’t just for tech companies. Capital One, a heavily regulated bank, built its own policy-as-code guardrails in 2016 to monitor and automatically fix cloud configurations against enterprise policy.

In none of these cases did the review get faster. The need for it went away.

Three lessons for security leaders

1. Accountability doesn’t require approval. The first question every executive asks is: if nobody signs off, who is accountable? The answer is consequences tied to risk. A service that stays unhealthy loses privileges that would increase its exposure, like frequent deploys, new dependencies, or autoscaling. At planning time, security health sits right next to reliability, and teams below the threshold get capacity reserved for recovery. When the constraint comes through engineering planning, it’s no longer a negotiation with the security team.

2. Measure what the program no longer has to do. Counting completed reviews rewards the wrong thing. The single most useful metric is the human touch rate: the percentage of changes that need any security engineer involvement. It should go down every quarter. Pair it with time to
remediate critical findings and the false positive rate. A falling touch rate is also how security coverage grows without headcount growing at the same pace.

3. Plan for the AI being wrong. The worst case is a false positive that blocks a team who knows the finding isn’t real. Therefore, give developers a fast way to escalate. The disputed finding should stop counting against them immediately, a security engineer should review it within hours, and every decision should go back into the model. Also, be honest about what automation can’t do. It doesn’t reliably catch business logic flaws, design complex authorization, or decide how much risk the business should accept. That’s where your senior security talent belongs, and this model gives them the time for it.

Where to start

Don’t start with AI. Models need your organization’s data to be accurate, and that data comes from the basics: consistent scanning, an inventory of services with criticality and data classification, and simple rule-based risk scoring. Make assurance scores visible before you enforce them. Add machine learning once you have several months of history. Expect about a year before the program starts improving on its own.

The takeaway

AppSec used to be measured by how many reviews it did. At AI speed, the better measure is how few reviews the organization needs while risk goes down and delivery speeds up. Make the secure path the easiest path, and let the environment do the enforcing.

About the Author

Aparna Ash Himmatramka leads an application security engineering team at Amazon.com. She will present this model at Hacker Halted 2026. The views expressed are her own.

The post Stop Reviewing Faster: A Practical Model for AppSec at AI Speed appeared first on CISO MAG | Cyber Security Magazine.

By Alex Holden, Chief Information Security Officer Hold Security

For nearly two decades I made the Dark Web a place to be; however, I am a hacker nor a cyber threat actor. I am a cyber threat intelligence professional with a deep passion for cybersecurity.

After spending a decade in the 2000s in corporate security, I realized that as a CISO, I neglected to understand the enemy. The bad guys who are actually trying to hack our systems.

We spent significant amounts of time and resources building defenses. We worried about vulnerabilities, malware, compliance, firewalls, authentication, policies, and the latest technologies promising to make us more secure. But too many of our efforts were driven by reactions to ongoing attacks, fears, industry headlines, and sometimes fear-mongering from vendors.

We were looking at cybersecurity almost entirely from our side of the battlefield.

Turning my eyes toward the Dark Web helped me understand the enemy and scale defenses to the actual threats and approaches being used against us.

Just think about how quickly technology evolves. Tools change. Encryption changes. Evasion becomes more sophisticated. Infrastructure becomes distributed and disposable. Today, AI is accelerating portions of that evolution even further. Our ability to defend gets tougher because the technology on both sides continues to change.

What stayed relatively static?

The threat actors themselves.

They are people too and they dwell amongst us in our society. They make mistakes. They have goals and motivations. They have egos. They need money or information. They trust the wrong people. They get angry. They compete with each other. They brag about success and complain about failure.

And criminals need other criminals.

A successful cyberattack is rarely just somebody sitting alone in a dark room wearing a hoodie. There is an ecosystem behind cybercrime. Someone develops malware. Someone finds vulnerabilities. Someone obtains access. Someone sells access. Someone steals information. Someone launders money. Someone negotiates ransomware payments. Someone buys the stolen data.

Those relationships create intelligence opportunities.

Going to the Dark Web gave me an opportunity to learn about the enemy and gave me more tools to deter and prevent cyberattacks and breaches.

It also taught me that you cannot understand cybercrime simply by collecting indicators of compromise.

An IP address can tell you where something happened. A malware sample can tell you how something works. Logs can tell you what happened inside your environment.

But none of those necessarily tell you why you were attacked, what the criminal was looking for, what they succeeded in taking, what they plan to do next, or whether they are coming back.

For that, sometimes you need to understand the people behind the attack.

Running a diverse team that engages threat actors and keeps an eye on the pulse of the Dark Web allowed us to discover and investigate many of the highest-profile breaches of all time.

Sometimes it means getting inside a ransomware gang and understanding how they function. Who actually makes decisions? How do they choose victims? How much information do the people negotiating with the victim really have? If a victim pays, should they rely on the word of criminals that the stolen information will really be deleted?

Sometimes it means understanding the threat actor’s view of a breach. Companies naturally investigate incidents by looking inward. What systems were compromised? What logs exist? What data could have been accessed?

But attackers may already be talking about what they actually obtained.

That creates a completely different perspective.

There is an enormous difference between information that could have been stolen and information that actually was stolen. There is also a difference between what criminals claim to have and what they really possess. Understanding that difference requires more than automated monitoring. It requires context, history, access, and understanding how these communities operate.

The same applies to tracking nation-state threat actors. Their motivations are different, but they are still people operating within organizations and relationships. Watching their dynamics, infrastructure, interests, tools, and targets helps us understand not only what happened yesterday, but what may become important tomorrow.

There is another misconception about the Dark Web that is especially important.

There is a lot of stolen data on the Dark Web, but data stolen does not always translate to data abused.

That distinction creates opportunity.

Credentials may be stolen before somebody uses them. Corporate access may be offered for sale before ransomware operators purchase it. A database may circulate privately before criminals figure out how to monetize it. Sensitive information may appear in one criminal community before spreading into many others.

Once data has been weaponized, our options become much more limited.

Before that happens, there may still be time.

We can reset credentials. Disable accounts. Investigate compromised systems. Change access rights. Notify organizations. Watch for fraud. Understand how the compromise happened and prevent the next stage of the attack.

This is one of the reasons simply searching the Dark Web for a company name is not enough.

The real question is not just, “Is our data there?”

The questions are: Who has it? Where did it come from? How recent is it? Is it legitimate? Who else is interested in it? What can they do with it? And perhaps most importantly, what are they likely to do next?

That is where information starts becoming actionable intelligence.

The Dark Web has changed considerably during the years I have been watching it. Communities disappear. Criminal marketplaces get seized. New communication platforms replace old ones. Criminals move between public forums, private channels, messaging applications, invitation-only communities, and direct relationships. Artificial Intelligence…

The location changes.

The need for criminals to communicate, collaborate, sell, buy, recruit, and monetize does not.

That is why understanding the Dark Web is not about knowing the address of a few criminal forums. It is about understanding the ecosystem.
The bottom line that every cybersecurity professional needs to be aware of is that the Dark Web is a pulse of cybercrime.

Ignoring it today is dangerous.

You do not need to become a Dark Web investigator yourself, but somebody in your security strategy needs to understand what is happening outside your network, not just what your security tools are telling you from inside it.

I learned a long time ago that defending only from your own point of view leaves a significant blind spot.

Therefore, I go to the Dark Web every single day.

To understand the enemy. To see what is changing. To find opportunities before vulnerable or stolen information becomes weaponized. To defend. To deter.

And to make the cyber world a bit better.

The post Why I Go to the Dark Web Every Day appeared first on CISO MAG | Cyber Security Magazine.