Building a security overview dashboard for actionable insights

Turning security data into a triage list

Security teams no longer struggle to find data; they struggle to find the signal in it. Context is what separates noise from insight, and without it, a dashboard full of events is just another obstacle between an analyst and an answer to the question: “What now?” Jumping between tools to trace a single misconfiguration burns the time you need to prevent an incident.

That’s the gap the new Security Overview dashboard is built to close: a single view that shifts the focus from observing everything to acting on what matters.

Prioritized fixes without the hunt

The core change is the introduction of Security Action Items. Instead of scanning raw logs for problems, analysts get a list of surfaced vulnerabilities ranked by urgency:

• Critical: risks that demand immediate action to prevent exploitation.
• Moderate: issues that need attention to sustain a solid security posture.
• Low: best-practice recommendations and hardening opportunities.

You can also filter the list by Insight Type, e.g. Suspicious Activity or Insecure Configuration, to focus on the threat category most relevant to your environment.

Closing the configuration gap

A common root cause of breaches isn’t a missing security tool — it’s a tool that was never enabled or was set up incorrectly. The Detection Tools module exposes that blind spot directly on the Overview. Rather than clicking through nested settings pages, you can assess the operational status of your entire Cloudflare security stack at a glance:

• Are primary shields active, or are you running in Log Only mode during a period of heightened risk?
• Are shadow APIs being discovered, or are you unaware of their existence?

Viewing these controls next to your action items reframes the responsibility, turning the question from “Do we own this tool?” into “Is this tool defending us right now?”

Deep links that remove the switching tax

A dashboard summary is only useful if it helps you resolve the issues it highlights. Suspicious Activity cards now live in two linked locations: the Security Overview and the Security Analytics page. When a card on the Overview draws your attention, the link takes you straight into Security Analytics with the relevant filters pre-applied. There’s no need to rebuild the query you were just looking at.

That direct path erases the friction of moving between views and keeps the focus on the response, not on navigation.

Turning raw signals into security insights at scale

Modern security monitoring has to operate on two tracks at once: breadth and depth. Our engine validates everything from SSL certificate hygiene to AI bot configurations, producing and refreshing over 10 million actionable insights daily. Achieving that scale requires sweeping coverage across a customer's entire stack — and a system design capable of keeping that coverage current without drowning in data.

The solution is a distributed architecture of specialized micro services called checkers. Each checker acts as a subject-matter expert for one slice of the stack, such as DNS records. These checkers scale independently and hook into the system in two complementary ways.

Scheduled configuration checks

For risks that demand deep inspection, an orchestrator schedules periodic tasks. The orchestrator pushes work to checkers, which execute in a massively parallel fashion. A typical task for the DNS checker might be: "Scan all the DNS configurations of zone xyz.com and find anomalies."

Each checker independently picks up tasks and applies its specialized logic to the relevant assets — for DNS, that means examining A/AAAA/CNAME records along with DMARC and SPF settings. The lifecycle follows a well-defined loop:

1. The checker activates when a message is received.
2. The checker collects relevant assets (e.g., DNS records) for the zone or account.
3. The checker runs checks against each asset's status, such as whether a CNAME record resolves to a live server.
4. If state or configuration violates a threshold, an insight is flagged.
5. If the condition persists on the next check, the insight's timestamp is updated.
6. If the issue is remediated, the insight is removed from the database.

Real-time event handlers

While scheduled checks run around the clock, event handlers react instantly to changes in our control plane. They listen for specific signals and process them the moment they occur.

The real-time ruleset insight lifecycle demonstrates the speed of this approach:

1. A WAF rule configuration is modified.
2. An event with the change details fires immediately.
3. The ruleset handler, actively listening, kicks into action.
4. The handler detects an anomaly, e.g., the Cloudflare Managed Ruleset is enabled but left in "Log Only" mode.
5. The handler deduces that attacks are being logged but not blocked.
6. An insight is registered and appears on the dashboard.
7. When the configuration is corrected, the handler clears the insight immediately.

This lets us flag misconfigurations or confirm fixes in real time, without waiting for the next scheduled sweep.

Contextual insights: from notification to action

