From Stochastic Identity to Deterministic Intent: A Zero-Trust Architecture for Hostile Environments
In December 2020, the SolarWinds Sunburst attack exposed a catastrophic flaw in how we think about CI/CD security. The attackers (APT29) didn't breach source code directly—they compromised the build server itself. The malware silently swapped legitimate source files with backdoored versions, and the build system happily signed the malicious artifact with SolarWinds' own certificate. Eighteen thousand organizations downloaded what they believed was a trusted update.
The industry's response was predictable: more policies, more approvals, more compliance checkboxes. But I kept returning to a fundamental question that no amount of process could answer:
If a session token can deploy to production, and that token can be stolen, how do we actually know a human intended to deploy?
This question led me to build Attestia—a hardware-rooted zero-trust deployment architecture that shifts the root of trust from software identity (IAM sessions) to hardware intent (FIDO2 challenge-response on an air-gapped embedded device). The complete v1–v5 stack was implemented in approximately 80 working hours, and this article tells the story of that architecture.
The Problem: Authentication ≠ Intent
Modern CI/CD pipelines operate on what I call a "Stochastic Trust Model"—the assumption that possession of a session token is equivalent to conscious human intent. An engineer logs in at 9 AM, and that session remains valid until 5 PM. The system assumes continuous presence and control.
This assumption is catastrophically flawed.
Consider what happens in a standard deployment flow:
- An engineer provides a session token (via
git pushor SSO login) - The system verifies the identity holds the
DEPLOY_PRODrole - The system alters production state
This sequence verifies that credentials possess authority, but it utterly fails to verify that the human possesses intent at that specific moment. If malware compromises the credential-bearing device, the system functions "correctly" (permissions are valid) while failing catastrophically (the action was unauthorized by the human principal).
I call this the Intent-Verification Gap—and it's the attack surface that SolarWinds, Codecov, and countless other supply-chain attacks exploit.
The industry has been asking: "Who is this?"
Attestia asks: "Did this human physically, consciously initiate this specific deployment right now?"
The Dialectic: Process vs. Physics
Before diving into the architecture, it's worth understanding the philosophical tension that Attestia resolves.
The Prevailing Orthodoxy (Process-Based Security) argues that supply-chain integrity is maintained through layered "soft" controls: peer reviews, managerial sign-offs, cyber-insurance, and the social contract of employment. This philosophy views security as a "process problem" and accepts residual risk as the cost of operational velocity.
The Counter-Thesis (Physics-Based Security) argues that when the build system itself is the adversary, procedural checkpoints are bypassed. A compromised compiler doesn't respect a managerial sign-off. Therefore, security must be rooted in physics:
- Physical Presence: The deterministic requirement that a human must physically interact with a hardware token to close the circuit of authority
- Cryptographic Non-Repudiation: Asymmetric key cryptography generating mathematical proof of this interaction, computationally infeasible to forge without the physical device
Attestia is the synthesis. It accepts the reality of the "dirty environment"—where the laptop, network, and OS may be compromised—and establishes a Hardware Root of Trust that exists outside the compromised domain.
The Architecture: Five Evolutionary Versions
Attestia evolved through five architectural versions, each addressing vulnerabilities exposed by the previous iteration.
v1: The Cryptographic Intent (Cloud MVP)
The first version established the paradigm of action-level authorization. Rather than trusting a persistent session, every deployment requires a fresh cryptographic signature.
The core mechanism is WebAuthn (FIDO2). When a deployment is requested:
- The Attestia server generates a cryptographically random 32-byte nonce
- The browser invokes
navigator.credentials.get(), requiring physical touch of a YubiKey - The YubiKey's Secure Element signs the challenge using ECDSA P-256
- The server verifies the signature, confirms the nonce is fresh (anti-replay), and validates the TLS origin (anti-phishing)
Upon successful verification, Attestia issues a JWT with a 300-second TTL, binding the token to the specific commit hash being deployed.
The Critical Weakness: While v1 solved remote phishing (via WebAuthn's origin binding), it failed to address the compromised host vector. Both the request and approval occur on the same physical machine. A Trojan on the developer's laptop can modify the ClientDataJSON to point to a different commit hash before it reaches the YubiKey—while the browser UI still displays the expected commit. The developer touches the key believing they're signing a hotfix; in reality, they're cryptographically signing a backdoor.
This vulnerability—the shared trust domain—necessitated the physical isolation of v2.
v2: The Physical Sentinel (Isolation)
The foundational axiom of v2 is that any general-purpose computing device used for development must be treated as zero-trust territory. A standard developer workstation runs thousands of processes: browser extensions with broad permissions, background daemons (Zoom, Slack, updaters), and potentially supply-chain malware. In v1, cryptographic signing occurs on this "dirty host."
The Solution: Physical Trust Separation
To defeat this, we physically separate the requesting logic from the approving logic:
- Machine A (the laptop): Creates the deployment request. Explicitly untrusted.
- Machine B (the Sentinel): Displays the request and accepts the signature. Trusted.
The Physical Sentinel is a dedicated Raspberry Pi 4 running a minimal Linux kernel in single-process kiosk mode. SSH is disabled. TTY switching is disabled. The root OS partition is mounted read-only. The user cannot Alt-Tab. The YubiKey connects only to this device, never to the developer's laptop.
Figure 1: The Physical Sentinel architecture. The untrusted domain (laptop/cloud) cannot influence what the Sentinel displays or what the YubiKey signs.
The Approval Flow:
- Developer pushes code; CI/CD pipeline submits deployment request to Attestia API
- Physical Sentinel polls for pending requests via outbound HTTPS
- Sentinel displays deployment metadata (commit hash, repo, environment) on its own screen
- Developer physically walks to the Sentinel
- Developer reviews the information and touches the YubiKey connected to the Sentinel
- Sentinel performs WebAuthn challenge-response and forwards the signed attestation
- Attestia issues JWT; pipeline retrieves token and proceeds
The Security Gain: For an attack to succeed, the adversary must now compromise both the complex desktop environment and the stripped-down ARM64 firmware simultaneously. The cost of attack increases by an order of magnitude.
Deliberate Friction: Traditional UX design aims to reduce friction. Attestia v2 deliberately maximizes it. The engineer must stand up, walk to the Sentinel, plug in the key, and touch the sensor. This "protocol of friction" breaks the "click-through trance"—when an engineer is tired, they might reflexively approve a laptop popup, but they won't walk 15 feet to a dedicated terminal out of muscle memory.
The hardware bill of materials totals approximately $310: Raspberry Pi 4 ($75), 32GB microSD ($15), 21.5" monitor ($100), YubiKey 5 NFC ($50), mechanical keyboard ($40), power supply ($10), and passive cooling case ($20).
v3: Forensic Immutability (The Black Box)
Even the best preventive controls can be circumvented. The Codecov breach demonstrated this: attackers modified a Bash Uploader script to exfiltrate environment variables (including AWS keys) for three months before detection. The attack persisted because victims had no immutable record of what script version ran on which day.
Attestia v3 introduces the Forensic Black Box—a cloud-native WORM (Write-Once-Read-Many) architecture that guarantees no attack can happen in silence.
The Axiom: A log that can be deleted is a rumor. A log that cannot be deleted is evidence.
Implementation: Attestia leverages AWS S3 Object Lock in Compliance Mode—based on the WORM model derived from SEC Rule 17a-4(f) for financial record-keeping. In Compliance Mode, no user—not even the root account holder—can overwrite or delete an object during the retention period.
Every deployment event generates a JSON log entry. The Sentinel calculates the SHA-256 hash of the previous entry to create a hash chain (providing tamper evidence), then uploads the log with a Retain-Until-Date header set to T+7 years.
The Result: Even if an attacker gains full access to the company's infrastructure, wipes local logs, and modifies databases, the forensic record remains intact in the S3 bucket. The "blast radius" of any breach is bounded by the speed of forensic reconstruction—which v3 makes instantaneous.
v4: The Neural Sentinel (Contextual Awareness)
While v2 and v3 successfully introduced physical friction, we observed a secondary failure mode: Click-Through Syndrome.
When an engineer performs routine deployments 20 times a day, the act of walking to the Sentinel becomes muscle-memory reflex, devoid of critical thought. An attacker piggybacking on a routine workflow can slip a malicious payload past a bored engineer simply "going through the motions."
The v4 Axiom: Friction must be proportional to risk.
A minor CSS change should require minimal friction. A core database schema migration at 3 AM should require maximum friction.
The Neural Risk Engine: Attestia v4 introduces a heuristic analysis engine that evaluates deployment metadata and calculates a Risk Score (0-100) based on five vectors:
- Code Churn Velocity: High lines-of-code changes vs. low time-since-last-commit (ΔLOC/ΔT)
-
Dependency Depth: Modifications to
package.jsonorpom.xmlflag higher risk than application logic - Temporal Anomaly: Deployments outside the user's historical "active window" (e.g., 3 AM on Sunday)
- Author Reputation: Recent history of failed vs. successful builds
-
File Criticality: Modifications to "crown jewel" files (e.g.,
auth_provider.ts,firewall_rules.tf)
The Traffic Light Protocol:
- Green (0-30): Standard FIDO2 signature required
- Yellow (31-70): Forced diff review on Sentinel screen with 10-second read delay
- Red (71-100): Mandatory 5-minute cooling period; potential multi-party authorization
The Duress Protocol: A unique innovation of v4 acknowledges biological coercion (the "$5 Wrench Attack"). A cryptographic key is useless if the holder is physically forced to use it.
Attestia implements Plausible Compliance: if coerced, the engineer holds the spacebar while tapping the YubiKey. The system displays a standard "Deployment Approved" animation (satisfying the attacker), while the backend silently aborts the deployment and writes a cryptographically signed panic signal to the immutable ledger (v3), triggering an out-of-band emergency alert to security personnel.
No comparable feature exists in Sigstore, in-toto, SLSA, or any other CI/CD security framework I've surveyed.
v5: The Public Ledger (Decentralization)
SolarWinds proved that a digitally signed artifact is not necessarily safe. If the build server injects malware before signing, the signature merely validates the malware. Centralized authority is a single point of failure.
The Merkle Manifest Protocol: Instead of trusting the build server's output, we verify it against the developer's local state—the source of truth.
Before pushing code, the Attestia CLI calculates a Merkle Root Hash of the entire source tree on the developer's local workstation. This root hash is signed by the developer's YubiKey (Human_Signature).
When the Build Server produces an artifact:
- The Physical Sentinel requests the artifact from the build server
- The Sentinel requests the signed Merkle manifest from source control
- The Sentinel re-hashes the artifact's contents
-
Verification: If
Hash(Artifact) != Signed_Merkle_Root, the build server modified the code (injection attack detected). Deployment is rejected.
Figure 2: The Merkle manifest verification flow. If the artifact hash doesn't match the human-signed source hash, build-time injection is detected and the deployment is blocked.
The Public Anchor: While v3's S3 Object Lock provides centralized immutability, it's still owned by the AWS account holder. To achieve censorship resistance, v5 anchors the audit state to a public blockchain (Polygon, chosen for low gas fees and Ethereum L2 security).
We write only the root hash of the audit log epoch to the chain—no confidential data. This creates a checkpoint of truth in the public domain that no corporate actor can erase.
Threat Mitigation: How Attestia Addresses Real-World Attacks
The architecture was designed as a specific response to realized vulnerabilities, not theoretical concerns.
SolarWinds (Build System Compromise)
Attack Vector: Malware on build server swaps source files before compilation, then signs the malicious artifact.
Attestia Mitigation (v5): Merkle manifest compares Hash(Artifact) against Signed_Source_Hash. If they diverge, injection is proven and deployment blocked.
Codecov (Bash Uploader Attack)
Attack Vector: Modified script exfiltrates secrets; attack persists for months without detection.
Attestia Mitigation (v3): Every executed script's SHA-256 hash is logged to append-only S3. Forensic replay identifies exactly when the malicious variant ran.
Log4j (Dependency Nightmare)
Attack Vector: Panic deploys of patched-but-untested code introduce instability.
Attestia Mitigation (v4): Neural Sentinel detects "massive dependency update + high velocity" pattern, triggers Critical Risk score, forces mandatory cooling period.
Roaming Mantis (DNS/Router Compromise)
Attack Vector: DNS hijacking enables real-time credential harvesting, bypassing TOTP-based 2FA.
Attestia Mitigation (v2): FIDO2 origin binding at hardware level. YubiKey cryptographically binds signature to TLS origin. Origin mismatch = key refuses to sign. Attack is mathematically impossible.
The "$5 Wrench" (Physical Coercion)
Attack Vector: Adversary physically forces engineer to authorize deployment.
Attestia Mitigation (v4): Duress Protocol triggers covert abort + emergency alert while displaying fake success to satisfy attacker.
Attack Cost Escalation
A critical observation: Attestia's architecture systematically forces adversaries to escalate attack complexity and cost.
| Attestia Layer | Attack Now Requires | Cost Category |
|---|---|---|
| No Attestia | Stolen CI token or compromised dependency | Near-Zero (Remote) |
| + v1 (MVP) | + Stolen YubiKey + known PIN | Medium (Physical Theft) |
| + v2 (Sentinel) | + Compromise of isolated Raspberry Pi + physical presence at Sentinel | High (Multi-Device) |
| + v3 (Forensics) | + Ability to compromise remote append-only storage simultaneously | Very High (Multi-Site) |
| + v4 (Neural) | + Coercion of human operator who can silently trigger duress | Extreme (HUMINT) |
Without Attestia, a supply-chain attack can be executed remotely, silently, at near-zero marginal cost—the SolarWinds compromise required no physical presence and persisted for nine months before detection. With the full stack, an attacker needs nation-state resources and willingness to use physical force.
Comparative Analysis: Sigstore, in-toto, and SLSA
Attestia is not a replacement for existing frameworks—it's a governance layer that addresses gaps they leave unmitigated.
| Capability | Sigstore | in-toto | SLSA (L3/4) | Attestia (v5) |
|---|---|---|---|---|
| Per-Deployment Attestation | Yes | Yes | Yes | Yes (Mandatory) |
| Hardware-Backed Signing | Partial (Optional) | Partial (Optional) | Partial (L3+ Req) | Yes (Mandatory FIDO2) |
| Physical Isolation of Approval | No | No | No | Yes (Air-Gapped Sentinel) |
| Forensic Immutability | Yes (Rekor) | Partial | Partial | Yes (S3 + Hash Chain) |
| Contextual Risk Scoring | No | No | No | Yes (Neural Sentinel) |
| Duress Detection | No | No | No | Yes (Duress Protocol) |
| Phishing Resistance (Origin-Bound) | Partial (OIDC) | No | No | Yes (FIDO2) |
The Critical Differentiator: Sigstore, in-toto, and SLSA all operate on a shared trust assumption—the cryptographic signing operation occurs within the same execution environment as the code being signed. Compromise of the host environment undermines the entire trust chain.
Attestia's Physical Sentinel introduces a trust domain boundary. This architectural choice has direct parallels in established security practice: Certificate Authorities maintain offline root signing ceremonies in physically secured rooms; financial trading systems separate order entry from order confirmation across independent terminals; nuclear launch systems require geographically separated key-turn operators.
In a production deployment, Attestia can wrap Sigstore: the Physical Sentinel uses a YubiKey to sign a Cosign blob via the isolated approval channel, producing a Sigstore-compatible artifact that's also backed by physical isolation guarantees Sigstore alone cannot provide.
Engineering Velocity: The 80-Hour Execution Window
The complete v1–v5 architecture was implemented in approximately 80 working hours (6.5 days).
| Phase | Duration | Output |
|---|---|---|
| v1 (Intent) | 12 Hours | WebAuthn L3 + JWT Token Signing |
| v2 (Sentinel) | 18 Hours | Raspberry Pi Kiosk + HAL + Hardware Integration |
| v3 (Forensics) | 14 Hours | S3 WORM + Hash Chain Logic |
| v4 (Neural) | 20 Hours | Risk Scoring Engine + Duress Implementation |
| v5 (Ledger) | 16 Hours | Merkle Manifests + Smart Contract Auditing |
Standard enterprise projects of this scope typically span 6–12 months. Attestia achieved this velocity not despite its security constraints, but because of them.
By focusing strictly on the physics of intent (FIDO2 + S3 Lock), we eliminated 90% of the features usually associated with IAM dashboards: user management, password resets, RBAC GUIs, self-service portals. This validates the hypothesis that constraint-driven engineering yields higher velocity than requirement-driven engineering.
Performance: The Security-Friction Trade-off
A common objection to human-in-the-loop approval is operational friction. The analytical latency model (based on published FIDO Alliance benchmarks and hardware specifications):
| Operation | Latency |
|---|---|
| Deployment request (CI → server) | 50-150 ms |
| Sentinel polling interval | 500-1000 ms |
| Sentinel fetch + render | 100-300 ms |
| WebAuthn challenge generation | 10-50 ms |
| YubiKey crypto operation | 200-500 ms |
| Verification + JWT issuance | 20-80 ms |
| Token delivery to CI/CD | 50-150 ms |
Total automated overhead: ~1.5-3.5 seconds per deployment in the Physical Sentinel configuration.
Given that typical CI/CD pipeline execution times range from 2-15 minutes (build, test, package, deploy), the attestation overhead represents less than 3% of total pipeline duration.
The trade-off is asymmetric in favor of security: seconds of additional latency eliminate entire categories of supply-chain attack vectors that have historically caused damages measured in tens of millions of dollars (SolarWinds: estimated $40M+ in direct costs; Codecov: affecting 29,000+ customers).
Future Horizons: v6-v10
The v1-v5 journey was about survival. The v6-v10 journey is about governance:
- v6 (Multi-Human Governance): M-of-N consensus requiring multiple independent approvers—"Two-Person Integrity" for code deployment
- v7 (Just-In-Time Authority): Temporary privilege elevation with automatic expiration, eliminating standing access
- v8 (Distributed Trust Nodes): Geographic distribution of Sentinels, preventing single-site compromise
- v9 (Cryptographic Authority Fragmentation): Threshold signatures where the private key never exists in reconstructed form—even memory-scraping attacks find only mathematical fragments
- v10 (The Attestia Control Plane): Standardization into an IETF RFC for the "Intent Verification Protocol," enabling native CI/CD provider support
Conclusion: From Identity to Intent
The modern DevSecOps landscape is obsessed with identity. Organizations spend millions on SSO, SCIM, and biometrics to answer: "Who is this?"
Attestia demonstrates that this is the wrong question.
In a world of compromised endpoints, stolen sessions, and coerced engineers, the identity of the actor is irrelevant if their intent cannot be proven.
- Identity is a state
- Intent is an action
Attestia moves the security boundary from the user to the act. It doesn't ask "Are you Alice?" It asks "Did Alice physically, consciously, and voluntarily initiate this specific deployment right now?"
By anchoring this question in the unforgeable properties of hardware cryptography and immutable physics, Attestia establishes a new standard for high-assurance deployment engineering—the biological circuit breaker in an increasingly autonomous digital world.
Resources & Deep Dive
The complete Technical Monograph (22 pages), including formal threat models, API specifications, hardware schematics, and incident logs, is available on Zenodo:
📄 Attestia: A Hardware-Rooted Zero-Trust Deployment Architecture for CI/CD Pipelines
This includes the full project folder with implementation details, security evaluation against OWASP CI/CD Top 10 and MITRE ATT&CK frameworks, and comparative analysis methodology.
link:https://doi.org/10.5281/zenodo.18450179
Get in Touch
I'm always interested in discussing supply-chain security, zero-trust architectures, and the intersection of hardware and software security. If you're working on similar problems, have questions about the implementation, or are interested in collaboration:
This is the first in a series of articles exploring Attestia in detail. Upcoming posts will dive deep into specific components: the Physical Sentinel hardware build, the Neural Risk Engine algorithms, the Duress Protocol implementation, and the Merkle Manifest verification system.
Author: Kalyan Tamarapalli
Date: February 2026
Tags: #security #devops #cicd #zerotrust #supplychain #cybersecurity #hardwaresecurity #fido2 #webauthn
Top comments (0)