Corrections policy
We publish research that people may act on, so we fix errors in the open. This page sets out how, and lists every correction we have made.
What we correct
- Correction: a factual error, a wrong figure, a broken or wrong source, a misattributed finding, or a claim our sources do not support. We fix the text and add a dated entry to the post's Corrections section saying what was wrong and what changed.
- Update: new information that changes the picture but does not show the original was wrong, such as a vendor patch or a new advisory. We add it, mark it in the text, and change the post's updated date. Updates are not listed below.
- Retraction: when a post's central claim does not hold. We say so in a banner at the top of the post and keep the post at its address. If a post mostly described a product rather than research and can't be corrected into something accurate, we retire it: the address redirects to the closest current page and the retraction is listed below.
We don't silently edit published claims. Typos and formatting fixes that don't change meaning are made without a note.
How to report an error
Email [email protected] with the post, the claim and a source. If you are reporting a security vulnerability rather than an error in a post, follow the disclosure policy instead.
Archived posts
Posts from 22 March to 16 April 2026 describe MalCloud, ThreatFight's earlier threat-intelligence product. We audited every product and factual claim in them against MalCloud's code in October 2026. Posts we kept are in the archive with a banner and their corrections inline. Posts we could not correct are retired and listed below.
Corrections log
- Why Your Threat Intelligence Context Doesn't Export
We said STIX 2.1 has no standard field for free-text analyst reasoning and that the Opinion object only records agree/disagree. Both are wrong: the Note object carries free-text analysis and the Opinion object has an optional
explanationproperty (STIX 2.1, sections 4.13 and 4.15). - Why Your Threat Intelligence Context Doesn't Export
We said STIX only snapshots the final confidence state. STIX 2.1 supports object versioning (section 3.6), so a confidence history can be expressed; most exports ship only the latest version.
- Why Your Threat Intelligence Context Doesn't Export
We said every edge in MalCloud's graph carried an immutable provenance chain that exported with the graph, that annotations were versioned and searchable, that every confidence change was stored as an event with volatility alerts, and that every MalCloud action went to an append-only log. None of this matched the code. Provenance records were separate rows not attached to edges and never exported; annotations were append-only and listable per entity, with no search; only manual overrides were logged; the append-only table covered Graph Context writes only. The section now describes what the code did.
- Why Your Threat Intelligence Context Doesn't Export
Removed an origin story about organisations migrating between TIPs, claims about long-running customers, a statement of commercial terms ("no minimum commitment") and the call to action. MalCloud had no customers and the Graph Context code landed on 17 April 2026, the day after this post's date.
- Why Your Threat Intelligence Context Doesn't Export
Removed an unsupported figure ("thousands of these micro-assessments" in 12 months), replaced a vague reference to "NIS2 audit mandates" with the specific DORA provision, and marked platform-behaviour statements as our experience rather than fact.
- Detection-as-Code: Generating Sigma Rules from Threat Intelligence
The three Sigma rules and the Splunk, Elastic and Sentinel queries were presented as MalCloud output. They were written by hand: MalCloud's generator emitted a single
CommandLine|containsselection per technique, and its converter supported only Splunk SPL and Elastic KQL and ignored the rule's condition. The rules are now labelled as hand-written, and the queries are regenerated with sigma-cli 3.1.0 and the listed backends. - Detection-as-Code: Generating Sigma Rules from Threat Intelligence
Removed claims that MalCloud mapped extracted behaviour to ATT&CK techniques, combined technique templates with IOC values, included a rule testing framework, used a Git review workflow, deployed rules to SIEMs, fed results back into generation, computed per-actor coverage, and was "available in all deployment tiers". None of these existed in the code. Removed the "under 60 seconds" and "under 10 minutes" timings, which were never measured.
- Detection-as-Code: Generating Sigma Rules from Threat Intelligence
The third rule was titled "DNS Query to Known APT29 C2 Infrastructure" and listed two domains as known malicious. They were invented examples and may be real domains owned by others. They are replaced with
.exampleplaceholders and the rule is retitled as a template. - Detection-as-Code: Generating Sigma Rules from Threat Intelligence
Removed a figure attributed to the "SANS 2024 SOC Survey" (2-3 rules per engineer per week), which we could not find in that survey, and unsourced figures on actors tracked, rules maintained and hours per rule. Corrected "APT29 uses 27 documented techniques": ATT&CK lists far more for G0016, so the example now uses a hypothetical actor. Noted that the ATT&CK counts are for v18. Changed "covering the majority of ATT&CK techniques" to "a wide range", which is what we can support.
- Detection-as-Code: Generating Sigma Rules from Threat Intelligence
Fixed rule dates to the YYYY-MM-DD format the Sigma specification requires, replaced
evil.com(a registered domain) withexample.com, updated the moved Sigma specification link, and removed a duplicated call to action. - MalCloud vs OpenCTI vs MISP: An Honest Comparison
Retracted. The post made at least eight wrong statements about OpenCTI and MISP. Among them: that OpenCTI needs manual export or custom connectors to reach a SIEM (it ships stream connectors for Splunk, Sentinel, Elastic, Google SecOps and QRadar), that OpenCTI has no way to share signals between deployments, and that MISP and OpenCTI exports carry no analyst context (MISP added notes, opinions and relationships in 2.4.186). Its MalCloud claims did not match MalCloud's code: deployment size, search engine, provenance export, Microsoft KQL output, the extractor list, and an organisation binding in the zero-knowledge circuit that does not exist. It also listed pricing tiers for a product that was not on sale. We apologise to the OpenCTI and MISP projects. Published 25 March 2026; its address, /blog/malcloud-vs-opencti-vs-misp/, now redirects here.
- Why Self-Hosted Threat Intelligence Matters
Retracted. The post said self-hosting is a compliance requirement under DORA, NIS2, GDPR, ITAR and CMMC; none of them requires it, and its ITAR, CMMC and SecNumCloud statements were wrong. It said Midnight Blizzard compromised Azure; the 2024 intrusion reached Microsoft's corporate email and source code. It gave vendor prices with no source. Its MalCloud figures (ATT&CK objects, indicators, threat actors) were counts from a development database, not data that ships with the product. Published 29 March 2026; its address, /blog/why-self-hosted-threat-intelligence-matters/, now redirects here.
- ZK-STIX: Zero-Knowledge Proofs for Threat Intelligence Sharing
Retracted. The post described a protocol built on Pedersen commitments, accumulators, Bulletproofs and private set intersection, with a wire format and benchmarks. None of it existed. MalCloud's ZK-STIX service used Bloom filters over unsalted SHA-256 hashes of indicators, which anyone holding the filter can test guesses against, and its own documentation said it was not a zero-knowledge proof system. The benchmarks were never run. The post also made an unsupported claim about CMMC and ITAR, and attributed a quotation to DORA Article 17 that is not in it. Published 28 March 2026; its address, /blog/what-is-zk-stix/, now redirects here.
- Collective Threat Intelligence Without Revealing Your Watchlist
Retracted. The post's privacy guarantees did not hold in MalCloud's code. Every submitted hash travelled with the submitting organisation's ID, so the operator could see each organisation's watchlist. Hashes either could not be counted across organisations (with a random nonce) or could be brute-forced back to the indicator (without one). The sector threshold counted sightings, not organisations. The example signal ("47 organizations"), the events, the latency figures and the claim that the feature was available were invented or wrong, and the code landed the day after the post's date. Published 16 April 2026; its address, /blog/collective-threat-intelligence-without-revealing-your-watchlist/, now redirects here.
- Push Enriched Threat Intel to Your SIEM in Seconds
Retracted. The "under 2 seconds" figure was a design target that was never measured. None of the JSON, CEF or Go examples matched the code, the pushed records carried none of the claimed enrichment or ATT&CK fields, and the Splunk CIM and Elastic compatibility claims were false. The pricing tiers existed only in a design document. The post went up a day before the code landed, and Microsoft has since retired the Azure API the Sentinel connector used. Published 16 April 2026; its address, /blog/push-enriched-threat-intel-to-your-siem-in-seconds/, now redirects here.
- ZK Proof-of-Observation: Cryptographic Evidence You Saw It First
Retracted. The post's central claim was that a verifier learns nothing about the exact time an indicator was observed. In MalCloud's implementation the public time bound was set equal to the exact timestamp, so the verifier learned it. Proofs were generated on MalCloud's server from the plaintext indicator and nonce; commitments were submitted by clients, not created on ingestion; the timestamp was chosen by the client; and epoch roots were unsigned and not anchored anywhere external. The Groth16 trusted setup was a single-party step at build time, which the post did not mention. The constraint breakdown was wrong and the benchmarks were never run. Two figures did hold when we ran the circuit: 15,774 constraints and a 164-byte proof. Published 16 April 2026; its address, /blog/zk-proof-of-observation-cryptographic-evidence/, now redirects here.