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.
Figure 1: Creating dashboard “widgets” in the Rapid7 Command Platform
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:
Scope – Define what you’re focusing on (systems, business services, exposure themes, time horizons).
Discover – Identify the assets, identities, and exposures within scope.
Prioritize – Determine what matters most based on risk and impact.
Validate – Confirm exploitability and real-world likelihood.
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”
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.
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.
It satisfies compliance requirements for runtime-related vulnerabilities.
DAST catches vulnerabilities in the running web application, yielding findings that may be missed in static code testing.
It is security-drivenwith 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) isthe 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) isan 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 EUand 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
✖ 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
Login