Customers consistently ask for context alongside visibility. Knowing a record is misconfigured is only half the answer; defenders also need the "so what" to act confidently. We're expanding our detection engine with Contextual Insights that surface the business impact and technical root cause — for example, traffic volume to a broken A record — making every insight actionable.

We're starting with deeper DNS insights. Instead of merely flagging a broken record, we enrich the dangling signal with real-time context:

• Target Context: which deleted resource (e.g., an old S3 bucket or cloud instance) the record points to.
• Impact Context: how many users are still trying to reach that broken record.

The scale of this effort is significant:

Over 100 million DNS records are scanned weekly. In a recent week, the engine identified more than 1 million dangling DNS records — 97% being A/AAAA records and 3% being CNAME records. Of the roughly 31,000 dangling CNAME records, 95% point to Microsoft Azure and 3% to AWS Elastic Beanstalk.

These represent prime targets for subdomain takeover. An attacker can claim abandoned cloud resources, seize control of the subdomain, and use it for phishing or brand abuse. Such vulnerabilities demand immediate remediation — every insight is generated via a two-phase process.

Phase 1: Active verification

A DNS record can appear valid on paper while pointing to a decommissioned server. Our engine probes destinations in real time from outside our network to confirm whether a risk is genuine.

Dead server check (A/AAAA records): For records pointing at IP addresses, we attempt HTTP and HTTPS connections through a dedicated egress proxy. This simulates a real user connecting from outside Cloudflare's network. If the connection times out or returns a "404 Not Found" error, we confirm the destination is dead, proving the record is dangling.

Takeover check (CNAME records): CNAMEs often delegate traffic to third-party services. If that service is canceled but the record remains, attackers can claim it. We perform a three-step process:

1. Trace the chain: recursively resolve the CNAME to its final destination (e.g., my-bucket.s3.amazonaws.com).
2. Identify the provider: determine if the destination belongs to a known cloud service like AWS, Azure, or Shopify.
3. Confirm vacancy: probe the destination URL and match against provider-specific error patterns (e.g., S3's "NoSuchBucket") to confirm the resource is claimable.

If the resource has been released but the DNS record remains, we generate an insight prompting record removal before an attacker takes over the subdomain.

Phase 2: Context enrichment

Once a record is verified broken, we attach the context that guides smart remediation. For dangling insights, this covers three dimensions:

• Traffic Volume (Impact): We query our global ClickHouse clusters to sum total DNS queries for the record over the past seven days. This reveals whether the record is actively used — essential for prioritization. A record with zero queries can wait; one with 10,000 queries is an active vulnerability requiring immediate action.

SELECT query_name,
       sum(_sample_interval) as total
  FROM <dnslogs_table_name>
 WHERE account_id = {{account_id}}
   AND zone_id = {{zone_id}}
   AND timestamp >= subtractDays(today(), 7)
   AND timestamp < today()
   AND query_name in ('{{record1}}', '{{record2}}', ...)
 GROUP BY query_name

The query asks: "How many times has this broken record been requested by real users in the last seven days?"

• Infrastructure Owner (Target): Knowing who owns the destination infrastructure is vital for both remediation and severity assessment. For IP records (A/AAAA), we identify the ASN via geolocation data stored in a Cloudflare R2 bucket, performing in-memory lookups to pinpoint the dead resource's host, e.g., "Google Cloud" or "DigitalOcean." For CNAME records, we identify the specific Hosting Provider (AWS S3, Shopify, etc.). This drives risk level: providers known for easy takeovers, like S3, are marked Critical, while others are Moderate.
• DNS TTL: We extract the TTL value directly from the record configuration. This reveals the "lag time" of any fix. Deleting a dangling record with a high TTL (e.g., 24 hours) means it stays cached in resolvers worldwide for a full day, keeping the vulnerability open even after a patch — important context during incident response.

What's next

This experience launches at the domain level today. Enterprise customers, however, manage security across multiple domains simultaneously, so we're prioritizing an account-level view next. Security teams will get a centralized aggregator of action items, ranked by criticality, spanning all of their Cloudflare domains.

Our checker architecture and real-time event handlers aim to shift the balance back toward defenders. By detecting risks and enriching them with context, the Security Overview provides a starting point where risk data becomes strategy — ready for review each morning in the Cloudflare dashboard.