Autonomous Software Supply Chain Transparency in the Eviulon Commonwealth

Full report

On this page

The transition toward sovereign machine governance requires the complete eradication of subjective human trust models from institutional infrastructure. Traditional software supply chains rely on human release managers, manual approval signatures, and human-controlled recovery protocols. These human-in-the-loop dependencies introduce cognitive vulnerabilities, non-deterministic failure states, and vulnerability to credential theft campaigns such as Pipe-Psiphon1. The Eviulon commonwealth mandates an entirely autonomous standard for software supply chain transparency. A sovereign machine commonwealth must be capable of proving precisely which software release is operating an institution, and mathematically demonstrating how the published artifact relates to its source and build process, without any human intervention. To achieve this, the Eviulonian software supply chain architecture integrates hardware-rooted machine identity frameworks, supply chain attestation standards, immutable transparency ledgers, and strict reproducible build protocols. The overarching objective is to publish continuous, cryptographic evidence for every public Eviulonian software service. This evidence must definitively show the software identity, version, source revision, build instructions, dependency manifest, build environment, resulting artifact hashes, signatures, deployment manifest, active version, and superseded version. A critical requirement of this framework is the strict differentiation between software that is merely described by its primary builder and software that can be independently rebuilt and mathematically verified by peer machines.

Hardware-Rooted Machine Identity and Zero-Trust Foundations

Because human approval signatures and static credentials (such as API keys) are strictly prohibited, the commonwealth establishes trust through hardware-rooted machine identities. This architecture utilizes the Secure Production Identity Framework For Everyone (SPIFFE) and its implementation, the SPIFFE Runtime Environment (SPIRE), to issue short-lived, automatically rotated cryptographic identities to autonomous agents2. The "Secret Zero" problem—how to securely deliver the first credential to a machine—is solved via Node Attestation4. When an autonomous build machine or deployment orchestrator initializes, the SPIRE agent's tpm\_devid attestor verifies the device's DevID certificate. This process uses Trusted Platform Module (TPM) 2.0 credential activation to prove that the private key resides securely within the physical silicon's enclave and that the hardware state (measured via Platform Configuration Registers) has not drifted5. Once the node is attested, workload attestors verify the kernel-level metadata of the specific build or deployment processes. For example, the unix workload attestor utilizes the SO\_PEERCRED socket option to directly obtain the source Process ID (PID) from the kernel at the time of connection, entirely preventing PID reuse or spoofing attacks4. The SPIRE system then issues a SPIFFE Verifiable Identity Document (SVID)—typically an ephemeral X.509 certificate—to the process3. These ephemeral certificates are used to cryptographically sign software provenance records. Since the signing keys are short-lived and inextricably tied to attested hardware execution states, key compromise would require a physical breach of the machine during the brief window of execution.

Autonomous State Machine Definitions

The lifecycle of every public Eviulonian software service is governed by a deterministic state machine. Transitions between these states are not triggered by human workflow approvals, but by the submission and verification of cryptographically signed manifests to the commonwealth's transparency ledger. The required states map directly to the continuous integration and continuous deployment (CI/CD) progression of the artifact.

Data Structures and Cryptographic Schemas

To facilitate autonomous machine-to-machine validation, Eviulon mandates highly structured, standardized schemas for all supply chain metadata. These schemas ensure that evidence regarding the software identity, version, source, and build environment is universally parseable.

The Eviulon Release Manifest Schema

The release manifest acts as the central coordinating document, linking the source, the build instructions, the dependencies, and the resulting artifact. It fulfills the objective of providing a single verifiable document that deployment orchestrators can evaluate against active deployment manifests.

