Skip to content

Unsupervised Learning Security AI Business

A Conversation with Dan DeCloss

Daniel Miessler interviews Dan DeCloss, the founder of PlexTrac, and about seven minutes in it turns into a live walkthrough of the product. DeCloss came up through GRC into penetration testing and built PlexTrac because he loved testing and hated writing reports, but the pitch now is that discovery is no longer the bottleneck: scanners, testers, and AI all find plenty, and nobody can say which of 23,000 open finding instances will actually get you breached. He demos contextual risk scoring where a Tenable critical lands at 56, an algorithm editor scoped per department, bidirectional Jira and ServiceNow sync so IT never opens the security console, MITRE ATT&CK playbooks that generate a finished report, and the write ups library that stops client data bleeding between reports. The last three minutes turn to Claude Mythos and the vulnpocalypse, where his position is to put AI upstream in the SDLC and downstream on the backlog, because the known knowns are still where the bulk of the work is.

Published Jul 13, 2026 25:27 video 36 min read Added Jul 25, 2026 Open on YouTube →

At a glance

Daniel Miessler sits down with Dan DeCloss, founder of PlexTrac, for twenty five minutes that start as a founder interview and turn, about seven minutes in, into a live walkthrough of the actual product. DeCloss has been in cyber security for twenty plus years, came up through GRC before moving to penetration testing, and built PlexTrac out of a specific personal grievance: he loved testing and hated writing the report. Miessler, a pen tester himself, says the same thing in almost the same words at 1:50.

But the conversation is not really about reporting anymore. The thesis DeCloss returns to over and over is that the industry no longer has a discovery problem. Scanners find plenty. Pen testers find plenty. AI is about to find vastly more. What nobody can answer is which of the twenty three thousand open finding instances in front of you is the one that will actually get you breached, and that gap is what PlexTrac has spent the last several years growing into: aggregate every finding source into one place, score it against the business context that is true for your company, hand the security team a ranked list, and then push the work out into Jira, ServiceNow, or Azure DevOps so the people who actually fix things never have to log into a security dashboard.

The demo section is the meat. DeCloss clicks through exposure management, the risk scoring algorithm editor, integrations, status history, the workflow automation engine, the write ups and narratives libraries, MITRE ATT&CK based playbooks that generate a finished report at the end of an engagement, compliance questionnaires, and asset management. Then the last three minutes turn to what happens when Claude Mythos class models start finding vulnerabilities at machine speed, and DeCloss lands on a position that is both modest and useful: the answer is not to slow AI down, it is to put AI upstream in the SDLC so less broken code ships, and downstream on the backlog so defenders fix the right things first. This page rebuilds the whole conversation in order, including the parts of the demo that only make sense if you saw the screen.

Chapters

0:00 What is the core problem you are trying to solve? 1:33 How has PlexTrac evolved over time? 3:57 What attack trends are you seeing in the wild right now? 5:21 How do you factor business context into vulnerability prioritization? 7:13 Platform walkthrough: risk scoring, integrations, and playbooks 21:47 What new features are you excited to be working on next? 22:52 What was your recent Hacker News article about?

The problem he is actually hot on

Miessler opens with the question he says he always likes to start with: what is the problem you are really hot on and excited to try to solve?

DeCloss answers with his own career shape. His background is penetration testing. He has been in cyber security for twenty plus years. And the thing he has always tried to focus on is helping organizations prioritize the right things, meaning the things that will actually get them breached, then remediate those things, then stay focused on what an attacker can genuinely do inside their environment.

The origin of that focus is a frustration. He grew up partly in the GRC space, and with a technical background sitting underneath him, he kept feeling that GRC was not really asking the operative question. Not "did we check the box," but "what are attackers actually doing in environments, and how are those things actually getting people breached?" That gap is what pulled him toward penetration testing, where the technical aspects are literally how an attacker does the work. He describes himself as a hacker by trade in the older, nicer sense of the word: someone who always wants to understand how things work. Those were the things that got him excited.

Why PlexTrac exists: he hated writing reports

Then he started PlexTrac, and the founding motivation is refreshingly small and specific. He wanted to remove some of the friction in the pen testing process. They started in the pen test reporting space because, in his words, he hated writing reports and hated the lack of collaboration on findings, which arrived in a very static way, a document, a PDF, a thing that sat there.

What he wanted instead was a dynamic platform. Not just a report generator, but a place where the findings that are critical to an organization live right alongside all the other risks that are getting reported. That single design decision, findings from a pen test sitting in the same store as findings from everything else, is the seed of everything the product later became.

What still gets him excited, he says at 1:21, is helping people fix the right things, helping them avoid getting breached, and helping them know exactly what an attacker can do in their environment.

How the product evolved

Miessler says he has been aware of the product for quite a while and asks how much it has changed, particularly given what is happening now with AI attackers. Is it moving toward remediation in addition to reporting? Because the great thing about PlexTrac back in the day, he says, was that it helped with the part of the pen test that was the worst for the tester. Then he says the line every pen tester has said out loud at least once:

I always loved testing and I always hated reporting.

DeCloss confirms the expansion. Reporting is still the roots and still a very important piece of the puzzle: helping testers stay focused on more testing and less reporting is still core product. But four more layers have grown on top of it.

Stage 1Pen test reporting. The origin. Kill the static document, kill the copy and paste, let testers spend their hours testing instead of writing. Still core product today.
Stage 2Centralize every finding source. Vulnerability scanning, application scanning, code scanning, all of it pulled into one platform, so the pen test findings become an overlay on top of the whole vulnerability management picture rather than a separate PDF nobody opens.
Stage 3Risk scoring and prioritization. Score every finding against the context of the environment, because the blue team problem is not "I have no findings," it is "everything is labeled critical by Nessus and by my pen testers, so which one do I fix first?"
Stage 4Workflow automation for tracking and remediation. The track in PlexTrac. Visibility on who is doing what on the fix side, bidirectional ticket sync, triggers, assignment, escalation.
Stage 5AI on the lifecycle. Today it writes findings and reports from the context of the finding. Next it moves into recommendation and automation across remediation and prioritization. Announcements teased for "the near future."

Figure 1. The arc DeCloss describes when asked how the product changed. Each stage is additive, not a pivot: reporting stayed, aggregation wrapped it, scoring ranked it, workflow pushed it out the door, and AI is now being layered across the whole lifecycle.

The blue team pain point he names at 2:44 is the crux of the whole interview. A defender opens the console and sees tons of issues. They are all critical. They are all stated critical by Nessus and by the pen testers. So how does anyone know which ones to fix first? Because, as he puts it:

At the end of the day, we don't have a problem of sourcing findings. It's more where are the right ones to be fixing now that'll make the biggest impact on our business.

So the expanded product does three things: aggregate the data, provide a mechanism for scoring and prioritizing findings within the context of the business, and then facilitate workflow automation around tracking and remediation.

