ML provenance is not just software provenance with models added. The interesting problem is that datasets, code, configurations, weights, and execution environments are
coupled through transformations, while models can subsequently be fine-tuned or otherwise adapted. Atlas treats lineage as an authenticated chain of transformations rather
than simply an inventory of artifacts.
The individual mechanisms presented in the paper include Intel TDX, remote attestation, cryptographic measurements, C2PA manifests, and Merkle-tree transparency logs. What
I found interesting is their composition. An attestation client monitors PyTorch/Kubeflow execution, measures inputs and outputs, records runtime/configuration metadata,
and signs a transformation attestation containing hashes of precursor attestations. The transparency service makes these records tamper-evident; verification reconstructs
and validates the lineage.
More broadly, Atlas suggests that ML supply-chain integrity may require authenticating the transformation history, not merely signing the resulting model.
This isn’t just about reproducibility: it touches auditor trust, SBOM
completeness, and the future of supply chain assurance. Worth a skim if you
care about provable software integrity.
Automatic Bill of Materials (2023)
embeds source file hashes into binaries with compressed Bloom filters, making
it easy to check whether known-vulnerable code is present.
Here’s a modern classic:
Reflections on Trusting Distributed Trust
(2022) proposes an auditable deployment model using trusted execution
environments and append-only logs to solve distributed trust bootstrapping
without expensive cross-organization coordination.
I found it an approachable, practical read that is relevant to supply chain
integrity and multiparty, privacy-preserving computation.
Worth a read if you touch distributed systems and transparency in your work.