Infosec Tool Output

Security-tool output → evidence-backed, plain-English interpretation.

A dataset for training and evaluating models that interpret security-tool output, explain the limits of the evidence, and recommend defensive next steps.

v2.0.0: 1,004 canonical examples across 19 tools. This includes all 776 original records with traceable interpretation changes, plus 228 newly authored synthetic fixtures. The deduplicated training views contain 1004 examples, not additional independent data.

Licence: Apache-2.0 · Dataset DOI: 10.57967/hf/7654

Load the dataset

Load a v2 revision from Hugging Face:

from datasets import load_dataset

# One schema across all tools, with train / validation / test splits.
ds = load_dataset("tegridydev/infosec-tool-output", "all")

# Select an individual tool.
bandit = load_dataset("tegridydev/infosec-tool-output", "bandit")

# Fine-tuning views derived from the same records and split assignments.
sft = load_dataset("tegridydev/infosec-tool-output", "sft")
chat = load_dataset("tegridydev/infosec-tool-output", "chat")

Pin revision="<release-commit-sha>" for reproducible experiments. A Git tag is convenient, but a commit SHA is the exact reference. To load a local copy:

from datasets import load_dataset

ds = load_dataset("json", data_files={
    "train": "data/chat/train.jsonl",
    "validation": "data/chat/validation.jsonl",
    "test": "data/chat/test.jsonl",
})

No custom dataset loading script or trust_remote_code is required. The published files are UTF-8 JSONL with explicit configuration/split paths. The distribution contains JSONL files. Hugging Face manages its own Parquet conversion and Dataset Viewer processing.

Tools and coverage

The configuration is volatility3; the original file was named volatility.jsonl.

The 22 Hub configurations are all, these 19 tool views, sft, and chat. These are overlapping views, not 22 independent corpora. A Hub aggregate across configurations may count the same underlying examples more than once. The unique canonical total is 1,004.

Interpretation approach

v2 separates an observation from a scanner claim, a confirmed contextual issue, an incomplete result and a tool failure. An open port does not prove a vulnerability. A process-start event does not prove a command completed. A suggestive rule name does not establish a malware family.

The migration preserves reported versions and evidence, flags known ID/description conflicts, removes unsupported certainty from the old answers, and separates native tool severity from contextual risk. Public-looking network identifiers are pseudonymised in the working records; private and loopback addresses retain their network meaning. This is a targeted scrub, not a universal PII/secret guarantee.

The extension includes successful and failed runs, scoped negative results, false-positive candidates, missing context and paired examples where identical output has different implications under different supplied context. These examples cover different evidence and context requirements.

Record contract

Every canonical row uses the same schema. The important fields are:

assessment is one of finding_reported, observation, no_findings, inconclusive, or tool_error. These are not malicious/benign ground-truth labels. A reported finding can still be a false positive. risk_level="unknown" is deliberate when the supplied evidence cannot justify a deployment risk rating.

Canonical records use consistent field types: findings are lists of objects, actions and limitations are lists of strings, and evidence offsets are integers. Provenance identifies each record’s source and annotation method.

Training views and splits

sft contains string prompt / completion pairs. chat contains conversational prompt / completion message lists. Both include id, tool and group_id for filtering; those fields are not embedded in the model prompt. Completion text is the same structured JSON target in both views.

Canonical split sizes: 795 / 105 / 104. Deduplicated training-view split sizes: 795 / 105 / 104. Counts are train / validation / test.

Splits are assigned by groups before rendering training views. Explicit families, identical normalised excerpts and near-identical long excerpts are grouped within each tool. Context pairs stay together. Allocation aims roughly at 80/10/10 per tool, with group integrity taking priority. Identical model-input/target pairs are retained once in each training view while all source rows remain in the canonical corpus.

This reduces tested forms of leakage; it does not prove that every semantic overlap is absent. These are development holdouts, not an independently collected benchmark. Do not concatenate all with tool configs, or sft with chat, as if they were new examples. Use the existing split assignments when training or evaluating models.

Provenance and limitations

The original snapshot is pinned to commit 85ec39faa172a1bb86441f9a09f47a914b790058, as recorded in the archived source repository’s Git metadata. Canonical records retain source file names, row numbers, source hashes and annotation provenance. Source archives and curation tooling are not part of this data distribution.

Original excerpts were not independently authenticated as native captures. Many are abbreviated summaries. New records are explicitly model-assisted authored synthetic fixtures, not output from executed tools. Historical tool versions are preserved; authored fixtures use unspecified. Cuckoo 2.x remains historical coverage, not a recommendation to deploy that unmaintained line.

Official documentation informed corrections and interpretation boundaries; it does not certify these examples. CVE names and scanner IDs in historical excerpts remain observed claims, not newly certified advisory mappings. There is no independent expert-annotation study, incident ground truth or demonstrated model-performance improvement.

The corpus is small, English-only and uneven across tools. It is suitable for prototyping interpretation and structured outputs, not autonomous remediation or replacing professional incident review. Validate against current, independently collected native outputs before deployment.

Data quality

All 1,004 canonical records passed schema, evidence-offset, source-lineage and split-consistency checks. Local Hugging Face loading passed for all 22 configurations and 66 splits, including complete JSONL row equivalence, local Parquet round-trips and canonical streaming parity. These checks cover local loading and conversion; hosted Dataset Viewer processing and model performance are outside this validation scope.

Distribution contents

• data/canonical/: records grouped by tool and split.
• data/sft/: string prompt-completion pairs.
• data/chat/: conversational prompt-completion pairs.
• README.md, LICENSE, NOTICE, CITATION.cff and .gitattributes.

Install the datasets Python package to use the loading examples above. No repository-specific scripts are required.

Citation

@dataset{tegridydev_infosec_tool_output,
  author    = {{tegridydev}},
  title     = {Infosec Tool Output},
  publisher = {Hugging Face},
  doi       = {10.57967/hf/7654},
  url       = {https://huggingface.co/datasets/tegridydev/infosec-tool-output},
  version   = {2.0.0}
}

Include the exact commit used.

Report corrections through the dataset’s Community discussions, including the record ID and supporting evidence.