in-toto Layout (Supply-Chain Policy)
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.
{
"signatures": [
{
"keyid": "SAMPLE-KEY-8508979fe4f58126",
"sig": "U0FNUExFIFNJR05BVFVSRSAtIE5PVCBBIFJFQUwgU0lHTkFUVVJFLCBWRVJJRklDQVRJT04gTVVTVCBGQUlMIFtsYXlvdXRd"
}
],
"signed": {
"_type": "layout",
"expires": "2027-01-01T00:00:00Z",
"readme": "SAMPLE in-toto layout for a fictional release pipeline. SAMPLE — fictional supply-chain data. Every package, registry, version, hash, licence, advisory identifier and signature in this document is invented.",
"keys": {
"SAMPLE-KEY-dcdf73735832f5ac": {
"keytype": "ed25519",
"scheme": "ed25519",
"keyid_hash_algorithms": [
"sha256"
],
"keyval": {
"public": "SAMPLE-PUBLIC-KEY-NOT-REAL-343db8bcaf823e81f9e12f330cb4ae81"
}
}
},
"steps": [
{
"_name": "checkout",
"threshold": 1,
"expected_materials": [],
"expected_products": [
[
"CREATE",
"src/*"
],
[
"DISALLOW",
"*"
]
],
"pubkeys": [
"SAMPLE-KEY-dcdf73735832f5ac"
],
"expected_command": [
"git",
"clone"
]
},
{
"_name": "build",
"threshold": 1,
"expected_materials": [Specifications
- Seed
- 51200
- Sample Only
- true
- Format
- in-toto layout
- Steps
- 2
- Inspections
- 1
- Artifact Rules
- 7
- Expires
- 2027-01-01
- Line Endings
- LF
Testing contract
Expected to pass- Scenario
- Evaluate in-toto artifact rules against a set of link files.
- Expected result
- The build step's MATCH rule resolves against the checkout step's products, and the trailing DISALLOW rejects any file not explicitly allowed.
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
“in-toto Layout (Supply-Chain Policy)” is a deterministic Novus Examples fixture for JSON parsing, Config testing, Schema validation. Flat, deeply nested, JSON Lines, and intentionally invalid JSON for testing parsers and error handling.
Documented properties for this file: seed 51200 · LF · in-toto layout. 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("in-toto-layout.json") as f:
data = json.load(f)
print(type(data), len(data))Related files
- jsonHelm values.schema.jsonThe values.schema.json that validates the paired Helm values files: a 2020-12 JSON Schema with $defs, $ref, enums, quantity patterns, and additionalProperties: false on nested objects. Validates the defaults and rejects a values file with an unknown image key.
- yamlKubernetes CustomResourceDefinition with OpenAPI SchemaA CustomResourceDefinition carrying a deep structural OpenAPI v3 schema with a regex pattern, an enum, a default, and array minItems. Useful both as a CRD fixture and as a nested JSON-Schema-in-YAML validation target.
- jsonTerraform Plan JSONA Terraform plan JSON document with create, update and delete changes, after_unknown markers, sensitivity annotations, and a configuration section. This is the artifact policy engines read before anything runs, which is why it sits with pipeline definitions rather than with run reports.
- jsonRekor Transparency-Log EntryA 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.
- jsonSBOM Attestation Envelope (cosign Shape)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.
- jsonSigstore Bundle (v0.3 Shape)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.
Generated by generation/supply_chain.py. Free for any use, no attribution required — license.