Every SOC analyst knows this moment: an alert fires at 3 AM, triggered by some IOC from some feed you don’t quite remember subscribing to. You’re half-awake, staring at an IP address thinking — Is this real or is this another false positive waiting to waste my night?
We’ve built impressive pipelines for sharing threat intelligence — STIX, TAXII, MISP, OpenCTI, vendor CSVs (because of course someone still emails CSVs). But in all the rush to standardize formats, we forgot a more important question:
How do we know we can trust what we’re sharing?
The Silent Failure of Threat Feeds
Here’s what happens in most organizations:
- Feeds arrive in mixed formats — STIX 1.0, STIX 2.x, custom JSON, raw CSVs, XML.
- They get normalized for ingestion — good.
- But during that conversion, vital context is lost.
Later, when an indicator triggers action, nobody can answer:
- Who first reported this?
- Has it been modified since ingestion?
- Is this source historically reliable or just noisy?
- Has anyone else independently confirmed it?
- Has this intel already expired?
Security teams end up reacting blindly. Over-alerting wastes time. Under-alerting causes breaches. Both are expensive.
Our Approach: Intelligence With Memory and Accountability
Instead of building yet another parser, we’re building a provenance-aware, trust-scored intelligence pipeline that treats every IOC like evidence — with a full receipt of how it got there.
(See architecture diagram below.)
1. Normalization Without Losing Origin
Every incoming feed gets converted to STIX 2.1 — but we don’t discard the past. We preserve and attach:
- Original format & provider identity
- Schema validation results
- Mapping decisions made during transformation
- Historical failure/success rate of that feed
No IOC is just “added”. It’s documented.
2. Trust Isn’t Yes/No — It’s a Score
Instead of “allow/block”, we score each indicator using machine learning (XGBoost):
| Factor | Why it matters |
|---|---|
| Source Reputation | Has this feed been reliable before? |
| Corroboration Count | Has anyone else reported the same thing? |
| Sighting Frequency | Is this active or long forgotten? |
| Timeliness Decay | Old intel should expire, not linger |
| Pattern Anomalies | Fake indicators often look weird |
High-trust → auto-action.
Medium-trust → analyst review.
Low-trust → suppressed unless further confirmed.
3. Tamper-Evidence Without Hype
Yes, we use blockchain — but only for what it’s actually good at: proving that something *hasn’t been silently modified*.
- Each IOC’s provenance metadata gets hashed and recorded in a permissioned ledger
- No public exposure of sensitive intel
- No tokens, no coins — just non-repudiation and traceability
Not decentralization for the sake of it. Distributed attestation for accountability.
Why This Matters
One security team we interviewed estimated over 42% of automated alerts were later dismissed as false positives — yet still triggered escalations, meetings, and response procedures.
Multiply that across teams, hours, and tools — and the cost of bad intelligence becomes greater than no intelligence.
What’s Next
We’re actively building this pipeline and sharing the journey step by step.
Coming up:
- A live trust score visualizer for IOCs
- Metadata-preserving feed normalizer showcase
- Real-world trust decay curves across sample feeds
- Private ledger-backed audit trail demo
Your Turn
If you work with threat feeds, answer two questions in the comments:
- What metadata do you wish you never lost during ingestion?
- What trust score (0–100) would you automatically block on?
Because threat intelligence shouldn’t just be data.
It should be defensible.
Follow Along
We're building this in the open. The architecture, research notes, and
design decisions are all on GitHub:
github.com/greykaizen/ThreatChain
If you work with threat intel pipelines, have ideas about trust scoring
signals, or can contribute anonymized feed telemetry — open an issue.
We need practical input from people actually dealing with this problem.
Code releases are coming within the year. Watch the repo if you want
to see how the trust scorer and provenance ledger actually get built.
Top comments (0)