On that last one he tells the story that explains the company name. The track in PlexTrac has always been about tracking and remediation, and it comes from a specific failure mode he lived through as a consultant: he hated delivering a pen test report and then coming back a year later because nobody had fixed anything. Some of that is a procedural breakdown, he says with a certain generosity. They did not copy and paste the right data into the spreadsheet or the ticketing system. Or, less generously, they did not care about it at all. Either way, the fix is the same: permanent visibility into who is doing what on the remediation side, and as little friction as the platform can strip out.

What AI is actually changing in the wild

Miessler asks the AI question directly at 4:06. One of the narratives is that AI is letting people attack faster. What is DeCloss seeing in findings, what are Customers reporting back, and how is PlexTrac helping?

DeCloss's answer is notably unhyped, and it is worth quoting because it cuts against the way most vendors answer this question. As an industry, he says, we do not have a problem identifying more issues. Yes, AI is accelerating attacks and providing new attack vectors and new mechanisms. But the attacks still tend to be exploiting some of the same things, just at a faster pace, alongside identifying more issues.

Which means the defender's question does not change at all. It is still "what are the most important things I should be fixing first." That is the problem PlexTrac is trying to solve and, he says, does help solve: giving you a better perspective on the prioritized list. And then the sentence that becomes the through line of the last third of the conversation:

That list is going to continue to grow deep, and AI will only continue to make that list bigger.

He also draws a clear product boundary here, twice in the conversation: PlexTrac does not do automated remediation. The goal is to provide as much recommendation and automation around that process as possible, and to integrate with the products that actually perform the fix. Miessler agrees it gets a little sticky when vendors try to own the whole thing.

Context driven risk scoring

Miessler picks up the word "context," which he calls one of his favorite words, and asks how the business context gets factored into the prioritization.

DeCloss frames PlexTrac's approach against the industry norm. A lot of products and companies provide their own proprietary risk scoring mechanism, a black box that hands you a number. PlexTrac took a different approach. There is a default out of the box calculation using the things commonly associated with a risk score: asset criticality, the location of the asset, the type of data it processes, and so on. But then the flexibility goes back to the Customer and to the user.

You have full control over how those factors get weighted and what additional criteria you want to add, so you can say, in effect, this is how we structure our data, these are the fields that matter most to us, and we want those fed into the risk score. Full flexibility over what criteria go into the algorithm and what weights they carry. The result, in a phrase DeCloss likes, is an objective overlay applied in a somewhat subjective manner.

And it does not have to be enterprise wide. You can break the calculation down by department or division. Keep a default enterprise wide risk calculation, then give an R&D department that needs different scrutiny its own scoring algorithm. Miessler reads it back as Customers having a decent amount of control over the schema for the ratings, customizable per group, which is exactly right, and then asks the question that turns the interview into a demo: are you able to pull that up?

two examples from the demo

Tenable says CRITICAL accounting dept algorithm score 56 = HIGH context pulled it down a notch tester says CRITICAL default equation, no asset score = LOW no criteria were met scope: enterprise wide default, or per department / division an R&D team that needs different scrutiny gets its own algorithm

Figure 2. How the score is built, using only the variables DeCloss actually names on screen. Three families of inputs feed weighted, editable categories; the output is a 0 to 100 style score that can override the source severity in either direction. Both worked examples are real moments in the demo: a Tenable critical landing at 56, and a pen tester's critical landing at low because no asset was attached.

The walkthrough: findings, instances, and the number 56

At 7:15 the screen share starts and DeCloss is inside the exposure management module.

He explains the data model first, because everything downstream depends on it. There are findings and there are instances of findings. Think of a finding as "we have SQL injection." Each reported occurrence of it is an instance of that finding. That distinction is what lets one vulnerability class carry twenty three thousand real world occurrences later in the demo.

In the left hand column of the table sits the risk score. The finding at the top is labeled critical by its source, which he believes was Nessus, or Tenable. But its PlexTrac risk score reads 56, which lands in the high band, not critical, because it is being calculated by the risk scoring algorithm attached to it. And this particular algorithm is scoped to the accounting department specifically.

He opens the calculation to show what composes it. Instance severity and asset criticality are the two most heavily weighted inputs. Then a couple of others he set up for this example: is there a known exploit for it, and has it been used in a known ransomware campaign. That is the whole idea of contextual scoring in one screen: the scanner says critical in the abstract, the algorithm says high for this department on this asset, and the second number is the one that should drive the work queue.

Clicking into the algorithm itself opens the editor. Here you can see how points accumulate within each weighted category, and you can build a very robust set of rules. You can change the weights themselves. And you can add additional variables, which come in three families:

Asset related variables. If you tag all of your assets, or want to base scoring on their physical location or asset type, that is available.
Finding and instance variables. Anything about the finding itself. Did it have a CVSS score of four? You specify what score bands map to what criteria. Tagging works here too.
Custom fields. Any custom field you already use inside PlexTrac is exposed to the risk scoring engine. DeCloss says they see Customers lean on this a lot, because organizations tend to have custom fields they already use across their entire environment on assets or findings, and those are exactly the fields that encode the business context nobody else knows about.

The daily view: dashboard, assets, and the ticketing sync

Miessler asks what a Customer actually sees day to day. When you land on PlexTrac you get the general dashboard: open findings, that kind of thing, plus assets with critical findings. Drill into exposure management and you can pivot the whole view around assets. What assets live in my environment. How many findings does each one carry. DeCloss picks one asset and reads off its findings, their status, and who is assigned to what. The same drill down works at the finding and instance level.

Then he opens the integrations filter and the list of vulnerability scanning vendors PlexTrac ingests. But the more interesting integration, and the one he clearly cares about, is the ticketing side: Jira, ServiceNow, Azure DevOps, and those are bidirectional syncs.

The reason he cares is workflow, not features. If your IT operations group or one of your development teams has to leave their tooling and come into a security platform to update a ticket, they will not do it, and the security team ends up chasing them. So the ticketing and remediation process happens inside the fixer's own workflow, and that data syncs back into PlexTrac and automatically updates the status of the finding.

Miessler reads it back: so they can close an item inside their own workflow without having to come back to the dashboard. Exactly, DeCloss says. You are not interrupting anyone's workflow, and as the security team you still have a centralized view of everything that has happened and who responded to it.

He clicks a finding to show its full status history, and apologizes that it is a demo environment so it has been used a lot. He also notes you can define custom sub statuses to match your own process, things like "ready for retest" or "ready for review."

sources pen test findings Tenable · Qualys · Rapid7 app + code scanning Nmap scan results assets via API

PlexTrac findings → instances → assets contextual risk score weighted, per department priorities group instances + assets into one ranked queue

mobilize tickets Jira · ServiceNow · ADO notify Slack · Teams · email assign named owner, sub status

bidirectional sync: status flows back and updates the finding the fixer never has to open the security console

Figure 3. The whole platform in one picture, drawn only from what appears on screen during the demo. The point of the return arrow is the design philosophy DeCloss states outright: IT and development teams close their work in their own tooling, and the security team still gets a centralized record of who did what.

The workflow automation engine

DeCloss then opens the workflow automation engine, which reinforces the same mechanism from the other direction. Inside the reporting module, if a pen tester reports a critical finding, then the moment it is published it can be immediately assigned to somebody.

