IT Tech Pulse Exclusive Interview with Gadi Bashvitz Co-Founder and Chief Executive Officer of Bright Security

Gadi Bashvitz, Co-Founder and CEO of Bright Security, discusses how continuous offensive validation, AI-driven security testing, and independent security ground truth are transforming application security.

Gadi, you started in Israel’s 8200 unit and later built and sold multiple companies before founding Bright Security. Looking back, what belief about cybersecurity did that path force you to abandon or completely rethink? 

GB: The belief I had to abandon was that better prevention would eventually solve the security problem. Early in my career, the cyber industry was built around the idea that if we wrote better rules, added more controls, and found vulnerabilities earlier, we could prevent most meaningful failures. What I learned over time is that software changes too quickly, attackers adapt too quickly, and now AI is accelerating both sides of that equation.[Text Wrapping Break][Text Wrapping Break] The more important question is not, “Can I find everything that might be wrong?” It is, “Can I continuously prove what is actually exploitable, fix what matters, and verify that the fix really worked?” That distinction is fundamental. Security teams have spent years generating more findings, while developers have become overwhelmed by alerts that may or may not represent real risk. My thinking shifted from prevention and detection as the end goal to validation as the source of truth. In an AI-driven world, where code creation and vulnerability discovery are both becoming dramatically faster, that shift becomes even more important and has to be implemented at every stage of the AI SDLC by leveraging both AI and deterministic validation. 

Application security has traditionally treated developers and security teams as separate functions with competing incentives. What specific failure in that arrangement convinced you it needed to be restructured rather than just improved?

 GB: The failure is visible in the workflow: security produces a list of findings and effectively hands the problem to developers. Security is measured on finding risk; developers are measured on shipping software. Even when both teams are doing their jobs well, the system creates friction because the developer is being asked to interrupt productive work to investigate whether a finding is real, exploitable, relevant, and worth fixing. Just today I met with 1 prospect and 1 customer. Both very well known global organizations (one tech and 1 finance) and in both discussions the security leaders told me they have no way of influencing developers to adopt solutions that will enable them to create more secure products, even if the solutions provided will save the developers time. That does not make sense.[Text Wrapping Break][Text Wrapping Break] I don’t think the answer is simply to make the handoff more efficient. The handoff itself is the problem. Security has to become part of the development loop and provide developers with evidence, context, and ideally a validated remediation—not another queue of uncertain work. That is the philosophy behind Bright’s approach: prove exploitability at every stage of the SDLC, help remediate, and then prove the fix. When security can give a developer ground truth instead of an alert, the relationship changes from “security is blocking me” to “security is helping me ship safely.” 

Bright Security’s new AI PT module responds to what you’ve called a shrinking gap between vulnerability disclosure and exploitation. What actually breaks first in an organization’s security process once that gap approaches zero? 

GB: The first thing that breaks is the assumption that humans have time to triage. Most security processes still assume a sequence: discover a vulnerability, put it into a queue, assess severity, assign it, investigate it, fix it, and eventually retest it. That model only works when the attacker moves more slowly than the process.[Text Wrapping Break][Text Wrapping Break] As AI compresses the time between discovery and weaponization, a days or weeks-long remediation workflow becomes structurally inadequate. You cannot solve a machine-speed problem with a ticket queue. Organizations need a combination of agentic & deterministic continuous, autonomous offensive validation that can determine what is actually exploitable, prioritize it based on evidence, and verify remediation at comparable speed. AI penetration testing is important for 2 key reasons:  

• It moves beyond asking whether a weakness theoretically exists and toward continuously testing whether an attacker can actually use it.  

• It leverages AI to find more complex, chained and multi-step vulnerabilities that would otherwise be very hard to find. 

The scarce resource becomes human attention, so automation has to make the routine decisions and escalate the consequential ones. 

You’ve pointed to systems like Claude Mythos and OpenAI’s Aardvark as reasons customers are newly anxious about their AI SDLC. What changes about defense when the tools finding your flaws are as capable as the ones exploiting them? 

GB: Defense has to become empirical. For years, organizations could rely heavily on rules, static analysis, secure coding guidance, and human review because the rate of change was manageable. Once AI can generate code, discover weaknesses, reason about exploit paths, and iterate continuously, you can no longer assume that a preventative control or even another AI model saying the code looks secure is sufficient.[Text Wrapping Break][Text Wrapping Break] This is why I often say that AI cannot be allowed to grade its own homework. The model generating or reviewing code may be excellent, but organizations still need an independent source of security ground truth. That means testing the running application from an attacker’s perspective and proving whether a weakness can actually be exploited. In practice, defense starts looking more like a continuous feedback system: generate, validate dynamically, remediate, verify, and repeat. The advantage goes to organizations that can close that loop at machine speed while keeping independent validation in the process. 

