pip-audit Report (JSON)
A pip-audit report for the fictional Python packages. It deliberately carries no severity field — pip-audit does not assign one — which is the case a severity gate must handle without defaulting to critical. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.
{
"dependencies": [
{
"name": "example-logger",
"version": "3.4.1",
"vulns": [
{
"id": "NOVUS-SAMPLE-2026-0001",
"fix_versions": [
"3.5.0"
],
"aliases": [
"SAMPLE-CVE-2026-0001"
],
"description": "SAMPLE advisory: fabricated improper-input-validation issue in a fictional logging library."
}
]
},
{
"name": "example-cache",
"version": "0.9.2",
"vulns": [
{
"id": "NOVUS-SAMPLE-2026-0002",
"fix_versions": [
"0.9.5"
],
"aliases": [
"SAMPLE-CVE-2026-0002"
],
"description": "SAMPLE advisory: fabricated unsafe-deserialisation issue in a fictional cache library."
}
]
},
{
"name": "example-yaml-lite",
"version": "1.1.7",
"vulns": [
{
"id": "NOVUS-SAMPLE-2026-0003",
"fix_versions": [
"1.2.0"
],
"aliases": [
"SAMPLE-CVE-2026-0003"
],
"description": "SAMPLE advisory: fabricated uncontrolled-resource-consumption issue in a fictional parser."
}
]
},Specifications
- Seed
- 51200
- Sample Only
- true
- Tool
- pip-audit-shaped
- Dependencies
- 4
- Vulns Per Dependency
- 1
- Severity Field
- absent
- Line Endings
- LF
Testing contract
Expected to pass- Scenario
- Apply a severity threshold to a report format that has no severity field.
- Expected result
- Gate either resolves severity from the advisory id via another source or reports 'unknown' — it must not silently treat all four findings as critical.
What is a .json file?
JSON (JavaScript Object Notation) is a lightweight, text-based data-interchange format representing objects, arrays, strings, numbers, booleans, and null. It is language-independent, human-readable, and the dominant format for web APIs and configuration. It requires a single well-formed root value.
How to use this file
Use an example JSON file to test parsers and serializers, schema validation, Unicode and number-precision handling, and API request or response processing.
How to use this file for testing
“pip-audit Report (JSON)” is a deterministic Novus Examples fixture for JSON parsing, Conversion testing, Error handling. Flat, deeply nested, JSON Lines, and intentionally invalid JSON for testing parsers and error handling.
Documented properties for this file: seed 51200 · LF. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.
SBOM, lockfile, provenance, and advisory fixtures describe the same fabricated component tree across formats, so a converter or scanner can be diffed against a known answer. Every package name, version, hash, and advisory ID is invented — never treat a finding here as real.
Feed the file to your parser and assert it handles the documented quirks — quoted delimiters, embedded newlines, ragged rows, or invalid syntax; the valid↔invalid distinction is labelled in the title.
Code examples
import json
with open("pip-audit-report.json") as f:
data = json.load(f)
print(type(data), len(data))Related files
- jsonnpm package-lock.json (lockfileVersion 2, Dual Layout)The transitional npm v2 lockfile, which carries BOTH the v3 packages map and the legacy nested dependencies tree describing the same fictional install — the case where a parser must not double-count. Every package, version, hash and licence is fictional — the tree describes nothing real.
- jsonCucumber JSON — Failing Step with Stack TraceOne step of one scenario fails with an assertion message and a stack frame; every other step passes. In cucumber.json a scenario has no status of its own — it is failed if any of its steps is — so this file catches reporters that look for a scenario-level field that does not exist.
- jsonCucumber JSON — Undefined, Pending and Skipped StepsThe three non-failure statuses BDD runners produce and dashboards routinely collapse into "failed": undefined (no step definition matched), pending (explicitly unimplemented) and skipped (never attempted). Whether the run is red depends on the runner's strict setting, which is exactly the decision this file forces.
- ndjsonCucumber Messages — Failing Run (NDJSON)The messages twin of the failing run: one testStepFinished carries status FAILED with both a human message and a structured exception object, and testRunFinished reports success false. Comparing it with the passing stream in the other group isolates exactly which envelopes a failure changes.
- jsonJest — JSON ResultsJest's --json output, where skipped tests are called pending and the totals appear as flat numTotal/numPassed/numFailed fields alongside per-file assertionResults. Timestamps are epoch milliseconds rather than ISO strings, which is the field most converters mis-handle. Reports the same canonical run as the JUnit dialect files: 12 tests, 9 passed, 1 assertion failure, 1 error and 1 skip.
- jsonMocha — JSON Reporter OutputMocha's JSON reporter, which lists every test in a tests array and then repeats each one in passes, failures or pending. Summing all four arrays counts the run twice — this file exists so that bug shows up on a 12-test suite instead of in production. Reports the same canonical run as the JUnit dialect files: 12 tests, 9 passed, 1 assertion failure, 1 error and 1 skip.
Generated by generation/supply_chain.py. Free for any use, no attribution required — license.