Miessler asks who these people are: someone on a dev team, someone on a security team? Both, DeCloss says. In this example you can assign to a specific person, send it to Slack or Microsoft Teams, say into an open escalations channel, send emails, or immediately create tickets directly in the target system such as ServiceNow. The flexibility is deliberately wide so you can automate as much as you possibly can. And then the boundary again: they do not do the remediation itself, but they integrate with the products that do. Miessler: "that gets a little sticky when people try to do the whole thing."

Miessler asks whether triggers can fire off criteria like department plus severity. The trigger fires off the finding itself, DeCloss clarifies, and then you can layer criteria on top: if it is also assigned to this person, then go do these things. The base events are finding created, finding edited, or finding status changed, including a change to a specific sub status.

Libraries: write ups and narratives

Miessler spots the questionnaires, playbooks, and libraries in the navigation and asks what they are. DeCloss starts with libraries, which are pre built content and sit closer to the original reporting product.

The pitch is aimed squarely at anyone who has written a pen test report. You already have your standard way of writing up SQL injection. You already have your standard cross site scripting narrative. In PlexTrac those are write ups, stored in the write ups database. PlexTrac ships multiple sources of them and plenty of Customers bring their own.

The obvious benefit is reuse. The less obvious benefit is the one DeCloss actually emphasizes, and it is a genuinely good point that only a practitioner would raise: it reduces bleed over. When you copy and paste from one report into another, information unique to the previous Customer comes along for the ride. Every consultant has had that heart stopping moment of finding another client's hostname in a deliverable. A write ups database removes the copy and paste step entirely, so the bleed over cannot happen.

The narratives database is the same idea for the prose sections of a report: the executive summary, the methodology, the scope, all the parts that are written rather than enumerated. Pre built, templatable, so you can define the ten sections of the report you always want and have them appear.

Two Customers, one platform: internal teams and consultancies

Looking at the libraries, Miessler has a realization on camera. He had been thinking about internal use: a big corporation or a mid size company using this to explain findings to internal Customers, manage remediation, prioritize vulns. But the libraries make him see the other market. This could also be a pen test company, with multiple testers doing tons of work for different clients who want very different deliverables. Some Customers want cold, hard, direct truth in no more than three pages. Others want a giant twenty page verbose thing.

One hundred percent, DeCloss says. PlexTrac supports consulting teams working with many clients. The demo environment is an enterprise demo, so the containers are labeled departments, but in a consultancy those are the equivalent of a client, and you write a report for that specific client. Equally, a large enterprise with an internal pen testing team can write its own pen test reports in the platform and bring all its other findings together in the same place. Those are the two use cases the product supports:

an internal enterprise team with both exposure management needs and pen test reporting needs
consulting firms and managed services firms supporting multiple Customers, doing pen testing, vulnerability management, and sometimes the tracking and remediation on the Customer's behalf

The multi Customer story has a nice concrete detail. Tool integrations can be configured per Customer. If you are a managed services firm with ten Customers, one runs Tenable, one runs Qualys, one runs Rapid7, and you integrate with each Customer's tool set separately, centralizing all that data while keeping it isolated per Customer.

Playbooks: MITRE ATT&CK engagements that write their own report

This is the section where Miessler audibly changes posture, and it is the best few minutes of the demo.

Playbooks, also known as runbooks inside PlexTrac, support executing an engagement built off MITRE ATT&CK. You can build test plans against different frameworks, but ATT&CK was the primary use case. DeCloss says suppose we want to emulate APT28, opens it, finds it only has three procedures loaded in this environment, and switches to FIN6 for a better example.

Starting the engagement, he selects who it is being run against, and the playbook lists all the procedures that will be tested and executed, giving you a view of your coverage within the ATT&CK matrix itself. Then the testing team works the list. For each procedure they record the red team outcome, was it successful, and the blue team outcome, did the defenders log it, detect it, block it, or see nothing at all. You can attach all kinds of detail. And at any point you can mark a procedure done and say this becomes a finding, at whatever severity.

Miessler stops him:

Oh, okay. So this is a big deal. So you kind of casually mentioned this is also a methodology, like a workflow system for managing what needs to be done in a test.

Exactly. You build the template from whatever framework you use, MITRE or otherwise, it holds all the steps so the team can collectively make sure they cover everything, and the output flows into the report.

DeCloss adds the second purpose. It is a methodology for the testing team, and it is also a data collection surface for the blue team. The defenders can come in and say they did not see this activity, or that they went back and did have the logs, or that there was no evidence at all. That can be added during the engagement, or afterward, since the red team may not want to reveal everything until the report is delivered.

Miessler names the third audience: auditors and Customers who simply want evidence that the work was done, with logs of what happened and when. Especially, he says, for purple team engagements, where the whole question is what did they do and what did we do. Yep, DeCloss says, this really serves that purpose.

Then the payoff. When you are done you submit the engagement, and PlexTrac creates a report using whatever templates you chose. He flips to the reporting module and there it is: all the findings, including the one procedure he converted to a finding, sitting where it belongs, with all the procedures still shown underneath. The narrative sections came in automatically from the template chosen at the start of the engagement. Now the tester tweaks them, cleans them up, adds whatever else is needed, and has a full fledged report.

Miessler's reaction is the honest one:

This is hours and hours of manual work.

"Every single time you execute it," DeCloss says.

And then, in a moment of unusual candor for a product demo, DeCloss points out that the finding he just created is scoring low, not critical, even though he labeled it critical as the pen tester. Why? Because it fell to the default equation and he never assigned an asset to it, so none of the contextual criteria were met. He shows the miss rather than hiding it. Miessler's read is fair: it is good to have that kind of flexibility. It is also the clearest possible illustration of what contextual scoring does. Sever the finding from its business context and the context aware number has nothing to work with.

Module	What it actually does	Who it is for
Exposure management	Findings and instances from every source, contextual risk score in the left column, asset pivot, priorities grouping, integrations filter. The demo environment holds 23,000 finding instances.	Blue team drowning in "everything is critical"
Reporting + libraries	Write ups database (reusable SQL injection, XSS write ups, no copy and paste bleed over) and narratives database (executive summary, methodology, scope as pre built sections).	Testers who love testing and hate reporting
Playbooks / runbooks	Engagements built on MITRE ATT&CK procedures. Red team outcome and blue team outcome per procedure, coverage view, mark a procedure as a finding, submit and it generates the templated report.	Red, blue, purple teams, and auditors wanting evidence
Questionnaires	The longest standing module. Custom questionnaires for any compliance framework, for example an annual PCI self assessment. Mark non compliance, add notes, complete questions, deliver results as findings.	Internal audit and GRC, or assessment consultancies
Assets	Everything that arrived from a manual pen test entry, an Nmap scan, a vulnerability scanner, or the API from something like ServiceNow. Asset type, criticality, tags, data owners, and the metadata that feeds scoring.	Everyone, because scoring depends on it
Workflow automation	Triggers on finding created, edited, or status changed. Actions: assign to a person, post to Slack or Teams, send email, create the ticket in ServiceNow or Jira or Azure DevOps. Bidirectional sync back.	Security teams who are tired of chasing IT

Figure 4. The six surfaces DeCloss clicks through, what each one is doing, and the audience it serves. Note the shape of the product: two of them exist because reporting is miserable, three exist because prioritization is impossible, and one exists because nobody fixes what nobody tracks.

Questionnaires

Miessler apologizes for digging around the interface and asks about questionnaires. DeCloss calls it one of the older, longer standing modules. It was built for custom questionnaires tied to any compliance framework, or just general questionnaires. It has some similarities to runbooks but is not identical.

His example: an annual PCI self assessment questionnaire. He starts one. Miessler reads it back as making sure certain things are tested according to a standard you have to follow, which DeCloss confirms, and adds it serves two audiences: your internal audit or GRC team, and firms doing questionnaire based assessments rather than pure pen testing. He admits the demo example is weak because it only has three questions, but shows the mechanics: mark them as not compliant, add notes, mark the question complete. It is another workflow around executing a questionnaire and delivering those results as findings, which is the important part, since it lands the compliance output in the same store as everything else.

Twenty three thousand instances

Miessler asks whether they are seeing a lot of use and interest around this because more vulns are coming in. Yes, definitely, DeCloss says, and then starts to "land the plane on the demo side" with the number that makes the whole argument concrete.

In this demo environment alone there are 23,000 instances of findings.

That is the number the risk score exists to defeat. Sorted by contextual risk, the ones scoring 100 are the ones you go fix first. And beyond individual scores, the priorities capability lets you group instances and assets together to get a more holistic view: within this set of instances and assets, prioritize these things above all else.

Everything around the prioritization and management of findings, he says, is where they see the most demand and the most help needed, and that is what they are aiming to continue supporting: prioritization, understanding who is doing what, and automating as much of the remediation lifecycle as possible.

Asset management

Miessler notices the asset management and asks about it. These are all the assets that have come in, DeCloss says, whether reported manually in a pen test, produced by pen test tooling such as an Nmap scan, delivered by a vulnerability scanner, or brought in through the API from something like ServiceNow.

Inside an asset you get the metadata you would expect. You can set the asset type and the criticality, which is the input that flows straight back into the risk scoring capability. You can tag assets and assign different data owners. The intent, in his words, is to standardize and centralize as much of this information as possible.

What is coming next

At 21:53 Miessler asks what DeCloss is excited to work on next, and guesses he will be in Vegas. He will: Black Hat, for sure.

On the roadmap, the theme is AI across the lifecycle: more recommendations, more automation around the lifecycle, with things to be shared in the near future. The organizing frame he reaches for is Gartner's, which he calls the CTM lifecycle, covering the identification, validation, prioritization, and mobilization of findings. That is the main focus.

What exists today is the natural first application. PlexTrac's current AI capability helps testers write their reports, which he notes is a very natural fit for LLMs, since the model has the context of the findings and reports are structured prose. What is coming is AI supporting more automation in the remediation lifecycle workflow and in prioritization.

Miessler makes the point that ties the roadmap back to the demo: even with AI, you cannot do much unless you have the data. PlexTrac already has the connectors and the pre built plumbing that gets the data in one place, which is what makes the AI layer possible at all.

The Hacker News article, Mythos, and the vulnpocalypse

Miessler says he saw DeCloss on The Hacker News recently, and asks what that was about.

The article, DeCloss says, laid out a bit of their take on the Mythos and vulnpocalypse discussion, and he encourages everyone to read it. The premise is the one he has been circling all conversation. As everyone knows, AI is going to keep accelerating the ability to find more things. The solution is not to try to prevent that. It is to let AI help the defenders, and he splits that into two moves.

Move one: push AI upstream into the SDLC. His stated premise is that moving AI into the software development lifecycle is the natural fit for most people. If you have a Mythos class model sitting in your pipeline, then great, you should be producing far less vulnerable code right out of the gate. Fix it before it ships and it never becomes a finding.

Move two, because move one will not arrive fast enough. That upstream shift, he concedes, is not going to proliferate in the near term. So the next primary milestone is using AI to help defenders prioritize the findings they already have. AI will keep finding more and more, and it will go faster. If you can make sure you are prioritizing the things that will actually get you breached, that is always going to be the most important thing.

upstream Mythos class model inside the SDLC pipeline less vulnerable code ships it never becomes a finding "the natural fit" · but will not proliferate near term

downstream AI on the backlog rank what is already found fix what will breach you the list keeps growing deeper "the next primary milestone"

where the work actually is known knowns we know what attackers can do a giant unfixed backlog bulk of the work belongs here the next zero day always going to be harder still worth chasing but not instead of the backlog

Figure 5. DeCloss's closing argument, drawn as he states it. Two AI plays for defenders, one upstream and slow to arrive, one downstream and available now. On the right, the reason he weights the downstream play so heavily: almost nobody has cleared the known knowns, so that backlog is where the leverage sits.

Known knowns

Miessler distills it: it is easy to get over excited about new tech, but what is the new tech actually doing? In this case it is finding way more stuff, and you still have the central problem of what do I fix.

Exactly, DeCloss says, and that closes the loop back to why he got into pen testing in the first place. How are breaches actually happening. What is actually going to get people breached. Understanding what attackers can genuinely do in your environment. So be proactive about that, do the testing, try to identify it.

Then the strategic point, and it is the most quotable idea in the interview. We have so much more information available to us now than we did fifteen years ago. I know what attackers can do in our environment. That is a known known. They will always come up with other things, but for the most part we know a lot of what they can do. We just have to identify how to prevent it.

So focusing on the known knowns is always going to be just as important as trying to stay ahead of the next zero day. Staying ahead of the zero day is always going to be a lot more difficult. But if you have a handle on how you are reducing that backlog of known knowns, that is where the bulk of the work needs to be done.

Miessler agrees and puts the honest version of it plainly: we are not in a situation where we have fixed everything and everything is clean, and now we just need to worry about zero days. We are still sitting on a giant backlog of stuff that has not been fixed, and we need a priority for it. One hundred percent, DeCloss says.

They close on Vegas. Miessler will be at Black Hat, hopes to see him there, and says they will get the link added. Great to chat.

Best quotes

