Cloudflare Security Insights is a continuous website and infrastructure scanning system that checks customer security posture at internet scale. In 2026, Cloudflare said it processes more than 120 scans per second after a 10x capacity increase. The key lessons are simple: reduce query cost, tune workers, and design scanning as a pipeline.
Security scanning is no longer a once-a-quarter compliance task. Websites, DNS records, TLS certificates, exposed ports, and security headers change constantly. Cloudflare’s June 2026 engineering post says Security Insights now handles more than 120 scans per second and achieved a 10x global capacity increase without simply adding hardware.
That matters for WordPress owners, SaaS teams, and DevOps engineers because most breaches begin with a small exposed surface: an old admin panel, missing security header, expired certificate, or forgotten origin server. A scalable scanner turns those small mistakes into visible tasks before attackers find them.
A security scanning pipeline is an automated workflow that discovers assets, runs checks, stores findings, prioritizes risk, and notifies owners. At small scale it can be a cron job. At Cloudflare scale it involves queues, workers, databases, APIs, and careful backpressure.
The common architecture is: asset inventory enters a queue, workers perform network or configuration checks, results are normalized, the database stores current and historical findings, and an API presents prioritized issues. Kafka, PostgreSQL, object storage, and worker autoscaling are common building blocks.
# Minimal header check for your own domain
curl -sI https://example.com | egrep -i 'strict-transport-security|content-security-policy|x-frame-options|referrer-policy'
The first bottlenecks are usually duplicate work, slow database queries, and workers that retry too aggressively. Cloudflare’s post specifically highlights optimization around Kafka consumers, PostgreSQL queries, and APIs. That is a useful reminder: scanning performance is often limited by coordination and storage, not raw network speed.
For smaller teams, the biggest win is deduplication. If 10 checks ask for the same homepage headers, fetch the page once and fan out parsing. If 5 assets resolve to the same origin, avoid scanning the origin repeatedly in a short window.
WordPress sites should scan for exposure, configuration drift, and performance-affecting security settings after every deployment. Important checks include admin path protection, XML-RPC access, plugin version disclosure, TLS redirects, HSTS, cache headers, and origin IP leakage when using a CDN.
Security scanning should be paired with human triage. A missing header may be low risk on one site and critical on another. For example, a strict Content-Security-Policy can break inline scripts if deployed blindly, so test in report-only mode first.
Yes. Small sites change through plugins, DNS edits, hosting migrations, and CDN rules. Lightweight weekly or daily checks can catch mistakes early.
No. Kafka helps at large scale, but smaller teams can start with Redis, SQS, PostgreSQL jobs, or GitHub Actions schedules.
Scan owned domains for TLS status, security headers, exposed admin panels, open ports, sitemap/robots issues, and unexpected origin exposure.
Yes. Aggressive scans can overload systems or violate third-party policies. Limit scope to assets you own and use safe checks by default.
Run high-signal checks daily and after deployment. Deeper port or application scans can run weekly or monthly depending on risk.
Related reading: Cloudflare Private Origins, Docker VEX vulnerability scanning, Core Web Vitals 2026 guide.