This article is sponsored by XBOW and was written, edited, and published in alignment with our Emerj sponsored content guidelines. Learn more about our thought leadership and content creation services on our Emerj Media Services page.

The Cloud Security Alliance reports that AI-assisted software development is outpacing traditional application-security workflows. At the same time, the G7 Cyber Expert Group warns that AI allows attackers to probe systems faster, at greater scale, and with less expertise.

Common Vulnerabilities and Exposures (CVE) submissions to the National Vulnerability Database increased 263% between 2020 and 2025, the National Institute of Standards and Technology reports. Meanwhile, the FBI’s 2025 Internet Crime Report records nearly $21 billion in reported internet-crime losses.

For enterprise leaders, the challenge is operational and financial. Security teams must identify and prioritize exploitable vulnerabilities faster without increasing manual review costs or exposing critical systems to disruption.

In a recent series on the Emerj AI in Business Podcast, Niroshan Rajadurai, Chief Revenue Officer at XBOW, and Sridhar Boddula, Head of Security Platform Engineering at MassMutual, examine how enterprises can adapt their security operations to these pressures.

This article examines three strategies for helping enterprise security leaders identify and address vulnerabilities as AI accelerates cyber threats and software development:

• Exploit validation to prioritize vulnerabilities by business risk: Test whether attackers can reach and exploit identified software vulnerabilities, then prioritize remediation according to the sensitivity and business importance of the affected systems.
• Built-in governance to maintain control over autonomous security testing: Define authorized testing targets, prohibit destructive actions, and establish audit requirements so automated assessments can operate safely without requiring approval at every step.
• Focused testing of critical systems to guide security investment: Identify applications holding sensitive regulated data, conduct an authorized security assessment of a high-priority system, and use the findings to guide remediation and future investment decisions.

Listen to the full episodes below:

Episode 1: Machine‑Speed Security Risk in the Age of AI – with Niro Rajadurai of XBOW

Guest: Niroshan Rajadurai, Chief Revenue Officer at XBOW

Expertise: Application Security, DevSecOps, AI Strategy, Software Engineering

Brief Recognition: Niroshan Rajadurai is Chief Revenue Officer at XBOW. Previously at GitHub, he served as Vice President of Go-to-Market Strategy for AI, DevSecOps, and Application Security, following senior leadership roles in GitHub Advanced Security. He holds degrees in Computer Science and Electrical and Electronics Engineering from the University of Melbourne.

Episode 2: How Security Leaders Are Responding to Machine Speed Threats – with Sridhar Boddula of MassMutual

Guest: Sridhar Boddula, Head of Security Platform Engineering at MassMutual

Expertise: Security Engineering, Cybersecurity Strategy, Identity and Access Management, Zero Trust Architecture

Brief Recognition: Sridhar Boddula is Head of Security Platform Engineering at MassMutual. Previously, he worked at State Street, where he held senior leadership positions in cybersecurity architecture and engineering, application security, and digital platforms.

Exploit Validation to Prioritize Vulnerabilities by Business Risk

At GitHub, Niroshan Rajadurai’s team explored whether AI models could remediate existing code vulnerabilities without introducing new security risks. As AI-assisted development increases the volume of code requiring review, he demonstrates that security teams must distinguish false positives from genuine vulnerabilities and determine which confirmed findings present an exploitable risk:

“When we think about a security vulnerability, there are actually two parts to it. One is the original vulnerability. So this is a problem. This code has a bug in it, which can result in something bad happening. But the second part of that is: is that bug actually really reachable by someone who might want to do something bad with it?”

– Niroshan Rajadurai, Chief Revenue Officer at XBOW

Rajadurai explains that demonstrating whether a vulnerability can be exploited helps determine its priority. An exploit could allow an attacker to extract sensitive information, execute commands on the affected system, or gain access to other parts of the network.

Failure to demonstrate an exploit does not necessarily mean that exploitation is impossible. The result should inform prioritization alongside the vulnerability’s exposure, asset criticality, and potential consequences.

Sridhar Boddula emphasizes the importance of prioritizing software vulnerabilities according to the criticality of affected systems and the potential consequences for business operations.