"I've always really tried to focus on helping organizations actually prioritize the right things that will get them breached." Dan DeCloss, 0:17
"We started in the pen test reporting space cuz I hated writing reports, hated the lack of collaboration on the findings in a very static way." Dan DeCloss on why PlexTrac exists, 1:05
"I always loved testing and I always hated reporting." Daniel Miessler, 1:56
"I hated delivering a pen test report and then coming back a year later cuz nobody had fixed anything." Dan DeCloss on the origin of the "track" in PlexTrac, 3:30
"At the end of the day, we don't have a problem of sourcing findings. It's more where are the right ones to be fixing now that'll make the biggest impact on our business." Dan DeCloss, 2:58
"We're certainly seeing AI continue to accelerate attacks, provide new attack vectors and new mechanisms for attacks. But they're still tending to be exploiting some of the same things, just maybe at a faster pace." Dan DeCloss, 4:25
"That list is going to continue to grow deep, and AI will only continue to make that list bigger." Dan DeCloss, 4:56
"We don't do automated remediation, but our goal is to help provide as much recommendation and automation around that process as possible." Dan DeCloss, 5:05
"It provides that kind of objective overlay in a somewhat subjective manner." Dan DeCloss on Customer defined risk scoring, 6:24
"Oh, okay. So this is a big deal. So you kind of casually mentioned this is also a methodology, like a workflow system for managing what needs to be done in a test." Daniel Miessler on the MITRE ATT&CK playbooks, 16:40
"Yeah, this is hours and hours of manual work." Daniel Miessler on the auto generated engagement report. "Every single time you execute it." Dan DeCloss, 18:35
"While I said it was critical as the pen tester, the risk equation's saying, well, this is still a low. And it's because none of this criteria has really been met." Dan DeCloss showing his own demo scoring against him, 18:50
"We got 23,000 instances of findings. Like, how do I know? This risk scoring definitely helps in the prioritization of those." Dan DeCloss, 20:15
"If you have a Mythos like model in your pipeline, well, then great, then you should be producing way less vulnerable code right out of the gate." Dan DeCloss on moving AI into the SDLC, 23:28
"I know what attackers can do in our environment. That's a known known." Dan DeCloss, 24:30
"Focusing on the known knowns is always going to be just as important as trying to stay ahead of this next zero day." Dan DeCloss, 24:45
"We're still sitting on a giant backlog of stuff that has not been fixed and we need a priority for that." Daniel Miessler, 25:10

Where it stands

This is a sponsored vendor conversation. The video description links a PlexTrac demo through an Unsupervised Learning tracking link, roughly two thirds of the runtime is a product walkthrough, and DeCloss is the founder. None of that makes the observations wrong, but it is the frame, and Miessler does not pretend otherwise: he asks DeCloss to pull the product up on screen and then digs around the interface himself.

The core argument holds up independently. The claim that discovery is no longer the bottleneck is being validated in real time. FIRST forecast roughly 66,000 CVEs for 2026 after 2025 finished at a record 48,185, and NIST reclassified tens of thousands of backlogged CVEs as "not scheduled" for analysis. Anthropic's Claude Mythos Preview, the model DeCloss references, was announced in April 2026 as capable of autonomously discovering and exploiting zero days, and Palo Alto Networks reported finding 75 vulnerabilities in its own products in a month, roughly seven times its usual rate, after adopting frontier security models. Against that backdrop, "the list will keep growing and you still have to pick" is not marketing, it is arithmetic.

Two small corrections for anyone taking notes. DeCloss says "the CTM lifecycle" that Gartner deemed; the framework he is describing is CTEM, Continuous Threat Exposure Management, whose stages include the prioritization, validation, and mobilization steps he names. And "Hacker News" here means The Hacker News, the security news publication where PlexTrac runs expert insight pieces and won two 2026 Cybersecurity Stars Awards, not the Y Combinator link aggregator. The specific vulnpocalypse article is never named on air, so treat the two linked PlexTrac bylines in the Resources below as the closest published statements of the position rather than as the exact piece.

The one claim worth holding lightly is the implied efficacy. Contextual, Customer weighted risk scoring is a genuinely better idea than sorting by raw CVSS, and DeCloss argues that case well, including the moment where he lets his own demo score a critical finding as low. But the quality of the output depends entirely on whether an organization has actually tagged its assets, set criticality honestly, and maintained the custom fields the algorithm reads. A configurable scoring engine sitting on top of unmaintained asset data will produce confident numbers that are just as arbitrary as the ones it replaced. He says as much without quite saying it: assign no asset, get a meaningless score.

Resources

Unsupervised Learning, Daniel Miessler's newsletter, podcast and community, and the YouTube channel this conversation lives on
Subscribe to the Unsupervised Learning newsletter and join the UL community
Daniel Miessler on X and LinkedIn
PlexTrac, the platform demoed throughout, and the PlexTrac demo link from the video description
Dan DeCloss, founder of PlexTrac, twenty plus years in cyber security, OSCP and CISSP holder with a computer science master's from the Naval Postgraduate School
"Why CVSS Scores Don't Tell the Real Story of Risk", Dan DeCloss writing on The Hacker News, the fullest published version of the contextual scoring argument he makes here
"The AI Arms Race: Why Unified Exposure Management Is Becoming a Boardroom Priority", PlexTrac's other recent Hacker News piece on AI accelerated attack tooling
PlexTrac's 2026 Cybersecurity Stars Award from The Hacker News for Best Exposure Assessment Platform
Claude Mythos, the Anthropic model DeCloss names, and Anthropic's own assessment of its cyber security capabilities
"The Vulnpocalypse: why experts fear AI could tip the scales toward hackers", NBC News on the discussion DeCloss references
Palo Alto Networks finding seven times more flaws with frontier AI models, Axios
MITRE ATT&CK, the framework behind PlexTrac playbooks, plus the two groups DeCloss opens on screen: APT28 and FIN6
Scanners named in the demo: Nessus and Tenable, Qualys, Rapid7, and Nmap for asset discovery
Ticketing and messaging integrations named: Jira, ServiceNow, Azure DevOps, Slack, Microsoft Teams
Vulnerability classes used as write up examples: SQL injection and cross site scripting
CVSS, the score DeCloss feeds into his algorithm as one input among many, and CISA's Known Exploited Vulnerabilities catalog, the public equivalent of his "is there a known exploit" criterion
PCI Security Standards Council document library, home of the self assessment questionnaire he demos
Gartner on Continuous Threat Exposure Management, the lifecycle DeCloss calls CTM
Black Hat, where both of them are headed

Full transcript

