Webinar: A Case for CTEM

Paul Petefish:

Welcome everybody, and good afternoon. Welcome to "Why Your Business Can't Afford to Wait: The Case for Continuous Threat Exposure Management," otherwise known as CTEM. My name is Paul Petefish. I'm the President and Co-Founder of Evolve Security. Joining me today is Jason Rowland, Chief Delivery Officer, and Victor Marchetto, Manager of Advisory Services here at Evolve Security. Jason and Victor are our resident CTEM experts, and they'll spend the next hour explaining and discussing CTEM.

Jason and Victor, welcome — looking forward to gaining some of the wisdom you guys have. A couple of housekeeping things: we have this slotted for up to two hours, but we'll probably only run an hour. If there are really great questions, we'll continue on and potentially fill the whole slot. So, Jason, maybe kick us off with a bit of the history — how CTEM came about, who started the term. I think this is going to be interesting. Jason, please.

Jason Rowland:

Thanks, Paul. So CTEM was a framework created by Gartner a few years ago — maybe three or four years ago. It really seeks to address some of the fundamental gaps that are part of our traditional vulnerability management motion. It's gained a lot of momentum as a program that helps those activities stay aligned with business priority, and that has a continuous motion, which fixes the problem we've had with traditional vulnerability management — where it's a very static and episodic type of motion, which is obviously not the way that attackers operate.

It's impactful and effective. Gartner's prediction is that by next year, organizations that prioritize CTEM as their go-forward approach for managing exposures are going to be three times less likely to suffer a breach, which is a big impact.

Paul Petefish:

So, Jason, a very simplistic way to look at it is that this is an evolution of vulnerability management — a vulnerability lifecycle management model.

Jason Rowland:

Yeah, I think it's the next iteration — one that really accounts for the fact that our attack surface is fundamentally different than it was ten years ago, or even five years ago, when we were using vulnerability scanners to scan owned IT assets and then prioritize based on the scores they gave us. So it's the next evolution of vulnerability management.

As for why it's needed: as our attack surface has grown, we've continued to deploy multiple vulnerability scanners. I know a lot of organizations that have two or three of these things. What we've found is that the number of vulnerabilities we can identify through traditional scanning is overwhelming. When you look at the list — even the prioritized list these programs turn out — it cannot be consumed by an organization.

This is a story we hear a lot from our customers: "We do our vulnerability scans, we prioritize them the best we can — maybe there's some risk-based prioritization, certainly a lot of prioritization based on CVSS — we take those results to the business, to our IT partners or development partners, and we can't get movement." The reason they can't get movement around remediation is that a lot of the time they cannot articulate the business impact of those vulnerabilities, and they can't demonstrate what the actual impact is. And of course, when you're dealing with that much data, there are going to be false positives — and once you get one or two of those in the mix, you start to lose credibility as a security team.

So a lot of these vulnerabilities go unresolved, and that comes at a real cost. The cost of a data breach continues to rise year over year. What's interesting is that vulnerability exploitation as an initial access vector has reclaimed its spot on the podium as one of the number-one ways nefarious actors gain a foothold to facilitate these breaches. I think the reason — and there's a lot of data around this — is that when everything's important, nothing's important. In the sea of data being turned out by a vulnerability management program, you miss the things that truly have an impact because of the amount of noise. CTEM is a program and a framework to address exactly that — to make sure we understand what's important from a business-priority perspective, and what exposures in the modern attack surface could negatively impact it.

Paul Petefish:

Jason, I just want to comment on your point about vulnerability fatigue and alert fatigue. That's what I'm hearing a lot in discussions with cyber leaders. More vulnerability data is not better. We're looking to be more thoughtful, to enrich the data and understand what the true business impact is. For larger organizations, it truly is overwhelming and almost paralyzing.

And just a quick comment on that chart you shared — it's a pretty striking statistic around the number of CVEs dropped in 2025: about 40,000. These are known vulnerabilities. That's about 90 a day. The velocity at which these things are being released is incredible and extremely hard to manage and keep up with. Hence the evolution here.

Jason Rowland:

And that really only accounts for traditional vulnerabilities — that's not misconfigurations or what we'd consider an exposure today. That's just software vulnerabilities.

My last point: for the last ten years, I've seen this resource shortage, and we've been a part of it. Teams aren't staffed all the way; they don't have as many resources as they'd like. And I don't think that day is necessarily coming. As an industry, we have got to stop relying on the scale of resources and get very smart and very targeted with where we spend the resources we do have. One day we may have the resource constraints figured out — but I don't see it in the near future.

