Cyber Threat Intelligence Sources: Checking Report Origins

Choosing cyber threat intelligence sources is rarely the hard part. A new feed switches on, the queue fills with thousands of indicators within days, and nobody can say which of them answers a question the team actually has.

APIs are one common way to collect source data, and they can support repeatable, measurable collection. They do not make a source relevant, and they do not turn an indicator into a conclusion.

In this article, we examine the role of APIs in collecting threat intelligence, how open-source intelligence fits the mix, how to evaluate a source before wiring it in, and how to keep collection honest about provenance, duplication, and what it leaves unknown.

Sources, Tools, and Intelligence Are Different Things

Cyber threat intelligence sources are the places where information about threats originates or is collected: internal telemetry, government and vendor advisories, public research, community sharing, and commercial reporting. A source supplies raw or processed inputs. Whether they become intelligence depends on analysis that ties them to a threat, a relevant environment, and a possible action.

Three things are easy to confuse.

Source. Where the information comes from, such as a sensor, an advisory, or a research report.

Tool or platform. How the information is collected, stored, enriched, and shared, such as a threat intelligence platform, a SIEM, or a script.

Transport and format. How the information moves and how it is represented. A format such as STIX describes how intelligence is structured, and a protocol such as TAXII describes how it is exchanged. Neither says anything about whether the content is accurate.

An indicator list is an input. Analysis connects it to a threat, an environment, and an action, and collection volume is not evidence of better intelligence.

Main Types of Cyber Threat Intelligence Sources

Each category gives a different output, carries a different limit, and is usually collected a different way.

Internal telemetry. Local context from the organization’s own sensors, logs, and incident findings. The limit is coverage: it shows only what the sensors can see. It is typically collected through authorized telemetry exports or APIs into a SIEM or platform.

Government and vendor advisories. Confirmed vulnerabilities, exploitation notes, and mitigation guidance. The CISA Known Exploited Vulnerabilities catalog is a specific example: a catalog of vulnerabilities known to have been exploited, which supports prioritization but is not proof of local compromise. These sources provide external context, and local applicability still requires checking against the organization’s environment. They arrive through published reports, subscriptions, and machine-readable downloads.

Public research. Campaign reporting and infrastructure analysis from researchers and vendors. It can lag events, vary in quality, and repeat an upstream report that other publications also cite. It is collected by reading, subscriptions, and, for open-source retrieval, APIs.

Community sharing. Peer knowledge from sector groups such as ISACs. It is valuable context, though sharing markings, such as the Traffic Light Protocol, and group terms limit how it can be reused. It moves through group exchanges and sharing platforms.

Commercial intelligence. Curated or faster reporting for documented coverage gaps. Its coverage has to be tested against the actual requirement, and licensing terms vary. It is delivered through feeds, portals, or APIs under license.

Access and licensing are conditions to verify, not assumed entitlements. Free access does not automatically permit unrestricted redistribution or commercial reuse.

Where APIs Fit in Threat Intelligence Collection

Intelligence gathering methods in cyber defense include manual review, subscriptions, files and reports, streaming telemetry, community exchanges, and APIs. APIs provide programmatic access to source data and, in some services, analytical outputs. Teams can use them to standardize requests and automate collection. Normalization, deduplication, validation, and delivery depend on the provider’s capabilities and the surrounding pipeline. APIs can support four collection capabilities, depending on the service and integration.

Documented, repeatable requests. A documented request procedure can run on a schedule or in response to an event. That promises a repeatable procedure, not identical results, since sources, permissions, pagination, and available data change.

Defined response schemas. A defined schema can reduce manual extraction. Different sources and methods may still require field mapping, parsing, and handling of schema changes.

Provenance where it is provided. Where a response carries an origin, a citation, or a timestamp, those can be stored with the item. Otherwise, the pipeline can at least record the request and the retrieval time.

Delivery through the integration layer. Context reaches the SIEM, platform, or ticketing tool through whatever integration the team builds or buys, and that mapping is implementation work.

Receiving information through an API does not establish that it is accurate, relevant, or sufficiently supported for action. Those judgments depend on the evidence, the service’s analytical methods, and the team’s acceptance criteria.

Why Indicator Volume Is Not Threat Volume

APWG reported 1,069,681 phishing attacks in Q2 2026, up 10.1% from Q1, using its site-based counting methodology, according to its Phishing Activity Trends Report published in August 2026.

