Tical Framework: Trusted Build Pipeline

• Tical Framework is a trusted compilation pipeline that uses Intel SGX enclaves, file system shielding, and Git-based audit logs to secure CI/CD builds.
• It integrates secure TEEs with a Configuration & Attestation Service and GitFS to intercept syscalls and enforce tamper-proof, cryptographically chained commit histories.
• The framework balances security and performance through configurable logging granularity, achieving robust build integrity with moderate overhead in real-world CI/CD environments.

The Tical framework provides a trusted compilation pipeline that delivers integrity and confidentiality guarantees from source code ingestion to the final executable, operating robustly even under a fully compromised host operating system. Building on secure TEEs—specifically Intel SGX—with supplementary shielding for file system operations and cryptographically chained versioned audit logs, Tical enforces end-to-end provenance for CI/CD build processes. By leveraging enclave isolation, file system compartmentalization, and transparent Git-based commit histories, it prevents untrusted infrastructure from modifying build artifacts or introducing supply chain attacks, while imposing only moderate overhead under practical configurations (Krahn et al., 21 Nov 2025).

1. Architecture and System Components

Tical is interposed between conventional build pipelines (e.g., gcc, make, npm) and the untrusted host OS. Each build tool invocation is encapsulated within an SGX enclave using the SCONE TEE runtime, which relies on a modified musl-based libc to mediate all file and network syscalls.

Two principal components define the runtime ecosystem:

• Shielded build processes: Each compiler or tool runs inside an enclave, with all file and network operations intercepted and verified before access or exposure to the enclave memory space.
• Configuration & Attestation Service (CAS): An external, trusted service responsible for remote attestation of the enclave environment, management of secret provisioning (e.g., tokens, cryptographic keys, compiler binaries), and replay protection.

The SCONE-based file-system shield inside each enclave divides the filesystem into regions (e.g., /src, /build, /tmp). Each region is backed by a storage provider implementing either encryption, authenticated integrity, or GitFS-based versioning. All file modification syscalls (e.g., write(), close()) on shielded regions are intercepted and transformed into Git commits, with state changes buffered securely in-enclave until persistently committed.

2. Threat Model and Security Guarantees

Tical's model assumes a maximally privileged adversary, with the host OS, hypervisor, and all layers of management software compromised. Adversaries can tamper with syscalls, file content, or network traffic, but are presumed incapable of physical attacks on enclave RAM or subverting CPU hardware. The framework's security primitives rest on the following mechanisms:

• Enclave memory protection: MEE ensures that all enclave memory pages are encrypted and authenticated.
• SGX local and remote attestation: Binds enclave execution to verified measurements (MRENCLAVE), blocking the use of unauthorized code or configuration.
• TLS-secured enclave-to-CAS channels: Ensures that secrets, binaries, and tokens are only provisioned to correctly attested enclaves.
• Immutable audit log: All file modifications are hashed and versioned via GitFS, producing a Merkle-chain with checkpointed root hashes maintained at CAS.
• Cryptographic protection layers:
  • Authenticated regions (e.g., Git refs/logs) protected with HMAC or AES-GCM to detect unauthorized on-disk manipulation.
  • Encrypted+authenticated regions protected with AES-GCM.
  • In-enclave secure buffering enforces atomicity of commits, eliminating any window for unlogged modifications.

The outcome is that source code, intermediate artifacts, and binaries remain confidential and tamper-proof throughout the build lifecycle.

3. Implementation and CI/CD Integration

Tical is deployed on Intel SGX hardware (e.g., Xeon E3-1280 v6) with Ubuntu Linux and leverages the SCONE runtime to support standard developer tools (gcc, clang, make, node) without modification. All interaction with the build process is at the syscall level; binaries are unaltered, and build scripts require only minimal adjustment: mounting project directories under shielded paths and pointing environment variables (e.g., $CC) to the SCONE-wrapped compiler.

Key elements of the technical stack include:

• LIBGIT2 library: Integrated inside the enclave as a storage provider (GITFS-HANDLER), partitioning metadata into:
  • Region A: .git/refs and .git/logs under authenticated protection.
  • Region B: .git/objects with no direct cryptographic protection, trusting the hash chaining in Region A to detect tampering.
• Syscall mapping: Common syscalls are consolidated for more efficient interception (e.g., read/readv mapped to preadv, write/writev to pwritev).
• Logging modes:
  • Fine-grained: Every write triggers a git commit, maximizing accountability.
  • Coarse-grained: Commits only on operations such as close, sync, fork, or execve, reducing overhead at the cost of less granular history.

During a typical CI/CD workflow, source code is ingested and cloned into the enclave following CAS attestation. Compilation proceeds entirely on shielded file regions; object files and intermediate outputs are versioned and cryptographically chained by GITFS, with optional post-build steps such as upstream git push or packaging into containers.

4. Performance Evaluation

Evaluation involved both microbenchmarks (using IOZone filesystem tests) and macrobenchmarks (Linux kernel compilation).

Overhead Metrics

Configuration	Write Throughput	Relative Overhead	Notes
Fine-grained+encryption	0.2 MB/s	≈ 99.8%	Each write generates up to 8 disk accesses
Coarse-grained+integrity only	37 MB/s	≈ 50%	Commit grouping amortizes overhead
Coarse+enc. (“git push” off)	96 MB/s	≈ 4%	Disabling external commits improves speed
Native (kernel build)	1800 s	Baseline	No Tical protection
Integrity-only (coarse)	2020 s	12%	Tical with amortized logging
Enc.+Integrity (coarse)	2200 s	22%	Both confidentiality and integrity

Fine-grained logging creates prohibitive overhead for large builds due to Git’s heavy metadata I/O per commit, while the coarse-grained mode with in-memory buffering approaches native throughput with acceptable trade-offs.

Optimization and Bottlenecks

• Commit granularities: Fine-grained ensures maximal accountability but is not practical for typical CI workloads. Coarse-grained, especially with large file buffering, presents a feasible alternative.
• Enclave-induced overhead: SGX enclaves contribute roughly 5–10% additional latency for pure computation and syscall activity; the main performance penalty is attributed to Git metadata manipulation and versioning.
• Storage amplification: Builds with numerous small outputs (such as npm installs) incur additional overhead due to increased Git commit activity.

5. Security Analysis and Audit Logging

Tical’s immutable audit log is based on transparent, versioned, cryptographically chained Git commits. Every file read/write is intercepted and logged, forming an interlocking record where any tampering would be detectable by hash inconsistencies. Key security features include:

• In-enclave commit atomicity: Secure buffering prevents the OS from observing or modifying interim file states before commit completion.
• Merkle hash chaining: The chain of commit hashes anchors provable provenance and can be periodically checkpointed at CAS, providing replay and rollback resistance.
• Confidential artifact delivery: Final build outputs are delivered encrypted, with their hashes recorded in the log, ensuring that post-build modification would immediately invalidate the recorded chain.

6. Limitations, Trade-offs, and Future Directions

Current limitations include exclusive hardware support for Intel SGX with SCONE; cross-platform support (AMD SEV, TDX, ARM TrustZone) is identified as an area for future development, requiring reimplementation of the loading and shielding layers. Developers must also adopt a Git-based build environment, which may conflict with legacy scripts that depend on traditional file system semantics.

Key trade-offs involve:

• Logging granularity: Selection between extreme accountability (fine-grained, high overhead) and practical performance (coarse-grained).
• Git churn and storage amplification: Workloads with many small files may generate significant overhead due to Git’s data model.
• TEE overheads: The native performance impact of running toolchains inside enclaves is non-negligible but not prohibitive for most applications.

Future directions emphasize smarter commit policies (e.g., batching writes), distributed CAS deployments to strengthen rollback prevention, support for incremental or Merkle-based file system protections, and broader TEE integration to accommodate heterogeneous cloud infrastructure.

7. Summary of Impact

Tical demonstrates a practical approach to realizing trusted build pipelines, addressing a significant gap in application security by providing build-time confidentiality, integrity, and forensic auditability. It achieves these guarantees without code changes to compilers or build tools and with tunable overheads compatible with continuous integration pipelines, highlighting a feasible paradigm for trusted software supply chains in adversarial environments (Krahn et al., 21 Nov 2025).