Paul Petefish:

You guys have done an excellent job of framing the problem with traditional vulnerability management programs. Let's break it down and talk about what CTEM offers as an evolution — or maybe an improvement — on how to tackle this problem. Victor, take us through it.

Victor Marchetto:

There are a lot of differences between the CTEM approach and a traditional vulnerability management program, and we'll break these down in phases. It does bear mentioning that aspects of this run in cycles — it's an iterative process, and some phases are ongoing and evergreen, happening around the clock. But think of it like a sprint, and we'll walk through the process.

As mentioned, scoping is a huge issue in a traditional vulnerability management program, because the scope is everything — all of your infrastructure, externally facing assets, internally facing applications, and the like — and you're scanning that on a regular basis. CTEM proposes a different approach: you get specific about the scope. You pick something you can manage through this whole cycle in about 30 to 45 days. And to deal with the buy-in problem — where at the end of the process you have to articulate the impact to the organization — CTEM argues we should do that from the get-go. So let's pick an application in its entirety, something manageable, and get specific about it — something that has real impact to the business. That could be a key customer-facing application or a key dataset, and you work to include everything that supports that impactful part of the business. Understanding that and writing it in from the get-go is important.

Jason Rowland:

The clarifying thing for me around scoping: I grew up in a world where, when you're going to scope any kind of assessment of this type, you ask questions like "What are your IP ranges? What are your CIDRs? What applications do you have?" What CTEM proposes is that we ask questions like "What are the high-visibility, priority business processes that are in focus for your organization from a business perspective?" — and then, "What are the applications, assets, environments, and partners that support those business processes?" Just going through that process at the beginning of your CTEM sprint really helps clarify things far beyond what you can do by asking about technology assets.

Victor Marchetto:

A true mindset shift there, and it's powerful. You have to start there, and that may require some additional conversations. I don't know if your organization has a regular business impact analysis, but that might be a good place to start to look for the key functions of your organization. Those conversations early on will help you build a really tight scope, which sets you up for success at the end of this process — because you won't have to re-articulate why this matters. It's built in from the start. You start with what really matters to the organization: if we didn't have this application, this information, this capability, what would that do to us? What kind of impact are we looking at? When that's high enough that everybody agrees, we can move on to the next phase, which is discovery.

So once you have that really tight scope, the discovery phase is ideally something you're doing consistently — your vulnerability scans, your pen tests, your threat intel. You have this pool of information that you can then filter by the scope you have. Given the scope we've selected, what's out there that could potentially impact it? Doing good discovery and good enrichment helps you filter down from just CVSS scores and the prioritization those bring. Now you can say, "These are the things that affect these systems, based on the scope we've selected."

Jason Rowland:

One thing to add as you move out of discovery and into prioritization — and certainly into validation — is that I think this is part of the power CTEM unlocks. I've long believed that what a great, well-run modern defense requires is continuous red-team thinking associated with how they prioritize their spend and their activities. There was a Mandiant survey a couple of years ago that said about 70% of cyber decision-makers did not understand their greatest threat, or the threat actors targeting their organization. To me, that means there's a good chance we're writing checks and spending money and time on things that may or may not have a direct impact on stopping bad guys.

So as you come out of discovery and into how you prioritize and validate, it's critical to bring red-team thinking to the table: these are our important assets, these are the exposures we've discovered — now let's think like bad guys and figure out how we could use these exposures to impact the business. Then let's go validate our thesis. That brings a whole new level of focus and rigor — and again, it doesn't include cleaning up 100,000 CVSS-nines with no attack surface. It's very focused.

Victor Marchetto:

It's decoupling the discovery in the traditional vulnerability management program from the immediate action. We're finding out a lot of potentially concerning things, but we're being selective about what we're going to act on. So in the discovery element, you're enriching and layering your traditional tools with the red-team thinking Jason was talking about, so we get more nuance beyond just the tool output.

Then we move into prioritization, and that's when things start to move toward execution. Given the specific scope, and given what we already know about the potentially concerning issues or exposures related to that scope — what do we care to solve for? We shouldn't be spinning cycles on informational or low-impact exposures. This is another filter that keeps us focused on where we should spend our time and effort as security professionals. We're constantly dealing with almost infinite risks and finite resources, so we have to choose where to fight our battles.