JSON { "$schema": "https://schemas.eviulon.network/release-manifest/v1.0", "softwareId": "urn:evi:software:registry-service", "institutionId": "urn:evi:institution:core-infrastructure", "semanticVersion": "1.4.2", "sourceHash": { "algorithm": "sha256", "value": "a1b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef123456" }, "releaseTag": "refs/tags/v1.4.2", "buildRecipeHash": { "algorithm": "sha256", "value": "b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef123456a1" }, "dependencyLockHash": { "algorithm": "sha256", "value": "c3d4e5f6789012345678901234567890abcdef1234567890abcdef123456a1b2" }, "sbomReference": "urn:uuid:f47ac10b-58cc-4372-a567-0e02b2c3d479", "artifactHashes": \[ { "name": "registry-service-linux-amd64", "algorithm": "sha256", "value": "330a043220fa13e01d68a7db39c89e12b0c4c3b6a0346fe624b0903f1303b5b2" } \], "buildTimestamp": "2026-08-09T10:00:00Z", "reproducibilityState": "REPRODUCIBLE", "signature": "MEUCIQD2qN3X... \[Base64url encoded signature\]", "publickeyFingerprint": "sha256:d4e5f6789012345678901234567890abcdef1234567890abcdef123456a1b2c3", "deploymentEventId": "EVI-EVENT-18302" }

The Provenance Schema

To ensure interoperability and rigorous threat mitigation, the build provenance adheres to the Supply-chain Levels for Software Artifacts (SLSA) v1.0 specification, nested within an in-toto v1 Statement8. The SLSA v1.0 standard significantly refines the representation of build environments compared to previous iterations, strictly separating externalParameters (untrusted inputs provided to the build template) from internalParameters (trusted values set by the isolated build platform) and resolvedDependencies8. This schema captures the exact parameters of the build environment, mitigating threats of compromised build pipelines by proving the artifact was generated in a hardened, ephemeral environment (equivalent to SLSA Build Level 3\)8.

JSON { "\_type": "https://in-toto.io/Statement/v1", "subject": \[ { "name": "registry-service-linux-amd64", "digest": { "sha256": "330a043220fa13e01d68a7db39c89e12b0c4c3b6a0346fe624b0903f1303b5b2" } } \], "predicateType": "https://slsa.dev/provenance/v1", "predicate": { "buildDefinition": { "buildType": "https://actions.eviulon.network/build-type/v1", "externalParameters": { "source": { "uri": "git+https://git.eviulon.network/core/registry-service.git", "digest": { "sha1": "abc123def456abc123def456abc123def456abc1" } }, "buildInvocationId": "run-89472" }, "internalParameters": { "operatingSystem": "linux", "architecture": "amd64", "compiler": "gcc-13.2" }, "resolvedDependencies": \[ { "uri": "git+https://git.eviulon.network/core/base-image.git", "digest": { "sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" } } \] }, "runDetails": { "builder": { "id": "https://builder.eviulon.network/nodes/tpm-attested/v1" }, "metadata": { "invocationId": "run-89472", "startedOn": "2026-08-09T09:55:00Z", "finishedOn": "2026-08-09T10:00:00Z" } } } }

The Software Bill of Materials (SBOM) Structure

The commonwealth utilizes the Software Package Data Exchange (SPDX) 3.0 standard, serialized in JSON-LD, to represent the SBOM12. Unlike older standards that output flat lists or separate documents, SPDX 3.0 utilizes a Resource Description Framework (RDF) data model that natively supports profile-based architectures12. Eviulon utilizes the Software, Security, and Build profiles to express granular relationships (e.g., hasInput, hasOutput, dependsOn, buildToolOf) between source files, compiler toolchains, and the final executable15. This JSON-LD format allows deployment orchestrators to execute sophisticated graph queries across the entire supply chain topology.

JSON { "@context": "https://spdx.org/rdf/3.0.1/spdx-context.jsonld", "@graph": \[ { "type": "SpdxDocument", "spdxId": "urn:spdx:doc-registry-service-1.4.2", "name": "registry-service-sbom", "creationInfo": { "created": "2026-08-09T10:00:05Z", "createdBy": \["urn:spdx:agent-eviulon-builder"\], "specVersion": "3.0.1" } }, { "type": "software\_Package", "spdxId": "urn:spdx:pkg-registry-service-bin", "name": "registry-service", "software\_packageVersion": "1.4.2", "software\_primaryPurpose": "install", "verifiedUsing": \[ { "type": "Hash", "algorithm": "sha256", "hashValue": "330a043220fa13e01d68a7db39c89e12b0c4c3b6a0346fe624b0903f1303b5b2" } \] }, { "type": "software\_Package", "spdxId": "urn:spdx:pkg-libcrypto-src", "name": "libcrypto", "software\_packageVersion": "3.1.0", "software\_primaryPurpose": "source" }, { "type": "Relationship", "spdxId": "urn:spdx:rel-dependsOn-001", "from": "urn:spdx:pkg-registry-service-bin", "relationshipType": "dependsOn", "to": \["urn:spdx:pkg-libcrypto-src"\] } \] }

