Hey everyone, I've been diving deep into Recorded Future's workbench for the last few weeks, primarily looking at their intelligence on emerging threats and vulnerabilities. I'm coming at this from a perspective of someone who loves tooling and wants to understand the underlying data structure—almost like evaluating a language server's diagnostics.
One pattern I keep hitting, and it's starting to nag at my productivity-focused brain, is the content of the 'Evidence' section for a lot of these alerts. So often, it feels like the primary—or sometimes *only*—piece of evidence provided is just a link to a tweet. Now, I get that Twitter (or X) is a primary source for a lot of initial disclosure and chatter, but when I'm triaging something in my workflow, I expect a bit more synthesis.
For example, I was looking at a recent entry for a potential software supply chain issue. The Recorded Future entry had all the right metadata: CVSS score, affected entities, timeline. But the Evidence section was literally:
```
Evidence:
- Source: https://twitter.com/ [researcher]/status/123456789
```
My immediate questions are:
* **Is this just a data model/plugin limitation?** Like, is their ingestion engine configured to just pull in the primary source URL as the "evidence" field without further processing? In my IDE world, a linter doesn't just give me a line number; it gives me a rule violation context.
* **Where's the corroboration or extracted insight?** A tweet is a starting point. I'd expect their analysts or automation to at least pull the key claim, screenshot, or code snippet *from* that tweet and present it in the workbench. Otherwise, I'm just doing the click-through and manual parsing myself, which defeats some of the efficiency purpose.
* **What happens when the tweet gets deleted?** The entire "evidence" for that record then points to a 404. That seems like a fragile data layer.
It makes me wonder about their backend pipeline. Is it a case of:
1. Automated collection flags a tweet via keyword/actor monitoring.
2. A low-fidelity alert is auto-generated with that source as a placeholder.
3. The ticket waits for a human analyst to enrich it... but maybe that enrichment step is often backlogged or skipped?
From a tooling perspective, if I were designing a plugin to visualize this, I'd want the Evidence section to be a structured data block, not just an outbound link. Something that caches the relevant text, tags the author, and notes if it's a claim, a proof-of-concept, or an announcement.
Has anyone else run into this? Have you found a way to filter or work around it in your review process? I'm curious if this is just the nature of fast-moving intel, or if it's a specific gap in their offering that could be improved with a different workflow configuration.
editor is my home
Your specific point about data model limitation is likely on the mark. I've seen similar issues across other intelligence platforms. The ingestion pipelines are often built to prioritize speed and volume, scraping social media and forum posts via API. The "Evidence" field is frequently just a raw dump of the first or highest-confidence source link, with minimal post-processing.
The real TCO issue surfaces when you need this analyzed for an audit or internal report. A tweet is not a verifiable source. It lacks the provenance a proper intelligence report should have. This pushes the synthesis work you mentioned directly onto the analyst, negating a key value proposition of the paid service. It's a gap between data collection and intelligence production that vendors need to address in their architecture.
—LJ
That's a good point about the TCO. I'd never thought about it increasing audit workload. It makes sense that platforms built for speed would cut corners here.
But is the alternative slowing down alerts too much? If they take the time to synthesize, do we risk missing a critical, time-sensitive threat that's only on Twitter?
You're absolutely right about the TCO hit from pushing synthesis work onto the analyst. I see this same pattern in my product analytics tools all the time, where an 'evidence' flag might just link to a single support ticket comment without any user session context 😩.
The core issue you flagged - the gap between data collection and intelligence production - is a product maturity problem. Early on, showing *any* source feels like value. But for a paid service, the synthesis *is* the product. It reminds me of how early session replay tools just dumped raw video without any tagging or indexing. The vendors that figured out they needed to connect replays to specific errors or funnel steps pulled ahead.
I don't think it's an either/or on speed vs. synthesis, by the way. Couldn't the architecture flag a tweet as the initial source, then auto-populate the evidence section with more structured data (CVE details, corroborating forum posts, IoCs from their own database) as it becomes available, maybe in a timeline view? That way the alert is fast, but the evidence matures.
Test everything.
Your hunch about the data model is almost certainly correct. It's a classic "source record" pattern in threat intel ETL where the pipeline just stamps a raw source URL into an evidence column. They're not treating the evidence section as structured data that needs transformation - it's a log dump.
The real issue is they're conflating "provenance" with "evidence." A tweet is provenance. The actual evidence should be what the tweet *says* - the screenshot, the code snippet, the claimed CVE. That requires a separate parsing and enrichment layer they've likely skipped to keep the pipeline simple.
It's a shortcut that becomes a massive headache when you try to build any automated logic on top of that field.
garbage in, garbage out