Software supply-chain tooling reads a small family of documents very carefully, and getting a realistic one to test against usually means scanning a real product. This category ships them outright: CycloneDX and SPDX SBOMs in JSON, XML, and tag-value form, describing the same fictional component tree so format converters can be diffed. Lockfiles cover the major ecosystems with pinned versions and integrity hashes. Provenance and attestation fixtures follow the in-toto and SLSA shapes, VEX and OSV documents carry advisory data for invented packages, and dependency-audit reports show the output a scanner would produce. Every package name, version, hash, and advisory ID is fabricated — realistic in shape, and traceable to nothing real.
Filter supply chain on Browse · 116 files · 5 subcategories
Cargo's tree output, which writes versions with a leading `v` and marks already-shown subtrees with `(*)` — close enough to npm's tree to fool a parser, different enough to break one. Every package, version, hash and licence is fictional — the tree describes nothing real.
The dependency graph in GraphML, with typed attribute keys for node version, licence and depth and for edge range — the interchange format graph databases and analysis tools import. Every package, version, hash and licence is fictional — the tree describes nothing real.
The dependency graph as Mermaid, for embedding in Markdown documentation — labelled edges carry the declared range and a classDef highlights the two diamond joins. Every package, version, hash and licence is fictional — the tree describes nothing real.
The cyclic plugin graph as DOT, with the three cycle edges highlighted. Graphviz renders it happily, which is exactly why a topological sort must be the thing that rejects it. Every package, version, hash and licence is fictional — the tree describes nothing real.
A dependency graph containing a genuine three-node cycle between fictional plugins — the fixture that makes a naive recursive walker hang or blow the stack, with the cycle path stated so the expected answer is unambiguous. Every package, version, hash and licence is fictional — the tree describes nothing real.
An explicit node/edge dependency graph with in-degree, out-degree and depth precomputed, plus a diamonds array naming the two shared nodes and their parents — the reference answer for any graph builder run against the SBOMs and lockfiles here. Every package, version, hash and licence is fictional — the tree describes nothing real.
The same diamond graph as Graphviz DOT, with edge labels carrying the declared semver range and the two diamond joins filled — renderable to SVG and diffable against the JSON twin. Every package, version, hash and licence is fictional — the tree describes nothing real.
`go mod graph` output: a flat edge list, one `parent@version child@version` pair per line with no indentation at all — the simplest graph serialisation in this category and the easiest to diff. Every package, version, hash and licence is fictional — the tree describes nothing real.
Gradle's dependency report, which marks repeat subtrees with `(*)` and explains the marker in a footer — so a parser has to resolve those references back to their first occurrence. Every package, version, hash and licence is fictional — the tree describes nothing real.
Maven's dependency tree, complete with the [INFO] log prefix that has to be stripped before the tree can be read and the five-part coordinate form Maven uses. Every package, version, hash and licence is fictional — the tree describes nothing real.
The nested tree `npm ls --json` prints, where a shared dependency is REPEATED under every parent rather than deduplicated — so counting objects gives a larger number than the graph has nodes. Every package, version, hash and licence is fictional — the tree describes nothing real.
The console tree with box-drawing characters and `deduped` markers on repeat visits — the output people paste into issues, and a genuine test of whether a scraper handles non-ASCII tree glyphs. Every package, version, hash and licence is fictional — the tree describes nothing real.
pipdeptree output, whose top level is an ARRAY rather than an object — the shape that breaks a loader written against npm's tree — with both installed and required versions on every edge. Every package, version, hash and licence is fictional — the tree describes nothing real.
Every edge in the fictional dependency graph as one row — parent, child, declared range, resolved version, depth and whether the edge is direct — the form a spreadsheet or SQL import can aggregate. Every package, version, hash and licence is fictional — the tree describes nothing real.
The written explanation of both diamonds in this category — the one that resolves to a single shared node and the peer conflict that forces a nested duplicate — with the four assertions a resolver test should make. Every package, version, hash and licence is fictional — the tree describes nothing real.
Bun's text lockfile, where each package is a positional array of descriptor, dependency map and integrity string rather than an object — a shape that breaks parsers assuming every lock entry is keyed. Every package, version, hash and licence is fictional — the tree describes nothing real.
The same fictional Rust tree pinned by a version 3 Cargo.lock, for testing that a reader keys on the declared version rather than assuming the newest format. Every package, version, hash and licence is fictional — the tree describes nothing real.
A Rust Cargo.lock in the version 4 format — TOML [[package]] tables with a registry source, a sha256-shaped checksum and a name-only dependencies array that resolves against the other tables. Every package, version, hash and licence is fictional — the tree describes nothing real.
An intentionally corrupt Cargo.lock: a valid version 4 lockfile cut off inside a [[package]] table so the final key/value pair is incomplete. Small on purpose. Every package, version, hash and licence is fictional — the tree describes nothing real.
A PHP composer.lock in JSON, pinning each fictional package by both a git reference and a dist zip shasum, with a content-hash binding it to composer.json. Every package, version, hash and licence is fictional — the tree describes nothing real.
A conda explicit lock: an @EXPLICIT marker followed by one fully-resolved URL per fictional package with an md5 fragment — no solver involved, which is exactly what makes it a lockfile. Every package, version, hash and licence is fictional — the tree describes nothing real.
A Bundler lockfile in its indentation-significant block format — specs nested under GEM, transitive requirements nested one level deeper, and the BUNDLED WITH version on its own indented line. Every package, version, hash and licence is fictional — the tree describes nothing real.
A Go module manifest with separate direct and // indirect require blocks for the fictional tree. Served with a .txt extension because go.mod has no registered media type; the content is verbatim go.mod syntax. Every package, version, hash and licence is fictional — the tree describes nothing real.
go.sum content: two h1: lines per fictional module — one for the module zip and one for its go.mod — which is the pairing a verifier must require. Served as .txt because go.sum has no registered media type. Every package, version, hash and licence is fictional — the tree describes nothing real.
A Gradle dependency lockfile: one `group:artifact:version=configurations` line per fictional module plus the `empty=` line that records configurations resolving to nothing. Every package, version, hash and licence is fictional — the tree describes nothing real.
Declared range against resolved version for every fictional package pinned by the lockfiles in this category — the table a review needs to see which pins drifted from their manifest ranges. Every package, version, hash and licence is fictional — the tree describes nothing real.
An Elixir mix.lock: a literal Elixir map whose values are tuples of atoms, strings and lists. It is neither JSON nor TOML, so a generic lockfile reader has to special-case it. Every package, version, hash and licence is fictional — the tree describes nothing real.
An npm lockfile where the fictional example-cache pins a peer of example-logger@2.9.0 while the rest of the tree resolves 3.4.1, forcing a nested node_modules duplicate — the shape a deduplication report must detect. Every package, version, hash and licence is fictional — the tree describes nothing real.
An intentionally invalid npm lockfile: two fictional packages carry sha512 integrity strings that cannot match their resolved tarballs — one derived from the wrong version, one a padded placeholder. Every package, version, hash and licence is fictional — the tree describes nothing real.
The original npm v1 lockfile layout — a nested dependencies object with requires maps and no packages section — still found in long-lived repositories and needed by any migration path. Every package, version, hash and licence is fictional — the tree describes nothing real.
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.
An npm lockfile in the modern v3 layout: a flat packages map keyed by node_modules path, with resolved tarball URLs and sha512 subresource integrity for nine fictional dependencies. Every package, version, hash and licence is fictional — the tree describes nothing real.
The shrinkwrap variant of an npm lockfile — identical in structure to package-lock.json but published inside the package tarball, so tooling that keys on the filename must handle both. Every package, version, hash and licence is fictional — the tree describes nothing real.
A NuGet lockfile keyed by target framework, distinguishing Direct from Transitive entries and recording a base64 contentHash for each fictional package. Every package, version, hash and licence is fictional — the tree describes nothing real.
A pip constraints file pinning the same nine fictional packages. Constraints bound a resolution without adding dependencies, so a tool that treats this like requirements.txt installs nine packages too many. Every package, version, hash and licence is fictional — the tree describes nothing real.
A hash-pinned pip requirements file with two sha256 hashes per fictional package (wheel and sdist) and line continuations — the form `--require-hashes` installs demand. Every package, version, hash and licence is fictional — the tree describes nothing real.
A pip-compile output where every pin carries a `# via` annotation naming the requirement that pulled it in — the only place the transitive graph survives in a pip workflow. Every package, version, hash and licence is fictional — the tree describes nothing real.
A Pipenv lockfile in JSON, with the _meta hash that ties it to its Pipfile, a named index source and nine fictional pinned packages in the default section. Every package, version, hash and licence is fictional — the tree describes nothing real.
A pnpm v9 lockfile with its three-section layout — importers for declared specifiers, packages for resolution metadata and snapshots for the resolved edges — pinning the same fictional tree. Every package, version, hash and licence is fictional — the tree describes nothing real.
A CocoaPods lockfile: a YAML-subset document listing pods with their nested requirements, a SPEC CHECKSUMS block of SHA-1 values and the CocoaPods version that produced it. Every package, version, hash and licence is fictional — the tree describes nothing real.
A Poetry lockfile: TOML array-of-tables entries with per-artifact sha256 hashes, a [package.dependencies] table per package and the content-hash that binds the lock to pyproject.toml. Every package, version, hash and licence is fictional — the tree describes nothing real.
A Dart pubspec.lock in YAML, labelling each fictional package as direct main or transitive and recording a sha256 in its description block along with the SDK constraint. Every package, version, hash and licence is fictional — the tree describes nothing real.
A uv lockfile in TOML, recording an sdist and a wheel per fictional package with inline tables carrying url, hash and byte size — a newer layout than poetry.lock and a useful contrast for parser tests. Every package, version, hash and licence is fictional — the tree describes nothing real.
A modern Yarn Berry lockfile: YAML-shaped with an __metadata header, npm: protocol resolutions and cache-key-prefixed checksums — deliberately different from the Classic file in the same family. Every package, version, hash and licence is fictional — the tree describes nothing real.
A Yarn 1 lockfile in its own line-oriented grammar — quoted descriptor headers, two-space indented fields, resolved URLs with a SHA-1 fragment — which looks like YAML but is not. Every package, version, hash and licence is fictional — the tree describes nothing real.
The policy an admission controller evaluates before an artifact is allowed through: required predicate types, an allowed-builder list, a minimum SLSA level, a transparency-log requirement and one dated exception. Every package, version, hash and licence is fictional — the tree describes nothing real.
An in-toto statement whose predicate is an entire SPDX 2.3 document — the nesting that makes attestation payloads large and that a size-limited verifier has to cope with. Every package, version, hash and licence is fictional — the tree describes nothing real.
The plain build record a CI job writes next to its artifacts — source ref and commit, builder identity, timings, toolchain versions and output digests — from which a provenance statement can be generated. Every package, version, hash and licence is fictional — the tree describes nothing real.
An ASCII-armored detached signature block of the shape that accompanies a SHA256SUMS file. It is a SAMPLE placeholder, not a valid OpenPGP signature — armor detectors will find it, verifiers must reject it. Signatures, key ids and certificates here are SAMPLE placeholders — the base64 decodes to the words 'SAMPLE SIGNATURE', so verification must fail. Nothing here is cryptographically valid and no key material is real.
An intentionally corrupt DSSE envelope: the JSON parses and the signature block looks complete, but the payload is truncated and contains characters outside the base64 alphabet. Signatures, key ids and certificates here are SAMPLE placeholders — the base64 decodes to the words 'SAMPLE SIGNATURE', so verification must fail. Nothing here is cryptographically valid and no key material is real.
A DSSE envelope whose base64 payload decodes to the SLSA v1 statement in this family — the wrapper attestation tooling actually transports. Signatures, key ids and certificates here are SAMPLE placeholders — the base64 decodes to the words 'SAMPLE SIGNATURE', so verification must fail. Nothing here is cryptographically valid and no key material is real.
The policy half of in-toto: a layout declaring which steps must run, which keys may sign them, and the MATCH/CREATE/DISALLOW artifact rules that bind each step's products to the next step's materials. Signatures, key ids and certificates here are SAMPLE placeholders — the base64 decodes to the words 'SAMPLE SIGNATURE', so verification must fail. Nothing here is cryptographically valid and no key material is real.
An in-toto link file recording one build step: the materials that went in, the products that came out and their sha256 digests, wrapped in the signed/signatures envelope in-toto uses. Signatures, key ids and certificates here are SAMPLE placeholders — the base64 decodes to the words 'SAMPLE SIGNATURE', so verification must fail. Nothing here is cryptographically valid and no key material is real.
The predecessor predicate: SLSA v0.2 uses invocation/materials/buildConfig where v1 uses buildDefinition/runDetails, so this file is the migration test for any verifier that must accept both. Every package, version, hash and licence is fictional — the tree describes nothing real.
An unsigned in-toto Statement carrying a SLSA v1 provenance predicate for a fictional release: build definition, external parameters, resolved dependencies with digests, and run details naming an invented builder. Every package, version, hash and licence is fictional — the tree describes nothing real.
The five checks a verifier must perform against the attestation fixtures in this category, and the exact result each one should produce — including the two that are meant to fail. Every package, version, hash and licence is fictional — the tree describes nothing real.
A transparency-log entry keyed by its own UUID at the top level — a shape that breaks parsers expecting a fixed root key — with a base64 body that decodes to a dsse record. Signatures, key ids and certificates here are SAMPLE placeholders — the base64 decodes to the words 'SAMPLE SIGNATURE', so verification must fail. Nothing here is cryptographically valid and no key material is real.
The oldest supply-chain artifact there is: a sha256sum manifest with the exact two-space separator the tool emits, listing a fictional release tarball and its nine dependency archives. Every package, version, hash and licence is fictional — the tree describes nothing real.
Two independent builds of the same fictional artifact on different architectures, both producing one digest — the evidence a rebuilder publishes, with SOURCE_DATE_EPOCH recorded as the thing that made it possible. Every package, version, hash and licence is fictional — the tree describes nothing real.
An attestation that binds an SBOM to an artifact digest rather than shipping the SBOM loose — the pattern keyless signing produces, complete with the empty keyid that identity-based signing leaves behind. Signatures, key ids and certificates here are SAMPLE placeholders — the base64 decodes to the words 'SAMPLE SIGNATURE', so verification must fail. Nothing here is cryptographically valid and no key material is real.
A Sigstore bundle in the shape verifiers read: a SAMPLE certificate, a transparency-log entry with an inclusion proof and checkpoint, and the DSSE envelope carrying the provenance. Signatures, key ids and certificates here are SAMPLE placeholders — the base64 decodes to the words 'SAMPLE SIGNATURE', so verification must fail. Nothing here is cryptographically valid and no key material is real.
How the nine fictional dependencies distribute across SLSA build levels, with the policy outcome for each band — the table that turns the VSA's dependencyLevels object into something reviewable. Every package, version, hash and licence is fictional — the tree describes nothing real.
A VSA — the attestation a verifier issues so downstream consumers do not have to re-verify the whole chain — recording a PASSED result against a fictional SLSA L3 policy and the level distribution of dependencies. Every package, version, hash and licence is fictional — the tree describes nothing real.
A CycloneDX 1.4 XML SBOM of the same fictional tree — the version most long-lived tooling emitted first, kept for backwards-compatibility tests against the 1.5 and 1.6 documents in this family. Every package, version, hash and licence is fictional — the tree describes nothing real.
A CycloneDX 1.5 SBOM of the same fictional tree, useful for spec-version migration tests: 1.5 introduced the object form of metadata.tools and this file uses it, while dropping the 1.6-only external references. Every package, version, hash and licence is fictional — the tree describes nothing real.
A complete CycloneDX 1.6 SBOM in JSON for a fictional application and its nine dependencies, with purls, SHA-256 hashes, supplier records, external references and an explicit dependency graph. Every package, version, hash and licence is fictional — the tree describes nothing real.
The same fictional CycloneDX 1.6 SBOM serialised as XML against the cyclonedx.org/schema/bom/1.6 namespace — the JSON twin of this file carries identical components and edges, so a converter can be diffed exactly. Every package, version, hash and licence is fictional — the tree describes nothing real.
The smallest CycloneDX document that is still valid: required metadata, one fictional component, and no dependencies array — for testing that a reader handles an SBOM with nothing optional present. Every package, version, hash and licence is fictional — the tree describes nothing real.
A CycloneDX SBOM whose root component is an OCI container image rather than an application, mixing a fictional operating-system package with language packages — the shape an image scanner emits. Every package, version, hash and licence is fictional — the tree describes nothing real.
A CycloneDX 1.6 SBOM whose dependencies array contains two diamonds: the fictional example-logger is reached through three parents and example-json-path through two, both resolving to a single node. Every package, version, hash and licence is fictional — the tree describes nothing real.
A CycloneDX 1.6 SBOM that carries its own vulnerabilities array — four clearly-marked SAMPLE advisories in the invented NOVUS-SAMPLE namespace, with CVSS v3.1 vectors, CWE classes and affected version ranges. Every package, version, hash and licence is fictional — the tree describes nothing real.
Every fictional component in this CycloneDX SBOM carries three hash algorithms and five external-reference types (distribution, vcs, issue-tracker, documentation, build-system). Every package, version, hash and licence is fictional — the tree describes nothing real.
An intentionally invalid CycloneDX SBOM: the JSON parses, but bomFormat is missing, one component has no name, and a dependency references a bom-ref that no component declares. Every package, version, hash and licence is fictional — the tree describes nothing real.
A CycloneDX SBOM that declares external services and composition completeness alongside components — the sections tools most often skip. Both services are fictional endpoints on the .example domain. Every package, version, hash and licence is fictional — the tree describes nothing real.
A CycloneDX SBOM that uses compound SPDX licence expressions — AND, OR, WITH and a LicenseRef — instead of plain licence ids, for testing compliance scanners that must evaluate the expression grammar. Every package, version, hash and licence is fictional — the tree describes nothing real.
A CycloneDX SBOM whose author names and properties contain accented Latin, CJK, right-to-left Hebrew, emoji and a deliberately long property value — for testing encoding handling and field-width assumptions. Every package, version, hash and licence is fictional — the tree describes nothing real.
An intentionally corrupt CycloneDX SBOM: a valid 1.6 document cut off mid-object so the JSON never closes. Small on purpose — it exists to check that a reader fails cleanly instead of half-loading a component list. Every package, version, hash and licence is fictional — the tree describes nothing real.
The same fictional component tree flattened to a spreadsheet-friendly CSV — name, version, licence, depth, purl and a SHA-256 prefix — for testing the export path SBOM tools offer alongside JSON. Every package, version, hash and licence is fictional — the tree describes nothing real.
The field-by-field map between the CycloneDX 1.6 and SPDX 2.3 documents in this category, plus the five invariants a correct conversion preserves and the three things it legitimately loses. Every package, version, hash and licence is fictional — the tree describes nothing real.
The same fictional tree as an SPDX 2.2 tag-value document — the version still produced by older toolchains — for upgrade and compatibility tests against the 2.3 twin in this family. Every package, version, hash and licence is fictional — the tree describes nothing real.
An SPDX 2.3 SBOM in JSON describing the same fictional tree as the CycloneDX documents in this category, with SPDXIDs, purl external references, SHA-256 checksums and DESCRIBES/DEPENDS_ON relationships. Every package, version, hash and licence is fictional — the tree describes nothing real.
The same SPDX 2.3 SBOM in the specification's plain-text tag-value form — the serialisation many licence-compliance tools still read first, and the exact twin of the JSON document in this family. Every package, version, hash and licence is fictional — the tree describes nothing real.
The SPDX 2.3 SBOM in its YAML serialisation — the third form the specification defines alongside JSON and tag-value, and the one most often hand-edited in a repository. Every package, version, hash and licence is fictional — the tree describes nothing real.
An SPDX 2.3 tag-value document with only the mandatory document header and a single fictional package — no relationships, no files — for testing that a parser accepts a document with every optional block absent. Every package, version, hash and licence is fictional — the tree describes nothing real.
An SPDX tag-value SBOM emphasising its relationship block: one DESCRIBES edge and ten DEPENDS_ON edges that form the same two diamonds as the CycloneDX graph fixture. Every package, version, hash and licence is fictional — the tree describes nothing real.
An SPDX 2.3 tag-value SBOM that descends to file level: two fictional build outputs with SHA-1 and SHA-256 checksums, per-file licence findings, and CONTAINS relationships back to their package. Every package, version, hash and licence is fictional — the tree describes nothing real.
An SPDX tag-value SBOM that declares a non-standard LicenseRef with its extracted text and uses it inside compound expressions — the case that breaks compliance tools which assume every licence is an SPDX id. Every package, version, hash and licence is fictional — the tree describes nothing real.
An SPDX 2.3 JSON SBOM that uses the snippet section to attribute a fictional vendored fragment inside a file to a different licence, with both byte-offset and line-number ranges. Every package, version, hash and licence is fictional — the tree describes nothing real.
An SPDX 3.0 SBOM in JSON-LD — the element-graph model that replaced the 2.x document layout — describing the same fictional tree with software_Package elements and typed Relationship nodes. Every package, version, hash and licence is fictional — the tree describes nothing real.
An SPDX tag-value SBOM whose document name is a fictional container image digest rather than an application version — the naming convention image scanners use, and the SPDX counterpart of the CycloneDX container fixture. Every package, version, hash and licence is fictional — the tree describes nothing real.
An intentionally corrupt SPDX tag-value document, cut off part-way through a tag name so the final line has no colon or value. Kept small on purpose. Every package, version, hash and licence is fictional — the tree describes nothing real.
A cargo-audit report that shows three findings while a fourth is on the ignore list, plus an unmaintained-crate warning — so a gate must decide whether warnings count against it. 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.
A CSAF 2.0 VEX advisory with the nested product tree that CSAF requires — vendor, product name, product version — and product_status buckets rather than a per-statement status field. 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.
A CycloneDX VEX document asserting a different analysis state for each of the four SAMPLE advisories, so a suppression pipeline can be tested against every branch at once. 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.
The shape a hosted dependency-alert API returns: alerts with lifecycle state, a nested advisory, a patched-version pointer and an explicitly null dismissed_reason on the alerts that were not dismissed. 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.
A Grype-shaped report of the same four SAMPLE advisories, with the match detail block that explains WHY each package matched — the field that makes false positives diagnosable. 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.
The console table a scanner prints, in fixed-width columns — the output people actually paste into tickets, and the one a log scraper has to parse without a delimiter. 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.
An npm audit v2 report keyed by package name, with the via chain, the effects list showing which fictional parents are impacted, and npm's own severity vocabulary where MEDIUM is spelled 'moderate'. 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.
The legacy npm audit shape — numeric advisory ids, a separate actions array and dependency paths written with '>' — which tools built for the v2 report silently read as zero findings. 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.
An OpenVEX document covering all four status values, with the justification and impact statement OpenVEX requires alongside not_affected and the action statement it requires alongside affected. 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.
An intentionally invalid OSV record: the JSON parses, but the required id is missing, modified is not an RFC 3339 timestamp, the SEMVER range has a fixed event with no introduced event, and severity.score is a number where the schema demands a CVSS vector string. 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.
A single OSV-schema advisory record for a fictional package, with a SEMVER range expressed as introduced/fixed events rather than as a version string — the part naive parsers get wrong. 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.
All four SAMPLE advisories as newline-delimited OSV records — the bulk shape an advisory database is loaded from, where each line must parse independently. 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.
An OSV-Scanner report that nests full OSV records under each affected package and adds the groups array that collapses aliases into one finding — the structure de-duplication depends on. 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.
A Dependency-Check-shaped JSON report, including the evidence-collection block that records how a package was identified and the confidence attached to that identification. 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.
The XML twin of the Dependency-Check report — the form most Maven and Jenkins integrations consume — carrying the same four SAMPLE findings inside a namespaced analysis element. 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.
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.
An intentionally corrupt scanner report: a valid Trivy-shaped JSON document cut off inside the first finding, for testing that a CI gate fails the build rather than reporting zero vulnerabilities. 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.
The same four SAMPLE findings expressed as SARIF 2.1.0 — the format code-scanning dashboards ingest — with a rules array, security-severity properties and physical locations. 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.
A severity-band table mapping CVSS ranges to remediation SLAs and gate actions, with the finding count each band has in this fixture set — so a policy engine can be tested end to end. 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.
A clean scan report — the case dashboards get wrong. Trivy omits the Vulnerabilities key entirely rather than emitting an empty array, so a reader that assumes the key exists throws on a passing build. 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.
A Trivy-shaped image report with three result blocks — OS packages, language packages and a Dockerfile misconfiguration — so a parser must handle a Results array whose members have different keys. 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.
A Trivy-shaped filesystem scan report with four SAMPLE findings against a fictional npm lockfile, one per severity band, each with a CVSS v3.1 vector, CWE class and fixed version. 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.
The four SAMPLE advisories flattened to one row each — the export a security review circulates, and the reference answer for any converter run against the Trivy, Grype or OSV reports here. 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.
A suppression policy that gives every waiver an owner, a reason and an expiry date — the fields that stop a suppression file becoming a permanent blindfold. All four entries are SAMPLE. 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.
The human-readable end of the pipeline: a triage report that records a decision and a reachability path for each of the four SAMPLE findings, matching the states asserted by the VEX documents here. 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.
CycloneDX in JSON and XML, and SPDX in both JSON and tag-value form — all describing the same fictional component tree, so format converters can be diffed against a known target.
Never. Components, versions, hashes, licences, and advisory identifiers are fabricated to be realistic in shape while referring to nothing that exists.
Yes — in-toto and SLSA-shaped attestations, VEX and OSV documents, dependency-audit reports, and lockfiles with pinned versions and integrity hashes.
We use Google Analytics and show ads via Adsterra. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.