In an e-commerce business, a vulnerability affecting purchasing or sales infrastructure may warrant earlier remediation than a comparable vulnerability on a non-internet-facing internal system, depending on the actual access paths and potential impact.

Together, Rajadurai’s emphasis on exploit validation and Boddula’s focus on business exposure provide a four-step framework for prioritizing vulnerabilities and verifying remediation:

1. Can an attacker reach it? Assess direct and indirect access paths. Limited exposure may reduce priority, depending on asset sensitivity and potential impact.
2. Can testing demonstrate an exploit? A validated exploit strengthens the case for urgent remediation. An unsuccessful test does not establish that the vulnerability is safe.
3. What would compromise affect? Consider regulated data, revenue-critical services, privileges, and potential access to other systems. Rank findings according to business consequences and technical severity.
4. Did the fix hold? Retest the application after remediation, including variations of the original exploit, to determine whether the underlying weakness has been addressed.

The last step matters because of what Rajadurai calls a naive fix. He describes a published customer case in which a team blocked a malicious URL by adding a filter for that string to its web application firewall. They retested by swapping one letter for its percent-encoded equivalent, and the request passed straight through because the filter matched only the raw text.

Security leaders can measure the operational impact of autonomous vulnerability testing by tracking three performance indicators:

• Analyst hours spent validating findings.
• Time from vulnerability discovery to verified remediation.
• Proportion of high-priority applications assessed within a defined testing cycle.

Together, these measures help leaders assess whether autonomous testing improves security coverage and remediation efficiency without proportionally increasing staffing costs.

Built-in Governance to Maintain Control Over Autonomous Security Testing

Rajadurai notes that if a model writes code at 200 miles per hour and a human reviewer checks it at 10, the human becomes a speed bump that the pipeline cannot absorb. Requiring human approval at every stage can delay autonomous testing, particularly outside working hours when reviewers may be unavailable.

Removing routine human approvals requires automated testers to operate within defined safety boundaries, particularly when assessing production systems where destructive actions could interrupt business operations or compromise data:

“An experienced hacker would say, ‘Don’t do that,’ because if it’s a production system, you’re going to wipe out all the data and that’s a bad thing. It turns out if you use a model to do the same exercise, the model says, ‘Wow, I found a SQL injection. I’m going to do a drop table.’”

– Niroshan Rajadurai, Chief Revenue Officer at XBOW

Autonomous offensive testing therefore requires governance and safety controls built into the testing framework. Rajadurai describes guiding models to follow the practices of experienced ethical hackers, defining operational boundaries and providing expert instructions during the reasoning process.

Human reviewers can then focus on escalations requiring judgment rather than approving every automated step. Organizations remain responsible for authorizing testing, establishing acceptable behavior and evaluating the resulting evidence.

That framework is also where Rajadurai sees in-house builds stall. His rule of thumb from conversations with companies that built their own is that about 80% of an AI security tool is easy to build and 20% is hard. Leaders weighing a build can test their plans against the hard 20% he describes:

• Noise control: Reduce false positives from large language model (LLM) scanners through dedicated filtering mechanisms and ongoing analysis to prioritize actionable findings.
• Safety boundaries: Define approved testing targets, prohibited destructive actions, and escalation conditions within the governance framework before deployment.
• Exploit generation: Address model-provider restrictions on exploit generation through frameworks that support authorized vulnerability validation.
• Model adaptability: Combine models from different providers and provide expert guidance through their context windows to accommodate new capabilities without repeated model training.
• Toolchain integration: Integrate validated findings into existing developer tools and coding assistants to support remediation within established workflows.

Boddula highlights that keeping pace with automated threats requires changes to security operations rather than simply adding tools. Embedding security engineers into development workflows allows organizations to identify risks earlier and reduce delays caused by manual reviews:

“Security cannot remain a review queue that slows down change while attackers operate in hours. It has to become an embedded, engineering-native function. That means security engineers are working alongside or inside DevOps and DevSecOps pipelines, expressing policy as code, and building automated guardrails that catch these types of issues or these types of risks when they are introduced.”

