Source-linked security intelligence is not ordinary content with links added at the end. A reader should be able to identify which source record supports a material claim, which version was retrieved, what transformation BaitaPhish applied, what remains uncertain, and how a later correction relates to the earlier result.
A URL answers only “where might I look?” Provenance must also answer “which record, observed when, transformed how, and used for which claim?”
Preserve the source record before interpreting it
A minimum source packet should contain:
| Field | Purpose |
|---|---|
| Stable source ID | Joins claims and relationships to the exact source record |
| Title and publisher | Identifies the responsible source, not merely a domain |
| Canonical URL | Gives the reader a direct verification path |
| Version or effective date | Distinguishes the rule, schema, advisory, or release used |
| Retrieval date | States when the publisher's representation was observed |
| Source role | Separates primary evidence from supporting interpretation |
| Claim scope | States which proposition the source is being used to support |
| License or retention state | Defines whether content is linked, archived, or redistributable |
W3C PROV supplies useful concepts for entities, activities, agents, derivations, and revisions. W3C PROV overview A security-intelligence system does not need to expose RDF to users, but it does need stable semantics for those relationships.
Keep source, structure, and interpretation separate
Consider a CVE record. A source may publish an affected product range and description. Another provider may add CVSS, applicability information, or change history. BaitaPhish may normalize tags or explain operational implications.
Those are different layers:
- Source evidence: what a named publisher supplied.
- Normalization: deterministic restructuring or identifier extraction.
- Enrichment: provider or system-added fields.
- Interpretation: BaitaPhish analysis of what the evidence means.
- Decision context: environment-specific exposure and ownership not contained in the public record.
Collapsing those layers creates false certainty. A derived summary can be useful without becoming the source of truth.
Security records change
NVD documents CVE and change-history APIs, including modification sources and event types. NVD Vulnerability API documentation A CVE identifier therefore does not imply that every consumer has the same fields, provider enrichment, or observation time.
For a material decision, retain:
- upstream publication and modification timestamps where available;
- local retrieval time;
- source and schema version;
- immutable snapshot identity or digest where retention is allowed;
- transformation version;
- the claim or decision that used the record.
When the upstream record changes, create a new observation and link it to the previous one. Silently overwriting history prevents reproduction and makes corrections indistinguishable from ingestion drift.
Links do not establish corroboration
Ten articles may repeat one vendor statement. They are ten documents, not ten independent confirmations. Provenance should record derivation or common sourcing when known so presentation volume does not become an accidental confidence score.
Source class also matters. The affected vendor or CNA may be authoritative for product behavior and affected versions. CISA may be authoritative for KEV catalog membership. NVD may be authoritative for its own enrichment. None automatically knows whether a specific BaitaPhish reader operates an exposed affected asset.
What BaitaPhish currently claims
BaitaPhish's public methodology says configured sources receive identifiers; available URLs, publisher labels, timestamps, and stable record identifiers remain attached; added structure and predicted relationships are labeled; and unavailable data remains a limitation rather than being synthesized. BaitaPhish methodology
This Article contract extends that approach to authored analysis by binding citations to structured source packets, separating draft and publication gates, exposing review and limitation data, and retaining material correction history. It does not claim that every upstream record is true or that current source coverage is complete.
A practical verification test
Before relying on an intelligence claim, ask whether another analyst can:
- open the exact authoritative source;
- identify its version and observation date;
- locate the field or passage supporting the claim;
- distinguish quoted evidence from BaitaPhish interpretation;
- see conflicts, missing fields, and limitations;
- reproduce the transformation or understand why it cannot be reproduced;
- determine whether a correction superseded the result.
If the answer is no, the item may still be useful discovery material. It should not be presented as reproducible source-linked intelligence.
Practical takeaway
Treat provenance as part of the content model, not a bibliography component. Bind every material claim to a scoped source record, preserve time and version, label transformations, and keep unknowns visible. Then use the analysis as a path into the underlying Research, CVE Explorer, source directory, and methodology—not as a replacement for them.
Continue with Why Provenance Matters in Security Intelligence, inspect the current source directory, and review the BaitaPhish methodology.
Limitations
Provenance documents lineage, not truth. It cannot establish source independence, product applicability, asset exposure, or business impact without additional evidence. Public URLs can also change or disappear; archival and licensing decisions require separate governance.