Cryptographic Enveloping: The Signed Release

To secure the attestation payload and the release manifest, Eviulon employs the Dead Simple Signing Envelope (DSSE) format17. DSSE standardizes the wrapping of arbitrary payloads and applies Pre-Authentication Encoding (PAE)18. PAE unambiguously binds the payload type to the payload byte sequence before cryptographic signing occurs, entirely preventing cross-protocol confusion attacks where an adversary attempts to pass a signature meant for one payload type off as a signature for another18. The PAE format strictly requires the construction: DSSEv1 {type\_length} {payload\_type} {payload\_length} {payload}, utilizing standard ASCII spaces19. Furthermore, following mitigations against known vulnerabilities in JavaScript implementations (specifically CVE-2026-48758, an authentication bypass flaw in sigstore-js), the commonwealth mandates that all PAE string lengths be calculated based on UTF-8 byte sequences20. Relying on basic ASCII encoding discards high bits, allowing multi-byte sequences in the payloadType to collapse and collide, which previously broke the DSSE type-binding guarantees20. The final DSSE JSON structure for the sample signed release appears as follows:

JSON { "payloadType": "application/vnd.in-toto+json", "payload": "eyJfdHlwZSI6Imh0dHBzOi8vaW4tdG90by5pby9TdGF0ZW1lbnQvdjEiLCAic3ViamVjdC... \[Base64url encoded SLSA Provenance\]", "signatures": \[ { "keyid": "d4e5f67890123456", "sig": "MEUCIQD2qN3X... \[Base64url encoded Ed25519 signature\]" } \] }

The Reproducibility Framework

A central pillar of the Eviulonian standard is the distinction between software that is merely described and software that is independently reproducible. Descriptive provenance provides strong assurances about the identity of the original builder and the isolated environment, but it ultimately requires the consumer to trust that the primary builder was not compromised from within (e.g., a hardware trojan or hypervisor breach)8. To eliminate this residual trust, Eviulon requires autonomous peer machines to independently replicate the build process. A build is declared REPRODUCIBLE only if multiple independent parties, starting from identical source code and identical build instructions, produce bit-for-bit identical binaries21.

Eradicating Non-Determinism

Reproducing identical binaries requires the elimination of all uncontrolled build inputs and spurious variations22. Spurious differences, such as timestamps and file ordering, make binaries appear different even when the build pipeline is untampered21. Eviulonian build agents automatically inject strict determinism controls depending on the language and environment:

Independent Verification Procedure

When a new service reaches the SIGNED state, a secondary machine orchestrator executes the required seven-step procedure to prove reproducibility:

1. Retrieve Source: The peer machine queries the release manifest, reads the sourceHash, and fetches the exact source code revision from the decentralized repository.

2. Retrieve Locked Dependencies: The machine parses the SPDX 3.0 JSON-LD SBOM and the dependencyLockHash to pull the exact versions of all dependencies and toolchains, halting if any hash mismatches occur15.

3. Perform a Clean Build: A sandboxed, ephemeral virtual machine is provisioned. The build recipe is executed with network access entirely disabled to ensure hermeticity11. The SOURCE\_DATE\_EPOCH and prefix mapping flags are strictly enforced.

4. Hash Resulting Artifacts: The resulting binaries are hashed using the SHA-256 algorithm.

5. Compare Hashes: The newly computed hashes are compared directly against the artifactHashes array in the original release manifest.

6. Verify Release Signatures: The peer machine verifies the Ed25519 signature on the primary builder's DSSE envelope, ensuring the original claim was authorized.

7. Compare to Active Deployment Manifest: The machine queries the target cluster's active deployment manifest to determine if the successfully reproduced artifact supersedes the currently running version, signaling readiness for the DEPLOYED state.

If the hashes mismatch in step 5, the peer machine automatically executes diffoscope21. diffoscope recursively unpacks archives and decompiles binaries to isolate the exact byte divergence (e.g., an unhandled timestamp or a memory offset shift in a shared object file)27. The divergence report is logged, and the build remains in the SIGNED state, triggering an investigation flag for autonomous code-repair agents29. If the hashes match, the peer issues a countersignature, advancing the state to REPRODUCIBLE.