All right, Dan. Welcome to Unsupervised Learning. Yeah, hey. Thanks, Daniel. Thanks for having me. Big fan of your newsletter and content and appreciate having me on. Yeah, yeah. Absolutely. So, I guess the first thing I always like to figure out is what is the problem that you're really hot on and excited to sort of try to solve? Yeah, I mean, I would say, you know, my background is in penetration testing and I've been in cybersecurity for 20 plus years and I've always really tried to focus on, you know, helping organizations actually prioritize the right things that will get them breached, right? How to remediate those things and how to be focused on the things that an attacker can actually do in their environment. I think I kind of grew up in some of the GRC space and kind of felt, you know, with my technical background that like, hey, we're not really focusing on like, what are attackers actually doing in environments and how are these things actually getting them breached? And that's really kind of what led me to penetration testing with the technical aspects of this is how an attacker is actually doing their work. And I, you know, being kind of a hacker by trade in terms of just wanting to always understand how things worked. Those were the things that always kind of really got me excited. And then started PlexTrac to a help remove some of the friction in that whole process around pen testing. We started in the pen test reporting space cuz hated writing reports, hated the lack of collaboration on the findings in a very static way. So, wanted to have a dynamic platform that brought those findings that are critical to an organization, brought those right alongside all the other risks that are getting reported. So, that's where we've continued to grow and expand our product. But, you know, what gets me excited is actually trying to help people fix the right things and and try to avoid getting breached and knowing exactly what an attacker can do in their environment. Those are the things that really continue to excite me and hope we can help in that in that process, right? Yeah, that makes sense. I think I've been aware of the product for quite some time. How much has it changed over time given like what's happening now with like AI attackers and stuff like that? Has there been much shift? Like, are you moving more towards remediation in addition to reporting? Cuz I remember the great thing about PlexTrac sort of back in the day was the fact that it would help with the part of the pen test that was like the worst for the tester. Like I always loved testing and I always hated reporting. Right. So PlexTrac was always kind of a go-to there, but it seems like you're doing a lot more than just that now. Yeah, yeah, exactly. Like I said, we've expanded our product quite a bit since it. So that's There's our roots and that's still a very important piece of the puzzle that we help supply is one, helping testers stay focused on more testing, less reporting. That's still a very core part of our product, but the ability to bring those findings into a platform. So we centralize all of the results from other scanners as well. So like if you're doing vulnerability scanning or app code scanning, we can bring all those together and now you have an overlay of all the pen test findings in addition to all of your vulnerability management and other exposures. Being able to report those all in a single platform and then what we've expanded on is our ability to add risk scoring and prioritization of findings based on the context of the environment, which is another big problem, right? That especially blue teamers have is like, "Hey, I've got tons of issues. You know, they're all critical. They're all stated critical by Nessus and our pen testers." So how do I actually know which ones I should fix first cuz that's ultimately at the end of the day, we don't have a problem of sourcing findings. It's more where are the right ones to be fixing now that'll make the biggest impact on our business. So that's really what we've been able to help expand in our product offering to be able to do is aggregate that data, provide a mechanism for scoring the findings and prioritizing them within the context of the business, and then facilitating kind of workflow automation related to the tracking or remediation. So so the track in PlexTrac has always been related to the tracking and remediation. With that pen test reporting angle, I hated delivering a pen test report and then coming back a year later cuz nobody had fixed anything. Some of that is just a procedural breakdown. They didn't copy and paste the right data into the spreadsheet or ticketing system or didn't care about it at all, right? And so having that ability to always be able to have visibility around who's doing what on the fix and the remediation side has always been a core tenant of ours as well. And so we just continue to expand on that, provide workflow automation around that. So we have full visibility and you know, just try to remove as much of the friction in that process as possible. That makes sense. And how are you seeing actually things happening in the wild right now? One of the narratives is basically the AI is allowing people to attack faster. Like what are you seeing in findings? What are you seeing from customers in terms of the stuff that's being reported back and how are you helping with that? Yeah, yeah. I think like kind of what I was saying before is like as an industry in general, we don't have a problem of identifying more issues, right? We're certainly seeing AI continue to accelerate attacks, provide new attack vectors and new mechanisms for attacks. But they're still tending to be exploiting some of the same things, just maybe at a faster pace, as well as like identifying more issues. But at the end of the day, the defenders really still need to know like, "Hey, well what are the most important things that I should be fixing first." So that's really the problem that we're trying to help solve and and and do help solve is like, "Hey, we can give you a better perspective of like this is the prioritized list." That list is going to continue to grow deep and AI will only continue to make that list bigger, right? But our goal is to help identify, "Hey, these are the ones you should fix first." And potentially even, you know, help automate that process as well. We don't do automated remediation, but our goal is to help provide as much recommendation and automation around that process as Okay, yeah, that makes sense. I mean that is, like you said, kind of the most important part. Like you said, there's no problem finding the vulns. It's the problem of figuring out which ones to fix. So can you talk through a little bit about how you're doing that prioritization? You mentioned context, which is like one of my favorite words. So how are you factoring in the context of the business into that prioritization so they know what to fix first? A lot of products and companies will provide their own kind of proprietary like risk scoring mechanism. And we've taken a different approach in allowing, you know, we have our default out of the box like, "Hey, here's a calculation for risk." You know, things that would be more commonly associated with like a risk score, things like the asset criticality, the the location of the asset, the type of data that it processes, those kinds of things. But then we give flexibility back to the customer and back to the user of here you have full control over how these things get weighted, what other criteria you want to add to your risk score so that you can actually say like, "Hey, you know, these this is how we structure our data. These are the fields that are most important to us and we want to make sure that those are provided in into the risk score." So you really have full flexibility over what criteria goes into the risk scoring algorithm, what weight are given, and then, you know, it provides that kind of objective overlay in a somewhat subjective manner, which is kind of nice. We even allow you to break it down by department or division, so it doesn't have to be enterprise-wide. You can have like kind of a default enterprise-wide risk calculation, but then say you have like an R&D department that you need to give different scrutiny to, you can provide different calculations or risk scoring algorithms for those different departments as well. So it provides a little more flexibility and customization into the hands of the end users, so they can actually specify what context they care about and actually then gives you the risks that are related to what you specified. Okay, so it sounds like they have a decent amount of control over the schema for doing the ratings in general, and you can customize that for the group. Interesting. So are you able to pull that up? You you're able to show that at all? Yeah, absolutely. So I'm I'm actually in our exposure management module, and so we have instances of findings. So think of finding as like, "Hey, we've got SQL injection." And then each reported instance is an instance of that finding. And you'll see in this left-hand column we have the risk score associated with these findings. So this one at the top here is is labeled critical from its source, which I believe was like, you know, Nessus or something like that, right? Tenable. But you can see its risk score is rated at like a 56, which is a high, and that's because right here it's calculated using this risk scoring algorithm. So, this is for the accounting department specifically. So, this calculation, you can see what composes that. The instance severity, the asset criticality are the two most important things. But, is there a known exploit for it? Has it been used in a known ransomware campaign? Those were just a couple other criteria that we set for it. If I were to actually click on this, it'll take me to, you know, where we could actually, you know, edit this, right? So, you see this is specific to that department. These were the criteria. If I click on this, this is how you accumulate points within each weighted category. You can have a very robust set of rules, and then you can also change the weights themselves, as well as add additional variables. So, you have asset-related variables. So, if you tag all of your assets, or they're going to base it on their physical location, or what type they are, you can do that. Then, anything related to the finding and instance itself. So, like, hey, did it have a CVSS score of four? And And you could specify what the scores were to to get the different criteria, tagging as well. And then, any custom fields that you use within PlexTrac are also available into this risk scoring capability. So, we see customers using this a lot, where they may have custom fields that they use throughout their entire environment for either assets or findings. And then, you can actually in to be used in your risk scoring calculation. Nice. And what does it look like to just show kind of the overall, like the dashboard? What What do they see when they use it day-to-day? Yeah, yeah. So, when you land on PlexTrac, you're seeing your your general dashboard, like open findings and things like that. And then, assets with critical findings. And as you drill into the especially the exposure management category, you can view things based on assets. So, like, how What are these, you know, what assets live in my environment? How many findings do they each have? So, here, with this asset has, for instance, a findings associated with it. So, I can look at these and kind of get an idea of like what their status is, who's is to what. I can also do that at the finding and instance level. So, I see all the different findings at the instance level as well. One other thing, too, is that not only do we integrate with all of the vulnerability scanners, you know, you can see actually if I were to filter here, all of these different vulnerability scanning vendors and whatnot, you know, we can we can integrate with, but also we can integrate with your ticketing system. So, Jira, ServiceNow, Azure DevOps. So, this supports the ability to actually track things within PlexTrac, and those are bidirectional syncs, but then you're not interrupting the workflow of say your IT operations group or your one of your development teams. They can do the ticketing remediation process within their own workflows. That data syncs back into PlexTrac and automatically updates the status of of the finding itself. Okay, so they can close an item inside of their own workflow without having to come back to the dashboard. Exactly. So, you're not interrupting workflow, but as the security team, you have a centralized view of everything that's been going on, who's responded to it. If I click here, here's the status update, right? So, this is the full status history of this finding. This is a demo environment, so it's been used a lot, but you also support like you can have your own custom sub statuses to support the workflow that you would want you know for these, like whether it's ready for retest or you know ready for review, those kinds of things. So, it really supports a robust view of the tracking remediation process, trying to eliminate again some of that friction in in the manual workflow. And then we also have a workflow automation engine that I can kind of show you some examples of here as well. That also just continues to reinforce that mechanism. So, like within our reporting module, if say a pen tester reports a critical finding, once that's published, it can you can immediately assign that to somebody, right? So, here's an example of like a custom workflow within the environment. So, you know, we support Oh, okay, so you can assign this to and who are these people that are being assigned to? This is like someone in a dev team or someone in a security team? Yep, exactly. So, I mean you can in in this kind of example, you can assign to a specific person, you could send it to Slack or Teams. Say you have like a an open escalations channel, you can also send emails, you can immediately create the tickets directly within those environments as well, like ServiceNow. So, it really has a lot of flexibility as to being able to automate that as much as you possibly can. We don't do the remediation itself, but we can integrate with the products that do those types of things. Yeah, that that gets a little sticky when people people try to do the the whole thing. Yeah. And these triggers can be triggered off of criteria like if it's in this department and if it is a certain severity. So, it triggers off the finding itself. So, yes, you could add like some criteria of like, "Hey, if it's also assigned to this person, then go do these things." Yeah. So, like basically if the finding gets created or edited or if the finding status is changed itself, right? Then you could pay say it changes to a specific sub-status or something like that. You can have all those different kind of that the flexibility around the triggers is is very Okay, and I'm looking at these questionnaires and playbooks over here. What what are these and the libraries? So, generally speaking within PlexTrac, I'll start with the libraries. So, this is just pre-built content and this is more from our core reporting capabilities. So, I'm sure you know, in your pen testing days and I'm sure you still do pen testing, but you probably have your This is how you always write up SQL injection or this is how you always write up cross-site scripting. Those are what we call a write-up in the write-up's database. So, you can have these saved and we have multiple sources and then a lot of customers will also just bring their own, right? And so, this allows you to reuse that content and not have to copy and paste it from previous reports. It reduces the amount of bleed over from previous reports, you know, cuz like if you're doing copying and pasting from one report to another, some of that information that's unique to that customer might bleed over and you want to avoid that. So, our write-up's database really supports that of like just reusing write-ups in a consistent basis. Very easy to get it into a report. And same with our narratives database, so in the reporting function of PlexTrac, we support that narrative context of the report itself. So, the executive summary, the the methodology, the scope, all those things that you might put in a more prose type of the report, that's what the narratives database is for is like just those pre-built sections like, "Hey, this is how you can have this all templated out, too." So, like, "Hey, these are the 10 sections of the report that that we want, right?" Okay, this is reminding me I was thinking internal use. So, this is like a big corporation, medium-size company, whatever. You're using this to explain things to your internal customers, you know, do your remediation, all that all that kind of stuff, basically manage the prioritization of these vulns. But, looking at these, I'm reminded this could also be a pentest company, right? So, you got multiple testers doing tons of stuff, but different customers want to see different reports. And maybe some people want like cold, hard, direct truth, and they want no more than a three-page report, and other people want these giant 20-page super verbose things. So, I guess this would be a way to manage that for different customers? Yeah, 100%. So, yeah, and that's where, you know, we support teams that are doing, you know, more consulting work where they're working with lots of different customers. This kind of an enterprise demo, so it's labeled departments, but these are the equivalent of a client, right? And so, I could write a report for that specific client. And then also, take even the example of a large enterprise that has an internal pentesting team, this really supports both of those functions of like, "Hey, I can write my pentest reports for my company in this platform as well as bring all their other findings together." So, really what we support is kind of those two use cases. An an internal enterprise team that has the exposure management needs as well as a pentest reporting needs in addition [clears throat] to the the consulting firms that that might be or even managed services firms that are that are supporting multiple customers, not only doing pentesting and vuln management, but also maybe the tracking or mediation, and so they can show and and centralize all of those activities on behalf of their customers. So, like, when we talk about like tool integrations, which I can kind of show you that dashboard here just as a as a visual, but like we can integrate with all these tools and they can be on a per customer basis. So, if I'm a managed services firm, say I have 10 customers, one has Tenable, one has Qualys, one has Rapid 7, and I can integrate with each customer's tool set, centralizing all that data, and it's still isolated to that customer. Yeah, that makes sense. What are the playbooks over here? Playbooks, yeah. So, also known as runbooks within PlexTrac. So, this really supports the ability to execute an engagement initially based off of MITRE ATT&CK. You can create all kinds of different test plans and they can be based on different frameworks, but MITRE ATT&CK was kind of the the primary use case here where you could do like, you know, say we wanted emulate APT28, right? So, we could I guess there's only three procedures in that one. Let's do a different one. Let's do FIN6 here. So, like if I was to start this, I could select who we're doing it on. These are all the procedures that will test and execute and then you can you kind of get the, you know, perspective of the coverage within MITRE ATT&CK itself. And so, as we create this engagement, now the testing team can go through and say like, "Okay, I'm testing these things, right? Here's the red team outcome. It was successful. The blue team, you know, logged it but didn't didn't have any detection or, you know, blockage." You can add all kinds of details. So, as you execute through this, you could also say like, "Hey, we're done with this procedure and it is going to become a finding. It's going to become critical." So, as I Oh, okay. So, this is a big deal. So, you kind of casually mentioned this is also a methodology like workflow system for managing what needs to be done in a test. So, basically you build this template based on whatever it is, if it's MITRE or whatever it is, and that has all the steps so the team can collectively make sure it they go through everything. And of course, that will correspond with the reporting and output as well. Yes, you know, it serves a couple different purposes, right? So, one that methodology for the testing team as well as you You have to have the blue team data alongside it, but you can. Like the blue team can come in and say like, "Hey, yeah, I didn't see this activity going on in my environment." You know, but we did go back and we did have those logs or didn't have any evidence at all. You can continue to add that in as part of the engagement or they can come back later. Say the red team or the pen testing team doesn't necessarily want to show everything until afterwards. Like once you're done with the report, they can come back in and then say like, "Okay, yeah, we logged this and things." So, it adds some more elements for data collection that are useful for your security program in in general, right? Yeah, and also auditors and some customers will just want to see evidence that things were done and like have, you know, logs of what happened when and that sort of thing. Especially for like purple team engagements. Yep. Like what did they do and what did we do? Yep, exactly. Yeah, this really serves that purpose. And then when you're done, you submit the engagement and it'll create a report in Plex Track using all the templates that you want. So, here's an example of like, "Hey, in the reporting module, here's all the findings." That one finding that we, you know, created, said it was a finding, here is where that lives. It still shows all the procedures. You can then come in and do whatever. Oh, really cool. This was all templated. We chose the template for this engagement, so all these narrative sections came in automatically and now I can just tweak them, clean them up, edit them, add, you know, any other information that I want there and then I have a full-fledged report. Yeah, this is hours and hours of manual work. Every single time you execute it, yeah. Yep, exactly. So, yeah, and and you'll also notice here in this finding itself, it's just being calculated using this default equation. So, that's why I didn't assign an asset to this one, you know, or things like that. So, that's why while I said it was critical as the pen tester, the risk equation's saying, "Well, this is still a low." And it's because none of this criteria has really been met, right? So. No, it's good to have that kind of flexibility. Sorry to be digging around the interface here. What about our questionnaires? Yes, questionnaires is is one of our older, I would say our longer standing modules and this was really geared towards the ability to do custom questionnaires related to any kind of compliance framework or just general general questionnaires. It has some similarities to runbooks, but not necessarily exact. So, if if we were to say like, "Hey, I want to do an annual PCI self-assessment questionnaire." I can begin that and I can say like, "Okay, let's do that here." So, this is just making sure certain things are tested according to a standard that we need to follow. Yep. And it can serve two kind of both purposes as well. Like, your internal audit team, your internal GRC team, or if you're, you know, doing more of these types of engagements, not just pen testing, but more questionnaire-based assessments, this is what that can serve. So, this wasn't a great example cuz it only has three questions. But, you know, you can say like, "Hey, they weren't compliant." You can add notes. You this question's complete. So, it it provides another workflow around executing a questionnaire and delivering those results as findings. Okay. Yeah, that makes sense. And are you seeing a whole lot of use and like interest around this just because more vulns are coming in? Yes. Yeah, definitely for sure. I mean, I think, you know, when we talk about the the prioritization of findings and you know, kind of start to land the plane on the demo side here is that even in this example, we got 23,000 instances of findings. Like, how do I know this risk scoring definitely helps in the prioritization of those, right? Okay, hey, I've got these ones that are 100. These are the ones I should go fix first. And then, being able to group these together to get a more kind of holistic view of like, "Hey, within that set of instances and assets, I want to prioritize these things above all else." That's what our priorities capabilities support. So, everything around the prioritization and management of findings is what we're seeing a lot of demand for, a lot of help needed, and that's what we're really aiming to continue to help support is the prioritization, being able to understand who's doing what, and helping automate as much around that remediation life cycle as possible. That makes sense. And it looks like you've got some asset management there as well, so they can sort of see like what the state is of the overall systems. So, like these are all the assets that have come in, whether those have been reported manually in a pen test or through the results of a pen test like an Nmap scan or something like that or like your vulnerability scanners. You can bring stuff in via, you know, our API from like ServiceNow and stuff like that. And so, like within an asset itself, you know, we we, you know, can support all the kind of metadata that you would expect. You can start to say what type of asset it is as well as like the criticality, right? And this is what will play into those risk scoring capabilities as well. So, you can tag assets, you can have different data owners. So, we are meant to help, you know, standardize and centralize as much of this information as possible. That makes sense. So, very cool. What are you excited to be working on next? Like what are you thinking about for next features? I imagine you're going to be in Vegas. We'll be in Vegas for Black Hat for sure. Yeah, so I mean, you know, we're continuing to focus on our AI as well of being able to help provide more recommendations, provide more automation around the life cycle. So, we'll be sharing some of those things in the near future. But everything around that entire what Gartner has deemed the CTM life cycle of being able to help support everything related to the identification, validation, prioritization, and mobilization of findings. That's our main focus. And so, we're excited to continue to emphasize there. With our AI capabilities today, we do have the ability to help testers write their reports, which is very natural for, you know, LLMs to help write the reports based on the context of the findings. We're going to be using AI to help support more automation in the workflow around remediation life cycle and the prioritization there as well. So, there's some cool stuff coming out here soon. Yeah, that's the thing. I mean, even with AI, you can't really do much unless you have the data, right? So, you have all these connectors, you have all these things already pre-built that basically help you do that. I saw you on Hacker News recently. What was that about? Uh yeah, yeah. We had we had an article kind of explaining, you know, some a little bit of our take on on the mythos volmpocalypse, you know, discussion. And so, it's great article. Definitely would encourage everyone to check it out. But, it's related to that concept of like, yep, as we all know, AI is going to continue to accelerate being able to find more things. And the solution is not so much trying to prevent that, but letting AI help the defenders either A, identify these before the attackers do. So, my premise, which I think I talked a little bit about in the article, is like moving AI into the SDLC is is going to be the natural fit for most people as well. So, like, hey, if you have a Mythos like model in your pipeline, well, then great. Then you should be producing way less, you know, vulnerable code right out of the gate, right? Um but, you know, that's not going to proliferate in the near term. So, being able to help defenders prioritize those findings using AI is the next primary, you know, milestone of being able to say like, hey, you you know, AI is going to continue to find more and more things. It's going to go faster. If you can make sure you're prioritizing the things that will actually get you breached, that's always going to be the most important thing. So, that's that's kind of the premise of the article, but I definitely would encourage you to to to read it and check it out. Yeah, that makes sense. I mean, it's easy to get over excited about new tech, but what is the new tech actually doing? In this case, it's finding way more stuff, but you still have the central problem of, okay, what do I fix? Yeah, exactly. And that goes back to the reason I got into pen testing at the beginning is like, hey, how are breaches actually happening? Like, how what's actually going to get people breached? And and understanding what those attackers can actually do in your environment. And so, be proactive about that. Do the testing. Try to identify, I mean, like, you know, we have we have so much more information available to us now than we did 15 years ago where it's like, I know what attackers can do in our environment. That's a known known. Like, they'll always be coming up with other things, but for the most part, we know a lot of what they can do. We just have to be able to identify, how do we prevent that? So, focusing on the known knowns is always going to be just as important as trying to stay ahead of this next zero day or whatever, right? I mean, that's always going to be a lot more difficult, but if you at least have a handle on, how are we reducing that backlog of known knowns, that's where the bulk of the work needs to be done. Yeah, we're not really in a situation where we've fixed everything and everything is clean. And we're like, okay, now we just need to worry about the zero days. We're still sitting on a giant backlog of stuff that has not been fixed and we need a priority for that. 100% yeah, so. Awesome. Well, I'll be in Vegas. Hopefully I'll see you there and yeah, we'll get the link added. Yeah, it was great to chat with you. Yeah, thanks Daniel. Appreciate it and yeah, looking forward to seeing you in Vegas as well. Awesome. Take care. Thanks.