A Function-level Dataset of Vulnerable and Fixed Source Code in JavaScript and TypeScript

What it is

JsVul — a function-level JavaScript/TypeScript vulnerable/fixed dataset (Viszkok & Hegedűs, University of Szeged), released on Zenodo in JSONL. The summary names the concept; what matters for a decision is the scale, the class balance, and how weak the baselines are. The final dataset holds 1,960 commits / 1,994 files / 2,039 vulnerable vs. 19,862 non-vulnerable functions (~1:10 imbalance). A balanced pairs_only subset gives 1,342 vulnerable / 1,342 fixed matched pairs — the only part with both pre- and post-fix versions present.

The numbers that should drive the decision

The three fine-tune/zero-shot baselines on the pairs subset are barely above chance:

CodeBERT predicts everything vulnerable (recall 1.0, precision ~0.50). The authors frame this as proof of a "learnable signal," but for an engineer it reads as: this is a hard task and current models get ~60% accuracy on the balanced split. Treat it as a research/evaluation dataset, not something to build a production detector on directly.

Sources and pipeline specifics

Seven sources: CrossVul, CVEFixes, JS Vulnerability Dataset, OSSF CVE benchmark, SecBench.JS (static), plus OSV (retrieved 2025-11-18) and NVD (2025-10-31, via API). The authors distrust every source's own metadata — they keep only the fixing-commit reference and re-derive everything via the GitHub API (standardizing to full SHA-1, resolving renamed repos, keeping only commits touching a JS/TS file). They document concrete upstream errors: OSSF's CVE-2018-8035.json postPatch commit doesn't exist; CVEFixes' programming_language field mislabels C++/Java/Go as JavaScript; CrossVul stored HTTP 404 pages as file content.

Labeling is fully re-done, not inherited. Key filters: onefunc (keep commits with exactly one vulnerable function) and nvdcheck (keep functions named in the NVD entry); commits failing both are discarded. Cosmetic-edit false positives are killed by normalizing with ESLint + Prettier, extracting function bodies via Babel + recast, then dropping any "modified" function byte-identical to its fixed form. This is where the data collapses: normalization + function dedup takes affected functions from 22,053 down to 4,391.

What to do

• Use js_vul_pairs_only for balanced evaluation; use the full js_vul if you want the realistic ~1:10 class distribution.
• Respect the chronological split (80/10/10 by publish_time) — the authors deliberately avoid k-fold to prevent temporal leakage. Don't re-shuffle it.
• Each record carries id, body, binary label, loc coordinates, and optional cwe/cve/ghsa/snyk identifiers, so you can filter by weakness class.
• Global dedup rule to be aware of: identical functions with conflicting labels are kept as vulnerable (minimizing false negatives) — a deliberate bias baked into the labels.

Caveats

Manual verification covered only 25% of normalized changes and all 97 flagged duplicate commit pairs. Function-level labeling rests on heuristics (onefunc/nvdcheck), so multi-function fixes are excluded by design. The page text is truncated before full Usage Notes.