Offensive Security Needs to Become Continuous

During RSAC 2026, one theme kept coming up in conversations at the XBOW booth.

When we demonstrated targeted exploit validation triggered directly from a development pipeline, the conversation shifted quickly. What started with “Can AI do this?” quickly became “How do I integrate this into my existing workflow?”

More often than not, we then talked about an even broader question: how do we bridge the gap betweenthe developer fixing code and the analyst investigating issues in production?

That gap is clear in how penetration testing is done today.

A test runs. A report is produced. Weeks or months later, teams work through the findings. By then, the system has already changed.

Static security checks break down in systems that are constantly changing. I saw this firsthand working in cloud security: Teams made decisions based on posture findings that were already outdated by the time they were acted on. What they needed was runtime signal to prioritize action.

If software ships continuously, testing has to follow the same pattern. Testing needs to be triggered by real changes in risk, not scheduled on a calendar. Changes could include new deployments, code changes, identity updates, or newly exposed assets.

Otherwise, security teams are making decisions based on stale information. This isn't just an anecdotal observation; it’s a structural shift that the industry is already recognizing.

By 2028, over 60% of enterprise pen test programs will operate as continuous validation executed within DevSecOps pipelines.
– Source: Gartner, How to Implement a Continuous Offensive Security Program, March 2026

Continuous offensive security will become a shared layer that connects how software is built with how it’s secured.

The Rise of Continuous Offensive Security

To meet this 2028 reality, we have to solve two problems: autonomy and integration.

Testing can’t scale if every assessment depends on a human tester driving each step. It has to run where teams already work: inside development pipelines and security workflows.

Without both, “continuous” can’t really exist. With them, penetration testing becomes something that runs continuously inside real workflows, and not something that happens separately.

Findings don’t sit in reports anymore. They show up in pull requests, pipelines, and security tools, where teams can act on them immediately.

Making Continuous Testing Work in Practice

To make this model work, offensive testing has to integrate directly into both development pipelines and security operations workflows, bridging a gap that has historically existed between how software is built and how it’s secured.

We’ve recently introduced capabilities that make this integration possible:

• APIs to trigger testing from development pipelines and security platforms
• Incremental testing focused on changed application components

This enables testing to run continuously without requiring manual coordination or full re-tests of entire applications.

At RSAC, we demonstrated this model running in real environments.

Continuous Security in the Development Pipeline

XBOW can now detect and validate real application vulnerabilities during development, before code reaches production.

In one example we demonstrated at RSAC, a fork of the Spree e-commerce application contains an Insecure Direct Object Reference (IDOR) vulnerability. This is the type of vulnerability that static analysis often misses, but the more dynamic, autonomous agents from XBOW can prove.

It starts with a pull request.

When a developer opens a PR, a GitHub Action analyzes the code delta, identifies which parts of the application have changed, maps those changes to affected routes and endpoints, and triggers a targeted assessment through XBOW’s API.

This approach helps reduce scan fatigue by focusing only on the impacted surface area.

Once validated, the IDOR finding is posted directly into the pull request with the affected endpoint and actionable context.

Instead of waiting for periodic tests, teams evaluate changes as they happen, catching issues earlier and focusing on real risk. For this to fit into development workflows, assessments need to complete quickly (minutes, not hours) so teams can act without blocking delivery.

By testing only what changed, teams reduce noise while maintaining high signal quality.

One practical challenge is that most environments aren’t deployed for every pull request, which makes dynamic testing difficult. Targeting only affected components and integrating with existing environments is key to making this usable in practice.

Continuous Security for Security Operations

This is where the model connects two worlds that have traditionally operated separately: development and security operations. At a high level, it creates a continuous feedback loop between them.

Continuous offensive testing creates a shared signal across development and security operations, aligning how software is built with how it’s investigated and secured.

After all, continuous security doesn’t stop at code. Once software is deployed, risk is shaped by the environment it runs in. Testing code alone doesn’t tell you whether an attack would be detected, or how much exposure actually exists.

Continuous offensive security has to validate that as well.

At RSAC, we demonstrated this model running inside Microsoft’s security ecosystem.

XBOW now integrates with Microsoft Security Copilot and Microsoft Sentinel to bring offensive testing directly into operational workflows.

Validated findings are ingested as structured telemetry, including request paths, exploit behavior, and observed responses, so they can be analyzed alongside existing signals.

This creates a continuous feedback loop between testing and detection.

Security teams can:

• See how exploits manifest in their environment
• Identify where detection coverage exists, and where it doesn’t
• Investigate validated findings using the same tools they use for incidents

Instead of asking “how severe is this vulnerability?”, teams can ask:

“Is this exploitable here, and would we detect it?”

To support this workflow, XBOW and Microsoft introduced three components in public preview.

• XBOW Pentest Manager Agent: Initiates and orchestrates penetration tests
• XBOW Pentest Analysis Agent: Analyzes results and correlates signals for investigation
• XBOW Sentinel Data Connector: Ingests validated findings into Sentinel as structured telemetry

By integrating with Microsoft’s security ecosystem, offensive testing moves out of its silo and into the tools where defenders actually work.

The Pentest Agent allows a practitioner to initiate an assessment by providing a target (such as a URL), orchestrating the test through XBOW’s APIs.

The Pentest Analysis Agent enables investigation by querying the ingested data in Sentinel, supporting cross-correlation with existing telemetry and even generating queries to validate real-world exploit activity.

A practitioner can initiate a test from Security Copilot. XBOW runs an autonomous assessment, validates exploitability, and sends results into Sentinel.

Assessment results are ingested into Sentinel across three core tables—findings, assessments, and assets, allowing teams to correlate exploit activity with known resources in their environment.

From there, teams investigate findings in context—correlating exploit activity with Azure resources, Defender signals, and existing telemetry. This allows analysts to check whether exploit behavior observed during testing appears elsewhere in the environment, using the same tools they rely on for real incidents.

Remediation decisions are based on validated findings and observed detection coverage, not theoretical severity. There’s also early exploration of workflows where validated findings can be fed directly into automated remediation processes, though this is still evolving.

Final Thoughts

CI/CD changed how software is built and deployed. Continuous offensive security is starting to do the same for how systems are tested.

RSAC 2026 didn’t introduce this shift, but it made it clear how quickly it’s becoming necessary. The question is no longer whether an application passed a penetration test months ago. What matters is whether it can be exploited right now.

Continuous offensive security answers that by testing systems as they change, not after the fact. As attack surfaces expand, it’s one of the few models that can realistically keep pace with modern engineering. More importantly, it finally connects development and security operations around a shared understanding of real risk.

Get Started

We are currently rolling out the XBOW + Microsoft Security integrations in public preview. They can be accessed in the Microsoft Security Store below:

https://securitystore.microsoft.com/solutions/xbowinc.xbow-pentest-manager-agent
https://securitystore.microsoft.com/solutions/xbowinc.xbow-pentest-analysis-agent
https://securitystore.microsoft.com/solutions/xbowinc.xbow-sentinel-connector

We’ve got some great documentation to help you get going: https://docs.xbow.com/console/microsoft-integration.