– Sridhar Boddula, Head of Security Platform Engineering at MassMutual

Boddula also recommends applying zero trust principles, which require users, devices, and applications to have their access verified rather than trusted automatically. Restricting permissions and continuously evaluating access can limit an attacker’s ability to move between systems if an account is compromised.

He recommends treating automation engineering as a core security discipline, embedding automated controls into development workflows so engineers receive prioritized findings with sufficient context and proposed remediation paths. This reduces reliance on manual review queues while maintaining oversight through established security policies.

By reducing routine handoffs and verification effort, organizations can expand security-testing capacity without proportionally increasing headcount. Leaders can measure operational improvements through analyst hours spent on manual reviews, time to verified remediation, and the number of high-priority applications assessed within a defined testing cycle.

Focused Testing of Critical Systems to Guide Security Investment

Boddula explains that AI-enabled probing, phishing tools, and synthetic media have lowered the expertise and cost required to launch certain cyberattacks. He illustrates this accessibility with an example of approximately $50 for access to an AI model, enabling attackers to repeat techniques across multiple targets at comparatively little additional cost. The figure illustrates declining barriers to entry rather than the verified cost of conducting a successful cyberattack.

Rajadurai highlights the imbalance between attackers and defenders. An attacker needs to exploit only one vulnerability to compromise an application, while security teams must identify and address every exploitable weakness. This asymmetry strengthens the case for continuous, automated security testing that can identify vulnerabilities and validate remediation before attackers exploit them.

Boddula illustrates the importance of continuous, scenario-based security testing through a hypothetical attack in which an AI-generated voice is used to manipulate a help desk employee, followed by the compromise of a dormant service account and an attempt to escalate access through the organization’s identity provider. He recommends testing such scenarios proactively to determine whether existing security controls can prevent or interrupt an attack.

Continuous, authorized testing allows security teams to assess high-priority applications more frequently than periodic penetration tests alone. As systems change, teams can use exploit evidence to prioritize remediation and verify whether fixes address the underlying vulnerabilities.

Security leaders can begin implementing continuous vulnerability testing by prioritizing systems that hold sensitive data or support critical business operations. Drawing on both guests’ recommendations, the following five steps provide a practical approach to establishing testing priorities, addressing security weaknesses and informing future investment decisions:

1. Build an asset inventory: Identify sensitive data, applicable regulations, data locations, processing activities, and accountable owners. Boddula recommends including internal applications, subscribed cloud services, managed platforms and network hardware to improve visibility into the organization’s digital assets.
2. Prioritize applications by business exposure: Assess public-facing applications according to their connections to sensitive data, critical systems and internal development environments. A standalone marketing page may warrant lower priority than an application connected to customer or billing systems, provided its integrations, credentials, and potential downstream access have been assessed.
3. Test high-priority applications without credentials: Rajadurai recommends using authorized autonomous testing to assess whether attackers could gain access to critical applications from outside the organization. Begin with high-value, public-facing systems to identify exploitable vulnerabilities before expanding testing.
4. Address identity and access weaknesses: Identify dormant service accounts, excessive permissions, unmanaged application programming interface keys, standing administrator access, and third-party integrations. Boddula recommends removing unnecessary access and strengthening controls to limit potential attack paths.
5. Present findings to the board: Use validated vulnerabilities, remediation priorities, and results from an initial high-value assessment to demonstrate remaining security risks and support decisions about expanding continuous testing.

Boddula cautions against delaying initial security assessments until the next audit or budget cycle, recommending that leaders begin with a focused test of a system containing sensitive regulated data:

“An imperfect control operating today creates more value than a perfect strategy that remains on paper. If I were to leave listeners with one action immediately, it would be this: Choose the system, at least one system that holds your most sensitive regulated data and run a focused test on it, and see what are those findings.”

– Sridhar Boddula, Head of Security Platform Engineering at MassMutual

For security leaders, the immediate priority is to establish what an attacker can reach, validate the vulnerabilities that pose the greatest business risk, and develop a remediation plan. The results can establish a baseline for expanding continuous testing, measuring improvements in security coverage, and determining where further investment is justified.