Scaling Security Insights: how we achieved a 10x increase in global scanning capacity

Security Insights provides actionable security recommendations for every Cloudflare account. To find these insights, we perform regular scans for all accounts, zones, and DNS records, looking for potential security risks and misconfigurations.

However, two key issues emerged. First, our scans were too infrequent. Scans were only being performed every week or two, and therefore newly introduced security risks could remain undetected for up to two weeks. Second, automatic scanning was opt-in for many free plan accounts – meaning lots of accounts weren’t being scanned at all.

The risks of infrequent or nonexistent scans are rising: as automated attacks accelerate, the window for detecting security misconfigurations is shrinking. Making sure that we’re finding these issues for all of our customers is crucial to our aim of building a better Internet for everyone.

We calculated that to increase our scanning frequencies and enable automatic scanning for all accounts, we would need to increase our scanning throughput by around 10x on average – from 10 scans per second to 100 per second. But our system was already struggling with its load: millions of events were filling up our backlog waiting to be processed; our API was frequently timing out; our processes were crashing. Continue reading

AI in Networking with Andrew Yourtchenko

I always wanted to find someone who is more positive about AI than I am, while having solid “can deliver working stuff at scale” credentials. Andrew Yourtchenko definitely fits the bill. I first met him (online) when he was still an engineer in Cisco TAC, and when we finally met in person, he was busy automating the deployment of Cisco Live networking infrastructure. He was also instrumental in bringing us closer to ubiquitous IPv6 deployment with Happy Eyeballs.

Read more …

Data Synchronisation

These days the Internet operates with vast infrastructure of replicated data, and the only differentiator between order and chaos is the ability to impose consistency upon the data through synchronisation across the distributed publication points of the same data. What tools can we use to synchronize data across multiple instances? There are many ways of performing this function, and here I'd like to look at a number of approaches, their strengths and weaknesses and their applicability.

Cisco Live 2026 – Requiem For A Corner

Cisco Live US 2026 was an interesting ride this year. There was a lot of talk about AI. There was a big discussion about security and how we are protecting our software from the AI models on the horizon that are ready to uncover every bug ever conceived. And there was even more discussion about whether Cisco was ahead of the game or behind the curve on their support for everything from eBPF to the latest Mythos reports. I say there was a lot of discussion, but I’m not sure where exactly it was happening.

Social Desert

One of the biggest things I heard from my friends at the event was how light everything felt. Fewer people was a common theme. The reported number was around 22,000 but it felt closer to 20,000 to me. The World of Solutions felt very spread out this year, with most of the back side being Cisco booth space.

The other thing was the Social Hub. It had shrunk from last year. At least the couches were facing each other this year. And there were some cool stickers and some interesting puzzles to work on. But there were far too few tables for people Continue reading

Installing Dnsmasq in My Homelab

Dnsmasq is an application which has features like DNS caching, DHCP server, and so on. It’s useful as a DNS server in a homelab as it can reply to DNS queries for what’s in its database, and forward everything else to an authoritative server or recursive resolver. This is useful in my lab as I want to resolve for example gitlab.lostintransit.se locally, but lostintransit.se (my web server) or any other domains via recursive resolvers. Most DNS servers are authoritative for a zone or parts of a zone, but dnsmasq responds only to what it knows and forwards everything else, which is perfect for my needs.

First I’ll configure a static IP on the host by modifying the file in /etc/netplan:

sudo vi 50-cloud-init.yaml

The contents are now:

sudo cat 50-cloud-init.yaml 
network:
  version: 2
  ethernets:
    ens160:
      dhcp4: no
      addresses:
        - 192.168.128.53/24
      routes:
        - to: default
          via: 192.168.128.1
      nameservers:
        addresses:
          - 8.8.8.8
          - 8.8.4.4

I’m using recursive resolvers for now but will update it later.

Then apply the configuration:

sudo netplan apply

The IP has been updated:

ip addr show ens160
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP>  Continue reading

Worth Reading 061026


When business volume and market capitalization cross a critical threshold, vertically integrating infrastructure ceases to be merely a cost-cutting financial tactic; it becomes an existential imperative for computational resilience and commercial survival.

 


It looks like industry mergers and acquisition activity is in high gear lately.

 


Building multi-agent systems right now feels painfully identical to the early, chaotic days of the micro services gold rush.

 


The standard is called DNS-AID (Domain Name System for AI Discovery). Its premise is that the internet already solved the problem of finding things at scale forty years ago with DNS — and that the same infrastructure should handle AI agents.

 