From there we move to validation, which is yet another filter, where we test to see if these can actually be exploited. We do a proof of concept — can these things be exploited in real time in our environment? Would we detect it? If that's the case, we move to mobilization. We've filtered at each stage, down to contextually relevant assets and the exposures that target them and are exploitable. Now the mobilization effort can take off, focused on things that could happen, that would matter, to assets that matter to the organization.

Jason Rowland:

On prioritization — inside our Darwin attack platform, which we use for continuous pen testing, we go beyond CVSS. It's things like: What is the exploitability? What does threat intel say about whether it's being used in the wild? Is there even a proof of concept available? That's from a vulnerability standpoint. From an asset standpoint: what is its function? There are certainly assets whose function makes them far more attractive to an attacker, and others that aren't. All of that goes into our scoring, and into being able to prioritize exposures so you know what to immediately go validate. And I like what you said, Victor — by the time you get to mobilization, you've got validated, business-impacting exposures that you can sit down and discuss with organizational stakeholders. That brings a lot of validity to the table for moving the ball forward on security posture.

Victor Marchetto:

On the mobilization piece, CTEM talks about how to bring folks into the same room — making a kind of strike team, a group of key individuals: security, infrastructure, application owner, a change-management delegate. It depends on your governance and organizational structure, but you get all the people in the room who can take action and run these things to ground. They're assigned to specific people — someone owns this. And you do even a bit more risk prioritization, because even of the list you validated, you still have to choose a priority. Keeping that tight really helps you maintain momentum and keep that continuous process going.

That's it in a nutshell. You can see how it addresses the same problem as traditional vulnerability management, but in a way that lets us make decisions along the way, so we spend those finite resources in the best possible places. And there's a lot of evidence and homework done along the way to defend those decisions to the rest of the business, bringing everybody into alignment.

Jason Rowland:

It's a very pragmatic, approachable way they've set this out — you don't have to boil the ocean right out of the gate.

Victor Marchetto:

Right — you start with bits and pieces, and as you cycle through them, you keep adding. By the time you get through it, you'll potentially have everything covered, but you're doing it a piece at a time in a very specific window — 30 to 45 days to get your arms around it. Then you iterate and pick something else.

And the scoping effort doesn't have to be perfect out of the gate. CTEM is a process and a methodology — it's not a product. You can't just install CTEM into your security program. It's a different way of thinking, a different set of procedures for approaching these problems. In the scoping period, maybe your first couple of iterations leave some things out — you'll get them on the next run. It's about narrowing the focus so the depth and context can be there, versus trying to boil the ocean. But let's move on to the maturity model, because I do want to talk about what adoption might look like.

Paul Petefish:

Let me take a quick moment on the maturity model, and give credit where it's due. You and Jason worked on this. Jason, you took an initial cut and had the idea to build this maturity model — which we believe is one of the first of its kind — to take CTEM from theory to more of an actual operating process, with the maturity overlay. So kudos. This is super helpful and really starts to help quantify what this looks like and how it might work into any given organization. Well done, guys.

Jason Rowland:

Thanks, Paul. As someone who has implemented and matured many programs across many domains of information security, I'll tell you it's easy to get lost in the woods and not know exactly where you are or where you should be. And to be clear — I'll let Victor cover this — the maturity model is just a guide. There's a fuller, richer guide available, or that will be available, on our site. But it's really just a way to say "Where am I today, and what's the next step or the next set of activities I need to engage in if I want to move our maturity level up?" You may find yourself at level two in some places and level one in others. It's not meant to be a perfect step-by-step guide — it's a way to assess and help define your journey across the levels of maturity with CTEM.

Victor Marchetto:

Exactly. If you don't have a roadmap, it's hard to articulate what to do now, or where to go from here, or whether it's enough. The maturity model helps in that regard. There's more to it than this — if we were really going through it, we could spend another hour on the maturity model alone. But the idea is that as you look to adopt this process, some of your existing practices are going to be more mature than others. Understanding where you are, and what the benefits are of moving to a higher maturity level in a different phase of the CTEM approach, helps you decide where to spend your resources or where to train — for example, to be better at scoping, where scoping could be more nuanced. Discovery is one of those critical aspects: there's a lot to consider when you're enriching how you understand and discover the potential exposures in your environment.

Paul Petefish:

Victor, just to make sure everybody's clear — the more robust materials, guides, and documentation are available on our website now, or will be?