The counting unit is the instructive part. A single phishing site can be advertised through thousands of customized URLs that all lead to essentially the same destination, so APWG counts reported sites, not URLs. The figures also cover only what was reported to APWG by its members, research partners, and the public. They are not a count of globally distinct campaigns.

The lesson concerns what is being counted. Whether a collection counts URLs, domains, sites, or campaigns can change the number by orders of magnitude, so a team should decide on the counting unit before measuring volume, and should not assume that a feed’s volume equals the number of distinct threats.

Where OSINT Threat Intelligence Fits

OSINT is intelligence produced by collecting, evaluating, and analyzing publicly available information for a specific requirement. The underlying material is not the same as open-source software, and it is not automatically free to reuse. For OSINT threat intelligence, that material includes public reporting, advisories, research, and the public footprint that actors and infrastructure leave behind.

What it adds. Context around an indicator. From a domain, an email address, a username, or a wallet address, public sources can show associated accounts, registrations, mentions, and links to other infrastructure, which an indicator list alone cannot.

What it does not do. A public association alone does not establish who operates the infrastructure, and a public mention is not a verified fact. Findings need evaluation and, where appropriate, independent corroboration before they support a conclusion. 

Where the boundaries lie. Collection stays within publicly accessible information and within the terms and laws that apply, with provenance recorded for each finding.

Evaluating a Source Before Wiring It In

Five questions help decide whether a source deserves an integration.

Is it relevant to a named requirement? A source earns a place by answering a defined question, not by being popular.

How good are its provenance and timeliness? Original citations and observation dates let an analyst test whether an item is current and where it started.

Is reliability separated from confidence? A respected publisher can repeat an uncertain report, so the provider’s track record and the confidence in a particular claim are assessed apart.

Is it independent? Several feeds can repeat one upstream report, so apparent agreement may be a single evidence lineage.

Are the terms and API behavior workable? Permitted use, rate limits, schema stability, and error handling decide whether an integration can run reliably.

More indicators or more vendors do not guarantee better coverage. A short pilot against a real requirement shows what a source contributes.

Building a Threat Intelligence Collection Plan

Seven steps place the collection stage inside the wider intelligence lifecycle.

Defining the decision and the question. The plan starts from a decision the intelligence will support.

Identifying gaps and candidate sources. The team lists what it does not yet know and which sources could answer it.

Establishing access, owner, and cadence. Credentials, rate limits, a responsible person, and a schedule are settled before collection begins.

Collecting and retaining provenance. Items are pulled, by API or another method, and stored with their origin and retrieval time.

Normalizing, deduplicating, and validating. Identifiers are normalized for matching while the original values and observations are preserved. Duplicate entities are grouped without discarding source citations, observation times, or conflicting assessments, and each item is checked before analysts act on it.

Analyzing and delivering to a named consumer. Findings go to a specific person or system with a stated purpose.

Reviewing usefulness and revising collection. The team looks at what the collection actually contributed and adjusts it.

A completed plan entry shows how the pieces fit together.

Requirement. Which lookalike domains have newly appeared against the company’s brand?

Source and method. Public registration and mention data, collected by API and checked against the team’s own telemetry.

Owner. A named analyst on rotation in the brand protection team.

Cadence. Daily collection, with a weekly review of whether indicators should remain active. 

Output. A reviewed list delivered to the brand protection team, with each item’s evidence attached.

Acceptance gate. The original citation behind each item is checked and its lineage recorded. Items resting on a single unverified report are held for review, and any restriction follows the approved response policy.

A rejected or held item is a normal outcome, and a process that accepts every observation is not credible.

Controls for Common Collection Mistakes

Automation can amplify mistakes as well as strengths, so each common failure needs a control.

Duplicate reporting. Several reports derived from one upstream source represent one evidence lineage, not independent corroboration. Group duplicate entities without discarding citations, observation times, or conflicting assessments. For URLs, avoid indiscriminate removal of paths or query parameters, since those components may distinguish relevant resources.

Stale indicators. Set review and expiration rules appropriate to the indicator and the use case. Expiration can remove an indicator from active enforcement without deleting its historical observations or case context.

Untrusted inputs. All external inputs, including commercial feeds, need validation proportionate to the action they could trigger, with human review before they drive disruptive action.

Unsupported attribution. Keep findings about infrastructure separate from claims about who is behind it.

Overbroad blocking. Action follows confidence, potential harm, and approved response policy. Restricting a specific malicious destination differs from blocking shared infrastructure.

