in-toto Attestation Framework

repository·main·Indexed 43 days ago

https://github.com/in-toto/attestation

A 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.

Tokens
37.8K
Snippets
94
Records
162
Agent score
56%

What's inside in-toto Attestation

  1. Overview of Java implementation for in-toto attestations

    main
    This package provides Java bindings for the in-toto Attestation Framework. The implementation is autogenerated from protobuf definitions located in the main in-toto/attestation repository. Use these bindings to work with in-toto attestations within Java-based environments.
  2. Overview of the in-toto Attestation Framework

    main
    The in-toto Attestation Framework provides a specification for generating verifiable claims about the software production process. It allows consumers to validate software origins and establish trust in the supply chain by using in-toto attestations. The framework consists of a core specification defining the attestation format and metadata, along with vetted 'attestation predicates' for common use cases.
  3. Supported language bindings for in-toto attestations

    main

    The project provides pre-generated language bindings for the protobuf definitions to ensure cross-language compatibility. Currently supported languages include:

    • Go
    • Python
    • Java

    Note: These bindings and the underlying protobuf definitions are considered unstable until the v1.1 tagged release. Use them at your own risk.

  4. What is an in-toto Attestation Bundle?

    main

    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.

    Security Considerations

    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:

    • Delete valid attestations.
    • Replay obsolete attestations.
    • Inject invalid or irrelevant attestations.

    To mitigate these risks, the specification aims to reduce such attack vectors, and predicates following the [monotonic principle] should be resilient to deletion attacks.

  5. What is the in-toto Attestation Framework?

    main

    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:

    1. Standardized Format: A common format for attestations that ensures metadata is structured and verifiable.
    2. Pre-defined Predicates: A set of standard metadata types (predicates) used to communicate authenticated information across software supply chains.

    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.

  6. What is the Software Supply Chain Attribute Integrity (SCAI) predicate?

    main

    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.

  7. What is a Simple Verification Result (SVR) predicate?

    main

    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.

  8. What is the Reference predicate type?

    main

    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.

    Use Cases

    • External SBOMs: Provide a link to an SBOM (e.g., SPDX) for an artifact without transmitting the entire file in-band. Consumers like GUAC can then retrieve the SBOM and verify its digest.
    • Policy Evidence: Provide evidence for policies such as "deny unless a reference to an SBOM is provided".

    Prerequisites

  9. What is an Attestation Bundle?

    main

    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.

  10. Available attestation predicates with protobuf definitions

    main

    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:

    • in-toto Link: A generic predicate for recording a software supply chain step.
    • SLSA Provenance: Describes how an artifact or set of artifacts was produced.
    • SLSA Verification Summary: An SLSA verification decision regarding a software artifact.
    • SCAI: Evidence-based assertions about software artifact and supply chain attributes.
    • VULNS: Stores results from scanners when detecting vulnerabilities in a software artifact.
    • Test Result: Expresses the result of a test run within the software supply chain.
  11. Check version compatibility for Java in-toto bindings

    main
    The Java library is currently in a pre-1.0 versioning state. This indicates that the protobuf definitions and the available predicate types are still being stabilized. When integrating this library, be aware that breaking changes in the protobuf schema or predicate definitions may occur as the framework matures.
  12. Data structure and format of Attestation Bundles

    main

    Attestation Bundles use the JSON Lines format to store multiple attestations.

    Rules for Consumers:

    • Each line SHOULD be an [Envelope].
    • Consumers MUST ignore unrecognized lines.
    • Consumers MUST ignore attestations with unrecognized keys, types, subjects, or predicates.
    • Processing of a bundle MUST NOT depend on the order of the attestations.

    Characteristics:

    • Each attestation within a bundle MAY have a different signing key, _type, subject, and/or predicateType.