Mythos is real. I know a big chunk of the industry thinks it’s a marketing stunt, and I get why. I get it. But I’ve seen the findings, and they’re bad.

Five Principles of an Accountable AI Agent Network: How to Evaluate Any Governance Platform

The first post in this series argued that AI agent governance hasn’t kept pace with deployment. The second laid out the five pillars of accountability, and what is required. The third walked through why network policies, API gateways, MCP/A2A protocols, DIY security patterns, and Role-based Access Control (RBAC) each leave critical accountability gaps.

So what does good look like?

The five pillars define what AI agent accountability requires. The principles below define how a governance platform should deliver it. These are the architectural principles your team should evaluate any AI agent governance solution against, whether you build it, buy it, or assemble it from open-source components.

If a vendor pitches you a governance platform that fails any of these five, walk away.

What are the five principles of an accountable AI agent network?

Kubernetes Network Policies are essential for securing any cluster. They restrict which pods can communicate with which other pods at the network level, and they should absolutely be part of your security posture.

  1. Default-deny: No agent communicates unless a policy explicitly permits it.
  2. Attribute-based policy: Policies reference agent attributes, not agent names.
  3. Zero-trust identity: Every request authenticated, every identity verified.
  4. Audit by design: Every interaction produces a Continue reading

Kubernetes Operational Maturity: Why You Should Modernize Your Ingress with Gateway API

SIG Network introduced Ingress in 2015 as a minimal way to expose HTTP services from a cluster. That simplicity was an advantage at a time when most workloads were HTTP, clusters were single-tenant, and the occasional gap could be papered over with a vendor annotation. As adoption grew and Kubernetes started running serious production workloads across multi-tenant, multi-cluster, multi-protocol environments, the annotations multiplied into incompatible dialects, and most organizations outgrew what Ingress could handle on its own.

The Ingress-NGINX Controller retirement, and the migration conversations that followed, exposed these cracks, but they were never the full story. Ultimately, ingress needed to grow up and the arrival of Gateway API, with SIG Network freezing the Ingress at v1 in favor of this successor, was what that looked like.

Even if migration has not been forced on your organization by the Ingress NGINX retirement, any team trying to reach Kubernetes operational maturity should be considering Gateway API as the next step on that journey.

Three reasons why Gateway API is more than and Ingress replacement

Gateway API is not just a new and improved Ingress with a few additional features bolted on. It re-architects incoming traffic management in three key ways that Continue reading

A field guide to the agents in your cluster

You know every service in your cluster by name. You know which team owns each one, what it talks to, how it scales, where its logs go. The agents are a different story.

That’s not a criticism, it’s an observation, and it’s one we keep running into. Every company we talk to is shipping agents of some kind, from scales of 10s to 1000s. Customer service bots that field tier-one tickets. Internal copilots that draft emails and summarise meetings and write the boring half of every PR. SREs that handle their own incidents at 2am while the team sleeps. What used to be a few experimental builds in a dev cluster is now dozens in some shops and hundreds in the biggest, growing faster than most teams are tracking.

That growth curve is the interesting part. Services tend to come into existence through a fairly heavyweight process. There’s a ticket, a design review, an owner, a runbook. Agents tend to arrive the way side projects do:

  • Somebody had an idea on a Tuesday.
  • By Friday it was in staging.
  • At some point nobody can quite remember when it became part of the actual business.

Who said it could do that?

Continue reading

Route public traffic to private applications with Cloudflare

For most of the Internet’s history, public and private infrastructure operated as separate worlds. Public applications lived behind content delivery networks (CDNs) and web application firewalls (WAFs). Private applications lived behind virtual private networks (VPNs), firewalls, and separate operational stacks. We think that distinction is becoming obsolete.

Many of the applications organizations care about are not public websites. They are internal APIs, AI agent backends, MCP servers, operational tools, and services that were never designed to be exposed to the public Internet. Yet these applications still need modern security, performance, and programmability services. Security should be a property of the traffic reaching an application, not an accident of where the application happens to sit.

Until now, applying those services to private applications often required public IPs, firewall exceptions, connector software, or complex networking. As a result, many private applications missed out on capabilities such as WAF, bot management, rate limiting, caching, traffic acceleration, rewrites, and Workers, despite needing the same protections and controls as public-facing applications.

Today, we're launching Application Services for Private Origins in closed beta for eligible Enterprise customers. Customers can now securely route traffic to private origins without exposing those origins to the public Internet. This allows Continue reading

1 … 8 9 10 11 12 … 3,888