Collection is worth keeping when it yields relevant items that other sources do not, saves analyst effort, and shortens the time to usable context. A source should not be retired solely because it adds no new indicators, since independent confirmation, resilience, or additional context can make overlapping coverage valuable.

A Scenario: The Domain Three Feeds Agree On

Consider a hypothetical example. A security team’s feeds list a lookalike domain linked to a phishing campaign against the company’s brand. The domain, harborline-support[.]example, is fictional, and all details are invented for illustration.

Sources and lineage. Three feeds list the domain. Tracing each back through its original citation shows all three repeat one vendor report, so they count as one evidence lineage, not three. The team reads the original report for its observation dates and the evidence behind the claim.

Enrichment. An API query on the domain and the contact details tied to it returns a public email address connected to the domain. The same address appears on two other lookalike domains already in the team’s records. It is not a registrar or privacy-service address, so the team treats the link as distinctive, which shared hosting alone would not be.

Local check. No matching queries were observed from covered user devices during the reviewed period. DNS visibility does not establish that nobody visited the destination or submitted credentials, so the team records this as a limit of the evidence.

Rejected inference. Other domains on the same hosting provider are not treated as malicious, since shared infrastructure hosts many unrelated sites.

The team records the evidence and applies its approved response policy. Depending on confidence and potential harm, it may monitor, warn users, or restrict the specific destination. A second independent source can increase confidence, but one sufficiently strong primary source may justify action, and two weak sources do not necessarily do so. What the workflow leaves unknown is whether any user interacted with the domain and who operates it, and the team notes which new evidence would change the assessment.

Where SL API Fits Into Threat Intelligence Collection

SL API provides structured access to open data from hundreds of sources, including social media, public records, corporate sources, registries, and messengers, through a single integration. Availability depends on the method and source. A team starts from an indicator it already holds, such as a domain, an email address, a username, a phone number, an IP address, or a cryptocurrency wallet, and retrieves associated public information.

For threat intelligence collection, that supports the enrichment and monitoring side of OSINT threat intelligence: context around an indicator, keyword and hashtag monitoring for brand and employee protection, and support for threat and incident investigation. Teams should confirm which fields, source references, and timestamps each method returns, how monitoring behaves, and what integration work is needed.

Mapping results into a SIEM or ticketing tool, logging, and acceptance gates are implementation work on the team’s side, and the intelligence work itself stays there too: the requirement, the corroboration across independent sources, and the decision about action. Coverage varies by source and region, so a short pilot against a defined requirement, with an analyst reviewing what is accepted, is the sensible first step.

The Takeaway

Choosing cyber threat intelligence sources is a requirement-first decision. APIs can support the collection step by making requests documented and repeatable, but accuracy, relevance, and sufficient evidence for action still depend on provenance, independent corroboration, and the team’s acceptance criteria. What turns collected items into intelligence is analysis, delivered to a named consumer who can act.

FAQ

What are the main cyber threat intelligence sources?

Internal telemetry, government and vendor advisories, public research, community sharing, and commercial intelligence. The right mix depends on the requirement. Internal data gives local context, public sources give breadth, and community and commercial inputs fill specific gaps. APIs are one common way to collect from them.

Is OSINT the same as cyber threat intelligence?

No. OSINT is intelligence developed from publicly available information, such as research, advisories, and the public footprint of infrastructure. Cyber threat intelligence draws on several kinds of sources and connects the analysis to a threat, an environment, and an action. OSINT is one input among others.

Are free threat intelligence sources enough?

Sometimes. Free sources can cover a lot, but the question is coverage, effort, and gaps, not price. Free access also does not always permit redistribution or commercial reuse. A team should test what its free sources miss against a defined requirement before deciding that anything paid is necessary.

How should a team validate a threat intelligence feed?

By testing provenance, timeliness, relevance, and duplication, and by reviewing a sample of its findings. Tracing items to their original citation shows whether feeds are independent, and a short pilot shows how much of the output an analyst could actually use.

How often should collection and indicators be refreshed?

It depends on the decision, the source, and the type of data. Indicators such as domains and URLs age quickly and need review and expiration rules, while advisories and research change less often. Scheduled or event-driven collection can support the required cadence, depending on source capabilities and integration effort, but cadence should follow how fast each kind of information loses value.

Want to see how open-source context can make threat intelligence collection more useful to analysts? Book a personalized demo to see how SL API helps security teams enrich domains, emails, and usernames with structured open data, check each result against their own acceptance criteria, and work with the findings within their existing workflows.