The claim is not enough
Security intelligence arrives as claims: a domain is malicious, a vulnerability is exploited, a campaign uses a technique, a package was built from a repository, an incident affected a product, or a control reduces a particular path. A claim can look precise while hiding the facts a decision-maker needs most. Who asserted it? What did they observe? Which source version did they use? How was the record transformed? What changed after publication? Which parts are evidence, and which are analyst inference?
Provenance is the information that answers those questions. The W3C PROV overview describes provenance in terms of entities, activities, and agents and explains that it can support assessments of reliability, trustworthiness, derivation, and version relationships. For security intelligence, that means treating lineage as part of the record rather than an editorial footnote.
Provenance does not make a claim true. A signed, perfectly traceable mistake is still a mistake. It makes the basis of the claim inspectable, supports reproducibility, and lets policy distinguish evidence paths that should not be treated as equivalent.
What a useful provenance record contains
A practical intelligence record should identify:
- the source and canonical location;
- publisher or asserting agent;
- source type and authority scope;
- publication, effective, retrieved, and reviewed dates where relevant;
- source version, revision, or content digest;
- the specific claim supported by that source;
- transformations such as parsing, normalization, enrichment, translation, summarization, or deduplication;
- tools, rules, and versions used in those transformations;
- analyst judgments, confidence, limitations, and review status;
- relationships to superseded, derived, or conflicting records;
- the intended decision scope and expiry or re-review trigger.
The “claim supported” field is especially important. A vendor advisory may authoritatively describe its own affected product versions but may not establish broader campaign attribution. A government alert may report exploitation at a point in time but may not support a timeless statement that every exposed instance is compromised. A MITRE ATT&CK page may support a technique definition and cited procedure example, while a local mapping still needs scenario-specific evidence and rationale.
Provenance should therefore be claim-scoped, not merely document-scoped.
Four decisions provenance improves
1. Whether to act
A responder deciding whether to block an indicator needs to know its origin, observation time, context, and expected false-positive cost. A domain extracted from a current authoritative incident report differs from one copied through several feeds without the original context. Provenance allows policy to demand stronger evidence for disruptive actions and accept broader evidence for low-risk hunting.
2. Whether a claim is still fresh
Security facts decay at different rates. An immutable vulnerability identifier is durable; affected-version ranges, exploit status, cloud product behavior, certification scope, and incident impact can change. Retrieval and review dates let consumers distinguish “published once” from “checked recently.” A supersedes relationship prevents an older record from silently competing with the current one.
Freshness is not one global time-to-live. Define it by claim type and decision. An emergency block may tolerate minutes-old unreviewed observations. A public educational article may require stable primary sources and a scheduled review. A legal or compliance conclusion needs the effective date and applicable jurisdiction, not simply the latest web crawl.
3. Whether two records really corroborate each other
Ten feeds can repeat one original report. Counting them as ten independent sources creates false confidence. Derivation links reveal common ancestry. True corroboration requires sufficiently independent observations or analysis.
This matters in incident reporting and campaign attribution. A news article quoting a vendor report and a feed quoting the same article do not independently confirm the vendor's conclusion. Provenance lets an analyst collapse that chain, preserve the useful distribution context, and avoid inflating confidence.
4. Whether an artifact followed an approved path
Software supply-chain provenance applies the same principle to build artifacts. SLSA v1.2 describes provenance as verifiable information about where, when, and how an artifact was produced. Build provenance can connect an output digest to source inputs and a builder. Policy can then reject an artifact built by an unexpected workflow or from an unapproved revision.
That evidence does not prove the source code is benign, the build platform is flawless, or the dependency set is safe. It proves selected properties of origin and process, depending on how the provenance was produced and verified. Those limits should travel with the result.
Separate observation, inference, and decision
Many intelligence failures begin when three layers are collapsed:
- Observation: what a source or sensor directly recorded.
- Inference: what an analyst concludes from one or more observations.
- Decision: what an organization does under its own risk and operating context.
Consider an OAuth consent scenario:
- Observation: a message contains an authorization link; the application requests mail and offline access; the publisher is unverified.
- Inference: the request is likely a malicious consent lure and could yield durable application access.
- Mapping decision: the scenario maps to a phishing-link technique and a token-access technique because the recorded actions match the maintained definitions.
- Response decision: deny consent, report the client, and revoke the grant if it was accepted.
Each layer has different evidence. The source defining a technique is not the source proving that the scenario occurred. The scenario evidence is not the authority for a product-specific revocation procedure. Provenance keeps those responsibilities visible.
Transformations need lineage too
Security data is rarely used exactly as published. Pipelines extract text from HTML or PDF, normalize timestamps, resolve URLs, assign identifiers, merge duplicates, translate labels, enrich infrastructure, calculate confidence, and generate summaries. Every transformation can lose context or introduce error.
Record at least:
- input identifiers or digests;
- transformation name and version;
- parameters and reference data versions;
- output identifier;
- time and executing service identity;
- deterministic versus analyst-judgment status;
- validation results and quarantine reasons.
For a deterministic transformation, a consumer should be able to repeat the operation or at least verify the relevant rule version. For analyst judgment, the record should preserve rationale, evidence references, confidence, and reviewer status. Model-generated suggestions should remain suggestions until an accountable review accepts them.
Quarantine is a valid result. A parser should not manufacture complete-looking fields from ambiguous input. Preserve the source, record the failure, and keep the incomplete item out of public or automated decisions until it can be resolved.
Integrity, authenticity, and transparency are different
These properties are often confused:
- Integrity helps detect whether recorded content changed.
- Authenticity helps establish which identity produced or signed it.
- Transparency makes the process and evidence inspectable.
- Correctness means the claim accurately represents reality.
- Authority describes the publisher's standing for a particular claim.
A hash provides integrity comparison, not identity. A signature can bind content to a key, but trust still depends on key governance and authority scope. A transparent pipeline can consistently transform a low-quality source. A primary source can be authoritative about publication state while still requiring interpretation for a local decision.
Provenance design should state which properties are provided and which are not.
Provenance as policy input
Once lineage is structured, systems can apply explicit rules. Examples:
- publish only records with a canonical source, retrieved date, claim scope, and accountable review;
- require a primary or official source before labeling a certification domain map current;
- prevent a model-suggested relationship from appearing as an accepted ATT&CK mapping;
- require two genuinely independent observations before a high-impact automated block;
- reject expired relationships and review-due content from “current” views;
- deploy only artifacts whose verified provenance references an approved builder and source revision;
- keep source-restricted or internal evidence out of public outputs while retaining a sanitized control record.
These policies should fail visibly. If provenance is missing, consumers should see “unknown” or quarantine rather than a fabricated default. If a relationship expires, remove it from public resolution and alert its owner. If a source changes, record a new version and its relationship to the prior record.
Privacy and security limits
More lineage is not always safer. Provenance can expose analyst identities, internal systems, private sources, customer data, investigation methods, build topology, or sensitive timestamps. Apply data minimization and access control.
Maintain separate layers when necessary:
- a public record with canonical sources, general rationale, and review dates;
- an internal record with restricted evidence, responder details, and sensitive infrastructure;
- cryptographic commitments or opaque IDs that allow integrity checks without publishing protected content.
Do not cite a source publicly if the citation itself reveals a victim, private feed, active investigation, or access method. Instead, state the limitation and keep the public claim within evidence that can be disclosed.
Provenance stores are also high-value integrity targets. Protect write authority, retain history, monitor mutation, separate reviewer roles where warranted, and test recovery. A system that lets an attacker rewrite both a claim and its lineage creates convincing false confidence.
A minimum viable implementation
Start with a small schema rather than a graph platform. For each source, record an ID, title, publisher, canonical URL, type, authority scope, version, effective date, retrieved date, license or reuse status, and claim scope. For each content record, reference sources by ID and record author, reviewer, reviewed date, due date, aliases, and superseded records. For each relationship, record its type, rationale, evidence source IDs, assertion method, confidence, status, and expiry.
Then enforce invariants:
- identifiers and canonical routes are unique;
- public records reference known sources;
- evidence-required relationships cannot be published without evidence;
- draft, rejected, expired, or unreviewed model suggestions do not resolve publicly;
- dates and versions use stable formats;
- public links are validated;
- every transformation failure is explicit.
Add graph features only when the decisions require them. A simple relational or document model with immutable history can support strong provenance if the semantics are clear.
Questions for reviewing an intelligence claim
Before using a claim, ask:
- What exact decision will this claim influence?
- Which source directly supports it?
- Is that source authoritative for this claim scope?
- When was the source published, effective, retrieved, and reviewed?
- Which transformations occurred between source and record?
- Which part is observation, and which part is inference?
- Are apparently independent sources derived from one origin?
- What evidence would contradict or expire the claim?
- Who owns review and correction?
- What sensitive lineage must remain restricted?
If those questions cannot be answered, reduce the claim's confidence or decision authority. Do not repair missing evidence with more polished prose.
Final principle
Provenance is the connective tissue between a source, a transformation, a claim, and a decision. It improves security intelligence because it makes disagreement diagnosable. Reviewers can challenge the source, version, parser, inference, mapping, or policy separately instead of arguing over an opaque conclusion.
The goal is not maximal metadata. The goal is sufficient, protected, and verifiable lineage for the consequence of the decision. When a claim can block infrastructure, change a public record, trigger incident response, or approve a production artifact, its evidence path deserves the same design care as the action it drives.