Middleware is the layer everyone forgets

Ask a team for their architecture diagram and you'll get boxes for services and arrows for traffic. The arrows are the interesting part. Every one of them passes through an API gateway, a message broker, or a service mesh — and in most threat models, those systems appear nowhere.

That gap is why we built Vectasec.

The layer that routes everything#

Middleware is infrastructure's connective tissue. The gateway terminates TLS and decides who gets in. The broker holds every event your business emits, sometimes for weeks. The mesh decides which service may call which. Compromise any of these and you don't own one service — you own the conversation between all of them.

Yet the tooling attention goes elsewhere. Cloud posture tools stop at the AWS API. Code scanners stop at the repo. Runtime agents watch processes, not routing tables. The middleware config — thousands of lines of YAML that constitute your actual security policy — is rarely audited at all.

Enlarge

What to check first#

These are misconfigurations Vectasec checks for, and none of them is exotic:

• The plaintext listener. A broker listener mapped to plaintext, one VPC peering away from being readable by anything on the path.
• Nobody checks who is calling. A broker running with no authorizer, so every client that can connect can do everything.
• The wildcard ACL. A broker rule written during an incident three years ago, granting * on a topic prefix that now includes payments events.
• The default account that still works. A RabbitMQ guest user, or a default login, that nobody turned off.

Two failures worth knowing about are ones Vectasec does not detect today. A dead-letter queue holding sensitive messages is invisible to it, because it never reads message contents. A staging policy looser than production is too, because no check compares one environment with another. Review those by hand.

They are all configuration, which means they are checkable — if anything bothers to check.

Auditing the seam without becoming one#

A middleware security tool sits in a sensitive spot, so Vectasec keeps its access narrow: read-only calls against gateway, broker and mesh admin APIs, and every finding backed by the stored observation that produced it. Its engine and console run on a hosted control plane today. For systems that only answer from inside your network, a Collector runs the same checks there, keeps the credentials local and sends findings out. Self-hosting is in preview.

It also refuses to treat silence as a pass. When a check cannot read the setting it needs, the result is a not-assessable finding that names what could not be read, never a clean report.

The arrows on the diagram deserve the same scrutiny as the boxes. That's the whole thesis.

To see what Vectasec reads on each system, start with the connector reference. The quick start scans deliberately misconfigured Kafka, RabbitMQ and Redis dev targets locally, so you can check the findings against a setup you control.