Caution makes host, cloud account or pipeline compromise alone insufficient to expose protected data or substitute trusted software when isolation, verification and access controls are enforced together. Our provisional assessment identifies specific mitigations or consequence containment in 63 of 222 MITRE ATT&CK Enterprise technique categories (28.4%). This measures taxonomy coverage, not the percentage of real-world attacks prevented.
Table of contents
What does an attacker get from a compromised server?
Suppose you run an application that processes sensitive customer data. An attacker gets access to your cloud administrator account and replaces the application with their own version. Your customers still connect to the same domain, TLS works, and the deployment appears successful. But the software receiving their requests is now controlled by someone else.
If the attacker can also administer the underlying host, they may not even need to replace the application. In a conventional deployment, they can often inspect its memory and read the data it’s processing in plaintext. Disk encryption and TLS don’t protect that stage. Confidential compute protects data while it’s in use through hardware-enforced isolation and, on supporting platforms, memory encryption. The application still processes plaintext inside the protected boundary, but ordinary host access no longer exposes it.
Replacement is another route to the same data: malicious software can collect whatever customers submit and misuse any credentials it receives. That’s why Caution combines confidential compute with reproducible builds and verification, so clients and secret holders can reject software they haven’t approved.
We should be able to design systems where compromising a host or deployment account doesn’t automatically expose everything the application holds. To understand which attacks this addresses, we need to follow what the attacker can actually do.
How this works in Caution
Caution packages your application with EnclaveOS inside a hardware-backed trusted execution environment (TEE), which I’ll call an “enclave” here, including confidential VMs. Three pieces connect that isolation to software you can trust.
First, reproduce the software. Caution’s reproducible builds connect the deployed image to inspectable source, all the way through the operating system and StageX’s source-bootstrapped toolchain. That’s a key differentiator: you can independently establish what should be running, not just identify an opaque binary. Your application build must be deterministic too; our AI-agent skill helps you get it there.
Then, verify what’s running. Caution unifies attestation behind a common interface and client workflow, handling each supported backend’s specific checks. It authenticates fresh hardware-signed evidence and compares the software measurements with the expected values. This establishes software identity, not whether the source is safe.
Finally, make access depend on verification. In the Locksmith workflow, share holders check those independently reproduced measurements before sending encrypted secret shares to the enclave’s attested key. Enough shares unlock the application’s secrets inside the enclave; a mismatched image stays locked. For customer traffic, STEVE binds encrypted sessions to fresh attestation, keeping payloads unreadable to the host. Clients must check the expected measurements and refuse plaintext fallback, not just verify once at deployment.
The analysis assumes these controls work together on a backend providing the required isolation and attestation, with debug access disabled and trustworthy verification clients.
The compromised infrastructure must not also control the verification software, its accepted measurements or enough secret holders to authorize a replacement. For the stored-data mappings, encrypted secret files must be included in the approved measured image, and other protected data must be encrypted before reaching external storage, with decryption keys confined to the approved enclave. Still-valid plaintext copies in infrastructure-readable secret stores must be removed or rotated. These storage protections require application configuration; deploying an app in an enclave does not automatically establish them.
For databases, this can mean running the database and disk decryption inside the enclave, or storing encrypted values in an external database and decrypting them only inside the enclave. Network shares must likewise expose only ciphertext to surrounding infrastructure. Ordinary storage encryption is insufficient if a compromised database or file server can return plaintext; enclave and application access controls must also prevent unauthorized decryption requests.
For authentication-key mappings, the application must keep usable private or cookie-signing keys inside the enclave and authorize their use. Protecting a key does not help if the application will sign arbitrary attacker requests.
Which attacks does this address?
MITRE ATT&CK gives us a common language for describing what attackers do. It’s useful here because “protects against credential theft” is too vague. Preventing a host administrator from reading an enclave’s key doesn’t protect another copy left in a repository.
We assessed the full MITRE ATT&CK Enterprise inventory against Caution’s protected-workload setup. Our provisional assessment identifies specific mitigations or consequence containment in 63 of 222 parent technique categories, or 28.4%. This does not mean Caution protects every platform represented in ATT&CK. The table groups those mappings for readability; its rows are not the units used to calculate coverage.
The table describes how each control blocks an attack path or contains its consequences for protected data and workload authority. The attacker may still compromise surrounding infrastructure. All mappings assume the setup described in the previous section. Detecting a mismatch only becomes preventive when access is refused.
A credited category does not mean every way of carrying out that technique is prevented.
| ATT&CK techniques | What Caution can block or contain |
|---|---|
| Network interception and content injection (T1040, T1020.001, T1557, T1659) | Verified, encrypted sessions prevent infrastructure from reading protected payloads or substituting their endpoint or content. Interception and traffic mirroring can still occur; metadata remains visible. |
| Memory collection and credential theft (T1005, T1003.007, T1552.001, T1552.004, T1528, T1555.006) | Isolation and verified secret delivery deny host extraction of protected memory, keys and tokens. Replacing infrastructure-readable secret stores with Locksmith removes their plaintext retrieval path. Still-valid legacy copies and secrets exposed by the application remain outside this protection. |
| Process injection and credential hooks (T1055.008, T1055.009, T1055.014, T1056.004) | Host-side process inspection cannot directly inject code or install credential hooks inside the protected workload. Compromise within the enclave is a separate case. |
| Cookie forgery and authentication-key theft (T1606.001, T1649) | Enclave-confined cookie-signing and authentication private keys cannot be copied from the host to forge sessions or impersonate the workload. This requires strong cryptography and authorized key use. Stolen valid cookies, broken validation, certificate-enrollment abuse and application compromise remain outside this protection. |
| Software supply-chain and pipeline compromise (T1195.001, T1195.002, T1677) | Independent reproduction and verification reject unexpected outputs. StageX reduces reliance on opaque toolchain binaries. Malicious approved source can still reproduce, and CI credentials remain exposed. |
| Image implants, binary backdoors and launch hijacking (T1525, T1554, T1505.003, T1574.006, T1574.007) | Unauthorized changes to measured binaries, libraries or launch configuration cause protected access to be refused. A web shell installed through runtime exploitation need not change launch measurements. |
| Stored, transmitted and runtime data manipulation (T1565.001, T1565.002, T1565.003) | Changes to encrypted secret files in the approved image fail measurement checks; authenticated encryption rejects altered traffic; isolation prevents direct host memory writes. Mutable external data needs separate integrity and freshness checks. Application-level manipulation remains possible. |
| Malicious modules and tainted shared executables (T1129, T1080) | A replaced library or infected shared binary or script packaged into the deployment changes its measurements and is denied protected access. This does not cover unmeasured runtime modules, arbitrary documents or malicious source accepted as the baseline. Attestation is not continuous module-load enforcement. |
| Operator-induced malicious image deployment (T1204.003) | An operator may launch an attacker image, but independent clients and secret holders reject its unexpected measurement. The operator must not also control the trusted baseline or sufficient release authority. Execution and costs elsewhere remain possible; this is not general phishing prevention. |
| Workload masquerading (T1036.005) | A replacement using the legitimate resource name or location still fails independently pinned measurement checks. Matching a name does not grant secrets or trusted sessions. Generic malware concealment and post-launch application compromise are not covered. |
| Encrypted cloud-storage data (T1530) | An attacker can copy encrypted objects but cannot recover their plaintext when decryption keys are confined to the approved enclave. This requires encryption before storage. Plaintext copies, application compromise and unauthorized access through the application remain outside this protection. |
| Database collection (T1213.006) | Protected database storage remains unreadable when the database and disk decryption run inside the enclave, or an external database stores values decrypted only there. Queries that return plaintext, application compromise and plaintext exports remain outside this protection. |
| Network-share collection (T1039) | Reading a backing network share yields ciphertext when protected files are encrypted before storage and decrypted only inside the enclave. File-server disk encryption alone is insufficient if the share serves plaintext. Metadata, deletion and application-level access remain separate concerns. |
| Transfer to an attacker’s cloud account (T1537) | Cloud-native copies or shares can transfer protected encrypted objects and backups, but not their enclave-confined decryption authority. Disclosure is contained; the transfer itself is not blocked. Plaintext exports and access through a compromised application remain outside this protection. |
| Snapshot-based data access (T1578.001, T1578.002) | On the assessed backend, copying parent-host disks does not capture protected live enclave memory or reconstruct its secrets. External databases and plaintext exports require separate protection. |
| Container and cloud administration commands (T1609, T1651) | Ordinary infrastructure administration does not provide an execution channel inside the protected enclave. Commands can still affect the host, and application-exposed command interfaces remain dangerous. |
| Accounts, host authentication and remote administration (T1078.003, T1078.004, T1021.004, T1021.008, T1556.003) | Stolen infrastructure credentials or host-login backdoors do not themselves grant protected memory access or authorize replacement software. Application authorization and secret release must not trust compromised host authentication. Credentials passing through it remain exposed; infrastructure disruption remains possible. |
| Account creation and permission expansion (T1098, T1136.001, T1136.003) | Adding infrastructure accounts, credentials or roles does not confer independent workload or secret-release authority. Control of verification clients or sufficient secret holders remains outside this separation. |
| SSH session hijacking and external remote access (T1563.001, T1133) | Hijacking infrastructure SSH sessions or gaining access through a VPN or exposed administration API does not itself confer enclave memory access or secret-release authority. The access and lateral movement can succeed. Access into the protected application, verifier or secret-holder environment is excluded. |
| Exploitation of public-facing and remote infrastructure services (T1190, T1210) | Exploiting a service outside the protected workload can grant host or network access without granting enclave memory access or independent secret-release authority. The exploit and lateral movement can succeed. Exploitation of the protected application, guest, verifier or secret-holder environment, or defeat of the isolation boundary, is not covered. |
| Privilege escalation and permission changes (T1068, T1548.001, T1548.003, T1548.005, T1222.002) | Escalating host privileges or relaxing host file permissions does not cross the enclave boundary. Exploits inside the protected operating system or application remain separate risks. |
| Deployment tools and trusted third parties (T1072, T1199) | Compromised management tools or infrastructure providers cannot silently substitute a trusted workload when independent verification is enforced. A provider controlling trusted inputs or verification can bypass that separation. |
| Container deployment, persistence and escape (T1543.005, T1610, T1611, T1612) | Malicious containers, host-built images and escapes into surrounding infrastructure can leave the enclave boundary intact. An escape that defeats that boundary itself is not covered. |
| Host rootkits and kernel modules (T1014, T1547.006) | Host rootkits and malicious kernel modules can persist and hide activity, but their host privileges do not themselves expose protected enclave memory. Guest compromise or failure of the isolation boundary is not covered. This does not prevent installation or assume guest module loading is disabled. |
| Host service execution, startup and event-triggered persistence (T1053, T1037.004, T1543.002, T1569.003, T1546.004, T1546.017, T1546.018) | Scheduled jobs, RC scripts, systemd services, systemctl commands, shell configuration, udev rules and Python hooks can execute host code without gaining enclave memory access or trusted workload identity. Their execution is not prevented. Compromise of the guest, verifier or secret-holder environment remains outside this claim. |
| Malicious TLS trust anchors (T1553.004) | An installed TLS root may make attacker-controlled HTTPS appear trusted, but cannot itself satisfy STEVE’s separate attestation and measurement checks. This requires independently trusted measurements and attestation roots. Replacement of the client, its configuration or browser bootstrap code is not covered. |
| Compromised network equipment (T1600, T1601) | Weakening network-device encryption or modifying a router or gateway image does not itself expose or allow forgery of payloads inside independently verified STEVE sessions. Trusted clients and enclaves must refuse plaintext fallback. The equipment, unrelated traffic and availability remain unprotected. |
| Host shells, native APIs, reflective loading and IPC (T1059.004, T1106, T1620, T1559) | These mechanisms can execute attacker code on the surrounding host without granting enclave memory access or independent workload authority. Their execution is not prevented. Execution inside the guest, verifier or secret-holder environment, and application interfaces that permit sensitive operations, remain outside this protection. |
| Downgrade attacks (T1689) | Expected measurements and fail-closed transport reject unapproved images or plaintext fallback. Still-approved vulnerable images and application-state rollback need separate controls. |
These mappings use MITRE ATT&CK Enterprise v19.2. Coverage is counted once per parent technique category, even when several sub-techniques are listed. The mappings describe specific protected attack paths, not complete protection against every procedure within a category. They are Caution’s assessments, not MITRE ratings or endorsements.
Fresh attestation challenges also address evidence replay, which has no single attestation-specific ATT&CK technique. Application-transaction replay remains a separate concern.
Where the attack stops
Let’s return to the attacker who replaced your application. Their software can run in a genuine TEE and produce an authentic attestation. But its measurement differs from the approved image, so clients refuse to send protected data and secret holders refuse to release credentials. The hardware has accurately identified software you haven’t approved.
Forwarding fresh evidence from the original enclave doesn’t help them obtain its session key. They can relay ciphertext, but can’t decrypt that protected session themselves. Root access outside the TEE’s trusted boundary likewise doesn’t provide ordinary access to the application’s protected memory.
Of course, they could run the approved image, which would pass the measurement check. That’s why provisioning policy still has to decide which deployment gets access to which resources, and the application must check who is allowed to read data or request an operation.
You still have a compromised cloud account to deal with. The difference is that the attacker hasn’t automatically gained access to the sensitive data the application handles.
What this does not protect against
An application can have the expected measurement and still contain an exploitable bug. An exploit after startup need not change its launch measurements, and malicious source can reproduce perfectly. Code, configuration and model weights loaded later need their own integrity checks. Keeping data in an enclave won’t help if the application’s API exposes it to unauthorised users.
A fresh launch from the approved image removes nonpersistent runtime implants only if writable or restored state does not reintroduce them. It does not undo prior disclosure or prevent reinfection through an unchanged vulnerability. Once a compromised application obtains plaintext, isolation alone does not prevent it from collecting, packaging or sending that data out.
The client matters too: STEVE runs verification and encryption inside a service worker, separate from the page’s JavaScript context. A compromised page can still steal sensitive input before it reaches that worker, or read decrypted data returned for display.
An old vulnerable image can produce fresh evidence, so release policy must withdraw it. That doesn’t take back secrets already released; session limits, credential rotation and application replay protection remain necessary.
These controls do not prevent phishing, fix compromised endpoints, provide DDoS resistance or ransomware recovery, or establish protection against physical and side-channel attacks. The Caution threat model documents the remaining dependencies.
What the percentage measures
We assessed all 222 active parent techniques in MITRE ATT&CK Enterprise v19.2. The assessment credits 63 of 222, or 28.4%, for specific mitigations or consequence containment. Each parent is counted once, even when multiple sub-techniques or shared controls apply. No platform or tactic categories are excluded from the denominator.
We count a category when the assessed setup blocks a specified attack path or contains its consequences for protected data or workload authority, even if the attacker can still compromise surrounding infrastructure. Each parent category counts once; shared controls can support multiple categories. This is an architecture-based assessment, not an exploit-tested benchmark. The percentage describes the breadth of these mappings, not their effectiveness against every procedure or their frequency in real-world incidents. Uncredited categories indicate that this assessment establishes no qualifying protection, not that every possible deployment is vulnerable to them.
What matters for your system is whether a compromised host or deployment account gives the attacker access to the data and authority you’re trying to protect. Caution gives you mechanisms to break that connection.
If you’re looking to strengthen the security of your systems, talk to us.
