Cybersecurity software vendors: what security data you can license

What security data does a vendor actually hold?#

A security software vendor holds three kinds of data that look alike in a data lake but differ sharply in ownership. Customer telemetry comes from the customer's endpoints, networks, identities and cloud accounts. Threat intelligence describes attackers and their tools. Vendor-owned records document how the vendor's own people built detections, triaged alerts, answered customers and shipped code.

Endpoint detection and response, managed detection, email security, SIEM and vulnerability management products all mix the three. The licensing question is never whether the vendor holds the data, but which class each record belongs to.

Customer telemetry, threat intelligence and vendor records compared#

The comparison below sorts the record types a security vendor typically holds by who controls them and how a licensing review usually treats them. Use it to brief leadership before anyone promises a dataset.

Who owns EDR and product telemetry?#

EDR and product telemetry is usually customer data under the vendor's agreement, collected so the vendor can protect the customer. Many agreements give the vendor a license to use telemetry to provide and improve the service, and some add a right to derive threat intelligence. Few contemplated licensing telemetry to outside AI developers, and stretching an improvement clause that far invites a dispute.

Telemetry also carries personal data. Usernames, hostnames, file paths, email addresses and IP addresses can identify people, and under the GDPR, pseudonymized data that can be re-linked using additional information is still treated as information about an identifiable person. US state privacy laws may apply too, depending on whose data it is.

Many vendors publish responsible AI statements explaining how they train their own detection models on customer telemetry. Those statements describe the vendor's own use; they do not establish a right to give the same telemetry to a third party.

Threat intelligence: derived, shared and licensed in#

Threat intelligence sits between the other two classes because its origin varies. Indicators your researchers found by analyzing public malware are much easier to license than indicators extracted from a specific customer's incident, which may reveal that the customer was breached.

Shared intelligence carries its own rules. Information received through industry sharing groups often comes with Traffic Light Protocol markings or membership terms that limit onward sharing, and commercial feeds typically prohibit redistribution. Tag every indicator with its source so those limits travel with the data.

Vendor-owned records AI developers ask about#

Vendor-owned security records capture expert judgment, which is what model developers find scarce. The most useful ones link a signal to a decision and an outcome.

• 1Detection engineering histories: the rule, why it was written, how it was tuned and what false positives taught the team.
• 2Alert triage decisions with outcomes, from the vendor's own analysts in a managed service.
• 3Investigation and response playbooks, including revisions made after real incidents.
• 4Support cases where customers and engineers worked through deployment, tuning and integration problems.
• 5Code reviews, issue histories and postmortems from the product's own engineering team.
• 6Vulnerability disclosure handling records, with researcher and customer details removed.

Preparation risks unique to security data#

Security records need more preparation than most because they are full of things attackers want. Logs and tickets routinely contain credentials, API keys, internal hostnames and network layouts, and engineering records may contain working exploit code or detection logic that reveals how to evade the product.

Secret scanners help but need care. TruffleHog, an open-source scanner, covers sources including Git, chats, wikis and logs, and for secrets it can classify it can log in to confirm whether a credential is live, which means sending authentication requests. Run that verification only where you are authorized to.

Trade secret protection is the other risk. Under the Defend Trade Secrets Act, information qualifies as a trade secret only if its owner takes reasonable measures to keep it secret, so any license of detection content should carry confidentiality, access and use restrictions.

Illustrative: an MDR platform vendor separates its packages#

Illustrative: a fictional managed detection and response platform vendor serves mid-sized manufacturers and distributors. An AI developer building security operations agents asks about licensing triage and investigation records.

The vendor excludes customer telemetry entirely and drops indicators that came from paid feeds. The package that proceeds holds de-identified analyst triage notes with outcomes, the history of detection rules with tuning rationale, investigation playbooks and support cases. Preparation replaces customer hostnames and IP addresses with placeholders, removes every customer name and runs secret scanning across notes and code.

The license restricts use to training and evaluating models, prohibits publishing detection logic and requires the developer to protect the material as confidential.

How SourceX handles security vendor records#

SourceX begins with a metadata-only fit check; nothing is shared during the initial assessment. In the SourceX five-step transaction, the Rights step sorts records into telemetry, threat intelligence and vendor-owned classes, Preparation removes secrets and customer details, and the vendor approves the release.

Large security datasets stay in the vendor's own storage or ship on encrypted drives, and SourceX never hosts multi-TB datasets. Each package carries a SourceX Evidence Packet covering provenance, licensing rights, permitted use, the privacy record and release authorization.