01 Simple

One binary. Zero dependencies. Run it and go.

ICDB ships as a single executable. Download it, run it, and you have a working threat intelligence graph backed by an embedded database. No external services, no configuration files, no setup wizard.

When you outgrow the single binary, when you need dedicated PostgreSQL, a production frontend, horizontal scaling, everything is there. But you choose when to add that complexity, not the tool.

03 Automation First

Machines build the graph. Humans do attribution.

The vast majority of connections in an ICDB graph are created automatically. Indicators flow in from built-in OSINT feeds and your security stack. Detection results pushed in from your existing tools create edges. Consortium partners share indicators that land in your graph pre-linked.

The work that actually requires a human such as attribution, judgment calls, connecting the dots between campaigns is where your analysts spend their time. Not copying and pasting indicators between spreadsheets.

Inside a consortium, BOLOs (“be on the lookout”) match every incoming indicator against patterns your team registered. When a partner shares data that fits one of your standing patterns, you know immediately.

05 End-to-End Encrypted Sharing

Closed groups that share threat intelligence. Nothing leaks in transit.

By default a consortium is private: invite-only. An owner creates the consortium, emails invite tokens, and approves each new member, so there is no accidental exposure. When you want reach instead of secrecy, an owner can list a consortium in the public directory, with joins either owner-approved or open. The default is closed; opening up is a deliberate choice.

When you share data through a consortium, it is end-to-end encrypted with X25519 ECDH + AES-256-GCM before it leaves your instance. The relay broker that moves ciphertext between members cannot read it. Each organization holds its own encryption keys, so even the platform operator sees only opaque bytes.

Post and share BOLOs to alert your consortium when you see a critical indicator. Members that also observe it in their own network can reply with additional context.

07 Tamper-Evident Consortium Ledger

A per-consortium audit trail.

Every member holds a private, append-only immudb database for each consortium they belong to. Signed share events are appended on both sides: the sender’s outgoing tape and the recipient’s incoming tape. immudb’s Merkle structure makes the tape tamper-evident: any after-the-fact edit invalidates the proof for every subsequent entry.

ICDB’s broker is a blind encrypted relay. Members hold their own ledgers; the broker only routes ciphertext between them.

Because proofs are scoped per-consortium (one immudb database per group you belong to), you can produce an audit-grade export for a single consortium’s regulator, auditor, or peer-in-dispute without leaking the existence of any other consortium you participate in.

The result is permissioned multi-party data exchange without consensus: the resilience and audit guarantees of a blockchain without tokens, without miners, without a central orderer.