Today’s cybersecurity leaders are pushing their boundaries in reshaping how organizations identify, prioritize, and address security vulnerabilities. Welcome back to another insightful episode of ExtraMile by SecureITWorld featuring Daniel DeCloss, Founder of PlexTrac, now part of Brinqa.
The firm is a security validation and reporting platform used by penetration testers, red teams, and security operations teams to prove which exploits worked and which findings still need attention.
Our spotlight leader, Daniel DeCloss, has a background in application security and penetration testing. He now leads the combined offensive security practice at PlexTrac.
In this conversation, Daniel shares his views on the disconnect between vulnerability findings and remediation. He also discusses PlexTrac’s acquisition by Brinqa, the role of human judgment in determining which vulnerabilities are exploitable, and how organizations can build stronger vulnerability contexts using their own data.
Daniel also highlights continuous security validation, pentests reports, improving collaboration between red and blue teams, and shares his valuable advice for security leaders. This discussion is worth it for cybersecurity professionals and enthusiasts looking to take one step toward measurable security outcomes.
Daniel, it’s an absolute pleasure to have you with us on ExtraMile. Welcome, and let’s get started!
1. You spent more than 20 years in security before founding PlexTrac, much of it breaking into networks for clients and later running security inside an enterprise. What does that combination let you see that people who have only worked one side of it tend to miss?
Daniel. The pentest is where it shows up most. I spent years on the offensive security side breaking into networks and applications for clients, followed by late nights formatting those reports by hand. I know exactly how much of that work never reaches anyone who can do something with it.
Then I went in-house and became the person on the receiving end of those reports. As a security director I would get a hundred pages of vulnerability findings but no additional headcount to go fix them. What I needed to know was which five vulnerabilities to chase that quarter, but the report rarely informed risk prioritization. It told me what was wrong, ranked by a score ultimately disconnected to what my environment looked like.
Most of the friction in this industry comes from those two groups talking past each other. Testers get measured on what they find, while defenders get measured on what they fix. Having done both jobs, I stopped seeing that as a tools problem and started seeing it as a handoff problem, which is more or less why PlexTrac exists.
2. Congratulations to PlexTrac on winning The Hacker News’ award for Best Exposure Management Platform. What does that recognition mean to you as a founder and to the entire team?
Daniel. It means more to the team than it does to me, and I mean that in a good way. Engineers spend months on work that customers never explicitly thank them for, so having a respected voice in the cybersec industry look at the category and select our platform is a nice moment for us and what we’ve been building.
3. PlexTrac was just acquired by Brinqa in August. What does the combined company do that neither side could do alone, and what changes for PlexTrac customers?
Daniel. The short version is that PlexTrac now sits inside a program instead of next to one. I’ve been saying for years that closing a ticket and confirming a fix are two different things, and we’ve built the validation work around that. Brinqa spent a decade on the other half of the problem, which is deciding what deserves attention in the first place. Their prioritization says what matters, our validation proves the fix held. It’s a powerful combination to have under one roof.
What I would say to PlexTrac customers is that the product isn’t going anywhere. It continues as a standalone offering, so teams who want exactly what they have today keep it, and there’s a path into the wider platform whenever their program is ready for it.
The part I care about personally is that PlexTrac was built by offensive security practitioners for offensive security practitioners, and that hasn’t changed. I am running the combined offensive security practice now, and a good chunk of that job is making sure hands-on testing expertise keeps a seat at the table as more of this work gets automated.
4. Digging in a bit more there, AI and agentic security tools generate more vulnerability findings than teams can realistically address. Why do you believe human expertise and judgment are critical to determining which vulnerabilities are genuinely exploitable?
Daniel. Because exploitable and reachable are different questions, but only one of them can be answered from a database.
I have watched two findings with identical 9.8 CVSS scores mean completely different things. One sat on a lab box with no route to anything of value, while the other was on an internet-facing system tied to revenue, with working exploit code already circulating. A scanner sees the same number twice, but a person who knows the environment sees a weekend of work and a shrug.
Agentic tools have made the volume problem worse, which is expected. They are good at producing candidates, but what they cannot do yet is tell you whether a given path connects to something the business cares about, because that answer lives in your asset inventory and in the twelve access exceptions somebody granted three years ago that nobody wrote down.
The place I would draw the line is remediation. Automation can carry a finding most of the way, and it can pick the work back up afterward to validate the fix. The decision to change something in production still belongs to a person, and I do not see many organizations comfortable handing that over (rightly so). There may come a day in the future for fully automated remediation, but I think that the comfort level to get there will take time…similar to comfort levels with self-driving cars, which have been in the works for over a decade.
5. With challenges such as NVD backlogs and the move toward prioritized CVE subsets, how can security teams build reliable vulnerability context in-house and make well-informed decisions?
Daniel. Start somewhere unglamorous, which is your own workflow. Walk your triage process end to end and identify how you’re actually approaching the prioritized remediation problem. Most programs tend to rely on external opinions of their risk, rather than build a custom risk scoring framework that takes their own context into account. Companies that focus here not only improve their view of high priority items to address, but also become less reliant on external opinions.
After that, focus on how your organization stacks up with respect to the attack lifecycle. Ask key questions related to how an attacker could truly breach your environment. Questions such as what internet-facing assets have the most vulnerabilities? Do they sit on a path an attacker could actually traverse? Has anybody seen this exploited in the wild? Does the same finding keep coming back engagement after engagement? The answers live in your scan data, your pentest results, your asset inventory, and your remediation history, and most teams already have all of it sitting in siloed systems that do not talk to each other.
6. As organizations adopt continuous delivery, why is annual point-in-time penetration testing no longer enough, and what does effective continuous security validation look like?
Daniel. Annual pentests describe your environment only for the duration of the engagement. If you ship to production twice a day, the report is describing a version of the application that no longer exists by the time it reaches your inbox. The annual cadence came from audit requirements, and audit requirements move slowly.
Continuous validation, done well, focuses on actual change (a meaningful release, an acquisition that just added 300 hosts, etc.). In between your annual engagements, you are running smaller targeted tests with the latest attacker techniques and targets, and you’re retesting what you already fixed to confirm it stayed fixed.
Retesting still gets skipped over far too often. A finding gets closed in Jira and nobody checks whether the fix held or whether a later deploy quietly rolled it back. Closing a ticket and confirming a fix are very different things. If you take one habit from continuous validation, take that one.
7. Red and blue teams often struggle to translate vulnerability findings into security outcomes, and findings passed between teams as documents lose critical context along the way. How can organizations improve that handoff?
Daniel. The document is the problem. A report is a snapshot of a conversation, and the conversation is the part that mattered. A tester might spend three days identifying a service account with too much access, which is what turns a low-severity misconfiguration into domain compromise, then compresses all of that into a paragraph and a screenshot. Whoever picks it up on the blue team gets the paragraph and can lose a lot of the context and complexity associated with the exploit.
The better approach is both teams operating out of the same record instead of mailing artifacts back and forth. Findings carry their evidence, all of the reproduction steps, the attack path, and the retest history along with them…and nobody, then, is reconstructing intent from a PDF six weeks later. When the blue team asks why something is rated the way it is, the answer sits in the same place as the finding.
The other thing that helps is running both teams against the same script in real time. Purple team exercises get dismissed as a buzzword and plenty of them earn it, but a session where the tester runs a technique and the defender checks near real-time whether it produced an alert closes more gaps and improves posture much faster than any report I have written.
8. The pentest report is a compliance artifact rather than a security outcome. What should security teams be counting beyond the number of pentests completed, and what metrics should they focus on instead?
Daniel. Counting pentests completed doesn’t really tell you anything beyond the fact that you checked a box for your compliance validation.
The numbers I would rather see start with time-to-validate-fix instead of time-to-ticket-closure. Those two diverge more than people expect, and the space between them is where risk actually lives. After that, retest pass rate, meaning how often a fix works on the first attempt. A team passing half the time has a remediation quality problem that more testing will never find.
Recurrence is the one everyone struggles with. If the same finding turns up in three consecutive engagements, the interesting question stops being how to fix it and starts being why your build process or configuration management team keeps shipping it. That number tells you something real about how your company is deploying software or configuration changes to the environment.
I would also track what share of findings came with a confirmed exploit path rather than a scanner assertion. True exploitability says something about the quality of the testing, and it gives the remediation side a reason to believe the priority order in front of them.
9. What piece of advice would you give security leaders looking to build stronger teams and improve their overall security posture?
Daniel. Stop measuring your team by volume, whether that is findings reported or tickets closed. Both can lead to inaccurate results. What gets measured gets done, and a team optimizing for activity will happily produce a great deal of it without reducing anybody’s risk.
The second thing is to give testers ownership beyond the report. The best security people I have worked with stayed engaged for whether the issues got fixed, and it changes how they write and how much they care about being understood by whoever does the remediation. A tester who knows they will be engaged throughout the entire remediation process will produce higher quality writeups in their report.
And hire for curiosity, a true hacker mindset, over certifications. A certification tells you somebody can pass a test. I have had much better luck with people who take things apart at home for no particular reason.
Discover More In-depth Interviews:
