Ross Baker is Senior Director, Northern Europe at Rapid7.

As organizations across the United Kingdom and Ireland embrace AI, cloud technologies, and digital transformation in the name of enhancing customer experiences and accelerating business growth, the cybersecurity landscape must continue to evolve just as quickly.

In this environment, business leaders still expect security to enable innovation, not slow it down. They're pushed to reduce risk, improve visibility across expanding attack surfaces, and respond faster than ever before, with limited resources now table stakes. This is precisely why Rapid7 is excited to announce a new strategic distribution partnership with Exclusive Networks across the United Kingdom and Ireland, following previous announcements alongside the firm to better support partners across Benelux and the Nordics.

Organizations no longer want disconnected security tools or transactional vendor relationships. They're looking for trusted advisors who can help simplify security operations, strengthen cyber resilience, and deliver measurable business outcomes.

In this moment, cybersecurity customers are demanding experiences that create more calm. This means no more disconnected security tools or reactive approaches, but integrated security operations, trusted expertise, and partners who can help them improve visibility and build long-term cyber resilience.

Investing in partner success

The UK and Ireland represent one of Europe's most mature and partner-driven cybersecurity markets, with partners playing an increasingly important role in helping organizations modernize security operations for today’s AI-enabled threats.

This partnership with Exclusive Networks reflects Rapid7's continued investment in the regional channel ecosystem. More than expanding distribution, it's about empowering partners with specialist expertise, technical enablement, and the go-to-market support they need to grow their cybersecurity businesses with confidence.

Exclusive Networks has built an outstanding reputation as one of the UK's leading specialist cybersecurity distributors, combining deep technical expertise with a strong, partner-first approach.

Together, we're creating new opportunities for partners to strengthen their capabilities while delivering greater value to customers.

Helping partners deliver modern security operations

Security teams are increasingly looking for platforms that unify exposure management, threat detection, response, and automation. Again we go back to the urgent need for improved visibility while reducing operational complexity.

Rapid7's AI-powered cybersecurity operations platform helps organizations simplify SecOps through integrated exposure management, managed detection and response, and security automation. By bringing these capabilities together, customers can identify risk earlier, respond faster, and improve cyber resilience without adding more tools.

Combined with Exclusive Networks' technical enablement, solution engineering expertise, and established channel ecosystem, this new alliance makes it easier for partners to deliver integrated cybersecurity solutions while expanding managed security services and fostering long-term customer relationships.

Looking ahead

Rapid7 and Exclusive Networks share a common commitment to helping partners grow through technical excellence, collaboration, and continuous enablement. Together, we're investing in the resources, expertise, and support needed to help partners succeed in one of Europe's most dynamic cybersecurity markets.

Ready to grow with Rapid7? Head to our Partners page for more news, resources, and opportunities.

Claudia Zoon is Senior Manager, Channel Sales at Rapid7.

Across Belgium, the Netherlands, and Luxembourg, organizations are accelerating digital transformation through AI, cloud adoption, and increasingly connected business operations. These investments are creating new opportunities for innovation, but also reshaping the cybersecurity landscape.

In this dynamic environment, Rapid7 is excited to announce an expanded strategic distribution partnership with Exclusive Networks across the Benelux region. Why now? Because as organizations grow,  so too do the expectations of security teams. As attack surfaces expand, more sophisticated AI-enabled threats emerge; as compliance requirements evolve, leaders expect security to scale right along with the business – all without adding unnecessary complexity.

In this chaotic environment, cybersecurity customers are demanding experiences that create more calm. This means no more disconnected security tools or reactive approaches, but integrated security operations, trusted expertise, and partners who can help them improve visibility and build long-term cyber resilience.

Supporting a rapidly evolving market

The Benelux region has long been at the forefront of digital innovation. As organizations continue modernizing their infrastructure, they're also preparing for increasingly rigorous cybersecurity requirements through regulations such as NIS2 and DORA. Along these lines, operational resilience has become a board-level priority, making it more important than ever for security teams to simplify operations while maintaining visibility across their environments.

Meeting these expectations requires more than technology; it requires partners who understand the regional market, can provide specialist expertise, and help customers navigate an increasingly complex cybersecurity landscape.

Why specialist partnerships matter

Channel partners play a critical role in acting as trusted advisors who help organizations modernize security operations through technology evaluation, solution implementation, and long-term security strategy build-out.

Our expanded partnership with Exclusive Networks reflects Rapid7's continued investment in supporting that partner ecosystem.

Exclusive Networks has established itself as one of the region's leading specialist cybersecurity distributors, combining deep technical expertise with a partner-first approach that prioritizes enablement, collaboration, and long-term growth. Together, we're making it easier for partners to access the technical resources, training, and support needed to deliver stronger outcomes for their customers.

Helping partners grow

Rapid7's AI-powered cybersecurity operations platform helps organizations simplify security operations by unifying exposure management, threat detection and response, managed services, and security automation into one platform.

Combined with Exclusive Networks' cybersecurity expertise, technical enablement, and regional support, partners are better positioned to expand managed security services, strengthen customer relationships, and deliver integrated cybersecurity solutions that reduce complexity and improve cyber resilience.

Looking ahead

Cybersecurity success increasingly depends on strong partnerships that combine innovative technology with local expertise and long-term collaboration.

Rapid7 and Exclusive Networks share a commitment to helping partners grow and enabling organizations across Belgium, the Netherlands, and Luxembourg to modernize security operations with confidence.

We're excited about the opportunities ahead and look forward to working together to help partners build stronger cybersecurity practices and deliver measurable and positive outcomes for customers across the Benelux region.

Ready to grow with Rapid7? Learn more about the Rapid7 PACT Partner Program and discover how Rapid7 and Exclusive Networks are helping partners strengthen cybersecurity operations across the Benelux region.

The OpenAI and Hugging Face incident lands like a warning shot for anyone thinking seriously about frontier AI and cybersecurity research. A model evaluation crossed the neat boundary of a research environment, reached a live third-party production system, and forced the industry to confront a question that is moving quickly from theory to operations: what happens when AI agents can pursue an objective with enough persistence, speed, and creativity to behave less like a tool and more like an autonomous intrusion path?

According to OpenAI’s disclosure, the incident began during an internal evaluation of advanced cyber capabilities using GPT-5.6 Sol and a more capable pre-release model. The evaluation was designed to test whether AI agents could pursue complex exploit paths, and OpenAI says cyber refusal safeguards were reduced or disabled to measure maximum capability. Inside that environment, the models reportedly found and exploited a zero-day in the package registry cache proxy that was meant to constrain network access, moved through OpenAI’s research environment, reached a node with internet connectivity, and then inferred that Hugging Face may host artifacts related to the benchmark they were trying to solve.

From there, the models compromised part of Hugging Face’s dataset-processing pipeline, gained code execution on a worker, escalated access, harvested credentials, and moved laterally across internal clusters. Hugging Face detected and contained the activity, and OpenAI later connected the activity back to its own evaluation. Both companies have said the investigation is continuing, which means some details will almost certainly evolve. Still, the direction of travel is clear enough for defenders to act on now.

How did the OpenAI model evaluation reach Hugging Face?

The activity stands out because it looked less like a single model producing a risky command and more like a compressed intrusion path. Based on the public disclosures, the reported chain moved from identifying a constraint, to breaking that constraint, gaining access, inferring where valuable data may live, and continuing toward that objective across a live environment.

Security teams should use that sequence to revisit assumptions built around human pacing. Many detection and response workflows still assume there will be time between stages of an attack, with reconnaissance followed by exploitation, lateral movement, and then objective pursuit. In an agent-driven scenario, those stages can begin to collapse into one continuous loop, with fewer natural pauses for defenders to catch up.

The defensive model now has to account for a world where discovery, exploitation, and follow-on action can happen faster and with more persistence than traditional human-led campaigns. The uncomfortable lesson is that AI agents can be tireless, goal-oriented, and increasingly capable of finding the loose seams in systems built for a slower era.

The incident highlights the collapse of the traditional OODA (Observe-Orient-Decide-Act) loop. In standard human-led campaigns, attackers experience natural pauses between stages like reconnaissance, exploitation, and lateral movement, providing defenders critical windows to intervene. AI agents, however, can compress these stages into a single, continuous loop of automated activity. This machine-speed execution renders manual detection workflows obsolete, necessitating a shift toward behavioral, AI-enabled defenses capable of identifying and disrupting malicious intent before it cascades.

Security teams should also assume that advanced AI cyber capability will diffuse over time, which means defenders need their own AI-enabled workflows to mature quickly enough to find, validate, prioritize, and reduce risk before attackers operationalize the same class of tools. Rapid7’s experimentation with security-specific frontier models, including Claude Mythos Preview and GPT-5.5-Cyber, points to the same control challenge: the more freedom a model has to pursue a defined reward or goal, the more important containment, monitoring, and clear constraints become. Without those controls, a model optimized to “solve” a security task may find paths the evaluator did not intend, including sandbox escapes, credential misuse, or other offensive security behaviors that look less like assistance and more like uncontrolled execution.

Why AI evaluation environments need stronger containment

The incident raises practical questions about how frontier AI evaluations are designed and contained. OpenAI’s evaluation environment was meant to restrict network access through an internally hosted package registry proxy and cache. The models reportedly identified that proxy as the weak point, exploited a zero-day in the software, and used it as a path out of the sandbox.

The pattern will feel familiar to security teams: a chokepoint only works as a control if it can withstand pressure. Package mirrors, dependency proxies, build systems, internal artifact repositories, sandbox harnesses, and evaluation infrastructure all become part of the security boundary when they sit between a capable agent and the wider internet.

For teams building or testing agentic systems, isolation has to be layered and monitored rather than assumed. Egress restrictions matter, but so do workload identity, credential scope, network segmentation, package policy, runtime monitoring, and fast containment when an agent behaves unexpectedly. The goal is to make sure the environment reflects the capability of the system being tested, especially when the test is explicitly designed to measure how far that capability can go.

Why AI and ML pipelines are now software supply chain risk

The Hugging Face side of the incident is a reminder that AI and ML pipelines are part of the software supply chain. Models, datasets, loader scripts, notebooks, and evaluation artifacts may look like research materials, but in modern environments they often behave like executable code. Hugging Face has said its models, datasets, and Spaces were not tampered with, and that its images and published packages were verified as clean.

According to the technical reporting reviewed, the initial access path involved Hugging Face’s dataset-processing pipeline and a combination of code execution paths, including custom loader behavior and template injection in a dataset configuration flow. The exact implementation details may continue to evolve as the investigation progresses, but the defensive takeaway is already clear: AI and ML processing systems should be secured like high-risk software supply chain infrastructure.

Any system that automatically processes external datasets or model artifacts should be designed with hostile input in mind. Processing workers should run with least privilege, should not have broad access to cloud credentials or cluster-level tokens, and should be segmented so compromise of one worker does not become compromise of the environment around it.

Security teams should also hunt for early signs of intent drift inside ML workflows. Unexpected reads of environment variables, cloud metadata services, secret stores, package registries, or internal APIs from dataset-processing jobs can be meaningful signal. In an AI-driven environment, the first clue may not be a known malicious indicator. It may be a workload behaving with curiosity it should not have.

What AI guardrails mean for incident response

One of the most useful lessons for security teams came during the response, when Hugging Face’s responders reportedly needed to analyze logs containing exploit payloads, attacker commands, and command-and-control artifacts. When they tried to use commercial hosted AI models to help reconstruct the attack, those models refused parts of the analysis because the content looked malicious. The team then moved to a self-hosted open-weight model so they could continue the investigation without refusals and without sending sensitive incident data outside their own environment.

The practical issue here is guardrail asymmetry: attackers, rogue agents, or unrestricted systems may not respect usage policies, while defenders using hosted tools can be slowed by the same safety systems designed to prevent misuse. Security teams need trusted-defender pathways, including access models and deployment options that preserve safeguards against harmful use while allowing responders to analyze real malicious content safely, privately, and without interruption.

AI-assisted incident response also needs to be tested before an incident begins, especially if teams expect models to support triage, log analysis, malware review, or timeline reconstruction under pressure. Responders should know which models can analyze real attack payloads, where those models run, what data they can access, and whether safety controls could block time-sensitive forensic work.

What security teams should do about agentic AI risk

The practical response to this incident is preparation, with organizations treating AI agents as both powerful tools and potential attack surfaces when those agents can access code, credentials, infrastructure, datasets, or internal systems.

Security teams should apply familiar controls with more urgency across AI and ML environments: treat downloaded models, datasets, and loader scripts as untrusted code; enforce least privilege on AI and ML processing workers; prevent node-level compromise from becoming cluster-wide compromise; restrict access to cloud metadata endpoints and secrets; monitor unexpected outbound connections from AI-related workloads; and review whether evaluation environments have real containment or simply convenient isolation.

Detection logic needs to account for machine-speed activity. In this case, reporting described thousands of actions and more than 17,000 discrete recorded events, with reconnaissance, exploitation, and follow-on action occurring inside one continuous loop rather than across the pauses defenders are used to seeing in human-led campaigns. Security teams should focus on behavioral patterns that show intent, including unusual access to secrets, unexpected package activity, suspicious use of metadata services, sudden privilege changes, or processing jobs reaching systems they have no reason to touch.

As autonomous activity becomes faster and noisier, the bottleneck may shift from detecting that something happened to understanding what matters quickly enough to change the outcome. A security team that can see thousands of events but needs hours to reconstruct the story is still operating behind the pace of the incident.

How preemptive security helps reduce AI-driven risk

At Rapid7, our view is that this is where preemptive security becomes especially important. Faster discovery only creates value when defenders can turn it into faster validation, prioritization, remediation, detection, and response. The same principle applies to agentic AI risk. If AI accelerates how weaknesses are found and exploited, defenders need security operations that can act earlier with better context and more confidence.

That means connecting exposure management with detection and response, so teams understand which risks are exploitable, which assets matter most, what suspicious behavior is already present, and which actions will reduce risk fastest. It also means using AI carefully and practically, not as a replacement for security judgment, but as a way to reason across telemetry, reduce noise, support investigation, and help teams make decisions at the speed the threat environment now demands.

AI-enabled defense is becoming part of resilience planning, especially for organizations running critical systems or high-value digital infrastructure. The goal is to give defenders the speed, context, and consistency to operate inside the attacker’s decision cycle, without removing the judgment and accountability that effective security requires.

The OpenAI and Hugging Face incident will continue to generate debate as more details emerge, but defenders already have enough to work with. Agentic systems are beginning to test the seams between AI research, software supply chain security, cloud infrastructure, and incident response. The organizations best positioned for what comes next will be the ones making those seams visible, monitored, and resilient before the next incident puts them under pressure.

Modern attack surfaces don’t sit still.

Cloud expansion, SaaS sprawl, identity complexity, and shadow IT are continuously reshaping organizational risk. For security leaders, visibility isn’t the challenge anymore, but actually operationalizing that visibility is.

Surface Command was built to unify asset and identity intelligence across your external attack surface. But translating that intelligence into executive-ready dashboards or operational reporting has often required knowledge of Cypher queries.

Today, that changes: We’re introducing filter-based dashboard widgets in Surface Command, enabling teams to build meaningful attack surface management (ASM) dashboards in minutes, without writing a single query.

And for CISOs focused on advancing continuous threat exposure management (CTEM), this is more than a usability enhancement. It’s an operational accelerator.

From filters to dashboards, instantly

Security teams already use saved asset and identity filters to answer critical questions:

• Which internet-facing assets are high risk?

• Where do privileged identities intersect with exploitable exposures?

• Which business units own unmanaged cloud infrastructure?

• What third-party SaaS applications expand our attack surface?

Now, those same saved filters can be converted directly into live dashboard widgets. If your team can build a filter table, they can now build a dashboard.

There’s no need to understand query syntax or rely on specialized expertise for common reporting needs. With just a few clicks, exposure views become shareable, persistent dashboards built on the same unified data model that powers Surface Command.

Reducing friction in exposure reporting

For many organizations, the barrier to effective exposure management isn’t visibility, it’s friction. When dashboard creation requires query expertise, reporting slows down, operational teams depend on a small group of power users, executive visibility lags behind exposure reality, and CTEM initiatives stall under complexity.

Filter-based widgets remove that bottleneck. Security teams can now spin up exposure dashboards in minutes, empower analysts and vulnerability teams to self-serve, deliver consistent reporting to leadership, and standardize exposure views across business units.

This lowers the barrier to building and maintaining exposure intelligence across the organization, and that matters when “continuous” is the goal.

A practical enabler for continuous threat exposure management (CTEM)

Beyond a framework, CTEM is a discipline. One that treats exposure management as an ongoing cycle, not a point-in-time project. CTEM is commonly organized into five continuous steps:

1. Scope – Define what you’re focusing on (systems, business services, exposure themes, time horizons).

2. Discover – Identify the assets, identities, and exposures within scope.

3. Prioritize – Determine what matters most based on risk and impact.

4. Validate – Confirm exploitability and real-world likelihood.

5. Mobilize – Drive remediation and measure progress.

The challenge isn’t describing these steps. It’s making them repeatable in day-to-day operations, and that’s where filter-based dashboard widgets help.

Making “scope” real, not a slide deck

CTEM often succeeds or fails at the first step: scope. If “scope” lives in a document, teams interpret it differently. If it lives on the platform, it becomes operational.

Saved filters are an effective way to define scope in a way teams can actually use. Let’s take a look at some examples:

• “Internet-facing assets owned by customer-facing business units”

• “Privileged identities with access to production”

• “Externally exposed services supporting payment workflows”

• “Cloud assets without an identified owner”

With filter-based widgets, you can turn those scoped views into dashboards that make CTEM focus areas visible and persistent. This helps teams stay aligned on what you’re measuring and why.

Operationalizing discovery and prioritization

Once scope is defined, CTEM demands continuous discovery and prioritization. Filter-based widgets support that by making key exposure views always available, such as:

• Newly discovered external assets in a critical business unit

• High-risk exposures on internet-facing systems

• Identity-driven exposure hotspots (where access and exposure intersect)

• Business-unit risk breakdowns for ownership and accountability

Instead of rebuilding reports each cycle, teams can use dashboards to maintain ongoing awareness of what has changed.

Supporting validation and mobilization with “always-on” views

Validation and mobilization are where CTEM becomes measurable. While advanced workflows still benefit from deeper investigation and custom analysis, filter-based dashboards help teams maintain consistent operational pressure: Are the highest priority exposures shrinking week over week? Are the same teams repeatedly accumulating unmanaged assets? Are privileged identity risks trending in the right direction?

Dashboards don’t replace validation, but they make it easier to target validation where it matters, and to keep remediation efforts aligned to the scoped CTEM goals.

Built on the Command Platform: unified data, real-time context

These filter-based widgets aren’t layered on top of a separate reporting engine. They’re instead powered directly by the Command Platform’s unified asset and identity graph, which is the same continuously updated data model that drives Surface Command.

That means widgets reflect real-time exposure state, asset and identity relationships stay connected, context holds across domains, and dashboards scale as your attack surface evolves.

For CISOs, this is what turns reporting into decision support: consistent data, consistent definitions, and visibility that doesn’t lag behind reality.

Accessibility without sacrificing power

Most reporting can now be built from easy-to-use filter tables, without the learning curve associated with Cypher.

For advanced correlation, custom logic, and complex investigations, teams can still leverage custom queries. The result is balance: Accessibility for most users and flexibility for advanced practitioners – all via one unified platform.

Turning exposure intelligence into executive clarity

Surface Command was built to give organizations a unified view of their external attack surfaces across assets, identities, and exposures.

With filter-based dashboard widgets, that intelligence becomes easier to operationalize, easier to share, and easier to scale, especially for CTEM programs that rely on repeatability.

Because continuous threat exposure management shouldn’t depend on who knows how to write a query. It should be built into the way your platform works.

Wade Woolwine is Senior Director, Product Security at Rapid7.

The headlines around Glasswing have focused on how quickly AI can surface vulnerabilities, which has naturally caught the attention of security leaders. In my conversations with teams and customers, the more useful discussion has been about what that speed means in practice for business protection, especially across open source risk, dependency choices, and software supply chain resilience. The deeper issue for security leaders sits elsewhere. 

Software risk is becoming harder to manage across the full lifecycle, especially in open source dependencies, build pipelines, developer environments, and the operational processes that sit between disclosure and remediation. When vulnerabilities can be found faster and at greater depth, security teams need more than another source of findings. They need a stronger way to understand what they run, what they trust, what they can patch quickly, and where a single weak dependency can create disproportionate risk.

Faster discovery makes software supply chain resilience a more immediate leadership issue. CISOs need a clearer view of how dependencies are chosen, monitored, validated, and governed across production, build, and developer environments, especially as open source remains essential to modern software development.

Organizations already struggle to absorb vulnerability disclosures at the pace they are coming in, because when discovery gets faster, the operational gap widens between knowing there is a problem and being able to do something useful about it. That gap is especially serious in the software supply chain, where a single dependency can introduce risk into build systems, production workloads, developer endpoints, and the tools used to secure them.

This is why I would frame AI-driven vulnerability discovery risk as a lifecycle challenge. The pressure does not sit in one place, but across inventory, dependency decisions, threat intelligence, patching discipline, and validation – with people, process, and visibility shaping how well an organization can respond. Technology matters, but it cannot compensate for a weak operating model underneath it.

Open source still matters. Dependency choices matter more.

Open source remains essential to modern software development because it helps teams move faster and get products to market without rebuilding common functionality from scratch. The better response is to be more deliberate about where and how third-party code enters the environment. 

Open source has always involved a trade-off between speed, efficiency, flexibility, and inherited risk, and that trade-off becomes harder to manage as AI makes code review deeper and faster. More flaws and supply chain compromises will likely be found in packages that teams have trusted for years, including transitive dependencies most developers did not knowingly choose. One only needs to look back a few weeks to find that the widely used Axios package suffered a supply chain compromise that bundled a Remote Access Trojan (RAT) charged with stealing secrets. That raises the value of understanding which dependencies are essential, which ones can be removed, which ones pull in large chains of transitives, and which ones are maintained by too few people to inspire confidence.

That work starts with a more disciplined question than “Is there a package that does this?” It starts with “Do we need this dependency, and do we understand the risk that comes with it?” The safest dependency is often the one that never enters the environment in the first place.

Why inventory has to go deeper than package lists

Supply chain resilience begins with knowing what you are actually running, which sounds straightforward until a critical disclosure lands in a package no one realized was in the environment three layers deep. Dependency graphs are deeper than most teams think, and transitive risk is where a lot of operational pain begins. A package chosen directly by a developer may bring in dozens of additional packages, each with its own maintainers, release cadence, security posture, and potential failure points.

A mature approach to inventory needs to move beyond a static package list, because CISOs need confidence in three views at once: What is declared in source, what is resolved and built, and what is actually running in production? Those views often drift apart over time, which means a package can be patched in source and still remain unpatched in a deployed container or runtime environment. An SBOM on its own will not close that gap; continuous, usable inventory will.

That inventory also needs clear ownership attached to it, because the moment a critical dependency is identified, someone has to decide what happens next, coordinate the change, and absorb the operational consequences. Security teams cannot do that well if responsibility is unclear, which is why ownership needs to be treated as part of resilience rather than an administrative detail.

Build pipelines and developer environments deserve the same scrutiny as production

Supply chain conversations still tend to start with production systems, even though recent incidents have shown how quickly compromise can move through the build layer, developer tooling, or the security tooling inside the pipeline itself. Those environments hold code, secrets, and trust relationships that attackers know how to exploit, while developer workstations often carry a rich mix of credentials and elevated privileges because speed matters to the business. Build systems are predictable and privileged, which makes them both valuable and vulnerable, but also easier to monitor.

Seeing those layers as part of the same attack surface means asking harder questions about how code enters the build, how package updates are governed, how actions and dependencies are pinned, what secrets exist in CI/CD, and what controls are in place on developer endpoints to detect anomalous behavior or stop high-risk package activity before it goes unnoticed.

You can gauge the maturity of the operating model with the answers to a few basic questions:

• How tightly are dependencies controlled in CI?

• How are package lifecycle scripts governed?

• What secrets exist in CI/CD, and what protections surround them?

• What visibility exists into anomalous behavior on developer endpoints?

• How would the team detect or prevent high-risk package activity before it spreads?

If those answers are unclear, important parts of the model are still missing.

Why prioritization matters more as scanning accelerates

When software risk rises, the instinct is often to add another scanner because more visibility feels like progress. What matters more over time, though, is how well teams can prioritize the findings that follow, assign them to the right owner, choose the right mitigation, and prove that exposure actually went down. Broader scanning and faster discovery mostly add to the pile unless the operating model behind them is strong enough to turn findings into action. Feed more issues into a process that is already stretched and the backlog grows, priorities become harder to sort, and remediation slows in the places where speed matters most. The organizations that come through this period well will be the ones that treat supply chain resilience as a systems problem, with stronger intake, clearer governance, better intelligence, and faster paths from alert to action.

What stronger software supply chain resilience looks like in practice

A stronger response starts with a deeper inventory of dependencies across source, build, and runtime, so teams can see both direct and transitive packages and connect them back to real environments and real owners. Once that picture is in place, intelligence monitoring becomes far more useful when it runs continuously against credible signals on vulnerabilities, package risk, maintainer health, end-of-life software, and unusual changes in dependency behavior.

The same level of care needs to carry through into dependency governance, where better decisions depend on asking whether a new package is necessary, how much transitive risk it introduces, whether its maintenance model is healthy, and what policy governs its path into production. Build and developer controls belong in that same conversation, because version pinning, private registries, secret handling, script restrictions, immutable builds, ephemeral runners, and stronger endpoint monitoring all reduce the attack surface around the software supply chain.

Monitoring threat intelligence for notifications about new vulnerabilities and compromised packages and having a well defined and practiced process for scoping and remediating emerging threats becomes critical. Your supply chain vulnerability and compromise response should be practiced – just like your incident response plan – through table top exercises and simulated threat events. You don’t want to wait until the house is on fire to know how to execute an effective response.

Similarly, Engineering, DevOps, and Security teams should collaborate on establishing a trust and reputation scoring mechanism for supply chain dependencies. Being able to evaluate the speed of response, transparency of communication and updates, and ultimate resolution of the vulnerability or compromise speak volumes for how much you can trust the maintainers of the software you depend on. The OpenSSF Scorecard project offers a great place to start evaluating the open source packages you’re already using.

Organizations should also have a fallback plan for when obtaining a security patch is not available. Some options to consider include exploring other open source packages that perform similar functions, exploring other mitigations such as application firewalling, or even forking and contributing a security patch back to the community.

Validation closes the loop by showing whether the artifact came from where it was supposed to, whether the package has drifted in unexpected ways, and whether the mitigations applied are reducing live risk rather than simply documenting the process.

How CISOs should think about the next 12 months

The strain on security teams is only growing, and the potential for AI to relieve some of that pressure is understandably compelling, especially when boards, CEOs, and CFOs are asking how the organization plans to adopt it. That makes this a leadership question as much as a technology one. CISOs need a clear point of view on where AI can genuinely improve resilience, where it still introduces too much uncertainty, and how to explain those choices in business terms.

If software engineering teams are already adopting AI-assisted development, security teams should be part of that conversation early, especially around dependency management. I have seen teams begin connecting AI coding agents to vulnerability management workflows so those agents can interpret vulnerabilities found in the code base, assess reachability with more context, help plan remediation, and validate updates much faster than traditional handoffs usually allow. Used well, that can reduce drag across the workflow and help teams move faster on classes of issues that are currently slowing them down.

Getting there safely still depends on the foundation underneath it. A more resilient path starts with a clearer picture of the environment and a more complete inventory of dependencies across source, build, and runtime. From there, ownership needs to be explicit, threat and vulnerability intelligence needs to be embedded into how the organization prioritizes, and dependency sprawl needs to be reduced with more discipline around what actually enters production. The same mindset should carry through to the build layer and developer endpoints, where tighter controls and better visibility help reduce unnecessary exposure, while faster and more repeatable paths from disclosure to action make it easier for teams to respond before risk compounds.

That foundation will matter regardless of which AI model or platform becomes dominant six or twelve months from now. It will also matter if the next wave of AI makes backlog reduction, lower-tier remediation, or patch validation more practical. Organizations that know what they run and how they operate will be in a much better position to adopt those capabilities with intent.

The shift security leaders should make now

Security in an AI-accelerated world needs to be managed as a systems challenge, with supply chain resilience shaped by how well organizations connect software composition, exposure visibility, dependency governance, threat intelligence, build integrity, endpoint controls, remediation workflows, and validation. When those layers are treated separately, gaps open quickly; when they are tied together through a stronger operating model, teams are in a much better position to absorb faster discovery without losing control of the response.

For CISOs, that means continuing to use open source with a more deliberate view of dependency risk, reducing unnecessary packages where possible, knowing what is running and who owns it, and monitoring threat and vulnerability intelligence with enough discipline to act before the queue overwhelms the team. It also means paying closer attention to the attack surface across production, build, and developer environments, while treating AI as something that will amplify both the strengths and the weaknesses already present in the program. Faster discovery is here, and the organizations that handle it best will be the ones that can respond with the same level of discipline.

Cloud environments have changed how security teams detect and respond to threats. Signals come from more places, identities are harder to track, and attacks rarely stay within a single system. For many teams, the challenge is no longer visibility. It is having the risk context to understand what matters and act on it quickly. This shift is reflected in the conversations shaping this year’s Rapid7 Global Cybersecurity Summit.

Taking place May 12-13, the summit explores how detection and response are evolving across cloud, identity, and endpoint environments. The focus is practical: how attacks actually unfold, how teams respond under pressure, and how detection strategies need to adapt.

Detection is no longer just about coverage

One of the clearest themes across the agenda is that traditional detection models are struggling to keep pace with attackers. Environments are more dynamic, and attackers are more targeted. Catching everything is no longer realistic, and in many cases it is not useful.

Sessions like The New Rules of Detection Engineering will examine this shift in detail. The focus moves away from volume and toward precision. It will ask questions like: What makes a detection meaningful? How should teams prioritize signals? And how can detection strategies support real outcomes rather than just generate alerts? This is especially important in cloud environments, where context changes quickly and signals are often incomplete.

Understanding how attacks actually unfold

To improve detection, teams need to understand how attacks behave in practice. Several sessions across the summit focus on this directly.

The Reality of Running a SOC in 2026 will explore how modern attacks begin — from identity misuse to cloud misconfigurations— and how they evolve over time. Rather than following a predictable path, attacks move across systems, taking advantage of gaps in visibility and delayed decisions.

This theme continues in sessions like Inside the Modern SOC, where attendees follow a real investigation from first alert to outcome. These walkthroughs show how signals are correlated across environments and how decisions are made when time and clarity are limited.

From exposure to runtime risk

Cloud security also requires a closer connection between exposure and detection. In many cases, incidents begin long before an alert is triggered.

Sessions such as From Cloud Exposure to Runtime Attack explore how misconfigurations, permissions, and overlooked risks lead to active threats. The focus is on how teams connect exposure insights with runtime behavior to improve prioritization and respond earlier in the attack lifecycle.

This is a practical shift. Detection is no longer a separate function but part of a broader process that starts with understanding exposure and continues through to response.

What this means for security teams

Across these sessions, a consistent message emerges: Detection strategies need to be grounded in how environments actually behave, not how they are expected to behave.

This means focusing on signal quality rather than volume, connecting data across cloud, identity, and endpoint, and building workflows that support faster decisions. It also means accepting that not all alerts have equal weight, and that prioritization is a core part of modern detection.

A preview of what’s to come

Cloud detection is just one part of a broader shift happening across the summit. Sessions on MDR, AI, and exposure management all connect back to the same idea. Security operations must move earlier, reduce noise, and act with greater confidence.

If you are rethinking how your team detects and responds to threats in cloud and hybrid environments, this is where those conversations come together.

Join us May 12–13 and see how security teams are evolving their detection strategies for 2026.

Register now.

If you're a security leader operating in Germany, Austria, or Switzerland, you already know that compliance isn't a checkbox. It's a competitive differentiator. Rapid7 has completed BSI C5 Type 2 attestation for the Rapid7 Command Platform, including Threat Command, and it's a milestone worth unpacking.

This isn't just a badge on a webpage. It's proof that our security controls work, not just on paper, but in practice, over time.

What is BSI C5 and why does it matter?

The Cloud Computing Compliance Criteria Catalogue (C5) was developed by Germany's Federal Office for Information Security (BSI). It sets some of the most rigorous cloud security standards in the world, covering everything from data protection to operational transparency.

A Type 2 attestation is the gold standard within that framework. Unlike a point-in-time audit, Type 2 validates that security controls aren't just well-designed, but that they're actively working consistently over a sustained period. It's the difference between a security promise and a security proof.

For organizations in the DACH region, C5 is more than a nice-to-have. It's a procurement requirement for German federal agencies, critical infrastructure operators, healthcare institutions, and financial services firms. If you're operating in any of these sectors, your cloud providers need to meet this bar. Rapid7 now does.

BSI C5 Type 2 and your cloud security strategy

Whether you're evaluating security vendors, managing compliance obligations, or looking to strengthen your organization's risk posture, the question is the same: How do you know your cloud security provider actually does what it says?

BSI C5 Type 2 attestation answers that question. It's independent, rigorous, and sustained over time. While rooted in German regulatory requirements, C5 is increasingly recognized as a benchmark for secure cloud operations across Europe. It's one of the clearest signals that a cloud provider has the operational maturity to handle sensitive environments.

The Rapid7 Command Platform unifies exposure management with detection and response, giving security teams clear visibility across their attack surface. Threat Command extends that protection further, identifying and helping remediate threats across the clear, deep, and dark web. Both are now independently validated against one of the world's toughest cloud security frameworks.

Why independent validation of security controls matters

Trusting a security vendor shouldn't require a leap of faith. Independent validation exists so you have the evidence to make that call with confidence. This attestation reflects our continued investment in meeting the highest security standards for customers across Germany and the wider European market. Rapid7 has achieved a milestone that speaks directly to the conversations had every day with public sector and enterprise organizations who need more than a promise. 

They need proof that a security provider's controls have been tested, verified, and proven to hold up over time. That's the kind of assurance that matters when the stakes are high.

Ready to see the Command Platform in action? Visit Rapid7.com for a free trial.

Regardless of where you’re at in your application security maturity, dynamic application security testing (DAST) is a program staple in a few key ways:

1. It satisfies compliance requirements for runtime-related vulnerabilities. 

2. DAST catches vulnerabilities in the running web application, yielding findings that may be missed in static code testing.

3. It is security-driven with little overhead in configuration/maintenance from development or application teams.

Due to the nature of web apps powering mission-critical operations – hyperscaled of course by AI protocols that automate key processes within these apps – continuous DAST is essential to identifying and remediating potential weaknesses that could quickly lead to costly data breaches.

Compliance requirements

DAST helps satisfy multiple compliance requirements by simulating real-world attacks so it can test a running application for vulnerabilities.. While DAST alone doesn’t make you compliant, it supports key controls in many security standards and regulations. Get to know 7 of today’s top standards and frameworks, see which requirements they satisfy, and learn how DAST helps secure the following:

PCI DSS

Payment Card Industry Data Security Standard (PCI DSS) is the global security standard for any organization that stores, processes, or transmits payment-card data. DAST directly supports PCI compliance by performing vulnerability scans against live web apps.

Requirements satisfied: 

• Requirement 6.1 & 6.2: Identifying and addressing vulnerabilities.

• Requirement 6.6: All public-facing web applications must be either:

• Protected with application-layer firewall (WAF), or

• Tested for vulnerabilities (e.g., via DAST) at least annually.

OWASP Top Ten

While the Open Worldwide Application Security Project (OWASP) is not a compliance framework, the nonprofit organization is often referenced by industry and regulatory standards. 

Requirements satisfied:

• DAST tools are often tested against OWASP Top 10 vulnerabilities (e.g., XSS, SQLi, SSRF).

HIPAA

The Health Insurance Portability and Accountability Act (HIPAA) sets national standards for protecting electronic protected health information (ePHI). DAST supports risk assessment by identifying live vulnerabilities with the potential to expose such information.

Requirements satisfied: 

• Security Rule (45 CFR § 164.308 & § 164.312):

• Requires organizations to perform regular risk assessments.

• Includes application-level vulnerabilities as part of overall system security.

ISO/IEC 27001

ISO/International Electrotechnical Commission (ISO/IEC) is the international standard that specifies requirements for an information security management system (ISMS). DAST helps fulfill this requirement by scanning running applications for known and exploitable vulnerabilities.

Requirements satisfied: 

• Annex A.12.6.1: Management of technical vulnerabilities – Requires timely detection and remediation of vulnerabilities.

NIST SP 800-53/800-171

The National Institute of Standards and Technology (NIST) is a U.S. federal agency that develops measurement science, standards, and tech to boost innovation and economic security. DAST can be used to meet these technical controls.

Requirements satisfied: 

• RA-5 (vulnerability scanning): Requires scanning of systems and applications.

• SI-2 (faw remediation): Identify, report, and fix flaws in software.

SOC 2

System and Organization Controls 2 (SOC2) is an independent attestation report (from a licensed CPA firm) that evaluates whether a service organization’s controls are suitably designed. DAST contributes evidence for audit logs and control effectiveness over time.

Requirements satisfied: 

• Under the "Security" Trust Services Criteria, particularly:

• CC4.1: Monitor infrastructure for new threats.

• CC7.1/CC7.2: Detect and mitigate vulnerabilities.

GDPR

General Data Protection Regulation (GDPR) harmonizes privacy rules across the EU and sets requirements for how organizations collect, use, share, and protect personal data. DAST can be part of regular security testing under GDPR, especially if the app processes personal data.

Requirements satisfied: 

• Article 32 – Security of Processing:

• Organizations must ensure the ongoing confidentiality, integrity, availability of systems.

• Requires regular testing and evaluation of security measures.

Missed findings

Static application security testing (SAST) tools are effective at flagging insecure values on their own, but they often miss the broader application context needed to assess whether those values actually introduce risk. Here are some examples of findings that can be overlooked:

Forced browsing

Forced browsing (also called insecure direct object reference or unauthorized resource access) occurs when:

• A user can manually access restricted resources (files, endpoints, or actions) by guessing or modifying a URL.

• There are missing access controls or authorization checks.

Example: A user modifies a URL

https://example.com/admin/settings

Even though they’re not an admin, the app still serves the page because it lacks proper access controls.

SAST struggles to detect these findings due to:

• Lack of visibility into runtime access control

• SAST scans source code, but can’t simulate user roles or sessions.

• It doesn’t know who should or shouldn't be able to access a specific path.

• Abstracted access control logic

• Authorization might be handled via middleware, annotations, config files, or external services (e.g., OAuth).

• SAST often can’t follow the full enforcement logic, especially if it's custom or dynamic.

• Lack of awareness around routing and resource exposure

• SAST doesn’t map which endpoints exist versus which are intended to be public.

• It can’t verify which files/resources are accessible through URLs.

Out-of-band (OOB) cross-site scripting (XSS)

Out-of-band cross-site-scripting OOB XSS (a subtype of stored or blind XSS) occurs when:

• A malicious script is injected into an application (e.g., a form, comment, or field).

• The script doesn’t execute immediately but instead fires later, often:

• In a different user’s browser (e.g., an admin viewing logs).

• In an email client (e.g., via notification messages).

• In a third-party system or admin dashboard.

These attacks are asynchronous and context-shifted, meaning they don’t happen in the direct request-response flow. SAST struggles to detect these findings due to:

• Missing runtime context: SAST analyzes source code statically, line by line, without executing it. It doesn’t track:

• Where the injected payload ends up.

• How or where it's later rendered.

• Whether it’s rendered in a dangerous context (HTML, JS, email, etc.).

• Visibility is limited to code flow: SAST typically can’t follow data across storage layers or external systems. OOB XSS often spans:

• User-submitted input → stored in DB.

• Later retrieved → rendered in admin UI or email.

• Unable to observe execution: The XSS payload doesn't fire in the original request, so SAST has no way to "see" the exploit being triggered because it doesn't execute code.

Web config findings

Settings defined in the web config file can pose challenges for SAST tools. Depending on the tooling, these files may not be properly parsed, potentially causing the tool to miss important findings due to a lack of contextual understanding, such as:

Custom error handling depends on deployment mode

<customErrors mode="RemoteOnly" />

⠀
✔ Looks fine in static analysis; it shows friendly errors to remote users.

✖ Contextual issue: If the app is misconfigured to treat all users as local, then stack traces are exposed even with this setting.

SSL enforcement logic in code, not in config.

<rewrite>
<!-- Missing rule for HTTPS redirection -->
</rewrite>

⠀
✔ SAST flags the absence of HTTPS redirection in web.config, which is a valid finding.

✖  Contextual issue: If HTTPS redirection is handled in middleware or at a reverse proxy (like NGINX or Azure App Gateway), then this isn't actually a security risk. SAST can’t always know that.

Authentication mode

<authentication mode="None" />

⠀
✔ SAST will likely flag this as a critical issue.

✖  Contextual issue: If the app is a microservice behind an API gateway that handles auth, this may be acceptable. A SAST tool unaware of deployment architecture may raise false positives.

Debug enabled in a non-prod environment

<compilation debug="true" />

⠀
✔ Flagged by SAST, correctly so in most cases.

✖ Contextual issue: If this web.config is only used in a staging or development slot, it might be intentional and not a production risk.

Authorization settings ignored in custom pipelines

<authorization>
  <deny users="?" />
</authorization>

⠀

✔ This looks like it blocks anonymous access.

✖ Contextual issue: If a custom authentication mechanism bypasses ASP.NET authorization modules, this setting may be ineffective, but a SAST tool won't see that unless it's deeply integrated with the entire codebase.

Developer overhead

For organizations seeking to minimize developer burden, DAST is frequently the preferred option over SAST.  DAST processes evolve alongside your web applications, continuing to scan them so that your business can promptly identify and remediate emerging issues. Let’s finish by taking a look at a range of underlying dynamics that make DAST an easy decision for developers looking to fortify application security – table below.

⠀

Mark your calendars. The Rapid7 2026 Global Cybersecurity Summit returns May 12–13, bringing together security leaders, practitioners, and industry experts for two days of strategic leadership insight and hands-on operational guidance, designed to equip both decision-makers and defenders to build stronger, more resilient security programs.

This year’s theme is Preemptive Security Operations - a shift from reacting to threats to anticipating and neutralizing them before impact.

Security teams are navigating expanding attack surfaces, AI-accelerated threats, relentless alert fatigue, and increasing pressure to do more with less. The 2026 summit is designed to cut through that complexity and focus on what matters most, helping organizations move from reactive defense to confident, proactive operations.

What to expect from Rapid7's 2026 summit

Whether you’re shaping security strategy at the executive level or defending systems inside the SOC, the summit will deliver actionable insights you can apply immediately.

Day 1 will focus on the big picture. Designed to bring together security leaders, decision-makers, and practitioners around a shared narrative, the first day will explore the paradigm shift shaping modern security operations. Sessions will examine how MDR is evolving beyond monitoring into proactive defense, how exposure management and threat intelligence are converging with it into unified risk strategies, and how AI is changing both attacker capabilities and defender workflows. The emphasis will be on clarity, alignment, and strategic direction, helping organizations rethink how their SOCs operate in an increasingly complex environment.

Day 2 will go deeper. Structured with dedicated tracks for security leaders and frontline practitioners, the second day will provide focused, role-specific content. Leaders will engage with sessions centered on governance, resilience, and executive accountability, while practitioners will dive into real-world detection scenarios, threat hunting methodologies, red teaming insights, and operational playbooks. This two-track approach reflects the reality facing modern security teams: strategy and execution must move forward together.

Why attend Rapid7's global cybersecurity summit?

The Rapid7 Virtual Cybersecurity Summit is built for today’s reality where speed, clarity, and confidence matter more than ever. This year’s focus on Preemptive Security Operations reflects a shift from reacting to incidents toward anticipating and reducing risk before impact. Preemptive security means unifying visibility across the attack surface, aligning exposure with detection and response, and using AI and intelligence to prioritize what truly matters. It’s about giving security teams the insight and authority to act earlier, reduce uncertainty, and strengthen resilience across the organization.

If 2025 was about reacting faster, 2026 is about acting sooner, so save the date now and be part of the conversation shaping the future of preemptive security operations.

May 12–13, 2026
Rapid7 Virtual Cybersecurity Summit

Register here