Slussen — coming soon

snabridge began as a bridge with one bank on each side: a single threat-intel feed in, Cisco Secure Network Analytics out. It did that one job well. But the shape of the problem was always bigger than the bridge.

Defenders don’t have one feed and one tool. They have ThreatFox and OpenCTI and MISP and a commercial subscription or two — and more than one place that intel needs to land. The honest version of this tool isn’t a bridge at all. It’s a lock: a place where many flows are gathered, levelled, and let through to wherever they need to go.

Why Slussen

Slussen is the canal lock in the heart of Stockholm — the point where boats moving between the Baltic and Lake Mälaren are raised, lowered, and let through in a controlled, deliberate way. The water doesn’t just rush across; it’s reconciled between two levels, one chamber at a time.

That is exactly what this tool does with threat intelligence. Many sources flow in at different levels — different formats, different lifespans, different confidence. Slussen normalizes them, reconciles them against the desired state of each destination, and lets them through — retiring whatever has gone stale on the way. Flow control, for intel.

What’s changing

• Many sources in. Any STIX/TAXII 2.1 feed, normalized into one canonical model before anything downstream sees it.
• Many destinations out. Cisco SNA is the first; the routing core treats it as one destination among several, not the only one.
• Reconciled, not appended. The feed is the desired state. Slussen makes each destination match it — adding what’s new and retiring what’s aged out.
• Vendor-neutral by design. The core knows nothing about any one vendor; destinations plug in around it.

The router architecture is already live in production, routing real feeds. The full write-up — how the bridge became a lock, and what it took — is coming next.