The other factor that cannot be ignored is cost. Many organizations have fallen into the trap of trusting AI to find and fix vulnerabilities for them. Even assuming these solutions can do that (jury is out on that) the cost is extremely high. They might be able to absorb the cost of a 1-time run through their applications and APIs, but how does this become sustainable on an ongoing basis? The only way that becomes a reality is if we let AI do what only AI can do and use deterministic solutions for everything else so cost is optimized. 

As more vulnerabilities get discovered, exploited, and even fixed by AI systems with limited human review, how should organizations decide which security decisions still require a person in the loop, and which don’t? 

GB: I would separate decisions by consequence rather than by tradition. Humans should remain in the loop where a decision changes business risk, trust boundaries, architecture, production behavior, or where the system has meaningful uncertainty. A critical production change, an ambiguous exploit path involving sensitive data, or a decision to accept significant risk should still have accountable human judgment.[Text Wrapping Break][Text Wrapping Break] But humans should not be the bottleneck for repetitive evidence-based work. Testing whether a vulnerability is exploitable, reproducing it, correlating it with code, generating a candidate fix, retesting that fix, and closing findings that are demonstrably resolved are exactly the kinds of activities that should become increasingly autonomous. The goal is not “human out of the loop.” It is “human at the right level of the loop.” AI should absorb the volume and repetition so security professionals and developers can spend their time on decisions where judgment, context, and accountability actually matter. We are consistently seeing customers that have reduced the time it takes to remediate a vulnerability from an average of 3.5 hours to 10-15 minutes as the developer has all the evidence presented to them and they choose whether to approve the PR or not. That is a great example of a human in the loop at the correct time. 

Can you please give me two or three predictions for application security over the next three to five years that you suspect most CISOs would currently disagree with, and explain briefly what evidence is already pointing you toward them. 

GB: First, I think traditional vulnerability management based on large static backlogs will become much less relevant. AI will create and discover issues faster than humans can triage them, so organizations will increasingly prioritize continuously validated, exploitable risk rather than maintaining enormous lists of theoretical findings.[Text Wrapping Break][Text Wrapping Break] Second, I believe a meaningful portion of penetration testing will become continuous rather than periodic. Annual or quarterly pentests were designed for a world in which applications changed relatively slowly. AI-generated software can change continuously, and agentic offensive systems can test continuously. The economics and the technology are both moving toward persistent AI-driven penetration testing, with human experts focused on the hardest and highest-consequence scenarios.[Text Wrapping Break][Text Wrapping Break] Third, independent security validation will become a standard control in AI-native software development. We are already seeing coding agents move from assisting developers to creating increasingly complete applications and changes. If the same AI ecosystem generates, reviews, and approves its own work, organizations create a dangerous concentration of trust. I expect independent dynamic validation, essentially a security ground-truth layer, to become as natural to AI-generated code as automated testing and CI/CD are today. This is probably the most provocative of the 3. 

Bonus point: AI will not make AppSec obsolete. It will make it evolve. 

For security leaders and developers who feel caught between AI-driven development speed and mounting compliance pressure, what’s the piece of advice you find yourself repeating most, and why do teams keep needing to hear it? 

GB: Don’t try to make AI development move at the speed of your old security process. Make security capable of moving at the speed of AI development.[Text Wrapping Break][Text Wrapping Break] Teams need to hear that because the natural reaction to increased speed and uncertainty is to add another approval, another scanner, another policy, or another gate. That can create the appearance of control while actually increasing friction and expanding the backlog. Compliance also does not have to mean slowing development down. If you can continuously produce evidence showing what was tested, what was exploitable, what was fixed, and that the fix was verified, you can improve both security and auditability.[Text Wrapping Break][Text Wrapping Break] The objective should be evidence, not ceremony. Build security into the development loop, automate what can be proven automatically, and reserve human intervention for decisions that genuinely require judgment.

You’ve talked about moving security from a gate that blocks releases to something that enables them. What does a development team actually feel different day-to-day once that shift has genuinely happened inside an organization?

GB: The biggest difference is that developers stop experiencing security as an interruption. Instead of getting a long report days later, they receive a small number of high-confidence issues with evidence that the vulnerability is real, context for why it matters, and actionable remediation while the code is still fresh in their minds.[Text Wrapping Break][Text Wrapping Break] They also spend far less time debating false positives or trying to reproduce security findings. Ideally, the system can validate a proposed fix and tell them, before the change progresses, that the vulnerability is no longer exploitable. That shortens the feedback loop dramatically.[Text Wrapping Break][Text Wrapping Break] When this works, developers don’t feel that security has disappeared; they feel that security has become useful. Security saves them time and makes them more efficient. No developer (well, very few) wants to release vulnerable and sloppy code. We need to help them achieve their goal without disruption. Releases move faster because teams have more confidence, security teams spend less time chasing findings, and both groups are working from the same evidence. That is the transition from security as a gate to security as an engineering capability. 

Thank you, Gadi Bashvitz, for taking the time to share your insights with us.

Write to us [⁠wasim.a@demandmediaagency.com] to learn more about our exclusive editorial packages and programmes.