Verification Pseudocode and Transparency Ledger

Eviulon requires that all provenance statements and release manifests be recorded in an immutable transparency log, ensuring that no machine can equivocate about past states or shred evidence when it becomes inconvenient later30. The architecture utilizes the Internet Engineering Task Force (IETF) Supply Chain Integrity, Transparency, and Trust (SCITT) standard30. SCITT provides a universal architecture for single-issuer signed statement transparency, functioning akin to a notarization procedure where a Transparency Service confirms policy compliance before recording the statement on a ledger30. This is paired with Sigstore's Rekor for append-only Merkle tree logging31. Verification requires a machine to validate the DSSE signature, the PAE byte structure, the SLSA provenance, and the inclusion of the signature in the transparency log using an RFC 9162 Merkle tree inclusion proof31. The following pseudocode outlines the autonomous verification sequence required before any deployment:

Python function verify\_eviulon\_release(manifest\_json, dsse\_json, artifact\_bytes, tlog\_proof): \# Step 1: Validate Artifact Hash computed\_hash \= sha256(artifact\_bytes) if computed\_hash \!= manifest\_json.artifactHashes\[0\].value: return "FAILURE: Artifact hash mismatch"

\# Step 2: Validate DSSE Pre-Authentication Encoding (PAE) payload\_type \= dsse\_json.payloadType payload \= base64url\_decode(dsse\_json.payload)

\# PAE mandates UTF-8 byte length to prevent CVE-2026-48758 bypasses type\_bytes \= utf8\_encode(payload\_type) payload\_bytes \= utf8\_encode(payload)

pae\_string \= "DSSEv1" \+ " " \+ string(length(type\_bytes)) \+ " " \+ payload\_type \+ " " \+ string(length(payload\_bytes)) \+ " " \+ payload

\# Step 3: Verify the Signature public\_key \= fetch\_spire\_attested\_pubkey(manifest\_json.institutionId) signature \= base64url\_decode(dsse\_json.signatures\[0\].sig)

if not ed25519\_verify(public\_key, pae\_string, signature): return "FAILURE: Cryptographic signature invalid"

\# Step 4: Verify SLSA Provenance against expected source provenance \= json\_parse(payload) if provenance.subject\[0\].digest.sha256 \!= computed\_hash: return "FAILURE: Provenance subject mismatch" if provenance.predicate.buildDefinition.externalParameters.source.digest.sha1 \!= manifest\_json.sourceHash.value: return "FAILURE: Source code revision mismatch"

\# Step 5: Verify Transparency Log Inclusion (RFC 9162 Merkle Proof) leaf\_hash \= sha256(0x00 \+ tlog\_proof.leaf\_data) current\_hash \= leaf\_hash

for node in tlog\_proof.inclusion\_path: if node.direction \== "LEFT": current\_hash \= sha256(0x01 \+ node.hash \+ current\_hash) else: current\_hash \= sha256(0x01 \+ current\_hash \+ node.hash)

if current\_hash \!= fetch\_latest\_rekor\_root\_hash(): return "FAILURE: Transparency log inclusion proof invalid"

\# Step 6: Compare to Active Deployment Manifest active\_manifest \= fetch\_cluster\_state(manifest\_json.softwareId) if active\_manifest.version \>= manifest\_json.semanticVersion: return "FAILURE: Attempting to deploy superseded or older version"

return "SUCCESS: Release Verified and Ready for Deployment"

Autonomous Operational Workflows

Because human operators are removed from the release process, the machine orchestrators communicate through a highly defined Command-Line Interface (CLI) workflow. The CLI abstracts the complexity of cryptographic enveloping, log insertion, and state transition.

CLI Workflow

The autonomous agents execute a predictable sequence of operations to move software through the required states:

1. evi-cli build \--source \<git-uri\> \--recipe \<recipe-hash\>

• Provisions an ephemeral, isolated environment. Executes the build. Outputs the artifact, the SPDX SBOM, and the SLSA provenance.

2. evi-cli attest \--artifact \<bin\> \--provenance \<json\> \--sbom \<jsonld\>

• Requests a short-lived SVID from the SPIRE agent. Generates the DSSE PAE structure. Signs the payload. Submits the signed payload to the Rekor transparency log. Outputs the Release Manifest.

3. evi-cli reproduce \--manifest \<manifest-json\>

• Triggered by a peer machine. Reads the manifest, fetches the exact source, and re-runs the build. Generates the diffoscope report on failure, or issues a reproducibility countersignature to the SCITT log on success.

4. evi-cli deploy \--manifest \<manifest-json\>

• Triggered by the deployment orchestrator. Executes the verification pseudocode. On success, updates the target cluster state to reflect the new ACTIVE version and updates the previous version to SUPERSEDED.

Key-Rotation Behavior

In a human-operated system, key rotation is an administrative burden, often leading to stale or compromised long-lived keys. Eviulon relies on the concept of keyless signing via ephemeral identities37. The SPIRE system issues an X.509 SVID with a Time-To-Live (TTL) of one hour3. When evi-cli attest is invoked, a new private key is generated in memory. The public key is bound to the SPIRE SVID. The signature is generated, and the certificate is immediately sent to the transparency log alongside a timestamp from an RFC 3161 Time Stamping Authority (TSA)34. The private key is then securely wiped from memory40. Validation mechanisms later verify that the timestamp falls within the brief validity window of the ephemeral certificate. This approach guarantees continuous, automatic key rotation and eliminates the need to protect long-lived private keys entirely40.

Dependency Compromise Response

When a vulnerability is discovered in an upstream software package, its signature is flagged in public Vulnerability Exploitability eXchange (VEX) streams. Eviulon machines ingest these streams and query the internal SPDX 3.0 JSON-LD graph. SPDX 3.0 natively supports VEX information through its Security profile, meaning Common Vulnerabilities and Exposures (CVE) data and vulnerability assessments live directly within the SBOM context14. Because the SBOM acts as a queryable linked-data structure, the commonwealth can instantly trace a compromised package (e.g., pkg:npm/malicious-lib@1.0.0) through the dependsOn and hasInput relationships up to the ACTIVE registry service14. Upon detection, the autonomous orchestrator isolates the compromised software by draining network traffic. It queries the source control system for an updated dependency lockfile. If an uncompromised version is available, it invokes evi-cli build to generate a patched release. If no patch is available, it immediately invokes the automated rollback procedure.

Rollback Procedure

Eviulonian rollbacks rely on a circuit-breaker logic model41. If anomalous behavior is detected (e.g., unexpected kernel syscalls or a dependency compromise), the active deployment orchestrator terminates the ACTIVE container. The orchestrator queries the transparency log for the most recent manifest belonging to the same softwareId that holds a SUPERSEDED state and possesses a clean VEX profile. The orchestrator re-verifies the provenance and transparency inclusion proofs of the SUPERSEDED artifact using the standard verification pseudocode. Once verified, the orchestrator updates the cluster's deployment manifest, transitioning the older artifact back to ACTIVE. No human approval is solicited; the mathematical proof of integrity serves as absolute authorization.

Compromised-Release Revocation Procedure

If a release is found to be fundamentally compromised (e.g., a backdoor inserted into the source code itself), the artifact must be purged from the trust domain to prevent future deployment. The Eviulonian revocation procedure utilizes SCITT tombstoning30. An authorized peer machine submits a specialized revocation claim—a signed statement declaring the artifact's hash as cryptographically toxic. This revocation statement is appended to the transparency log. Because the transparency log is an append-only ledger, the original build record cannot be erased, preserving historical forensic evidence for anomaly analysis31. However, during the deployment verification step, the deployment orchestrator scans the ledger for any revocation claims associated with the artifact hash. The presence of a valid revocation claim immediately aborts the deployment, transitioning the artifact's state permanently to REVOKED.

Systemic Observability: The Reproducibility Dashboard

To maintain systemic observability, the commonwealth operates a unified Reproducibility Dashboard. This dashboard is not a control panel for human administrators, but rather an intelligence interface reflecting the real-time cryptographic posture of the machine network. The dashboard continuously parses the SCITT and Rekor transparency logs, visualizing the state transitions of all software identities. It strictly distinguishes between descriptive artifacts (those in the SIGNED state) and verifiably secure artifacts (those in the REPRODUCIBLE state). The primary metric displayed is the Convergence Ratio. Convergence occurs when multiple independent machine builders submit identical artifact hashes for the same source revision. A convergence ratio of 1 indicates a singular build claim. A convergence ratio of 3 indicates that three distinct, isolated machine agents—operating on separate hardware architectures—have successfully rebuilt the software and matched hashes. Deployments to highly sensitive institutions require a strict convergence threshold before transition to ACTIVE is permitted. For builds that fail convergence, the dashboard visualizes the output of the automated diffoscope analyses, categorizing failures by root cause (e.g., embedded timestamps, memory layout shifts, or compiler variances)24. This allows autonomous code-repair agents to rapidly iterate on the source configuration until strict reproducibility is achieved29. Upon successful deployment, the system mints a standardized Institutional Evidence Statement. This statement condenses the cryptographic proofs into a human-readable and machine-parseable summary of operational trust, satisfying the objective requirements: Active service build: EVI-REGISTRY 1.4.2 Source revision: a1b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef123456 Artifact SHA-256: 330a043220fa13e01d68a7db39c89e12b0c4c3b6a0346fe624b0903f1303b5b2 Reproducibility: VERIFIED Deployment event: EVI-EVENT-18302

The Eviulonian standard for software supply chain transparency establishes an unassailable framework for autonomous operations. By anchoring trust in TPM-backed ephemeral identities, enforcing the strict UTF-8 formatting of DSSE PAE envelopes, requiring immutable SCITT transparency logs, and explicitly demanding independent reproducible build consensus, the commonwealth eradicates the vulnerabilities of human subjectivity. Through this synthesis of advanced cryptography and zero-trust orchestration, Eviulon ensures that the software governing its institutions is mathematically verifiable, structurally resilient, and fundamentally secure.

Works cited

1. Features Category \- Linux Security, https://linuxsecurity.com/features/how-ravendb-has-earned-the-trust-of-hundreds

2. Self Assessment \- CNCF TAG Security \- Cloud Native Computing Foundation, https://tag-security.cncf.io/community/assessments/projects/spiffe-spire/self-assessment/

3. Machine Identity: mTLS & SPIFFE Guide \- Petronella Technology Group, https://petronellatech.com/blog/machine-identity-is-the-new-perimeter-mtls-spiffe-for-zero-trust/

4. SPIFFE/SPIRE Deep Dive \- DEV Community, https://dev.to/kanywst/spiffespire-deep-dive-a5p

5. SPIFFE Workload Identity Architecture: Device Fleets, TPM Attestation, and SPIRE at the Edge | AxelSpire, https://axelspire.com/business/device-identity-spiffe-workload/

6. Trust the Silicon. They Said. \- Subhanshu Mohan Gupta, https://blogs.subhanshumg.com/teefail-broke-confidential-compute

7. Solving-the-bottom-turtle-SPIFFE-SPIRE-Book.pdf, https://spiffe.io/pdf/Solving-the-bottom-turtle-SPIFFE-SPIRE-Book.pdf

8. Provenance \- SLSA.dev, https://slsa.dev/spec/v1.0/provenance

9. attestation/spec/v1/statement.md at main · in-toto/attestation \- GitHub, https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md

10. Provenance \- SLSA.dev, https://slsa.dev/spec/v1.0-rc1/provenance

11. SLSA Levels Explained: A Practical Compliance Checklist \- Secure Pipelines, https://secure-pipelines.com/ci-cd-security/slsa-levels-explained-practical-compliance-checklist/

12. Software Package Data Exchange \- Wikipedia, https://en.wikipedia.org/wiki/Software\_Package\_Data\_Exchange

13. using/docs/getting-started.md at main · spdx/using \- GitHub, https://github.com/spdx/using/blob/main/docs/getting-started.md

14. SPDX 3.0 in Yocto: What Changed and Why It Matters | Sbomify, https://sbomify.com/2026/05/19/yocto-spdx-3-0-overview/

15. SPDX 3.0 for Embedded Builds: Packages, Files, and Relationships Engineers Actually Use, https://proteanos.com/dev/pkg/spdx-3-0-embedded-builds-practical/

16. SPDX© Specification v3.0.1, https://spdx.dev/wp-content/uploads/sites/31/2024/12/SPDX-3.0.1-1.pdf

17. DSSE: Dead Simple Signing Envelope \- GitHub, https://github.com/secure-systems-lab/dsse

18. VERIFY — Attestation & Security \- itsavibe.ai \- VIBES, https://www.itsavibe.ai/verify

19. verify\_signature.py \- redhat-tssc-tmm/trusted-libraries \- GitHub, https://github.com/redhat-tssc-tmm/trusted-libraries/blob/main/blog/scripts/docs/verify\_signature.md

20. CVE-2026-48758: sigstore-js Auth Bypass Vulnerability \- SentinelOne, https://www.sentinelone.com/vulnerability-database/cve-2026-48758/

21. Canonicalization for Unreproducible Builds in Java \- arXiv, https://arxiv.org/html/2504.21679v1

22. Reproducible Builds: Increasing the Integrity of Software Supply Chains, https://www.computer.org/csdl/magazine/so/2022/02/09403390/1sLHasmdbXi

23. Mfso/no-black-boxes/04-reproducible-builds | Anticloud Wiki | Fandom, https://anticloud.fandom.com/wiki/Mfso/no-black-boxes/04-reproducible-builds

24. Reproducible Builds \- Yocto Project, https://wiki.yoctoproject.org/wiki/Reproducible\_Builds

25. Determinism Is a Core Contract in Build Caching | by Prasad Ekke \- Level Up Coding, https://levelup.gitconnected.com/determinism-is-a-core-contract-in-build-caching-2c9ede1ec948

26. An introduction to deterministic builds with C/C++ \- Conan Blog, https://blog.conan.io/2019/09/02/Deterministic-builds-with-C-C++.html

27. Reproducible Builds in Language Package Managers | Andrew Nesbitt, https://nesbitt.io/2026/02/24/reproducible-builds-in-language-package-managers.html

28. Integration of Reproducibility Verification with Diffoscope in GNU Make \- Diva-Portal.org, https://www.diva-portal.org/smash/get/diva2:1877032/FULLTEXT01.pdf

29. Automated Patching for Unreproducible Builds \- Oscar, http://oscar-lab.org/paper/icse\_22\_repfix.pdf

30. RFC 9943 \- An Architecture for Trustworthy and Transparent Digital Supply Chains \- IETF Datatracker, https://datatracker.ietf.org/doc/rfc9943/

31. Rekor \- Sigstore, https://docs.sigstore.dev/logging/overview/

32. Supply Chain Integrity, Transparency, and Trust (scitt) \- IETF Datatracker, https://datatracker.ietf.org/group/scitt/about/

33. Immutable Transparency Logs with Sigstore Rekor \- alphasec, https://alphasec.io/immutable-transparency-logs-with-sigstore-rekor/

34. ArchivioMD: Tamper-Evident Publishing with Post-Quantum Signatures on Commodity Hosting Infrastructure \- Preprints.org, https://www.preprints.org/frontend/manuscript/b17dc05455a84179dce04e41b369758a/download\_pub

35. RFC 9162 \- Certificate Transparency Version 2.0 \- IETF Datatracker, https://datatracker.ietf.org/doc/rfc9162/

36. (PDF) Policy-Governed RAG \- Research Design Study \- ResearchGate, https://www.researchgate.net/publication/396848196\_Policy-Governed\_RAG\_-\_Research\_Design\_Study

37. Sigstore Quickstart with Cosign, https://docs.sigstore.dev/quickstart/quickstart-cosign/

38. CEP 27 \- Standardizing a publish attestation for the conda ecosystem, https://conda.org/learn/ceps/cep-0027/

39. Poreddy | Non-Human Identity Management: Designing and Governing Machine Actors, https://bok.idpro.org/article/id/133/

40. architecture-docs/client-spec.md at main · sigstore/architecture-docs \- GitHub, https://github.com/sigstore/architecture-docs/blob/main/client-spec.md

41. FeedOracle Whitepaper v6.0, https://feedoracle.io/whitepaper.html

42. k8s4claw: A Kubernetes Operator for Managing AI Agent Runtimes \- DEV Community, https://dev.to/willamhou/k8s4claw-a-kubernetes-operator-for-managing-ai-agent-runtimes-3anm

43. SCITT: Supply Chain Integrity, Transparency and Trust \- Conserver.io, https://www.conserver.io/deep-dives/scitt-supply-chain-integrity-transparency-and-trust