Compliance frameworks¶
Governance › Compliance shows how untrust's automated evidence lines up with the frameworks your auditors use. The Frameworks tab is computed from your organization's reports.
Any role can read compliance. It is organization-wide: restricting a member to projects does not narrow it.
These mappings cover the confidential-computing layer only. They support an auditor's assessment and never replace one, and control titles are short paraphrases, not the standards' wording.
Control-level frameworks¶
Each of these frameworks has a By control roll-up: every control, its status, and the checks that evidence it. Controls that are people or process controls are listed as outside untrust, so the roll-up shows the whole selection rather than only what untrust can see.
| Framework id | Name | Version | Controls | Mapped to checks | Outside untrust |
|---|---|---|---|---|---|
soc2-cc6-cc7 |
SOC 2 (2017 Trust Services Criteria): CC1, CC6, CC7 and CC8 | 2 | 15 | 8 | 7 |
nist-800-53-r5 |
NIST SP 800-53 Rev. 5, selected controls | 1 | 18 | 11 | 7 |
pci-dss-v4 |
PCI DSS 4.0, selected requirements | 1 | 16 | 8 | 8 |
cis-aws-v3 |
CIS AWS Foundations Benchmark v3.0.0, selected requirements | 1 | 11 | 6 | 5 |
untrust-tee-baseline-v1 |
untrust TEE hardening baseline | 1 | 9 | 9 | 0 |
SOC 2¶
| Mapped to checks | Outside untrust |
|---|---|
| CC6.1 Logical access security over protected information assets | CC6.2 User registration and authorization before access is granted |
| CC6.3 Role-based access and least privilege | CC6.4 Physical access to facilities and assets |
| CC6.6 Protection against threats from outside system boundaries | CC6.5 Disposal of protected information |
| CC6.7 Restricting the transmission and movement of information | CC7.3 Evaluating security events |
| CC6.8 Preventing or detecting unauthorized or malicious software | CC7.4 Responding to identified security incidents |
| CC7.1 Detection of configuration changes and vulnerabilities | CC7.5 Recovering from identified security incidents |
| CC7.2 Monitoring system components for anomalies | CC1.4 Commitment to attract, develop and retain competent people |
| CC8.1 Authorization and testing of changes to infrastructure and software |
NIST SP 800-53 Rev. 5¶
| Mapped to checks | Outside untrust |
|---|---|
| AC-4 Information flow is controlled | AT-2 Security awareness training |
| AC-6 Least privilege | CA-8 Penetration testing |
| AC-17 Remote access is controlled | CP-9 System backup |
| AU-2 Auditable events are logged | IA-2 Identification and authentication of people |
| CM-7 Least functionality | IR-4 Incident handling |
| SC-7 Boundary protection | PE-3 Physical access control |
| SC-8 Transmitted information is protected | RA-5 Vulnerability monitoring and scanning |
| SC-12 Cryptographic keys are established and managed | |
| SC-28 Information at rest is protected | |
| SI-2 Flaws are remediated (firmware and TCB currency) | |
| SI-7 Software, firmware and information integrity |
PCI DSS 4.0¶
| Mapped to checks | Outside untrust |
|---|---|
| 1.3.1 Inbound traffic to the cardholder data environment is limited | 3.2.1 Account data retention and disposal |
| 1.3.2 Outbound traffic from the cardholder data environment is limited | 5.2.1 Malware protection on system components |
| 2.2.4 Only necessary services and ports are enabled | 8.4.2 Multi-factor authentication into the cardholder data environment |
| 2.2.7 Non-console administrative access is protected | 9.2.1 Physical access to the cardholder data environment |
| 3.5.1 Stored data is unreadable at rest | 11.3.1 Internal vulnerability scans |
| 3.6.1 Keys that protect stored data are guarded against disclosure and misuse | 11.4.1 Penetration testing |
| 7.2.5 Application and system accounts hold only the privileges they need | 12.6.1 Security awareness programme |
| 10.2.1 Audit logs are enabled for system components | 12.10.1 Incident response plan |
CIS AWS Foundations Benchmark v3.0.0¶
| Mapped to checks | Outside untrust |
|---|---|
| 2.1.1 S3 buckets require TLS | 1.2 Security contact information is registered |
| 2.1.4 S3 public access is blocked | 1.5 MFA is enabled for the root user |
| 2.3.1 RDS storage is encrypted at rest | 1.8 The password policy requires long passwords |
| 2.3.3 RDS instances are not publicly accessible | 1.10 MFA is enabled for console users |
| 2.4.1 EFS file systems are encrypted at rest | 1.17 A support role exists for incident management |
| 5.6 EC2 instances require IMDSv2 |
untrust TEE hardening baseline¶
| Control | Title |
|---|---|
| TEE-1 | Debug and non-production modes are off |
| TEE-2 | Attestation evidence is cryptographically verified and fresh |
| TEE-3 | Measurements are pinned to an expected baseline |
| TEE-4 | Keys are released only to attested workloads |
| TEE-5 | Platform TCB and firmware are current |
| TEE-6 | The host cannot alter the launch configuration |
| TEE-7 | Secrets cannot leak through the host |
| TEE-8 | Workload images are signed and pinned |
| TEE-9 | Bootstrap and state inputs keep their integrity |
How a control's status is computed¶
untrust takes the newest live report of each deployment. Demo (simulated) and retired reports are left out, and only checks that apply to a deployment's platform count for it.
The rules are applied in order, so the first that matches wins:
- FAIL: any applicable mapped check fails on any deployment. An accepted-risk
exception does not change this; accepted failures are counted beside the FAIL as
accepted. - NOT ASSESSED: the control is outside untrust, no checks are mapped to it, no live deployment runs a platform its checks apply to, or an applicable check was skipped, errored or missing.
- PASS: every applicable mapped check passed on every deployment it applies to.
FAIL beats NOT ASSESSED, and NOT ASSESSED beats PASS. Unknown is never PASS.
Checks from the hardware verifier count only when your fleet's collectors filed them.
The same check in a host report you uploaded yourself reads as REPORTED and never counts
toward a pass, so a self-uploaded host report cannot make a hardware control pass.
For each control the roll-up lists:
- its checks, and the policies and stages those checks belong to;
- the deployments it covers;
- how many results passed;
- each failing result: deployment, check, severity and whether it is accepted;
- each result that was not assessed.
A framework's counts are PASS, FAIL and NOT ASSESSED. Outside untrust is part of the NOT ASSESSED count.
Export a roll-up¶
On a framework's By control view:
- Download JSON saves the full roll-up as
compliance-<id>-v<version>.json. - Print / PDF prints the roll-up, or saves it as a PDF.
The same roll-up is available from the API with an API key of any role:
# List the frameworks
untrust api get https://app.untrustsecurity.com/v1/organizations/<org>/compliance
# One framework's roll-up
untrust api get "https://app.untrustsecurity.com/v1/organizations/<org>/compliance?framework=soc2-cc6-cc7"
For a signed bundle of a framework's evidence over a time window, request an evidence pack.
Framework cards¶
Beside the control-level frameworks, the Frameworks tab shows cards that map checks to a framework's areas rather than to individual controls.
| Card | What it shows |
|---|---|
| CCC Threat Model | How many checks map to the Confidential Computing Consortium threat model's areas: attestation, key release, isolation from the host, and the supply chain. This is untrust's mapping. |
| COIN (enclave interface) | Attacks on an enclave's untrusted interface: Concurrency, Order, Inputs and Nested calls. untrust tests host-supplied inputs only; no check tests call order, concurrency or nesting, and the card says so. |
| CWE Top-25 & generic | How many of the CWE Top 25 weaknesses a build-scan class detects. The drawer lists each weakness's rank, whether build scan covers it and whether it was seen in your CI builds. |
| TEE overlay | The build-scan classes for attestation, key binding, debug, signing and host-input trust, and how many were seen in CI builds. |
| Runtime check catalog | How many checks returned PASS or FAIL in the newest report per platform. SKIP means an input or active mode was missing. |
CLARITY Act readiness¶
The CLARITY Act card opens a readiness view that maps custody and security obligations to the technical evidence untrust collects. Each row is computed from your live check results:
| Area | Obligation | Evidence |
|---|---|---|
| Custody | Customer-asset segregation and key isolation | Enclave isolation and live attestation |
| Custody | Qualified key management | Key release bound to a code measurement |
| Security | Source-code and build integrity | Bootstrap checks, image signing and the latest CI build gate |
| Operations | Operational resilience | Anti-rollback and restart hygiene |
| Recordkeeping | Audit trail and recordkeeping | Audit logging and bucket versioning |
| Disclosure | Attestation evidence and disclosure | Live scan reports on record |
Each row reads Evidenced, Partial, Gap or No evidence. A row is Partial when some of its checks fail and others pass, or when a deployment it applies to produced no evidence.
Not legal advice
The CLARITY Act view is a readiness mapping only, not legal advice or a certification. untrust evidences the technical TEE controls that support CLARITY Act custody and security obligations; qualified-custodian status is determined by your counsel and regulator.