Overview of Java implementation for in-toto attestations
mainin-toto/attestation repository. Use these bindings to work with in-toto attestations within Java-based environments.repository·main·Indexed 43 days ago
https://github.com/in-toto/attestationA specification and set of implementations for creating verifiable claims about software supply chain processes. It provides a standardized format and pre-defined predicates (such as SLSA Provenance, CycloneDX, and VULNS) to bind subjects to authenticated metadata. The framework includes protobuf definitions and language bindings for Go, Python, Rust, and Java to enable automated policy engines to validate the provenance and integrity of software artifacts.
in-toto/attestation repository. Use these bindings to work with in-toto attestations within Java-based environments.The project provides pre-generated language bindings for the protobuf definitions to ensure cross-language compatibility. Currently supported languages include:
Note: These bindings and the underlying protobuf definitions are considered unstable until the v1.1 tagged release. Use them at your own risk.
An Attestation Bundle is a collection of multiple attestations stored in a single file using JSON Lines format. This allows grouping attestations from different stages of the software supply chain (e.g., Provenance, Code Review, Test Results, Vulnerability Scans) so that consumers can make decisions based on the complete set of available information.
The Bundle itself is not authenticated as a whole. Each individual attestation within the bundle must be authenticated using signature formats like [DSSE]. Because the bundle lacks a top-level signature, an attacker might be able to:
To mitigate these risks, the specification aims to reduce such attack vectors, and predicates following the [monotonic principle] should be resilient to deletion attacks.
The in-toto Attestation Framework is a standard for binding subjects (the artifacts being described) to arbitrary authenticated metadata. It achieves this through two primary mechanisms:
The framework is designed to be consumed by automated policy engines (like in-toto-verify or Binary Authorization) to make verifiable claims about how software is produced and validated.
The Software Supply Chain Attribute Integrity (SCAI) predicate is a data format used to capture functional attributes and integrity information about software artifacts and their supply chain. Unlike standard supply chain formats, SCAI is designed to capture security functionality, behavior, and granular properties of the software stack—ranging from code-level features (e.g., compiler instrumentation) to hardware-level properties (e.g., secure boot enablement).
SCAI is intended to be used within an existing in-toto attestation framework, ideally as part of an [attestation Bundle]. It is implemented by tools like builders, CI/CD pipelines, or analysis tools to provide more granular evidence about the artifacts they produce.
A Simple Verification Result (SVR) is an in-toto attestation predicate used to communicate that an artifact has been evaluated against one or more policies. It provides a concise summary of verified properties at a specific point in time (timeCreated).
This allows consumers to establish trust in a verifier's decision without needing access to the full underlying policies or the complex provenance data used to reach that decision. Verifiers can optionally generate additional provenance attestations to support the SVR if reproducibility is required.
The Reference predicate type (https://in-toto.io/attestation/reference/v0.1) is used to point to and sign metadata that is not provided in-band. Instead of including large files like an SBOM directly in the attestation, you provide a reference to where that metadata can be retrieved and its cryptographic digest.
An attestation bundle is a collection of multiple attestations stored in a single file. This allows grouping attestations from different points in the software supply chain (e.g., Provenance, Code Review, Test Results, Vulnerability Scans) so that users can make decisions based on the complete set of available information.
Security Note: The bundle itself is not authenticated as a single unit. Instead, each individual attestation within the bundle is authenticated using DSSE. Because of this, an attacker might be able to delete an attestation from a bundle without being detected. Predicates following the monotonic principle are resilient to this behavior.
The framework provides protobuf definitions for several specific attestation predicates. Use these to ensure your data format matches the in-toto Attestation Framework spec across different language implementations:
Attestation Bundles use the JSON Lines format to store multiple attestations.
_type, subject, and/or predicateType.