Jason Rowland:

Victor just published a blog post on this in particular, and there's a more detailed guide coming that will be available on the website.

Paul Petefish:

There'll be an ebook with all of this information, and a deeper dive into the model itself.

Victor Marchetto:

So if you think about it from a scope perspective — where it says "compliance-driven" — we'll give you a sense of what that really looks like: what actions you're probably taking today, and what more mature activities you might want to introduce to move to the next level. Let's unpack scope as an example. At level one, your activities are tied to compliance or contractual requirements. My client and I have an MSA where they require a risk assessment, or there's a series of controls we have to satisfy to pass an audit. We're just checking boxes — that's really all that's happening in maturity level one for scope. At level four, we're making decisions based on an upcoming merger or acquisition; we have threat intel about the threat actors that would target our particular business; we know where our assets are, inside and outside the organization; and we're considering all of that to determine the scope we're going to select. So there's a lot more detail and nuance to how we articulate what the scope is for a CTEM sprint.

Paul Petefish:

Victor, I want to make sure I understand where the "continuous" comes in. We have these five steps — scope, discovery, prioritization, validation, and mobilization — and you run through a sprint. I like that terminology; it matches the spirit and intent of the smaller scope and the quicker outcomes. But where does the continuous come in, and how does that work into the process?

Victor Marchetto:

The way it's continuous: you run through a sprint where you select a scope, filter from what you've discovered as it relates to that scope, prioritize which of those discovered exposures are worth tracking down, attempt to validate or make a proof of concept, and then mobilize to fix what's been validated. Discovery and mobilization happen continuously — you're always discovering more exposures, and they await the time when you select a scope that includes them. And you're constantly mobilizing to fix whatever's the highest priority once it gets filtered down. There will be outliers — things you discover that need to be addressed ASAP — but in general, discovery is always looking for exposures, and that's the continuous part. The whole CTEM process iterates, so it continues as well.

To me, one of the driving philosophies behind CTEM is that we have to focus somewhere. We have to choose what to spend our time on, and there's a reason we want to spend time and resources on certain exposures over others. To do that, we have to filter somewhere — which means getting specific about what we care about for a period of time, and prioritizing and validating what we find, so we can go tackle the things that are most critical, or whatever your risk threshold is.

Jason Rowland:

Let me put a more hands-on definition to it, Paul. Anywhere our organization is engaged with a customer doing continuous pen testing, any areas of their environment that are in scope are continuously being discovered. As we find exposures, they're enriched with prioritization signals like EPSS, KEV, and other threat intel, as well as an understanding of the attacker attractiveness and business function of the asset. Our OSOC team is continuously taking those exposures, based on priority, and validating that they exist. So when a customer comes to the Darwin platform and logs in with their scope — having gone through the process of figuring out what's a priority — they already have a set of discovered, prioritized, and validated exposures they can use to start driving decision-making in the mobilization process.

Paul Petefish:

Excellent example — thank you, Jason. Quick time check: we're about 30 minutes in, and we want to make sure we give plenty of time for Q&A. Let's talk a little about our fast track.

Jason Rowland:

I'll open this up — and again, this is great work Victor's done. When it comes to continuous pen testing — and to be clear, there are a lot of components to CTEM, but when it comes to continuous pen testing specifically — you obviously have to be great at the actual offensive security piece, and I think our resources and methodologies are second to none. But one of the things that really differentiates Evolve Security from a lot of folks out there is that we also have the strategy and program-management chops to deliver great offensive security and make sure it's initiated and maintains alignment with our customers' needs.

A lot of security is the same — a lot of the motion one organization does over another is the same — but it's the 10 or 20% of tailoring that makes exceptional security. When we engage in our offensive security managed services, we bring people like Victor and his team, as well as our service-management team, to the table to make sure this thing is aligned as well as possible. So, Victor, maybe walk us through how we help organizations get started — because it's one thing to be told about CTEM, and another to see it in action and actually work through it.

Victor Marchetto:

Certainly. CTEM is an interesting thought experiment for how we might do vulnerability management a little differently. But when the rubber hits the road — actually adopting it — the question is "Where do I start? How do I begin this?" So at Evolve, we created a fast-track assessment. As we bring customers on, we do an onboarding, get them into the Darwin platform, and get the resources up there regardless of their scope. We make sure they understand how to interact with it, and we begin discovery of an environment — maybe their external environment. We run a workshop where we help them with scoping and prioritization: what's important to you? We pick a scope from there, then go out and do our thing with discovery and automatic prioritization based on the exposures we find. Then we validate those things, so they get to walk through an entire cycle with a given scope in CTEM. At the end, not only do they understand how the cycle works, but they also get a recommendation — or a set of recommendations — that says "Here's where you are on the maturity model, and here's how you can move the ball; here are the most important things you can do to start the maturation process."

So there will be real-world findings and recommendations — it's not all theoretical. We're doing active discovery, we validate, we step you through the whole process. In addition, we provide guidance on how you can take this and expand it internally — how to run your own sprints against other scopes. You'll have a sense of how it worked for you in this instance, and a roadmap for where you may want to continue the adoption process.

Paul Petefish:

This is great — what a thoughtful offering to put together, and a very pragmatic approach to implementing this. Like any new framework, there will be changes along the way as people actually start to use it, but you've got to start somewhere, and this is a great start.

As a thank-you to all of our attendees: everybody who's attending will be registered to win, in a drawing, a CTEM fast-track assessment. We'll report the winner over the next few days. That's the least we can do to show appreciation for everybody joining us.

Victor and Jason — anything else before we flip into the Q&A?

Jason Rowland:

This has been great. The one other thing I'd say is that Victor and I are available to anybody attending today. If you want to have a deeper conversation around some of this — I know it can be conceptual and hard to wrap your mind around, and we think about this stuff all the time — we'd love to talk. We'll make sure there's contact information so you can reach out to us.

Paul Petefish:

Thank you, Jason. I just saw "talking permitted" roll across the attendee list, so everybody's unmuted from our side. Feel free to speak up, or drop something in the chat — we'd love to hear what people are thinking.

Audience question:

Hi, I had a quick question. Does CTEM only perform with signature-based threats, or how does it go beyond signature-based detection and exposure?

Jason Rowland:

As far as identifying exposures — a CTEM program should employ a number of different kinds of tools. A vulnerability scanner may certainly be part of that, but there should also be things like open-source intelligence incorporated, and non-vulnerability-based exposures that get identified. There's a plethora of tools and processes for doing that. As you're transitioning from vulnerability management into CTEM, I don't know that it's day one when you want to incorporate all of that — but incorporating things beyond just standard vulnerability scanning is very important. And nothing can replace the manual validations that humans bring to the information that gets compiled. So that's an important component as well. Does that answer your question?

Victor Marchetto:

If I might add a little to that — as a kind of wacky example: let's say we're talking about an application hosted internally, in a data center within one of your offices. It's just one server somewhere, and there are no locks on the doors to that server room. So there's a physical vulnerability there — a potential exposure for anyone with access to that office being able to walk in. Is that something you're going to be able to measure via vulnerability scans? No. But that's the red-team thinking that, at some point as you adopt this, you're doing: Is there physical access to these assets? What's the likelihood of this occurring? What could someone do with that kind of physical access? Depending on how you go through the rest of the CTEM process, that may drop out in terms of high or low priority — but vulnerabilities and exposures like that can be captured by this process. It's not just looking at tool output.

Jason Rowland:

That's a great point. One of the biggest changes to the attack surface over the last five or ten years is that a lot of it is non-patchable — meaning you don't own it. We don't own it, and you cannot take a traditional approach. When you look at things like SaaS providers, partnerships, and third-party organizations, those things have to be taken into account. You're not going to patch them — you need to address them, but it's going to be handled in other ways. And to your point, Victor, that's where bringing offensive-security people to the table — to figure out how you would exploit this, and how you would stop it — becomes very important.

Paul Petefish:

Excellent — that's a great question. Thank you. Next question — again, feel free to put something in the chat. Any other questions out there? I want to make sure I'm not missing the chat, but I've not seen anything. I think Victor must have covered it with such mastery.

Well, if there are no other questions, let's go ahead and wrap. A lot more to come: Victor's working on the CTEM Chronicles, and he's got a lot of good information out on our website and through our LinkedIn. There's an ebook coming that aggregates all of that into one source — it's on its way. And keep an eye on your email to see if you're the winner of the fast-track assessment.

I really appreciate everybody joining. Thank you for your time and attention. Jason, Victor — well done, and I appreciate your delivery here and all the work you've put into this maturity model that we're opening up and sharing with the world. Awesome. Thanks, everyone — have a good rest of the week.