Security datasets can look more authoritative than they are: a CVE identifier, CVSS score, or vulnerability label in a training example is not proof that the accompanying analysis is correct. This collection is most useful as a broad instruction-tuning and classification resource when its metadata is treated as noisy, testable input rather than ground truth.
What Sets It Apart
- The 60,517 records combine synthetic CVE-oriented analysis, NVD records, offensive web-appsec examples, HackerOne conversations, and PortSwigger lab material. This gives experiments more variety than a single-source corpus, but the synthetic CVE-oriented portion is still the largest.
- Examples pair conversations with fields such as vulnerability class, CWE, CVE, severity, and CVSS. That structure supports both answer-generation experiments and supervised classification across 35 vulnerability/report classes.
- Train, validation, and test splits are grouped to prevent shared-CVE leakage across splits. This helps evaluation, although it does not guarantee independence by vendor, product, or vulnerability family.
- The corpus is primarily web and application security, not binary exploitation: memory-safety examples are about 0.7% of records, and only around 3% of answers contain code.
Who It Suits—and the Trade-off
A good fit for researchers building or evaluating security assistants, vulnerability triage classifiers, or web-appsec instruction-tuning pipelines, especially when they can report results by source and audit labels. Look elsewhere for execution-based exploit reproduction or memory-safety benchmarks. Synthetic examples, backfilled labels, class imbalance, and potentially inaccurate security details mean that authoritative advisories and human review remain necessary.
